The Interrupt Is the Work
There are two ways to work with a coding agent, and I’ve done both long enough to feel the difference in my hands.
The first is to hand over a task and let it run. Describe what you want, let it plan, let it build, let it loop until it announces it’s done. The second starts the same way and then cuts in — stop it a few turns in, break the thing into smaller pieces, ask what it thinks the hard part is, argue with the answer, and only then let it write.
The gap between those two isn’t small. It’s a different category of result.
That claim would have been easy to dismiss two years ago as someone not trusting the tools. But the models have genuinely gotten much better, the harnesses have gotten much better, and the gap is still there. That’s the part I want to explain.
You probably disagree, and for your projects you’re right
I know how this sounds to someone who mostly builds side projects, because I am that someone on weekends. I loop. I give a simple requirement, let the agent run the whole way, and the result is fine. For a while I took that as evidence that the model and the harness were now smart enough end to end, and that anyone still hovering was just slow to let go.
Then I’d go to work on Monday and the same habit would produce something I had to throw away.
I don’t think that’s a contradiction anymore, and I don’t think the loopers are wrong about their own experience. Stanford’s Yegor Denisov-Blanch has been measuring this across 100,000+ developers at 600+ companies using private repos, scoring functionality delivered rather than commits. The average gain lands around 15–20%, but the average hides the whole story. Split it by what you’re actually doing:
- Low-complexity greenfield: ~30–35%
- High-complexity greenfield: ~10–15%
- Low-complexity brownfield: ~15–20%
- High-complexity brownfield: ~5–10%
A weekend project is the top-left cell. My job is the bottom-right. That’s a 3–6x spread between two people who are both using the same tool, both being honest, and both generalizing from their own cell of the table. And the 15–20% average is net of rework — the cost of fixing what the AI introduced is already inside the number.
So when someone tells me looping works fine, my answer isn’t “you’re wrong.” It’s: your project isn’t charging you for it yet.
The mechanism is scope, not capability
Here’s what I actually see when I let an agent run unattended. It doesn’t fail. It over-builds. It reaches for an abstraction nobody asked for, plans a feature two sizes larger than the one I described, adds a cache with no measurement behind it, and introduces a config surface for a case that will never occur. Every individual decision is defensible. The sum is a system I didn’t want to own.
That turns out to be measurable. A July 2026 study from HKUST gave agents underspecified but realistic instructions and counted what they did beyond the stated boundary. The OverScope rate — acting past the necessary scope — was 24.9% to 44.4% depending on the model and harness. Between 55.8% and 67.8% of runs that took action violated at least one boundary. Safe Success, meaning the right action on the right target, was only 15.5% to 36.8%. The agents weren’t refusing ambiguous work. They were guessing, then acting on the guess.
The bloat shows up in the diffs too. A position paper from CMU, Stanford, Princeton and UIUC found agent patches consistently longer than human reference solutions, with more than 15% of patches exceeding a 1.5x bloat ratio across every model tested — and, the part that matters, this persists despite high task success rates. The benchmark says the agent succeeded. The diff says it wrote twice what the job needed.
And the volume itself is the problem. A Concordia study analyzing code and architectural smells across LLM and multi-agent generation found lines of code correlating with architectural smells at ρ=0.94 — they call it the Volume–Quality Inverse Law, and at that correlation, volume is close to a perfect predictor of architectural decay. Their second finding is worse: more capable models produced more bloated and coupled code, not less. They call that the Reasoning–Complexity Paradox. Long Method instances ran 11–13 for the strongest model against a human baseline of 1. Few-shot prompting didn’t fix it — the smells “remained stagnant or even worsened.”
That last detail is the one I’d underline. If better prompting fixed over-engineering, this essay would be a prompt template instead. It doesn’t.
None of this is exotic. Erik Doernenburg at Thoughtworks wrote up a small, ordinary case in January: adding GitLab support to a Mac CI app. The agent proposed a cache nobody needed, built elaborate logic for a problem that didn’t exist, and duplicated URL construction instead of reusing the function already sitting there. His conclusion matches mine exactly: “This is a clear example where an AI agent left to their own would have changed the codebase for the worse, and it took a developer with experience to notice the issue.”
The agent will not stop for you
This is the finding that reorganized how I think about it.
SWE-chat, out of Stanford and NYU, is a dataset of 6,000 real coding sessions from open-source developers — 63,000 user prompts, 355,000 agent tool calls. Not a benchmark. Telemetry from people doing their actual work.
Two numbers sit next to each other in it:
Agents stop to ask a clarifying question in 1.4% of turns. Users push back in 44% of turns — 39% as corrections after the agent finishes, plus 3.3–6% as hard interrupts mid-run.
And the cost of that asymmetry: only 44% of agent-produced code survives into the user’s commits. More than half of everything these agents wrote was discarded.
The authors read it the way I do — agents are gaining autonomy faster than they’re learning when to ask for guidance, so the user absorbs the difference. The agent has one setting, and it’s proceed. If the specification is thin, it fills the gap silently and keeps going. The only thing standing between a thin spec and a large confident diff is you, deciding to break in.
That’s why I’ve stopped thinking of interruption as friction in the workflow. It’s the only point in the loop where the scope actually gets set.
What cutting in buys you
The interesting thing is how cheap the intervention is relative to its effect.
Just adding a clarification step — having the model identify what’s ambiguous and ask before generating — moved GPT-4’s pass@1 from 70.96% to 80.80% on MBPP-sanitized in the ClarifyGPT work. Ten points, from asking first. The problem is that models don’t do this on their own: ClarifyCodeBench finds current LLMs still struggle to spot what’s missing and ask good questions about it. Which puts the questions back on you, and makes the quality of your questions a load-bearing part of the output.
Decomposition pays similarly. An IBM team restructured agentic coding work from monolithic prompts into small subtasks with validated outputs between them and cut retry cost by up to 51.7%. Half the wasted work, from the thing I do by hand when I stop the agent and say “no, do just this part first.”
And CentaurEval ran the comparison directly with 45 expert developers: fully autonomous AI passed 0.67% of tasks, humans alone 18.89%, humans and AI together 31.11% — while finishing faster than either. I’d hold that one loosely, since the tasks were deliberately built to require collaboration, so the size of the gap is a property of the benchmark. But the direction is the same one everything else points in.
The part I can’t make clean
Here’s what I haven’t solved, and I’d rather say it than pretend I have a system.
Steering well is expensive. Breaking a task into small steps genuinely helps, especially early — but then I have to review the breakdown, and that’s real work. Reading a plan carefully enough to catch a scope problem takes almost as much understanding as writing the plan myself. Multiply by every task, and hours go into it. I haven’t found a neat, repeatable way to align with an agent quickly, and I’ve been looking for a while.
What’s kept me from treating that as a failure is that the field hasn’t solved it either. The CMU/Stanford position paper’s whole argument is that coding-agent research converged on maximizing autonomy and left steerability, verification, and task alignment largely unbuilt. The HKUST study makes it concrete: the same model asked for clarification 31.8% of the time under one harness and 10.5% under another, where stopping degraded into a silent dry-run. Whether you even get the chance to steer is currently a property of your tooling, not your model.
So the hours aren’t me being slow. They’re the price of a missing layer.
What I can say is that it’s a skill, and it behaves like one. The leverage comes from asking good questions with actual domain knowledge behind them — knowing which part of this system is load-bearing, which edge case is real and which is imaginary, where the existing code already does this. That’s not prompt craft. It’s the engineering judgment I already had, applied at a different altitude. I’ve started treating the steering pass as a learning session, because reading the agent’s plan against my own model of the problem is where I find out which of us is confused.
And the direction I steer toward is almost always the same: simpler architecture, less code. Partly because less code means less to test and less to review. But also because of that ρ=0.94 — volume is the decay predictor. Steering for less code isn’t taste. It’s steering away from the thing most strongly correlated with the codebase rotting.
Why looping feels fine until it doesn’t
The reason this is hard to learn from experience is that nothing signals failure at the moment it happens.
METR’s 2025 trial is the cleanest demonstration I know. Experienced developers were measurably 19% slower with AI tools while estimating they’d been 20% faster — a 39-point gap between the stopwatch and the feeling. I’d use that carefully: METR revised the picture in February 2026, with later runs showing −18% (CI −38% to +9%) for returning developers and −4% (CI −15% to +9%) for new ones, plus real selection bias they’re redesigning around. The headline number didn’t survive. The perception gap did, and that’s the part I care about: your sense of how well this went is not measuring what you think it’s measuring.
The long-run version is worse. SWE-CI, from Sun Yat-sen University and Alibaba, built 100 tasks from real repository history — each spanning on average 233 days and 71 consecutive commits — and ran agents through a maintenance loop. More than 75% of models showed accelerating regression rates: breaking previously passing tests more and more often as the loop went on, while continuing to pass the task in front of them. That’s exactly the failure mode you can’t see from inside a session. Every step reports success. The trend is down.
At organizational scale it surfaces as instability. DORA 2025 found AI adoption now correlates positively with throughput — and still negatively with delivery stability: more change failures, more rework. AI, as they put it, is an amplifier. Good processes get better; bad ones get worse. GitClear’s 2026 report puts numbers on the residue: duplication up 81% over 2023, refactoring line moves down 70%, cross-file reuse down 35%. And a longitudinal enterprise study of a “2x AI code” mandate found the binding constraint isn’t generation at all — it’s review capacity, which doesn’t scale with it.
Every one of those costs lands later than the session where it was created. That’s the whole reason the loop feels good.
The honest complication
I don’t want to oversell steering, because one result pushes back.
Meta’s SWE-Together built 109 reproducible tasks from 11,260 real user sessions and measured how much corrective feedback each model needed. The number of corrections correlated strongly inversely with capability — r = −0.92 against pass@1. Stronger models needed less steering. But the roughly 15-point gap between the best agent and the human reference persisted even with corrective feedback available.
The honest reading: steering reduces variance and cuts off bad trajectories more than it raises the ceiling. And the amount you need is falling as models improve.
Which means this is a skill with a shelf life. I’m fine with that — most engineering skills have one. But the shelf life isn’t here yet, and the gap between “the model is good enough that I stopped checking” and “the model is good enough that I don’t need to” is where the expensive mistakes live. Right now, on real codebases, the agent still won’t stop, still over-builds, and still ships more code than the job needs.
So I cut in. Not because the tools are bad — because the interrupt is where I do the part that’s actually mine.