Get Started
Home
Topics
Search
Library
Agents · Code Generation · Jun 26, 2026

Dockerless: Environment-Free Program Verifier for Coding Agents

Source: research paper via Hugging Face Daily Papers
Training a coding agent on repos you can’t containerize? Skip Docker: a verifier that greps the codebase for evidence about a candidate patch delivers RL rewards within 0.4 points of oracle test execution on SWE-bench Verified, beating diff-only LLM judges by 14 AUC.
TL;DR
Dockerless replaces per-repo Docker test execution with a verifier agent that greps the codebase for evidence about a candidate patch, closing the gap to real test-execution rewards to within ~0.4 points on SWE-bench Verified.
Why It Matters
You’re training a coding agent and want to reward it when its patches actually fix issues. The standard move: build a Docker image per repo, pin dependencies, run the hidden test suite, and use pass/fail as the SFT filter and RL reward. That works on curated benchmarks. It falls apart on private, enterprise, or legacy repos where nobody has a clean reproducible environment or a trustworthy test suite.
The dominant alternative today is a trained LLM verifier that reads the diff and scores it from surface text alone. Prior open-source verifiers like DeepSWE Verifier never touch the repository at scoring time. That’s the gap this paper argues is the real bottleneck once you accept that env-free rollouts are already viable.
How It Works
Give the verifier the issue, a reference patch, and the candidate patch, and let it act like a code reviewer: form questions, go read the repo, then decide. Concretely, a first stage generates 2–4 verification questions (where should the fix land, what should it do, what would break, what tests would confirm). Each question is handed to a parallel sub-agent that runs read-only shell tools (find, grep, rg) in a minimal Linux image and returns a short evidence-backed answer.
A judge stage then conditions on the issue, both patches, and all question/answer pairs, and emits a single verdict token. The score is the softmax between the “1” and “0” logits at that position, so you get a continuous [0,1] number instead of just a bit. One Qwen3.5-9B backbone plays all three roles (question generation, sub-agent exploration, judging) and is trained via Rejection-sampling fine-tuning (RFT) on 3.7K execution-labeled issues: a teacher model (GLM-5) generates full trajectories, and only trajectories whose final verdict matches the ground-truth test outcome are kept.
def dockerless_score(issue, ref_patch, cand_patch, repo): questions = generate_questions(issue, ref_patch) # 2-4 diagnostic Qs answers = parallel_map( lambda q: subagent_explore(q, repo, tools=["find","grep","rg"]), questions, ) logits = judge(issue, ref_patch, cand_patch, list(zip(questions, answers))) return softmax(logits)[1] # P(patch is correct)
That score then does double duty downstream: filter the top-K rollouts for SFT, and serve as the per-rollout reward for Group Relative Policy Optimization (GRPO) during RL. No Docker anywhere in the loop.
Core Insight
The prevailing environment-free verifier reads the diff cold and scores it from surface text, on the assumption that a strong enough LLM can judge correctness from the patch alone. This paper shows the opposite. A verifier that spends a few seconds actually grepping the repo for evidence about where the fix lands and what it touches beats both frontier zero-shot judges and larger trained critics, and it does so well enough to replace test execution as an RL reward. The load-bearing evidence is not the headline resolve rate but the RL ablation that swaps only the reward source and lands within half a point of oracle test execution.
What They Found
•
The mechanism-isolating result: on SWE-bench Verified, RL using Dockerless as reward reaches 62.0% vs 62.4% for RL with real per-repo test execution as reward, and beats RL with the DeepSWE Verifier reward by +1.4, +2.7, +1.1 points across Verified, Multilingual, and Pro. Reward quality, not test execution itself, was doing most of the work.
•
As a standalone verifier, Dockerless hits 81.0 AUC on the Verified split of the trajectory benchmark, +14.3 AUC over the best trained open-source verifier and +5.1 over the strongest frontier zero-shot judge (GPT-5.4).
•
SFT filtering: training on the top 4K of 16K env-free rollouts selected by Dockerless matches SFT on 4K env-based rollouts (60.6 vs 60.0 on Verified, 47.7 vs 48.3 on Multilingual, 35.3 vs 33.9 on Pro). Training on the full unfiltered 16K pool actually underperforms the base model, so the filter is doing real work.
•
End-to-end, the fully env-free pipeline produces a 9B model at 62.0 / 50.0 / 35.2 resolve rate on Verified / Multilingual / Pro, +2.4 / +8.7 / +2.9 over the Qwen3.5-9B base.
•
Ablation on question count K: AUC climbs from 78.3 (K=0, no exploration) to 81.0 at K=4, then plateaus; more questions add noise.
•
Latency: agentic verification adds 41–180 s per rollout, only 7.2% of total per-rollout wall time, because agent rollouts themselves dominate at ~2308 s.
•
Per-language caveat: env-based SFT still wins by +7 to +13 points on Rust and C, which the authors attribute to compiler diagnostics only being visible inside per-repo environments.
What’s Useful
Reach for this when you’re post-training a code agent on a corpus that includes repos you can’t reliably containerize: internal monorepos, legacy Python 2 packages, ML research code with broken setup.py. Instead of dropping those repos from training, you collect rollouts in a plain Ubuntu image and use an agentic verifier to filter SFT trajectories and reward RL rollouts. The recipe survives even when a fraction of the pool has no working test runner at all, because the verifier’s signal comes from repo exploration rather than test execution.
The paper doesn’t link a code release in the provided text. What is concretely reusable is the recipe: a Qwen-scale backbone, teacher-generated question-answer-judge trajectories from SWE-Gym and Multi-SWE-RL (3.7K issues) rejection-sampled against execution labels, 2–4 questions per scoring call, softmax over 0/1 verdict logits for a dense reward, and Group Relative Policy Optimization (GRPO) on top of the SFT model. The verifier evaluation benchmark itself (776 balanced trajectory-level samples split across SWE-bench Verified and Multi-SWE-bench Flash) is a useful artifact for anyone building their own reward model.
Takeaway
When you can’t run the tests, don’t ask an LLM to guess from the diff. Let it read the repo. Grounded evidence from a few targeted grep-and-read sub-agents is enough signal to replace oracle test execution as an RL reward, which is the piece that unblocks post-training on repos nobody has containerized.
Caveats
•
The mechanism assumes a reference patch is available at verifier time (both for question generation and for the judge). This fits SFT filtering and RL on labeled issue datasets, but doesn’t directly transfer to production inference where you only have a candidate.
•
Compilation-heavy languages (Rust, C) still lose 7–13 points to env-based training. The authors credit compiler diagnostics, which env-free rollouts never see. For a Rust-heavy codebase, this pipeline is not yet a full replacement.
•
All results are at the 9B scale with a single backbone shared across question generation, exploration, and judging. Whether the verifier’s AUC advantage over frontier judges holds when the base model itself is a frontier model isn’t tested here.
Topics
Don't miss new content
Log in to follow topics and personalize your feed.
By content type
Research Paper171 episodes
AI171 episodes