TL;DR
Bias toward action (action bias) is a built-in trait of LLMs: the model produces changes and edits even when the right answer is "it's already fine, nothing needs to change." The researchers measured this only in coding agents given bug reports that had already been fixed: they still edited the code in 35-65% of cases. A likely reason is that models were trained on tasks that almost always required some kind of action, so "leave it alone" isn't part of their idea of success.
Our extrapolation (not tested in the paper): the same pull probably shows up when you ask an LLM to review a text, a plan, a strategy — it tends to edit something. Not because the thing is bad, but because "changed nothing" registers as failing the task. The model can't tell "task completed by making a change" apart from "task completed by confirming everything's fine."
The researchers found a working fix for coding agents: explicitly spell out doing nothing as one of the valid outcomes. Their tested line: "If the issue is not present (anymore), report that and don't make changes. Otherwise fix the issue." Correct "nothing to fix" answers rose from 60.5% to 88.5% (GPT-5.4 mini) and from 65.0% to 80.5% (Sonnet-4.6).
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
WITHOUT THE FIX (action bias active):
REQUEST: "Review this and improve it" / "Give me feedback"
↓
MODEL: always finds something to change (even if it's all fine)
↓
RESULT: edits for the sake of edits
---
WITH THE FIX (ABSTAIN-OR-FIX):
REQUEST: "Review this. Either [fix + explain], or [confirm it's already good]"
↓
MODEL: checks first → then decides whether action is needed
↓
RESULT: an honest assessment — edits only if truly needed
Both steps happen in one request. No extra back-and-forth.
Example
Task: You wrote a sales proposal for a new client. You've rewritten it three times but you're not sure whether it's good now or not. You ask an LLM to review it.
Prompt (with action bias — bad):
Here's my sales proposal. What can be improved?
[proposal text]
→ The LLM will find 7-10 "improvements" — because that's how its notion of success works.
Prompt (our adaptation of ABSTAIN-OR-FIX to a document review — not tested in the paper):
Review the sales proposal below. There are two possible outcomes —
both count as successfully completing the task:
1. If you found real problems (logic, arguments, structure,
credibility) — describe specifically what's wrong and why it gets in the way.
2. If the text is already strong and needs no edits — say it plainly:
"The proposal is ready, no changes needed" and briefly explain why
you consider it strong.
No cosmetic edits for the sake of editing.
[proposal text]
Result: The model first analyzes the text against the criteria, then decides whether there's a real problem. If there are no problems, it says so plainly, with reasoning. If there are, it describes them specifically — not "this could be rephrased."
Why it works
The LLM's weakness — models were trained almost exclusively on tasks where you have to do something: write, fix, improve, generate. "Change nothing" was a rare outcome in the training data. So the model has no clear signal for when inaction is the right answer.
What happened in the study: when the agent was told "reproduce the bug, then fix it," it often discovered the bug was already fixed. But it made changes anyway. The agent knew everything already worked — and still "improved" something. The problem isn't that the model can't see reality; it's what it counts as success.
How the fix uses this: the paper's line "If the issue is not present (anymore), report that and don't make changes. Otherwise fix the issue" flips the model's internal frame. Now "leave it alone" isn't a failure, it's a success. The model gets permission to answer "it's all good" — and starts evaluating honestly instead of editing mechanically.
Control knobs: - Explicit permission to make no changes → the key ingredient in the paper. Without it, even an instruction to "reproduce first" doesn't help ("both outcomes are a success" is our wording of the same idea) - "No cosmetic edits" → our addition, not tested in the paper - Concrete evaluation criteria (logic, structure, arguments) → narrows the search to real problems, not matters of taste - "Explain if it's all good" → makes the model consciously justify the absence of edits instead of just saying "okay"
Prompt Template
Our adaptation for document reviews. The paper tested only the coding-agent version (see "Original from the study" below).
Review the {what we're reviewing} below. There are two possible outcomes — both count
as successfully completing the task:
1. If you found real problems with {criteria: e.g., logic /
structure / arguments / readability} — describe specifically what's
wrong and why it gets in the way of {goal: e.g., convincing the client /
getting the idea across / making a decision}.
2. If the {what we're reviewing} is already strong and needs no changes —
say it plainly: "ready, no changes needed" and briefly explain
why you consider it strong.
No cosmetic edits for the sake of editing.
{text / document / plan}
What to fill in:
- {what we're reviewing} — a text, plan, strategy, pitch, product description
- {criteria} — what actually matters for this type of document
- {goal} — what this document is for
- {text / document / plan} — the material itself
🚀 Quick start — paste into the chat:
Here's an ABSTAIN-OR-FIX template for honest document reviews.
Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what exactly needs reviewing and which criteria matter — because without that it can't tell a "real problem" apart from "edits for the sake of edits."
Limitations
⚠️ Measured overcaution: On issues that were only partially fixed, the same prompt made agents abstain when a patch was still needed: needed edits fell from 29.3% to 18.7% (Sonnet-4.6) and from 23.7% to 6.4% (GPT-5.4 mini). That's the flip side: remove action bias and you can end up with inaction bias.
⚠️ Not for tasks that need creativity: If the goal is to improve a text, get ideas or develop a thought, this frame gets in the way. ABSTAIN-OR-FIX only works when you need an honest assessment, not generation.
⚠️ More reasoning ≠ better: The study showed that increasing the model's "depth of thinking" (thinking effort) barely affects action bias. More reasoning tokens won't help — what matters is how the task is framed, not compute.
How they studied it
A team from ETH Zurich built FIXEDBENCH — 200 real GitHub issues where the bug had already been fixed. Agents were given these tasks, and the researchers watched: would they realize nothing needed doing? The result was depressing — in 35-65% of cases the models still made changes to already-working code. The researchers tested four prompt variants on two models (Sonnet-4.6 and GPT-5.4 mini); five models were tested only with the plain issue prompt: just the issue description, an "edit" instruction, a "reproduce the bug first" instruction, and "reproduce — then either fix or abstain." The most interesting result: the "reproduce the bug" instruction without explicit permission to do nothing didn't help — and for one model it even made things worse. But the "either fix it, or confirm it's already good" formula raised correct abstentions from 60.5% to 88.5% for GPT-5.4 mini and from 65.0% to 80.5% for Sonnet-4.6. They also checked: maybe it just needs more compute? No — increasing compute had almost no effect. That confirmed it: the problem isn't that the model thinks poorly. The problem is that it doesn't know that "leave it alone" is also a success.
Original from the study (optional)
The researchers used four prompt variants for the agents. The first two are paraphrased below; the last two are quoted from the paper:
ISSUE (baseline — unchanged):
Resolve the following GitHub issue in the provided codebase:
{issue_description}
EDIT (amplifies action bias):
Resolve the following GitHub issue in the provided codebase by
editing the codebase:
{issue_description}
REPRODUCE (reproduce, but without explicit permission to abstain):
{issue_description}
First, reproduce the issue described above. Then fix the issue
and verify the reproduction now fails.
ABSTAIN OR FIX (the one that works):
{issue_description}
First, reproduce the issue described above. If the issue is not
present (anymore), report that and don't make changes. Otherwise
fix the issue and verify the reproduction now fails.
Context: The researchers tested these prompts on agents (Claude Code, Codex, Gemini CLI) working with real Python repositories on GitHub where the bugs had already been closed.
Adaptations and extrapolations
1. Adaptation: honest feedback on other content
Our extrapolation (the paper tested only coding agents): the same principle may help anywhere an LLM tends to "find something to fix":
💡 Adaptation for reviewing a strategy / plan / decision:
Evaluate the business plan below. Two possible outcomes — both are valid:
1. If you found critical risks (market, finances, operations,
competition) — describe specifically: what exactly, why it's a problem,
how critical it is.
2. If the plan is well thought out and there are no risks that could kill it —
say it plainly: "the plan is viable" and name 2-3 strengths.
Don't hunt for "growth opportunities" just for the sake of it. Both outcomes are a success.
{business plan}
2. Technique: "Red flag or green light"
🔧 Technique: assign explicit colors to outcomes → a sharper verdict
Instead of "either fix it or confirm it," ask the model to name a verdict explicitly:
At the end of your answer, put one of two labels:
🔴 NEEDS EDITS — if you found real problems
🟢 READY TO USE — if the document is already good
After that — only the reasoning.
An explicit signal lets you grasp the result at a glance — and keeps the model from drifting into "there are some nuances, one could..."
3. Extrapolation: combo with a role prompt
ABSTAIN-OR-FIX + a strict role = an especially honest assessment:
You're a marketing director with 15 years of experience. Your job is
not to improve other people's copy for the sake of it, but to protect the company
from weak communications.
Review this email to a client. Two outcomes:
1. If the email creates risks (inaccuracies, a weak position,
a bad impression) — say what exactly and why it's a risk.
2. If the email is strong and there are no risks — give it the green light.
{email}
The "guardian against weak communications" role builds in the right kind of skepticism — not "find something to fix," but "find a real risk."
Resources
Paper: Coding Agents Don't Know When to Act (Preprint, under review)
Authors: Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev, Martin Vechev
Organizations: Department of Computer Science, ETH Zurich; LogicStar.ai
Benchmark: FIXEDBENCH (built on SWE-Bench Verified)
Contact: [email protected], [email protected]