The AI-native SDLC
The published playbooks for agentic development have converged on a shape, and they are right about it: six stages, each ending by committing an artifact the next stage reads. The handoff is a file. The commit is the trigger. Nothing waits for a meeting.
This page walks all six, and asks the same question at each one: what actually enforces that artifact once nobody is reading every line?
This is not a correction. The playbooks describe how a team should work, and a team that adopts one is better off than a team that does not. They do not describe a forge, and they should not have to — but the artifacts they rely on have to be held by something, and today that something is the same tool that wrote the code. This page is about the layer underneath.
The chain is the whole mechanic. A stage does not end by notifying anyone; it ends by writing something down, and the next stage begins by reading it. That is what removes the handoff delay, and it is also what makes the process auditable in principle.
Every one of those artifacts is a file in a repository. Everything that keeps them honest — the hook that blocks an edit to a protected path, the policy encoded as a skill — the playbooks' deterministic guardrails and advisory ones — the review pass that ranks findings, the gate that pauses for an approval — runs inside the harness that also wrote the code. That is not a flaw in the playbooks. It is the boundary of what a playbook can reach.
Read the middle column as a description rather than a complaint: each of these mechanisms is real, works, and is better than what came before it. The question is only what remains true when the agent does not cooperate, when the harness changes, or when someone asks in eighteen months.
| Stage, and what it commits | What holds it today | What a typed record makes of it |
|---|---|---|
| 01 Plan — the intent | A markdown file, reviewed by a person and committed. Nothing downstream requires it to exist, and nothing checks that the code which follows answers it. | An intent the change record references by identity. A pushed commit resolves to the intent its trailer names, and the evidence bundle names that intent in turn — so a change with none is a change policy can refuse. |
| 02 Design — the spec | The spec, the prompt that produced it, and the policy versions in force are all in version control — in several places, correlated by convention and by whoever remembers the convention. | Artifacts carried on the change and versioned with it. What a change is answering travels with the change rather than beside it, and is still attached when the branch is gone. |
| 03 Build — the plan, then the diff | Plan mode, a knowledge file, hooks that block edits to protected paths. All of it lives inside the harness, and a second harness on the same repository brings its own. | The diff stays ordinary git objects — git clone keeps working, and no tool has to learn anything. What is added is the harness, the model and the session that produced it, as fields rather than as a transcript. |
| 04 Test — the evidence | The agent runs the checks and reports the output; evals gate changes to the agent's own configuration. The thing that ran the tests is the thing telling you they passed. | Gates run in an isolated, network-denied container, and the verdict is a signed bundle bound to the state that will actually ship rather than to a branch head that will not. ADP attests; it never executes the code it attests to. |
| 05 Deploy — the findings, and the approval | Hooks pause an action until a named person approves — the agent runs to the production gate and never crosses it; the pull request is the audit record; autonomy is tiered by environment. All correct — and all enforced by the tool whose behaviour is being constrained. | Requirements evaluated where changes are admitted, over an instance floor, an organization floor and the repository's own rules, returning a typed verdict the authoring agent can act on. A refusal is recorded as carefully as an admission. |
| 06 Maintain — the incident record | A detection script invokes an agent on a breach, and the chat channel is the audit trail. The finding becomes the next intent and re-enters the loop. | The return edge is where the record has to still exist. An append-only operation log written in the same transaction as the change; undo as a first-class operation; the rollback on the record the way the change was. |
A discipline held by agreement is worth having. It is not the same object as a control, and the difference only shows up on the days that matter.
It cannot bind the thing it constrains. The separation-of-duties rule the playbooks state — the agent that wrote the code has no way to approve it — is exactly the right rule, and it is implemented as a hook inside the agent's own harness. The constraint and the constrained share an address space. That holds until it doesn't, and nothing records the moment it stops.
It cannot survive the stage where it matters most. The chain is legible while the work is in flight and the session is open. The question that needs it — what was this change for, and how was it verified? — is asked at three in the morning, months later. It is asked by someone who was not there, and who cannot re-open a transcript that no longer exists.
It cannot cross a harness boundary. Every coding agent ships its own checkpoints, session store and memory files. Run three and you hold three incomplete audit trails, none of which the next agent can read and none of which outlives the vendor that wrote it. No regulator accepts any of the three, and no engineer can resume work across them.
The playbooks' own framing is that build has stopped being the constraint, and that plan, review and deploy have stretched to fill the gap. Review is where the queue is visible. Deploy and operate are where the failures are, and the 2026 field data is blunt about it: among developers using AI coding tools very frequently, 69% report deployment problems always, nearly always or frequently, and 53% report more vulnerabilities and security incidents since adoption. Mean time to restore does not improve with adoption — it goes the other way, 7.6 hours against 6.3 for occasional users.
That last number is the one to sit with. Faster authoring, slower recovery. The reason is not mysterious: recovery is a question about the past, and the past is exactly what the machinery in front of it fails to keep.
For an incident to feed the next intent — the loop's whole point — three things have to be recoverable long after the session that produced them ended, and none of them is a property of the code itself.
Which change did this, out of the hundreds that landed this week — bound to the state that shipped, not to a branch that has since moved.
What produced it: the intent it answered, the harness, the model, the session, and which human attested to it.
Undo it without losing the reasoning, and have the reversal itself be as legible as the original change was.
ADP does not deploy your software and does not watch your metrics. It has no control bands, no promotion pipeline and no pager. Those belong to your delivery stack and your observability stack, and there are good products for both.
What it owns is the record those tools need and currently do not get: written at the moment the change is admitted, in the same transaction, and verifiable later by anyone — including by someone who is not running ADP.
A page arguing that assertions are not proof should be careful about its own. Four things this is not.
ADP has no opinion about how you plan, who approves a spec, or whether you use plan mode. Adopt any of them; the record is the same shape underneath.
Planning, context and model quality are where a coding agent earns its place. Workspaces, history, evidence and identity are not — no harness should be able to compete on owning your history.
Stated once more because the temptation to blur it is real. The operation log is an input to an incident review, not the review.
What is built and what is not are listed plainly, with the partial rows marked partial, on the front page — which is the one place that claim is maintained.
One command starts a throwaway instance, then uses ordinary git and an
unmodified gh to clone, push, propose, gate and land a change. It ends on a refusal: the
merge is blocked while the change has no gate result and no approval, and allowed once it has both.
You then read the signed evidence and the operation log that say why.
git clone https://github.com/DeDuva/adp.git && cd adp make demo
Mirror mode lets ADP sit alongside a repository that stays where it is, so trying it asks one person to add a remote rather than a team to agree — self-hosting guide.
Why verification became the bottleneck, why git and the forge cannot simply be patched, and how every other entrant scores — Why ADP exists.
Published as OpenAPI with a conformance suite, versioned, and served on every response — spec/.