Qwen Code 0.21.12: require review evidence and stop autofix loops before they bloat a PR
Quick answer
Qwen Code 0.21.12 adds two complementary controls for AI review loops. First, a confirmed Critical from /review must carry an executed witness—observed probe output, a base-versus-PR result, a failing build or test, or an explicit reason why execution could not settle the claim. An unwitnessed review Critical is mechanically demoted to low confidence and stays off the pull request.
Second, Qwen's own repository autofix workflow now measures net source and test growth in each counting window. When either budget is exceeded, optional suggestions stop while Critical fixes continue; when an over-budget diff keeps failing to shrink across rounds, the workflow hands the decision to a maintainer instead of patching forever.
These controls live on different surfaces. The witness gate is part of Qwen Code's review pipeline. The growth variables and handoff logic are implemented in the Qwen repository's GitHub Actions autofix workflow, so treat them as an official reference pattern—not as universal CLI settings that every Qwen Code user already has.
Who this is for
This guide is for maintainers who use AI to review pull requests and then let another agent address the findings. It is especially useful when plausible false positives can block a merge, or when each autofix round adds guards and tests that create the next review round.
If your immediate problem is attributing a failing test to the PR or the baseline, start with the Qwen Code 0.21.3 test-plan evidence gate. This article addresses the next layer: which Critical claims may enter the merge channel, and when the repair loop must stop growing.
What changed—and where
| Control | Confirmed behavior | Boundary |
|---|---|---|
| Critical witness | A review-sourced Critical needs observed output or witness: not run —
|
A reason preserves an unrunnable claim; it is not proof that the claim is true |
| Mechanical holdback | High-confidence review Criticals without the witness field are demoted to low confidence and terminal-only | Deterministic build, test, and probe findings already originate from executed output |
| Growth brake | Qwen's autofix workflow compares net source and test growth with separate per-window budgets | This is repository workflow policy, not a global Qwen Code preference |
| Critical-only mode | Exceeding either growth budget defers non-Critical suggestions but preserves blockers and failed checks | It reduces optional churn; it cannot stop growth driven by Critical findings |
| Non-convergence handoff | Repeated over-budget, non-shrinking rounds produce a maintainer decision point | The agent must not decide a split, redesign, or risk acceptance by itself |
Qwen's workflow defaults both source and test growth budgets to 400 net lines and uses a default two-prior-round divergence threshold. Those numbers describe the official repository workflow. Copy the control model, then tune budgets from your own PR distribution rather than treating 400 as a universal safe limit.
Use two budgets, not one confidence score
An AI review loop needs both a claim admission budget and a change growth budget:
- Claim admission: no Critical reaches the PR unless an executed artifact supports it or the reviewer records why it could not be executed.
- Change growth: no repair window gets unlimited source and test expansion merely because every new patch can produce another plausible suggestion.
- Human authority: when Critical-only mode still does not converge, automation stops and presents choices to a maintainer.
This portable policy sketch is not a Qwen configuration file:
review_gate:
critical_requires: witness_or_not_run_reason
autofix_window:
source_net_growth_lines: 400
test_net_growth_lines: 400
on_budget_exceeded: critical_only
non_converging_prior_rounds: 2
on_non_converging: maintainer_handoff
A six-step rollout workflow
1. Pin the evidence identity
Record repository, merge-base SHA, head SHA, Qwen Code version, workflow run, model, and review effort. A witness from an older head cannot certify the new diff. This complements the event-driven CI finalizer: CI decides when evidence is complete, while the witness gate decides whether a Critical is supported.
2. Define accepted witness forms
Accept only artifacts that another maintainer can replay or inspect: exact command plus relevant output, a BASE/PR pair, a parser or renderer read-back, or a repository-wide impact sweep using an external oracle. Do not reimplement the code under test as the oracle. If a sweep reports hits, inspect at least one real hit before quoting the count.
3. Separate source and test growth
At the start of a repair window, record net insertions minus deletions against the merge base. Classify test files separately from product source and exclude only tightly named mechanical artifacts such as lockfiles or generated schemas. A single combined budget lets test growth consume the entire allowance and hides whether product complexity is still expanding.
4. Keep the first brake fail-safe
At the boundary, allow deletion and in-budget fixes. Once either budget is exceeded, stop optional suggestions but continue Critical findings, failed required checks, conflicts, and explicit maintainer instructions. Starting a new window merely to reset the baseline defeats the control.
5. Run seven canaries
Before unattended use, verify:
- A plausible Critical with no witness is held from the PR.
- A Critical with replayable observed output keeps its evidence in the artifact and posted comment.
- An explicit
not runreason remains visible without being mislabeled as measured proof. - Growth exactly at a budget does not trip an “exceeded” rule; growth above it does.
- Either source or test growth can engage Critical-only mode independently.
- An over-budget diff that is shrinking does not trigger a non-convergence handoff.
- Repeated over-budget, non-shrinking rounds stop with split, redesign, or accept-and-track options for a human.
6. Promote by repository class
Start with low-risk repositories and review-only mode. Then enable comment posting, followed by bounded autofix. Track unwitnessed Critical holdbacks, false-positive reversals, net source/test growth, rounds per accepted PR, and maintainer overrides. Promotion requires fewer unsupported blockers and bounded accepted change—not merely more agent activity.
Decision tree
Does a Critical have replayable observed evidence?
no -> is there a specific reason execution cannot settle it?
no -> hold it as low confidence; do not post
yes -> expose the limitation and require human review
yes -> post with head SHA and witness
Does autofix remain within both growth budgets?
yes -> continue the bounded window
no -> switch to Critical-only
is the diff shrinking?
yes -> continue cautiously
no, across the configured rounds -> stop for maintainer decision
Common mistakes
- Treating a code reading, model agreement, or copied PR description as an executed witness.
- Building a sweep oracle that repeats the same logic and therefore repeats the same bug.
- Calling 400 lines a Qwen product limit rather than the Qwen repository workflow's default.
- Counting only additions, so deletion and replacement behavior disappears.
- Combining source and test growth into one number.
- Letting Critical-only mode run forever when Critical fixes themselves drive the growth.
- Resetting a window without recording why the previous one failed to converge.
Copyable review-loop record
repository / base_sha / head_sha / qwen_version / workflow_run:
critical_id / claim / witness_command / observed_output / replay_result:
not_run_reason / human_owner:
window_id / baseline_source_net / baseline_test_net:
current_source_growth / current_test_growth / budget_result:
round / critical_count / suggestion_count / diff_shrinking:
decision: continue | critical-only | hold-finding | human-handoff
handoff_options / recommendation / maintainer_decision:
FAQ
Does Qwen Code 0.21.12 eliminate false-positive reviews?
No. It makes unsupported high-severity review claims easier to identify and hold back. A bad oracle, misleading fixture, stale SHA, or wrongly interpreted output can still produce a bad witness, so human review remains necessary.
Can I set the two growth variables in any Qwen Code project?
Not automatically. QWEN_AUTOFIX_GROWTH_BUDGET_SRC_LINES, QWEN_AUTOFIX_GROWTH_BUDGET_TEST_LINES, and the divergence setting belong to the Qwen repository's documented autofix workflow. Reuse the pattern only after implementing equivalent measurement, markers, and stop behavior in your own automation.
Why not let the agent split a non-converging PR itself?
A split changes product scope, review responsibility, and sometimes release risk. Automation can show the trajectory and propose options, but that authority belongs to a maintainer. This is the same evidence-before-completion principle used in the Qwen Goal verification checklist.
Top comments (0)