As AI agents take over code authorship, the engineer's primary work moves up a layer — from writing implementations to specifying and verifying intent.
By Justin Rubin · June 2026
TL;DR — When agents write the code, an engineer's value shifts from producing implementations to defining and verifying what must be true. Intent that once lived in people's heads has to become explicit, durable, machine-checkable artifacts — chiefly Architecture Decision Records and decision-rich trace/log design — or it evaporates. Start by piloting this on one real service: encode its invariants as enforceable checks and see where your intent wasn't actually written down.
For decades, an engineer's value was bound up in producing code. AI changes the economics: local quality — style, coverage, the absence of obvious bugs — is increasingly something an agent can guarantee on its own. What stays hard, and stays human, is global coherence: are the boundaries right, do the invariants hold, and can anyone diagnose a system that no human hand-wrote?
The valuable work doesn't disappear. It concentrates. The judgment that used to be exercised between coding sessions becomes the primary output, and the typing that obscured how little of the job it actually was falls away.
When humans wrote the code, intent traveled tacitly — through code review, pairing, and senior judgment held in people's heads. AI authorship severs that transmission path. An agent absorbs no hallway knowledge and starts each session near zero. Left unaddressed, three failure modes follow:
- Intent evaporates. The "why" behind a boundary or a constraint has no durable home, so each change risks quietly undoing decisions no one remembers making.
- Review becomes theater. You cannot catch a subtle logic error by skimming syntax you didn't write. Approving it anyway launders accountability you can't actually exercise.
- Incidents get harder. No one has the implementation in their head. Without systems that explain themselves, diagnosis slows to a crawl.
The result is code that passes every local check and is globally incoherent.
The answer is not a new abstraction language. It is to treat the decisions as the reviewed artifact and let the implementation float beneath them. Two artifacts become the team's primary deliverables.
1. Architecture Decision Records (ADRs). A short, versioned document per significant decision: the choice, the context, the alternatives rejected, and the consequences. ADRs live in the repository beside the code, are reviewed through pull requests, and are immutable — a changed mind produces a new record that supersedes the old one, preserving the history of why the thinking changed. A good ADR contains what a product story never could: the reasoning beneath the requirement and the constraint it imposes on all future work.
2. Trace and log design. How a system explains its own runtime behavior is itself an architectural decision, and deserves to be recorded as one. The shift is from logging events to logging decisions — why a branch was taken, with the rule and inputs that drove it — in a structured form, tagged to the invariants in play. The goal is a system you can diagnose from its logs alone.
Where a decision is load-bearing, it is paired with an automated check so an agent cannot quietly drift from it. A rule like "controllers never access the database directly" can be progressively hardened: an ADR a human signs off on, a fitness function that fails CI on violation, and a type boundary that makes the violation impossible to compile. The hardness is chosen to match how much the rule matters.
Pick one real service and run a focused pilot:
- Encode the invariants. Write the five to ten rules that must always hold as fitness functions, then let an agent change code freely and observe what the checks catch versus miss. The gaps are intent you hadn't written down — and closing that gap is the whole exercise.
- Adopt lightweight ADRs. Make a short ADR a required output of any significant change — agent-drafted, human-approved, merged alongside the code.
- Author a trace contract. Define decision-rich logging for one flow, then break it on purpose and try to diagnose the failure from logs alone. If you can't, the runtime isn't yet legible enough for an AI-authored codebase.
- Keep human intent independent of agent-written tests. If the same agent writes both the code and its unit tests, a green build only proves the code does what the code does. Acceptance properties must encode human intent separately.
The team specifies and verifies what must be true. The agent implements. The code becomes a verified — and disposable — byproduct. Anything in today's process that assumes a human authored the code (review, debugging, onboarding, the path to senior judgment) is worth re-examining against that single shift.
Licensed under CC BY 4.0 — share and adapt freely with attribution. Contributions welcome.