For decades, software organizations treated code production as the scarce step. Roadmaps were negotiated around engineering capacity; architecture aimed to reduce implementation effort; productivity tools helped people type, navigate, and reuse code faster. Coding agents are now weakening that assumption.
The immediate effect is pleasant: a backlog item becomes a patch before the meeting ends. The second-order effect is less comfortable. Every plausible patch creates a verification obligation. If production rises faster than the organization’s ability to establish correctness, the bottleneck moves rather than disappears.
At XioX, we think this shift changes what a high-performing engineering system produces. Its primary product is no longer code. It is evidence: executable proof that a change satisfies an intended behavior, respects system constraints, and remains operable after deployment.
Plausible patches create asymmetric work
An agent can generate an implementation in minutes. A responsible reviewer may need far longer to understand the affected domain, reconstruct unstated requirements, test failure modes, inspect dependencies, and decide whether the change belongs in the system at all. Generation and acceptance have different cost curves.
This asymmetry is visible in software-agent benchmarks. SWE-bench evaluates systems against real repository issues, where producing code is only useful if the repository’s tests recognize the issue as resolved. METR’s time-horizon evaluations likewise ground capability in completed tasks rather than attractive snippets. These are better signals than demonstrations because the environment gets a vote.
Production environments are harsher still. Tests may be incomplete. The ticket may describe a symptom rather than the desired behavior. A patch can satisfy the visible assertion while violating performance, authorization, migration, or observability requirements that live in engineers’ heads.
The result is a new form of technical debt: unpriced verification debt. It accumulates when teams merge more machine-produced change than they can deeply validate. The code may be clean. The uncertainty is the debt.
Specifications must become executable boundaries
The common response is to ask agents for better code. That helps, but it does not repair a system whose intent is undocumented. Agents amplify the quality of the environment they inhabit. In a repository with sharp interfaces, representative tests, local setup scripts, and explicit invariants, they can act with surprising precision. In a repository governed by tribal memory, they generate reasonable guesses at industrial speed.
This makes specification work newly valuable. Not grand documents that drift away from implementation, but compact, executable boundaries: contract tests, schemas, permission matrices, performance budgets, state-machine properties, migration checks, and examples of behavior that must never change.
A useful task description should identify both the desired outcome and the protected surface. “Add retry logic” is underspecified. Which failures are retryable? Is the operation idempotent? What is the latency budget? How is exhaustion observed? Which downstream service must not receive duplicates? These questions were always part of engineering. Agents make the cost of leaving them implicit immediately visible.
Review the claim, not the diff
Traditional review is organized around a human-sized patch. A colleague reads the diff, infers intent, comments on suspicious lines, and relies on social context. That ritual strains when agents produce many patches, broad refactors, or implementations no team member authored line by line.
The review unit should shift from the diff to the claim. A change claims that some behavior is now possible, some defect is no longer possible, or some internal structure has changed without altering external behavior. Review should ask what evidence supports that claim.
- For a bug fix, reproduce the failure before the patch and demonstrate its absence afterward.
- For a refactor, compare observable behavior and performance across old and new implementations.
- For a dependency change, inspect provenance, permissions, transitive impact, and rollback.
- For an agent-generated test, verify that it fails for the intended reason when the implementation is removed.
This last point is crucial. Agents can write tests that agree with their own implementation while missing the actual requirement. A green test suite is evidence only when the tests are independently meaningful.
Give agents feedback, not unlimited discretion
The strongest coding workflows are loops. The agent edits, compiles, tests, inspects output, and revises. Tools matter because they let reality correct the model. Simon Willison’s extensive writing on AI-assisted programming repeatedly shows the practical value of hands-on experimentation and observable results over abstract claims about model capability.
Organizations should deepen those loops while controlling their blast radius. Agents need reproducible environments, fast tests, structured logs, and narrow permissions. They should be able to discover failure cheaply without gaining an easy path to publish packages, alter production data, or merge their own work.
Human review remains essential, but its purpose changes. Reviewers should spend less time correcting syntax and more time challenging assumptions, selecting verification strategies, and deciding whether a generated change improves the system’s long-term shape. The valuable engineer is not the person who can out-type the agent. It is the person who can define what must be true and recognize when the evidence is inadequate.
The engineering organization is the tool
Buying a coding assistant does not create agentic engineering. The surrounding organization determines whether cheaper code becomes leverage or noise. Repository hygiene, test architecture, incident learning, access control, and deployment design are all part of the agent system.
Teams that invest only in generation will experience an initial burst followed by review congestion and subtle regressions. Teams that invest in evidence can safely accept more change. Their advantage will look less like spectacular demos and more like short feedback loops, smaller incidents, and confident releases.
Code is becoming abundant. Confidence is not. The companies that understand that distinction will use agents to increase their ambition without surrendering their standards.
Advertisement
