The Interrupt Is the Work

There are two primary ways to work with an autonomous coding agent, and I have spent enough hours with both to feel the mechanical difference in my hands.

The first pattern is to delegate the task and walk away: describe what you want, let the agent plan, let it implement, and let it loop until it announces completion. The second pattern starts identically but cuts in early: pause execution after a few turns, break the work into smaller increments, ask what the model considers tricky, debate the proposed approach, and only then authorize code changes.

The divergence between these two approaches is stark. They produce fundamentally different categories of code.

Two years ago, skepticism about autonomous execution was easy to dismiss as developer resistance. But models have genuinely matured, test harnesses have become far more sophisticated, yet the quality gap between passive looping and active intervention remains wide. Here is why that gap persists.

Why autonomous looping works on side projects

I understand why developers working primarily on side projects find this critique counterintuitive. On weekends, I follow the same passive pattern: I provide a simple prompt, let the harness loop until finished, and the output is generally acceptable. For a time, I treated that success as proof that modern coding agents had solved end-to-end implementation, assuming anyone still hovering over their terminal was merely clinging to outdated habits.

Then Monday would arrive. Applying that same hands-off habit to a production codebase produced PRs I had to discard completely.

This is not a contradiction, nor are autonomous developers mistaken about their personal experiences. Stanford researcher Yegor Denisov-Blanch measured this across 100,000+ developers at 600+ companies within private repositories, measuring delivered functionality rather than raw commit counts. While the headline productivity gain landed at 15–20%, that average conceals a profound divide based on repository context:

• Low-complexity greenfield: ~30–35% gain
• High-complexity greenfield: ~10–15% gain
• Low-complexity brownfield: ~15–20% gain
• High-complexity brownfield: ~5–10% gain

A weekend hackathon project occupies the top-left quadrant; enterprise legacy code occupies the bottom-right. That represents a three-to-sixfold difference in productivity between two developers using the exact same model. Furthermore, that 15–20% average is net of rework: the engineering hours spent cleaning up regressions introduced by AI code are already subtracted.

When someone reports that unattended looping works seamlessly, they aren’t wrong. Their repository simply hasn’t started billing them for the accumulated complexity yet.

The failure mode is scope, not raw ability

When I leave an agent completely unattended in a complex codebase, it rarely fails by hitting a syntax wall. Instead, it over-engineers. It introduces speculative abstractions, expands a minor patch into a multi-layer refactor, adds caching layers with no benchmark justification, and creates configuration flags for scenarios that will never happen. Each individual edit is superficially defensible, but the cumulative diff is an unmaintainable burden.

This tendency is thoroughly documented. A July 2026 study from HKUST provided agents with underspecified, realistic tasks and tracked actions outside the requested boundaries. The “OverScope” rate (operating beyond the required problem boundary) ranged from 24.9% to 44.4%, depending on the model and harness. Between 55.8% and 67.8% of runs violated at least one boundary constraint. Safe Success (performing strictly the correct action on the intended target) hovered between only 15.5% and 36.8%. The agents did not pause on ambiguous instructions; they hallucinated assumptions and immediately executed them.

The bloat is visible in the diff sizes. A joint paper from CMU, Stanford, Princeton, and UIUC found agent-generated patches consistently longer than human baselines, with over 15% of patches exhibiting more than a 1.5x bloat ratio across all tested models. Notably, this bloat persisted despite high task completion rates: benchmarks labeled the runs as successful, while the diffs contained twice the code necessary to solve the issue.

Raw volume is an architectural liability. A Concordia University study evaluating code smells across agent generation discovered that total lines of code correlated with architectural smells at ρ = 0.94. The researchers termed this the Volume–Quality Inverse Law: code volume serves as a near-perfect predictor of architectural decay. Even worse, more capable models generated more coupled, bloated code than smaller models (a dynamic dubbed the Reasoning–Complexity Paradox). Long method violations occurred 11 to 13 times more frequently in frontier models compared to human baselines. Prompt engineering did not mitigate this; few-shot framing left smell densities stagnant or exacerbated them.

If prompt craftsmanship could solve architectural bloat, this essay would be a prompt guide. It cannot.

This matches real-world findings. Thoughtworks director Erik Doernenburg documented a typical case while adding GitLab support to a Mac CI application. Unprompted, the agent added an unnecessary cache, wrote convoluted logic for a non-existent edge case, and duplicated existing URL formatting utilities. His conclusion matched my daily experience: “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.”

Autonomous agents do not pause spontaneously

One empirical dataset permanently clarified this dynamic for me.

SWE-chat, developed by Stanford and NYU researchers, captures telemetry from 6,000 genuine developer sessions across open-source repositories: 63,000 user turns and 355,000 agent tool calls.

The core asymmetry in the telemetry is striking:

Agents pause to request clarification in only 1.4% of conversational turns, while users intervene or push back in 44% of turns. 39% of those interventions take the form of post-execution corrections, while 3.3% to 6% are hard interrupts mid-execution.

The cost of this asymmetry is severe: only 44% of agent-authored code survived into final commits. More than half of the code generated across these real sessions was discarded.

The study authors reach the same conclusion I did: agent architectures are gaining autonomous capabilities faster than they are learning conversational calibration. The agent default is always to proceed. When specifications are thin, models silently guess the missing constraints and keep writing. The only obstacle between an underspecified prompt and an over-engineered diff is a human engineer deciding to cut in.

