Teams that treat AI as either a threat to be contained or a magic wand to be surrendered to are both making the same mistake: they ask how much AI to use, when the real question is which work belongs to the machine at which moment, and who holds the gate between stages. The answer is a lifecycle with three separate sources of truth—pitch, specs, and architectural decision records—and a runtime that enforces human authority at the stages that require it.
The wrong question
Two common failure modes plague teams adopting AI. The first fights it: every AI-generated line gets rewritten by hand because trusting it feels reckless, so the team performs ceremony and captures almost none of the speed, telling themselves that is the price of quality. The second surrenders to it: requirements live in a chat log, the assistant produces a pull request nobody can properly review because there is no written intent to review it against, and "done" means "it ran once on my machine." That approach is fast until it is catastrophically slow, usually around the third feature, when the context window fills up and the model starts quietly contradicting decisions it made an hour earlier.
Both teams are asking the wrong question. They frame AI usage as a dial between zero and one, when the useful question is: which work belongs to a machine, at which moment in the life of a change, and who holds the gate between one moment and the next?
Three sources of truth
A healthy lifecycle has three separate sources of truth that must be kept apart. The pitch owns why—it is transient, belongs to one change, and evaporates once the work is bet on or dropped. The specs own what—they describe the behaviour of a specific change and get archived into a living description of what the system does. Architectural Decision Records (ADRs) own how—they are durable, cut across every change, and record the standing decisions your team has made about the way you build. An ADR is a small, deliberately boring document: a status, the context that forced the decision, the decision itself, and the consequences. You do not edit an accepted one; you supersede it with a new one, so the trail of reasoning survives every change of mind.
The move that makes ADRs earn their place in an AI-driven lifecycle is that accepted decisions become the constraints every agent works within, and a change that needs a new decision cannot proceed on an agent's say-so. Standards flow into the specs and the conversations, and new standards flow back out under human control—consumed on the way in, produced on the way out, with a person in the middle of both.
A state machine with mixed owners
If you list the stages a change moves through—shaped, bet on, proposed, built, published, reviewed, archived—and ask who does the work at each one, you get three answers. Some stages are pure human judgement, and an agent has no business touching them: deciding the appetite, placing the bet, accepting an architectural decision. Some stages are the machine drafting and a human correcting: expanding a rough pitch into a detailed spec, drafting a pull request description from a spec. And some stages are effectively automatic: folding a merged change back into the source of truth is mechanical and should simply happen.
Most agent tooling misses this by assuming every stage wants the same treatment. The question is never how clever the model is; it is where the authority sits. Architecture is the sharpest case of human authority. An agent may apply an accepted decision or draft a proposed one, and that is the ceiling of what it is allowed to do.
The runtime holds the gates
The runtime is a workflow engine that knows the sequence of stages, knows which require a person, knows which agent belongs to each, and moves a change forward one step at a time. What earns its keep is not cleverness but the rules it refuses to break: it will not skip a stage that needs a human, will not run an agent at a stage where no agent belongs, will not let a change outrun its appetite, and will not advance a change on the back of an architectural decision no human has accepted. A rule that lives only in a wiki page is a suggestion, and suggestions lose to deadlines every time. A rule the runtime enforces is one the team can actually rely on, because it holds at six in the evening when the person driving it would have waved anything through.
The right agent at the right stage
At shaping, a fast and cheap critic argues with the draft pitch. It is not there to shape the work—shaping is human judgement—but to push back: is this appetite honest, where are the rabbit holes, and does this work imply an architectural decision we have not yet made? Surfacing that last one before the betting table means the bet is placed knowing a new decision is coming. At betting, there is no agent at all, and that absence is the most important design choice in the whole system. Betting is a decision about what the team is willing to sacrifice this cycle, and no model should be anywhere near it.