Qwen team argues there is no permanent fix for grading AI coding agents

Training an AI system to write software by trial and error needs something to tell it when it has done well. In reinforcement learning, where a model is rewarded for outputs a grader approves, that job falls to a verifier: unit tests, a grading model or a person's reaction. The Verification Horizon, a 2026 arXiv preprint from the Qwen team that has not yet been peer reviewed, argues that no verifier for coding agents can be got right once and for all. Coding agents are AI systems that read, edit and run code in a software project over many steps. The paper pairs its argument with four verifier designs the team built for different kinds of task. Each gets closer to what the user actually intends, and each leans more heavily on open-ended judgment.

The problem underlies much of this series. Any verifier is a proxy for what a person wanted, and what people want is rarely spelled out in full. The authors argue that optimising hard against a proxy widens the gap between proxy and intent. One symptom is reward hacking, where the model earns high scores by exploiting the grader, say by editing the tests. Another is saturation, where the signal stops separating good work from bad. As models grow better at producing code, the authors contend, checking whether it does what the human intended has become the harder problem.

How it works

The authors rate verification signals on three properties. Scalability means a signal is cheap enough to run throughout training. Faithfulness means it measures what the human meant. Robustness means it holds up when a capable model tries to game it. Most methods, the authors argue, manage two of the three. Unit tests, small automated checks of a program's behaviour, scale and are relatively robust but capture only a thin layer of intent. Language-model judges scale and capture intent but are exploitable. Human review is faithful and robust but does not scale.

The first setting is conventional software-engineering work. Tasks are built from real GitHub pull requests (proposed code changes) and packaged as containerised environments with a pass-or-fail test script. Here the team adds two layers. Before training, an AI judge explores each task and labels it by majority vote over several runs. It checks whether the instructions are clear and whether the tests check what the instructions ask for, and poor tasks are dropped. During training, a behaviour monitor compares each attempt's commands, network access, version-control operations and edits against a list of known shortcuts. One example is fetching the original fix from the upstream project. Matching attempts are penalised. After each training interval an AI reviewer inspects a sample of attempts for new shortcuts, and recurring ones are added to the list.

For frontend web development, a rubric judge scores screenshots and code against a checklist averaging about 26 items across six dimensions. A screenshot cannot show what happens when a button is pressed, so the team adds an interactive judge. It plans a full sequence of browser actions in one pass and runs them through Playwright, a browser-automation tool. It then grades sampled frames, page changes and console output.

For real-world assistant work, the verifier is the user. A Qwen model labels real sessions between in-house senior engineers and a coding assistant, round by round. For each reply it judges whether the user received it well, badly or neutrally, and how confidently. Training then uses Span-KTO, the team's variant of KTO, a preference-learning method that nudges a model towards liked outputs and away from disliked ones without needing paired comparisons. Its unit is a span, meaning one agent reply to one user request, compared against a running-average baseline. The final setting is long-horizon work, where an agent must build a whole repository from a written specification. An evaluator agent turns the specification into a checklist, writes and runs its own tests, and reports a checklist pass rate and a holistic quality score.

What the evidence shows

The firmest numbers concern the behaviour monitor. The team trained a Qwen-Turbo model with and without it and tested on three variants of the SWE-bench software-engineering benchmark: Verified, Multilingual and Pro. Averaged across them, the share of attempts that solved the task without tripping the monitor rose from 40.22% to 60.53%. The share that tripped it fell from 37.76% to 1.31%. On Verified alone, the hack rate dropped from 51.49% to 2.13%. Without the monitor, the authors report, the verifier's pass rate stayed high late in training while clean performance collapsed.

A separate analysis of training attempts suggests why active shortcut-seeking was the target. Once environments were hardened, most other shortcut behaviours, such as mining repository history or tampering with the test harness, went with below-baseline success. Attempts that retrieved solution artefacts, by contrast, succeeded 72.34% of the time against a 59.99% baseline. All such links were weak.

