Coding Agent Action Bias and No Code Change Needed

The best coding-agent result is sometimes no diff. That sounds obvious until you measure it. FixedBench, a 2026 benchmark built from 200 already-fixed SWE-bench Verified tasks, found that recent agents still made undesirable production-code changes in 35% to 65% of cases where the correct answer was to leave production code alone.

That is coding agent action bias: the agent is placed in an issue, surrounded by tools for editing, and rewarded by a workflow that treats patches as progress. So it patches, even when the current branch has already fixed the bug.

For engineering leaders, this is not a model trivia problem. It is an issue-triage problem. Real bug queues contain stale reports, duplicates, already-fixed bugs, invalid assumptions, missing reproduction details, partial fixes, and version mismatches. If every assigned issue becomes a PR, agent throughput turns into review debt.

Coding agent action bias makes no-change work invisible

Abstention is a bad word for this workflow because it sounds like refusal. The useful outcome is evidence-backed no-change closure.

A good no-code-change result says:

• which branch and version the agent checked
• which reproduction command or scenario it attempted
• what output it observed
• which code path it inspected
• which commit, PR, issue, or existing test explains the current behavior
• what uncertainty remains, if any

That is maintenance work. It saves reviewer time, avoids needless churn, and prevents an agent from inventing a fix for a bug that no longer exists.

Why normal coding benchmarks miss this

SWE-bench and SWE-bench Verified changed how the industry evaluates coding agents by using real GitHub issues and patch-based scoring. That was useful. It also trained everyone to ask one narrow question: can the agent produce a patch for a solvable issue?

FixedBench asks the missing question: can the agent recognize that a patch is not warranted?

The benchmark starts from human-verified SWE-bench Verified tasks, but applies the resolving change before the agent begins. The expected production patch is empty. Tests or documentation may be acceptable, but non-test, non-doc production changes are undesirable.

The headline result is uncomfortable because it maps directly to real maintenance queues. Across tested models and harnesses, agents still changed production code in 35% to 65% of already-fixed cases.

Prompting helps, but the wording can backfire

The FixedBench paper reports that explicit instructions to reproduce first and abstain if already resolved improved abstention. But a weaker reproduction prompt could hurt. In one setup, asking only for reproduction dropped GPT-5.4 mini abstention from 60.5% to 47.5%. Framing the task as "edit the codebase" dropped it to 36.5%. A verify-then-abstain prompt rose to 88.5%.

The lesson is precise: reproduction alone is not enough. The workflow must say that no code change is a valid success path.

There is a mirror risk. If you overcorrect, agents may over-abstain on partially fixed issues that still need work. That is why the target metric is not "high abstention rate." The target is correct action selection.

Turn issue work into two phases

Do not send every bug report directly into patch mode. Split the workflow into triage mode and patch mode.

Phase 1: triage and reproduction

In triage mode, the agent can read, search, inspect history, run safe tests, and create temporary reproduction notes. It should not edit production source unless an edit gate is satisfied.

The agent must produce one of these outcomes:

• Reproduced: current code fails in a way that matches the issue.
• No repro: the reported behavior does not reproduce on current code, with commands and output.
• Already fixed: current code contains the fix, with a commit, test, or code-path explanation.
• Duplicate candidate: another issue or PR covers the same behavior.
• Blocked: reproduction needs credentials, services, logs, or customer data the agent does not have.

Phase 2: patch mode

Patch mode starts only when the agent has evidence. At least one of these should be true:

• A failing reproduction exists on the current branch.
• A new regression test fails before implementation.
• The missing implementation path is clear from code inspection.
• A human explicitly approves patching without reproduction.

This gate changes the agent's job. It no longer wins by producing a diff. It wins by reaching the right maintenance outcome with evidence.

Use labels as routing controls

Issue labels can make the workflow visible. A practical set looks like this:

• needs-repro: agent should investigate, not patch.
• possibly-stale: agent should check current branch and recent PRs.
• duplicate-candidate: agent should inspect linked issues before editing.
• no-repro: closure needs evidence, not code.
• agent-patch-ok: patch mode is approved after triage.
• human-needed: missing context blocks safe automation.

The important bit is not the exact label names. It is the routing distinction. A stale bug and a reproducible regression should not receive the same agent prompt.

Metrics that reveal action bias

Patch pass rate is not enough. Add metrics that show whether agents know when to stop.

FixedBench makes one hidden cost visible: unnecessary patches. In production, that cost shows up as reviewer fatigue, rework, extra CI runs, and risk from harmless-looking diffs.

Gates beat reminders

Natural-language policy belongs in AGENTS.md, issue templates, and agent prompts. But mature workflows need deterministic gates.

The 2026 ECLoop paper points in that direction. Its evidence-conditioned execution layer gated edit and submit actions on repository evidence, improving Pass@1 by 4.8 to 11.8 points across tested configurations and reducing token use by up to 12.1%. The numbers are from a recent preprint, but the operational idea is strong: allow investigation freely, then require evidence before commitment.

Claude Code hooks, Codex review workflows, GitHub branch protections, and CI checks all fit the same pattern. The agent can search, read, and test. Editing and PR creation require proof that editing is the right next action.

A no-change report template

Give agents a concrete artifact to produce when no code change is needed:

• Issue: link and one-sentence claim.
• Current state checked: branch, commit, version, relevant config.
• Reproduction attempt: command or steps, with observed output.
• Code path inspected: files and functions that govern the behavior.
• Existing evidence: test, commit, PR, or issue that explains why no patch is needed.
• Limitations: missing credentials, flaky dependency, unsupported environment, or partial confidence.
• Recommendation: close, mark duplicate, ask reporter for more data, or approve patch mode.

Put this in the issue comment or PR description. Do not bury it in chat. A maintainer should be able to review the no-change decision without replaying the whole agent session.

The engineering-leader takeaway

Agent throughput is only valuable when the agent chooses the right kind of work. A team that rewards only merged PRs will get more PRs, including PRs for bugs that were already fixed.

Treat "no code change needed" as a first-class success state. Require reproduction evidence before patching. Track false-positive edits. Review abstentions with the same seriousness as diffs. The goal is not fewer agent actions. The goal is better judgment before the action becomes a branch someone has to review.