AI & Automation

From reviewing code to converting judgment: a developer's note on working with agents

What changes when coding agents join daily work? The most useful skill may be the one nobody trained for: turning judgments you repeat into durable structure.

Flat geometric illustration in orange, sage and lavender: circuit-like lines link blocks and nodes, a small robot peeks out from behind a dark wall, and a monitor shows lines of code.

What actually changes in the chain of production when coding agents become part of daily work? Well, the most useful skill may turn out to be the one nobody trained for.

The workflow literature of 2026 has largely converged on a single story: the developer’s role shifts from writing code to directing, reviewing, and verifying it. Andrej Karpathy, who coined “vibe coding” in early 2025, updated the framing to “agentic engineering,” with the developer acting as oversight rather than author; industry surveys through mid-2026 report that a large majority of professional developers now use coding agents at least weekly — 90% in JetBrains’ 2026 survey. This is true as far as it goes, but it is also shallow — it describes the shift without confronting the problem practitioners actually hit, which is that the artifact under review has become simultaneously larger and more confidently wrong.

That problem has a name in the emerging discourse: the code review paradox. When an agent generates not only the implementation but also its tests and documentation, the reviewer’s traditional anchors erode — the tests may be observational probes rather than assertion-rich regressions (a pattern noted in analyses of agent-written tests on SWE-bench trajectories), and the documentation describes what the agent did rather than what you wanted. Anthropic’s own Claude Code guidance responds to this by elevating verification above dialogue: the highest-leverage practice, they argue, is giving the agent a way to check its own work — runnable tests, lint commands, comparisons that return pass or fail — because without verifiable success criteria the agent produces code that looks right and often is not.

Framing this in terms of a risk budget is not merely a metaphor. It maps onto a real asymmetry: a human engineer’s judgment about what is not worth doing is tacit, situational, and expensive to externalise, whereas an agent optimises toward a theoretical maximum of correctness because it has no representation of the downside of effort: added surface, added complexity, added review load. The three-tier plan (minimal / reasonable / full rewrite) is a lightweight mechanism for making that budget explicit at planning time, and it aligns with the documented recommendation to separate a read-only planning phase from implementation.

The more radical strand of the 2026 literature questions the premise underneath all of this. One line of argument (Cao, “Agentic Software: How AI Agents Are Restructuring the Software Paradigm,” first published as “The End of Software Engineering”) holds that in fully agentic systems, code ceases to be the carrier of decision logic and becomes ephemeral tooling — generated and discarded inside an LLM-driven reasoning loop. If code is disposable, the entire impulse to harden a SELECT statement you will regenerate next week partly dissolves; the thing worth protecting is no longer the implementation but the specification and the invariants behind it. A parallel strand (surveyed under titles such as “Skills for the Future Software Profession,” Roychoudhury, Kang and Ray) argues that as LLMs automate proof search, the bottleneck in formal verification shifts from proving correctness to inferring the right specification — making specification, not code, the fundamental artifact, and warning that inferred specifications drift from evolving implementations and require continuous consistency checking.

Governance conversion, the concept we build our conclusion on, comes from James C. Davis and colleagues: first in a 12-week case study, “Cheap Code, Costly Judgment” (July 2026), then in their Model-Based Agentic Software Engineering (MAGE) framework (Aug 2026). The claim is precise: high-velocity agentic implementation surfaces recurring structural failure classes, and engineering judgment sustains velocity by converting those failures into durable governance mechanisms. It is the move with teeth, because it turns selected lessons into durable engineering structure so that future work inherits them. The word “conversion” matters here: judgment is an ephemeral asset that fires once and is lost; governance is the durable form it converts into; and as that structure accumulates and lowers the cost of future work, it becomes what MAGE calls engineering capital — durable structure that reduces the cost or uncertainty of future work through reuse. Independent work on agentic SE reliability (e.g. “Agents as Software,” Barke and Murali) converges from a programming-languages direction, recasting agent behaviour as something to be specified over traces and state, checked before deployment, and monitored at runtime — which is, in effect, governance conversion applied to the agents themselves.

The practical upshot for a studio like ours is a change in where effort is invested. Reviewing agent output faster is a treadmill. The compounding move is to treat every recurring review comment as a diagnosis — the drop-the-table reflex is really a missing specification; you never declared that invariant mattered, so stop re-litigating it in review and either encode it as a control or decide, once and explicitly, that it does not matter. The scarce, durable skill is no longer writing code, nor even reviewing it, but stating precisely what must be true and converting the judgments you keep repeating into structure the system holds on your behalf. The open risk, flagged by the same researchers, is spec-drift: this capital depreciates, and keeping specifications consistent with fast-moving implementations is the next bottleneck in waiting. That is the problem we would rather be working on.

Sources

Back to the light read (4 min).

Related articles