- Coding agents changed the unit of work from a line of code to a scoped task: they read the codebase, plan, edit, run tests, and iterate, which moves the engineer's craft from typing to specifying and verifying.
- The productivity evidence is real but uneven. Gains concentrate in boilerplate, tests, migrations, and unfamiliar code; one 2025 randomized trial found experienced developers on repos they knew well were slower with AI while believing they were faster. Measure your own org.
- Governance is mostly classical engineering discipline applied deliberately: small reviewable diffs, tests the agent must pass, provenance in commit history, and review depth tiered by risk. Accountability stays with the human who ships.
From autocomplete to agents
The first generation of AI coding tools was autocomplete with taste. GitHub Copilot launched as inline completion: predict the next few lines from the surrounding file, gray them out, let the developer hit tab or keep typing. It was useful precisely because it was low stakes. A bad suggestion cost one keystroke to dismiss, the human remained the author of every line, and nothing about the development workflow changed except typing speed.
The second generation moved the model into a chat panel next to the editor. You could paste a stack trace and ask what it meant, describe a function and get a draft, highlight a block and request a refactor. The model saw more context and produced larger units of code, but integration stayed manual: the developer copied the answer in, adapted it, and verified it. The tool advised; the human still did the work.
The third generation is the qualitative break. Agentic tools such as Claude Code (Anthropic's terminal-based agent, released in 2025) and the agent modes in AI IDEs like Cursor do not suggest code so much as perform tasks: they search the repository, read the relevant files, edit them, run the test suite, read the failures, and try again, looping until the task is done or they get stuck. Three capabilities converged to make that loop viable: structured tool use, so the model can invoke search, file edits, and shell commands rather than just emit text; long context windows, so it can hold a meaningful slice of a real codebase; and reasoning models that plan multi-step work instead of pattern-matching the next token.
| Generation | Interaction | Unit of work | Cost of a bad output |
|---|---|---|---|
| Inline completion | Tab-accept in the editor | A line or a block | One keystroke to reject |
| Chat assistant | Ask, copy, adapt | A function or a snippet | Minutes of manual integration |
| Agentic loop | Delegate a scoped task | A branch-sized change | A diff you must actually review |
Each step up the ladder raises leverage and raises the cost of inattention in the same motion. That trade shapes everything else in this article.
How a coding agent actually works
Strip away the branding and every serious coding agent runs the same loop a careful engineer does. It gathers context: grep the codebase, read the files that matter, check how similar problems were solved nearby. It forms a plan. It edits files. Then, and this is the part that separates agents from chat, it verifies its own work by running something: the test suite, the type checker, the build, sometimes the application itself. It reads the output, and if something failed it goes back to the relevant step and iterates.
+--------+ +------+ +------+ +-----------+
| GATHER |--->| PLAN |--->| EDIT |--->| RUN tests |
| search | +------+ +------+ | build/app |
| read | +-----------+
+--------+ |
^ v
| fail: back to +---------+ +---------+
+---------------------| ITERATE |<-| OBSERVE |
gather or edit +---------+ +---------+
|
pass: diff goes to human review
The tools differ mainly in where the loop lives. Terminal agents operate on the repository directly and fit naturally into scripting, CI, and remote execution; IDE agents keep the loop inside the editor, where developers can watch edits land in real time and interrupt mid-flight. Neither is strictly better: terminals favor delegation and automation, IDEs favor tight supervision.
The other axis that matters for an enterprise is the permission model. At one end, the agent is read-only and proposes patches a human applies. In the middle, the default for most tools, every file edit and shell command requires explicit approval, often with an allowlist for safe operations. At the far end, auto-approve modes let the agent run unattended inside a sandbox or a disposable branch. Treat that dial as a risk control, not a convenience setting: the correct position depends on blast radius, and it should be set per environment, not per developer mood.
Supervision models: pairing, delegation, fleets
Teams adopt agents along a spectrum of supervision, and it pays to name the modes explicitly, because each one needs different guardrails.
- Synchronous pairing. The developer and the agent work the same problem in real time; the human steers, interrupts, and course-corrects every few minutes. Highest oversight, lowest leverage. This is where new adopters should live, and where genuinely hard or ambiguous problems should stay.
- Async delegation. The developer writes a scoped task with acceptance criteria, hands it off, and reviews the finished diff later, the way you would brief a capable contractor. Leverage rises because the human's attention is only needed at the start and the end. Quality now depends almost entirely on how well the task was specified.
- Parallel fleets. Several agents work simultaneously on isolated branches or git worktrees, each on its own task, with the developer acting as a reviewing tech lead. This is where the throughput demos come from, and where an unprepared organization drowns.
Notice what happens to the constraint as you move down the list. When code generation gets cheap, it stops being the bottleneck; human review becomes the bottleneck instead. An engineer can plausibly review two or three substantial diffs a day with real attention. A fleet can generate ten. The gap either gets closed with discipline (smaller diffs, better specs, stronger automated verification) or it gets closed with rubber-stamping, and rubber-stamping is how generated defects reach production.
That is why review is also the control point. The organizations doing this well treat reviewer attention as the scarce resource to be budgeted, and size their agent usage to the review capacity they actually have, not the generation capacity the tools offer.
What the productivity evidence actually says
The honest summary of the evidence as of mid-2026: gains are real, large in places, and much more task-dependent than the marketing implies. Agents shine on work that is well-specified and verifiable: boilerplate, test scaffolding, mechanical migrations, gluing APIs together, and, notably, navigating unfamiliar codebases, where the agent's ability to read and summarize thousands of lines in seconds genuinely outruns a human. Benchmarks such as SWE-bench, which score agents on resolving real GitHub issues, show steady year-over-year improvement, though benchmark deltas translate to production value only loosely.
Then there is the finding every executive dashboard should be forced to confront. In July 2025, METR published a randomized controlled trial in which experienced open-source developers worked on large repositories they knew intimately, with and without AI assistance. On average, the AI-assisted condition was about 19 percent slower. The same developers believed the AI had made them faster. It is one controlled study of one specific population, expert maintainers on deeply familiar code, using early-2025 tooling, and it should not be stretched into "AI slows everyone down." But it establishes two things beyond reasonable doubt: perceived speedup and measured speedup can diverge sharply, and the population most confident in its own judgment is not immune.
The reconciliation is not mysterious. Experts on familiar code already move at their ceiling; the agent adds prompting, waiting, and review overhead without removing much work. The same person dropped into an unfamiliar service, or handed a hundred repetitive edits, sits far below their ceiling, and the agent closes the gap. Portfolio-level averages hide this. Measure your own organization, task by task, and expect the answer to be "it depends" with a distribution attached.
Keeping it production-grade
The teams shipping agent-written code to production have not invented new engineering principles. They have taken old ones, the ones humans routinely skip under deadline pressure, and made them non-negotiable, because an agent amplifies whatever process it is dropped into. Sloppy process plus an agent yields sloppy code at higher volume.
The contract is the spec. A delegated task needs written acceptance criteria before the agent starts: what changes, what must not change, how success is verified. This is the same argument made in Spec-Driven Development, sharpened by the fact that the agent will do exactly what you asked, including the things you asked by accident. Ambiguity that a human colleague would flag in standup, an agent resolves silently and plausibly.
Tests are the guardrails the agent itself runs. A strong suite converts the agentic loop from "generate and hope" into "generate and converge," because the agent's self-verification step actually verifies something. Teams consistently report that test coverage, once a quality metric, has become a leverage metric: it determines how much work you can safely delegate. The same logic extends upward into CI, where eval-style gates (see the evals deep-dive) block merges that regress behavior regardless of who or what authored the diff.
And diffs stay small. One scoped task, one reviewable change, on the order of a few hundred lines, not an agent's overnight opus touching forty files. Small diffs are what keep human review real rather than ceremonial, which, given that review is now the bottleneck and the control point, makes diff size a governance parameter disguised as a style preference. The craft has moved: less typing, more specifying up front and verifying at the end. The engineers who thrive are the ones who notice the job changed.
Governing AI-generated code
Once agents contribute a material share of the codebase, "who wrote this and under what supervision" becomes a question your auditors, your security team, and occasionally your lawyers will ask. Answering it retroactively is miserable; answering it from records is cheap if you set up the records first.
Provenance comes first. Mark agent-assisted commits mechanically, for example with commit trailers (a Co-Authored-By line or an equivalent convention), so attribution is queryable from git history rather than reconstructed from memory. Provenance is not blame theater; it is what lets you compute escaped-defect rates for assisted versus unassisted changes, target audits, and respond credibly when a customer or regulator asks how much of the product is machine-written.
Scanning applies unchanged, and matters more. Static analysis, dependency and license checks, and secret detection do not care who authored a line, which is exactly why they are the right backstop: generated code can echo licensed snippets or reach for a plausible-but-unvetted dependency, and volume makes manual spotting unreliable. Review policy should then be tiered by risk, not applied uniformly: an agent-written unit test for an internal tool merits a skim; agent-written changes to authentication, payments, or data handling merit the same senior scrutiny as a new hire's first security patch, if not more. Keep the audit trail, ideally including the task prompt and the agent transcript for sensitive changes, retention permitting.
The broader control framework, including policy templates by risk tier, is covered in Governing AI Code.
An adoption path for engineering organizations
The failure mode to avoid is the license-drop: buy seats for everyone, announce a productivity target, and check back in two quarters. That produces scattered usage, unmeasured outcomes, and a backlash led by your best engineers. The pattern that works is narrower and more deliberate.
- Pilot with instruments, not anecdotes. Pick two or three teams with strong test suites and a real backlog of agent-friendly work (migrations, test debt, internal tools). Baseline cycle time, escaped defects, and review load before the tools arrive, then track the same metrics through the pilot. The METR result is your standing reminder of why self-reported speedup does not count.
- Build the paved road. Turn what the pilot learns into defaults: approved tools and models, sandboxed execution, permission presets per environment, shared agent configuration and context files per repository, commit-trailer conventions, CI gates. Adopting an agent should mean joining a configured lane, not improvising one.
- Train reviewers, not just users. Prompting is the easy half. The scarce skill is specifying tasks precisely and reviewing machine-generated diffs, which fail differently from human code: confidently, plausibly, and sometimes subtly beside the point. Make agent-diff review an explicit competency, and budget senior time for it.
- Scale by risk tier. Expand from internal tools toward customer-facing and regulated systems as your defect data earns it, tightening supervision as blast radius grows.
Notice that most of this list is organizational, not technical. The tooling is the cheap part and improves on its own schedule. What determines whether coding agents compound or corrode is culture: whether specs are taken seriously, whether review stays honest under volume, and whether the organization measures instead of believes. I ship production sites with these tools, this one included, and the workflow that survives contact with reality is the disciplined one, every time. Theory here; working systems in the Lab.