Practice Standard · Data & AI
Agentic AI
Development SDLC
The end-to-end process for delivering software with agentic coding assistants: readiness baseline, risk-tiered autonomy, phase gates, DORA guardrails, and the accountability model. Built on one thesis — outcome variance is a context and gating problem, and the fix is the repository, the gates, and the metrics.
Section 01
Purpose & Scope
What this page governs, who owns it, and where it yields to stricter agreements.
This page is the practice standard for using agentic coding assistants on delivery engagements. It governs how agents are used — the repository preparation, the gates, the review obligations, and the metrics — not whether they are used. Teams are held to it. Where a per-engagement client agreement imposes stricter constraints on tooling, data handling, or review, the client agreement wins. Nothing on this page authorises a tool or a data flow that an engagement contract forbids.
| Field | Value |
|---|---|
| Approved tools | Claude Code (CLI / web / IDE), GitHub Copilot in agent mode. Anything else requires security review before first use. |
| Engagements in scope | All delivery engagements, internal accelerators, and practice assets. Client agreements override where stricter. |
| Review cadence | Quarterly, and after any agent-attributed incident |
| Version | 1.0 |
§ The thesis of this page
Section 02
Why Outcomes Vary
Same tool, same task, wildly different results. The spread is observable on any engagement running agents today.
Put the same agentic assistant and the same ticket in front of two engineers and the outputs diverge far beyond what their relative experience predicts: one produces a small, well-scoped diff with passing tests and a reviewable narrative; the other produces a sprawling change that consumes more review time than it saved in writing time. The spread is not random. It traces to four causes, and each one is a property of the environment and process, not of the person.
The rest of this page is the fix for each. Section 4 repairs context starvation, Section 6 installs the plan gate, Section 5 bounds scope by risk, and Section 7 names the owner.
Section 03
How a Coding Agent Actually 10×'s a Single Consultant
Not typing speed. Six specific mechanisms, each with a concrete pattern a consultant can run this week.
The claim that agents make engineers faster is usually argued from the wrong mechanism. Autocomplete-style speed is the smallest effect. The real multipliers are structural — they change what one person can hold, supervise, and finish. Each mechanism below names the practice pattern and the worked example.
The shape of a supervised day
The two Tier 1 lanes run under agent autonomy on separate worktrees and wait at the review gate. The Tier 3 lane is human-led with the agent in analysis-only mode. The lanes never share files.
3.7 · The amplifier caveat
An agent multiplies judgement; it does not supply it. A consultant with good judgement gets leverage. A consultant without it produces bad decisions at ten times the rate — wrapped in confident, well-formatted code that passes casual review.
This is precisely why the rest of this page exists. Every section that follows — the readiness baseline, the risk tiers, the gates, the metrics — is the machinery that keeps the multiplier pointed at good judgement.
Section 04 · Phase 0
The AI-Readiness Baseline
Definition of Ready for AI. A repository is not agent-ready until every item holds — score your current engagement's repo against it.
○ This is an onboarding task, not polish
Section 05
Risk Tiers → Autonomy Levels
The governance backbone. Autonomy is not a property of the tool or the engineer — it is a property of the work.
| Tier | Work type | Agent autonomy | Required gate | Reviewer |
|---|---|---|---|---|
| Tier 1 — Low | Boilerplate, tests, docs, lint fixes, dependency bumps, formatting | Agent may work autonomously | Standard PR review | Any qualified engineer |
| Tier 2 — Standard | Feature work within existing modules, refactors, bug fixes | Agent proposes a plan; human approves the plan before code is generated | Approved plan, then passing tests | Named human reviewer |
| Tier 3 — High | Authentication, cryptography, data models, migrations, public/client-facing interfaces, IaC, anything export- or IP-sensitive | Agent may analyse and propose only. Human implements, or accepts line-by-line with justification | Line-by-line acceptance with justification | Architect sign-off required |
§ Escalation rule
Classify the work — tap an item
Section 06
The SDLC, Phase by Phase
For every phase: what the agent does, what the human owns, and the artifact that gates the transition to the next phase.
⬡ What the agent does
Drafts a specification from the ticket: goals, non-goals, constraints, open questions, proposed acceptance criteria.
◎ What the human owns
Owns and signs the acceptance criteria. Resolves the open questions with the client — the agent cannot know what was agreed in the steering call.
⛨ Gate: Spec committed to the repo
The signed spec is committed to the repository so future agent sessions read it as context rather than re-deriving intent from the code. A spec that lives in a ticket system or a chat thread is invisible to the next session.
§ The highest-leverage control on this page
The whole lifecycle on one screen
The Blueprint · End-to-End Map
How the Whole Lifecycle Connects
Every phase, block, and gate on one canvas. Hover a block to trace what it needs and what it unlocks; click to pin its detail. Turn on loops to see the governance and feedback that make it a living system.
No path from ticket to release routes around a human gate. The agent carries the volume; the human carries the judgement.
Section 07
The Accountability Principle
One sentence. It carries the weight of everything else on this page.
The human who merges is the author,
regardless of who or what typed it.
In practice this means three things. You can be asked to explain any line you merged, at any later point, and be expected to answer. “The agent wrote it” is never an incident response — it names a tool, not a cause, and it will not appear in a client-facing RCA. And authorship carries the same professional obligation it always did: merging code you do not understand was malpractice before agents existed, and it is malpractice now, at higher speed.
Section 08
Measuring It — DORA as the Guardrail
Whether delivery actually improved is the only question leadership should be asking. DORA answers it; tool-usage metrics do not.
8.1 · Why DORA and not AI-native metrics
The metrics vendors surface for AI tools measure tool usage, not delivery outcomes. A high acceptance rate is compatible with a rising defect rate; a large count of generated lines is compatible with a slowing team. The following are banned as success criteria on any engagement governed by this page:
They may be observed as diagnostics. They may never be reported as results. DORA’s four keys measure whether software delivery improved — report those.
8.2 · The four keys, and how agentic development moves each
| Metric | What agentic development typically does | The trap |
|---|---|---|
| Lead time for changesthroughput | Usually improves — plans, scaffolding, and first-draft implementation compress the writing phase. | Time shifts from writing into reviewing. Measure end-to-end including review latency, not coding time — a lead-time number that excludes review is measuring the wrong half of the work. |
| Deployment frequencythroughput | Usually improves — smaller units of work become cheap to finish and ship. | More and larger PRs queue behind a constant review capacity. Frequency gains evaporate at the review bottleneck unless review itself is resourced. |
| Change failure ratestability | The canary. If this rises, agent output is being merged without genuine comprehension. | Treat any sustained rise as a process failure, not a tooling problem — the gates in Sections 5 and 6 are being skipped somewhere. Fix the process, not the model settings. |
| Failed deployment recovery timestability | The honest test of comprehension: code nobody truly understands is slow to fix under pressure. | This metric degrades quietly and shows up late. By the time recovery time is visibly worse, the comprehension debt was accumulated quarters ago. |
8.3 · The core warning
Agentic development inflates throughput metrics first and degrades stability metrics later. The two failure curves are offset in time, and the offset is exactly the honeymoon during which bad practice gets institutionalised.
▲ Reporting rule
8.4 · Sourcing
Cite the most recent DORA / State of DevOps report by name and year when presenting this section to a client or leadership. As a reference point: the DORA State of DevOps report 2024 found that increased AI adoption correlated with small decreases in both delivery throughput and stability — evidence that adoption without the gates on this page does not automatically improve delivery. Later DORA research frames AI as an amplifier of existing organisational strengths and weaknesses rather than a uniform accelerant.
Verify current findings — including DORA’s published AI-related capability guidance — against the latest report before publishing or presenting; do not rely on remembered figures, including the ones in this paragraph.
LAST VERIFIED: 2026-07 · RE-VERIFY BEFORE EACH CLIENT PRESENTATION
8.5 · Supporting measures
| Measure | What it tells you |
|---|---|
| Revert and rework rate | How much merged work gets undone — the fastest proxy for comprehension debt. |
| Review turnaround time | Where the reclaimed writing time actually went. Rising turnaround means the bottleneck moved, not disappeared. |
| Coverage delta on touched files | Whether agent-assisted changes leave files better-tested than they found them. |
| Time-to-first-meaningful-PR on new engagements | The consultant-specific headline metric from Section 3.1 — the largest ROI is here. |
| Proportion of PRs merged with an approved plan | Direct compliance measure for the planning gate — the most-skipped control on this page. |
§ 8.6 · Baseline discipline
Section 09
Safety, Compliance & Client Constraints
Written for regulated, IP-sensitive client contexts — where data handling constraints are contractual, not theoretical.
Which tool, which tenant, zero-retention configuration, and whether client code may leave the approved environment — confirmed in writing, per engagement, before first use. Never assumed from a previous engagement: the same tool under the same vendor can sit under a different contract, tenant, and retention posture from one client to the next.
Where the engagement touches export-controlled technology or sensitive IP, obtain explicit legal sign-off on agent use before the first prompt. Do not infer permission from silence — silence means the question has not been answered, not that the answer is yes.
Run software composition analysis on every agent-suggested dependency. Hallucinated and typosquatted package names are a live, exploited attack vector — attackers register packages at the names agents plausibly invent. License scanning on everything added. Enable duplicate-detection / public-code filtering where the tool offers it.
No exceptions in the default posture, and no “anonymised” carve-out without explicit sign-off from the data owner and the compliance function — anonymisation claims are assertions to be verified, not permissions to be assumed. Use synthetic fixtures; the readiness baseline requires them anyway.
Internal coding assistants generally sit in the lowest risk category under the EU AI Act, meaning obligations centre on transparency and staff AI literacy rather than conformity assessment. Confirm this classification with the compliance function per engagement and record the date of confirmation — it is their call to make and their signature to give, not engineering's to assert.
Incident path — when agent-attributed code causes a client-visible defect
Treat it as any client-visible defect first: fix or roll back under the normal incident process. The agent's involvement changes the follow-up, not the triage.
Section 10
Anti-Patterns
Named, because people remember names better than rules. Each one carries its own mark — and a link back to the gate it violates.
Vibe merging
Approving a diff you cannot explain. The code looked plausible, the tests were green, and nobody in the room can say what it does.
The mega-prompt
One prompt asked to do six unrelated things. The result is one unreviewable diff instead of six reviewable ones.
Self-marking homework
The agent writes both the code and the test that validates it, and nobody reads the test. The suite passes because it was written to.
Context starvation
No agent instruction file, so the agent guesses conventions. Every session re-guesses differently, and the codebase drifts.
Chat-history-as-documentation
The design reasoning lives in a transcript that expires with the session. The next engineer — human or agent — starts from zero.
Autonomy creep
Tier 3 work quietly handled at Tier 1 autonomy because it was faster this once. The tier table only works if the inconvenient rows are enforced.
The metrics honeymoon
Celebrating throughput while stability drifts. Two quarters of applause, then a change-failure-rate chart nobody wants to present.
Section 11
Living Practice Library
The feedback loop that actually collapses variance over time — individual discoveries become practice defaults.
Every engagement discovers things: a prompt pattern that reliably produces reviewable plans, an instruction-file section that stops a recurring class of mistake, a tier call that was not obvious. The loop is mandatory in both directions — anything that worked goes back into the repo’s agent instruction file, so the next session on that engagement benefits, and into the practice-level library, so the next engagement starts where this one finished. Variance between consultants collapses precisely as fast as this loop runs.
What belongs in the library
| Asset | Why it is there |
|---|---|
| Instruction file templates by stack | Python/data, TypeScript/web, Terraform, Databricks — a consultant starts from the right template, not a blank file. |
| Plan templates | The stepwise implementation-plan format from Section 6, ready to fill. |
| ADR templates | Decision, context, options considered, consequences — the format agents draft into. |
| PR template | With the AI-involvement declaration from Appendix B. |
| Tier-classification examples | Real, anonymised judgement calls — especially the ones that were escalated. |
| Reusable prompts | Codebase archaeology, adversarial review, and test-first delegation — the three from Section 3 that transfer between engagements. |
Section 12
Adoption & Rollout
Sequencing matters more than content. A correct standard introduced in the wrong order becomes shelfware.
Lead with evidence of variance
Open with three real PRs from a live engagement showing the spread — same tool, same week, radically different review burden. Not with the framework. The framework is the answer; the PRs are the question that makes anyone care.
Co-sign before publishing
The delivery lead and the security/compliance function review and co-sign this page before it ships, so it lands as a practice standard rather than one architect's opinion.
One diagram only
The phase table with agent/human/gate columns is the diagram. If explaining the SDLC needs two diagrams, it is too complex to adopt.
Ship copyable artifacts with the page
Instruction file template, PR template, readiness checklist, and one exemplar repo that passes the Definition of Ready. A standard nobody can copy from is a poster.
Pilot, don't mandate
Two teams, six weeks, an agreed DORA baseline captured before the pilot and re-measured after, results published internally regardless of what they show.
Run a clinic, not a broadcast
A 90-minute working session where each team makes its own repo agent-ready beats any presentation. People adopt what they have already half-built.
Section 13
Appendices
The copyable artifacts. A standard nobody can copy from is a poster — start every engagement from these.
The root instruction file, complete and copyable. Replace the angle-bracket placeholders with engagement specifics; delete nothing without a reason. The same content, re-sectioned, serves as .github/copilot-instructions.md.