Coding agents are changing software development’s most visible activity: the production of code. A developer can delegate a feature, leave the agent to inspect a repository and run tools, then return to a plausible patch. The immediate sensation is abundance. Changes that once required an afternoon can appear in minutes.
Abundance, however, moves constraints rather than abolishing them. If a team can generate five times as many changes but can review only twice as many, its queue fills with unverified work. The limiting resource becomes confidence: evidence that a change satisfies the requirement, preserves important behavior, and has not expanded the system’s risk in an unexpected direction.
The practical future of AI-assisted engineering will therefore be shaped less by how quickly agents type and more by how cheaply teams can prove them right.
A plausible diff is a dangerous unit of progress
Code review was already an imperfect control. Reviewers skim repetitive sections, infer behavior from familiar patterns, and miss interactions spread across files. Agent-generated changes intensify those weaknesses because they can be large, polished, and internally consistent while resting on one false assumption.
Birgitta Böckeler’s account of developer skills in agentic coding captures a crucial operational fact: model output still requires active judgment, especially inside existing codebases. The issue is not that agents always produce bad code. It is that fluency makes defects expensive to notice. A patch can look more deliberate than the reasoning behind it.
Traditional review treats the diff as the main artifact and tests as supporting material. Agentic development should reverse that hierarchy. The primary artifact should be an executable claim: a specification, invariant, contract test, replayable scenario, or measurable acceptance condition. The code is one proposed implementation of that claim.
Verification must enter the agent loop
Sending every generated line to a human reviewer does not scale. Nor does asking the same agent to declare its own work correct. The useful middle ground is a harness that gives the agent fast, independent feedback while reserving consequential judgments for people.
A strong harness begins before generation. It states what may change, what must remain invariant, which commands constitute evidence, and which actions require approval. It provides the agent with repository conventions and narrow tools instead of unrestricted access. After each meaningful change, deterministic checks run automatically: type checking, unit and integration tests, schema validation, security scanning, performance budgets, and policy rules.
The agent should encounter failures while it still has the context to repair them. Humans should receive the requirement, the change, the evidence, and the unresolved uncertainty—not a wall of code with a confident summary. Kief Morris describes a related shift from humans being constantly “in” the loop to working on the software-delivery loop: designing the controls and feedback through which agents operate.
This is applied AI at its most useful. The model supplies flexible search and synthesis; the surrounding software supplies memory, constraints, and repeatability. Neither is sufficient alone.
Repository design becomes part of model performance
Two teams using the same coding model can get radically different results. The difference often lies in the environment. A modular codebase with quick tests, clear boundaries, reproducible setup, and explicit conventions gives an agent short feedback cycles. A tangled repository with slow builds and undocumented side effects forces it to guess.
That means familiar engineering investments acquire a second return. Refactoring reduces human cognitive load and model context burden. Hermetic tests make failures attributable. Structured logs make agent runs diagnosable. Small interfaces limit the blast radius of an incorrect assumption. Good internal documentation becomes machine-operable context rather than shelfware.
The lesson also applies to tool permissions. Simon Willison’s writing on prompt injection shows why agents that combine private data, untrusted input, and external actions require careful boundaries. A coding agent that can read an issue, retrieve secrets, modify infrastructure, and publish artifacts is not merely an editor. It is a privileged automation system. Its tool surface deserves the same threat modeling as any production service.
Measure accepted outcomes, not generated code
Lines of code, suggestions accepted, and tasks attempted are seductive metrics because tools can count them. They are also easy to inflate. A team can produce more code while increasing review time, incident risk, and future maintenance cost.
Better measures sit closer to outcomes: lead time for verified changes, escaped defects, rollback frequency, review latency, time spent clarifying requirements, and the proportion of agent work rejected for substantive reasons. Teams should also track how often their verification system catches an error before a person does. That number reveals whether automation is reducing review burden or merely relocating it.
The mature coding-agent workflow will look less like supervising a tireless junior developer and more like operating a high-speed fabrication process. Specifications define tolerances. Automated checks inspect routine properties. Humans investigate anomalies, revise the production system, and remain accountable for what ships.
Code is becoming cheaper. Assurance is not. The teams that recognize that asymmetry will use agents to shorten the path from idea to dependable software. The rest will simply create larger piles of plausible changes waiting for someone to trust them.
Advertisement