Interrupting an agent is not workflow friction; it is the exact inflection point where scope is enforced.

The outsized leverage of mid-stream steering

Targeted human intervention is inexpensive relative to the quality improvement it delivers.

Simply inserting an explicit clarification step (instructing the model to surface ambiguity before writing code) lifted GPT-4’s pass@1 rate from 70.96% to 80.80% on the MBPP benchmark in the ClarifyGPT research. A ten-point jump materialized simply by asking questions first. However, models rarely do this unprompted: ClarifyCodeBench demonstrated that frontier LLMs still struggle to detect missing requirements independently. That responsibility remains with the human engineer.

Task decomposition yields similar gains. An IBM research team restructured agent execution from monolithic prompts into granular subtasks with intermediate validation gates, reducing retry costs by up to 51.7%. Half the wasted computational cycles vanished through the exact intervention I perform manually when pausing an agent to scope down work.

Similarly, CentaurEval evaluated 45 expert software engineers across complex development tasks: autonomous AI alone succeeded on 0.67% of tasks, solitary humans achieved 18.89%, while human-AI collaboration hit 31.11%, finishing faster than either group operating alone.

The unresolved friction of steering

I do not want to present steering as a solved science, because active oversight has real costs.

Steering effectively requires substantial cognitive energy. Breaking tasks down into modular increments prevents scope creep, but reviewing the resulting breakdown demands rigorous scrutiny. Reading a multi-step execution plan carefully enough to detect subtle architectural misalignment requires nearly as much domain comprehension as formulating the plan yourself. Multiply that by several tasks a day, and oversight becomes exhausting.

The broader research community is confronting the same bottleneck. The CMU and Stanford position paper highlights how agent research prioritized unbounded autonomy while neglecting steerability, runtime verification, and semantic alignment. In HKUST’s benchmark, the identical model requested clarification 31.8% of the time under one harness, but plummeted to 10.5% under another where human intervention was poorly integrated. Whether an engineer even receives a meaningful opportunity to steer often depends on the harness rather than the underlying model.

That manual overhead is not personal slowness; it is the price of an architectural layer the industry has yet to standardize.

What I have learned is that steering is a distinct technical skill. Leverage stems from asking pointed, domain-grounded questions: identifying which system interfaces are load-bearing, distinguishing genuine production constraints from theoretical edge cases, and knowing where existing utilities already solve the problem. That is not prompt trickery; it is traditional engineering judgment applied at a higher abstraction layer. I treat plan reviews as alignment checks: reading the agent’s proposal against my mental model of the codebase reveals which of us misunderstood the problem.

The directional goal of steering is consistent: leaner architecture, less code. Less code means fewer test fixtures and lower review burdens. More fundamentally, because lines of code correlate with architectural decay at ρ = 0.94, steering toward minimal diffs is the most effective defense against codebase rot.

Why passive looping feels productive until it fails

The psychological trap of autonomous looping is that failure rarely produces immediate feedback.

METR’s 2025 developer study illustrated this disconnect clearly: experienced developers using AI tools were measurably 19% slower while perceiving themselves to be 20% faster, a 39-point gap between subjective impression and stopwatch measurement. (While METR’s February 2026 follow-up adjusted the uplift estimates to −18% for returning developers and −4% for new ones, the perception gap itself remained undeniable.) Subjective feeling is an unreliable measure of actual productivity.

The compounding downstream effects are worse. SWE-CI, from Sun Yat-sen University and Alibaba, constructed 100 long-horizon tasks from real git histories (averaging 233 days and 71 consecutive commits) and ran agents through continuous maintenance cycles. Over 75% of models exhibited accelerating regression rates, breaking previously passing integration tests with increasing frequency as the maintenance loop lengthened, even while reporting success on the immediate issue. Inside a single session, every step looks successful; across repository history, the quality trajectory degrades.

At company scale, this manifests as operational volatility. DORA’s 2025 report observed that AI adoption correlates positively with throughput, yet correlates negatively with delivery stability: more change failures, increased rollback frequencies, and elevated rework. AI acts as an amplifier: disciplined workflows improve, while brittle ones fracture faster. GitClear’s 2026 code quality report recorded code duplication up 81% since 2023, refactoring line adjustments down 70%, and cross-file reuse down 35%. In an enterprise study tracking an aggressive AI code mandate, the primary constraint was not code generation speed, but review throughput, which cannot scale arbitrarily.

Every one of these costs arrives long after the initial coding session closes, which is why unattended looping feels satisfying in the moment.

The honest horizon

Steering is not an eternal prerequisite. Meta’s SWE-Together study analyzed 109 reproducible tasks from 11,260 real developer sessions, discovering that corrective interventions correlated strongly negatively with model capability (r = −0.92 against pass@1). Frontier models require fewer coarse corrections than earlier generations, even though an approximate 15-point capability gap relative to human reference solutions remained.

The realistic assessment: human steering reduces variance and prunes invalid trajectories far more than it elevates peak theoretical performance. As foundation models advance, the volume of manual intervention required will inevitably decline.

Steering is a transient skill, and like most engineering techniques, it has a finite window of relevance. However, that window is not closed today. The space between “the model is capable enough that I stopped checking” and “the model is capable enough that checking is unnecessary” is where costly architectural mistakes accumulate. On real codebases today, autonomous agents still over-build, still guess through ambiguity, and still ship more complexity than necessary.

I cut in regularly, not out of distrust for the tools, but because the interrupt is precisely where human engineering judgment does the real work.