A Human Would Have Asked.
Part 2 of an ongoing series on building an agentic engineering practice.
The first piece ended with a claim: the effort inverted, from roughly 20% specification and 80% implementation to roughly the reverse. That is easy to say and it sounds like a reallocation of hours.
It is not. It is a change in what a specification is, and the reason is one property of human developers that nobody thinks to write down.
Humans repaired your specification
Hand an ambiguous ticket to a developer and something happens that never appears in any process document. They notice. They ask in the standup, or they raise an eyebrow in refinement, or they work out halfway through implementing it that the edge case you forgot has to behave a particular way and they just make it behave that way. Then they mention it, or they don't.
That silent repair was doing an enormous amount of work, and it was never free. It was part of the old process and it always carried a price: days lost while a ticket waited on an answer, rework when the answer arrived after the code, edge cases settled by whoever happened to be implementing that afternoon, and reasoning that stayed in one head instead of reaching the specification. The price never appeared as a line item, which is not the same as costing nothing.
An agent does ask. Ours asks structured questions at intake whenever its confidence is low, and they are frequently good questions — better formed than the ones that would have come up in a corridor conversation. What it does not do is repair. It asks about the uncertainty it can recognise inside the frame it was handed, and it cannot ask about the gap that nobody framed as a gap in the first place. Everything outside that frame gets interpolated: filled with something plausible, confidently, at speed, by a process with no stake in whether it is right. Those gaps do not surface as questions. They surface as merged code that looks fine.
So the operative rule of the whole practice is not "AI writes the code." It is:
Anything you do not write down will be invented. Not maybe. Not sometimes. It is the default behaviour of the system, and the only variable is whether the invention happens to be correct.
Once that lands, the artifacts have to change shape. Not because process is good, but because every ambiguity now has a delivery date.
One requirement, all the way through
A requirement arrives however someone happens to phrase it. Plain language, no template. That part deliberately did not get harder.
It is classified before anything else happens. One of six task types — new function, change, bugfix, refactoring, service request, review.
The PRD stopped being a narrative. It is now numbered capabilities, C-1 through C-n: individually implementable, individually acceptable, with dependencies stated explicitly so they can be topologically sorted, and acceptance criteria written in Gherkin. That last part is the single biggest change to product management in the whole transformation.
A clickable prototype validates the assumptions before anything is built, and it is also what makes the PRD checkable: with something to look at, the capabilities can be tested for completeness and correctness rather than read for plausibility. That review is the first gate, and it is a conversation on purpose — worked through with customers, stakeholders and the developers who will own the code. The PRD is not final until it has been approved there. This is where the questions a human would have asked are supposed to get asked, by humans, while asking them is still cheap.
Then, unusually, the prototype does not get thrown away. It becomes part of the binding handover, alongside the PRD and the design record, so that what was shown to stakeholders is what gets built.
The architecture record is agent-drafted and human-approved before elaboration, not after. Twelve sections: system boundaries, data model changes, API contracts, non-functional requirements, security, annotated legacy zones, guardrails, test strategy. The checkpoint has a hard limit of two revisions, which sounds arbitrary and is not: an approval loop without a bound becomes a place to hide.
The blueprint is the plan a machine can validate. Which files will be created or changed and why. Test strategy per level, with mandatory regression tests on bugfixes. Guardrails as explicit must and must-not lists including protected legacy ground. Acceptance criteria. Open questions, written down as open rather than resolved by assumption. When the work is done the blueprint is persisted into the target repository, so the reasoning behind a change lives next to the change.
Then specialists execute — parallel across chains, sequential within them, one atomic commit per capability, tests before code. Then the gates. And then documentation that is a completion condition rather than an aspiration: an architecture decision record for each decision, an incident report for each bugfix. Missing them is a finding.
Most requirements do not look like that
The walkthrough above is the deep lane. It is what a new capability on the platform costs, and it is worth what it costs.
It is not what a two-line fix costs, and a practice that charged the same for both would deserve to be ignored. The classification at the front is what makes the difference: the task type and the size band determine how much of the chain actually runs. Small, well-understood changes go through a short lane — described, classified, implemented, gated, done. No product requirements document, no architecture record, no ceremony that exceeds the change.
What is not optional is the classification itself. Something has to have looked at the requirement and decided which lane it belongs in, and that decision has to be visible. The failure we designed against is not "someone shipped a small change quickly." It is "nobody knows which of those this was."
That distinction is doing more work than any single artifact in the chain, and getting it right is still not finished — the lane model is the most incomplete part of the system as it stands today.
The rule that earns its keep
Each specialist reports one of three statuses: success, re-engagement, or blocked. There is no fourth, and specifically there is no silent path where something ambiguous gets resolved locally and quietly.
Five named situations force a hand-back to the architect: an architectural decision the plan did not anticipate, a conflict between the specification and the code, an ambiguity in the blueprint, scope that turned out larger than written, or protected legacy ground being reached.
The reason this exists is worth stating plainly. The dangerous failure is not an agent that is wrong. It is an agent that is decisive. Being wrong and being confident produce identical output, so stopping has to be an available, named, structurally rewarded outcome — otherwise the system's only way to express uncertainty is to guess well.
What this does to a working day
Product management writes criteria that can fail. The specification is no longer a requirement handed on for someone to interpret; it is the thing that determines what exists. The conversation about it belongs at the first gate and it closes there: approving a PRD is now closer to signing off a build than opening a negotiation.
Senior engineers moved from writing code to writing conventions. Their judgment used to apply when they were in the room. Encoded as conventions, guardrails and legacy zone annotations, it applies to every task whether they are there or not. This is the change most senior people resisted and, in my experience, the one they came around to fastest, because the leverage is obvious once you see your own rule stop something at three in the morning.
Review changed direction. Findings from an automated review are checked individually, in parallel, with refutation as the default — a verification pass reads the actual code and must confirm, refute or sharpen each one. Only surviving findings reach a person. The working principle behind it is the same one that governs everything else: AI output is a hypothesis, not a result.
And nothing commits or publishes itself. Every gate has a name and a person attached.
The problem with all of this
Everything described above is, so far, a set of instructions. Good ones, in documents people agreed to.
Instructions get skipped, and the interesting part is that skipping them is often correct. A customer escalation lands, the fix is two lines, and the full ceremony is plainly disproportionate. Everyone in the room agrees, and everyone in the room is right.
That is the actual design problem, and it is harder than enforcement. Anyone can make a process mandatory. The difficult question is how much process a given piece of work deserves, who decides that, and what stops the answer from always being "less" when a deadline is near.
Which is the subject of the next piece.