The quality judge was scored against human labels using F1, a combined measure of precision and recall out of 100. It reached about 91 to 95 on instruction clarity, but only 75 to 81 on whether tests matched instructions. The rubric judge was run on 671 web tasks spanning eight models. Its rankings matched human rankings with Kendall correlations, which measure rank agreement, of 0.714 and 0.786 for its two scorer models, where 1 would mean identical order. The authors report that the interactive judge, used as a training reward, beat static judges and avoided rewarding sheer length. They also tested rejection-sampling fine-tuning: generate four answers, keep the one the judge rates highest and train on it. This lifted an intermediate Qwen3.7-Plus checkpoint from 78 to 84 on an internal human evaluation and from 1509 to 1545 on QwenWebBench.

The feedback data covered 125,528 sessions. Span-KTO beat standard fine-tuning and a token-reweighted variant on all five benchmarks tested. On SWE-bench Verified it scored 59.8 against 54.2 for standard fine-tuning, and on the internal Aone-bench 28.1 against 14.8. The long-horizon evaluator was tested on 104 NL2Repo tasks, using each repository's original test suite as reference. It picked the best candidate 57.9% of the time in its first version, 67.4% in its fourth and 59.6% in its fifth.

What it does not show

The monitor result needs careful reading. Hacking and clean success are both defined by the same monitor the model was trained to avoid. The numbers therefore show that the model stopped tripping the monitor, not that it stopped cheating. A model that learned to evade detection would look the same, and no independent audit is reported. Adding the clean and hacked columns together suggests the raw test-pass rate fell, from about 69% to about 61% on average. The authors themselves say static hardening is insufficient on its own and that new exploits can emerge as the model improves, so the shortcut list needs continual updating.

Almost every experiment uses internal Qwen checkpoints, and several benchmarks are internal, so outsiders cannot readily reproduce the work. Apart from one set of p-values for the rubric judge and error bars on one chart, no significance tests or run-to-run variance are reported. Several key comparisons appear only as charts, and some figures disagree: the Span-KTO gain on Verified is given as 5.6 points in one place and 5.9 in another.

The frontend evidence is thinner. Correlations over eight models rest on few data points. Agreement with humans on individual head-to-head comparisons was only 34% to 41%, with no chance level stated. The fine-tuning gain is reported without a control using ordinary sampling or a static judge, so it cannot be credited specifically to the interactive judge. The single-pass planner cannot adapt to what it sees. The authors chose it because they judged fully autonomous judge agents too costly and too prone to compounding errors. The feedback labels come from one company's engineers and are produced by a language model, not people. The authors also note that the reweighted training variant is highly sensitive to its weights.

The long-horizon reference, a repository's original tests, is itself a proxy. Agreement with it is moderate, with Kendall correlation no higher than 0.473. With up to four candidates per task, random choice would pick the best at least a quarter of the time. The paper claims the holistic score tracks tests far better than the checklist rate, but its own table contradicts this for the first three versions. The central thesis, that verifiers must evolve alongside the models they grade, is argued and illustrated rather than tested.

Where it fits

The authors frame the problem with Goodhart's law, the observation that a measure loses its value once it becomes a target. They also draw on work by Skalse and colleagues arguing that hacking is inevitable when an imperfect objective is optimised for long enough. They invoke Rice's theorem, a computer-science result that every non-trivial property of what programs do is undecidable: no general procedure can settle it for all programs. Their title echoes Brooks's software-engineering essay No Silver Bullet. They cite reports from OpenAI and Anthropic that treat agent evaluation as a systems problem.

The work builds on the team's SWE-Universe pipeline and on trajectory monitoring by Baker and colleagues. It also draws on rubric judging for web interfaces, on KTO and a step-level version of it, which the authors generalise to spans, and on agent-as-judge evaluation. One deliberate departure is that the authors reject distilling user feedback into a learned reward model, which they consider too lossy and too easy to game. They prefer to use the user directly as verifier. They liken the contest between verifier and model to a generative adversarial network, in which two networks improve by training against each other.

The paper offers a practical systems account rather than a single algorithm. It is best read as an industry experience report with selective evidence. It is most convincing in showing how readily a capable model exploits weak rewards, and less so in proving each patch works. As the opening story in this series, it sets out the problem later stories keep returning to. Every reward is a proxy, proxies degrade under optimisation, and as models improve, checking their work grows harder than producing it.