AI across the SDLC

Two years ago the working model was a developer, a prompt, and a review. The mature version of the same thing has very little to do with phrasing a request well. It is about the environment the request lands in, and about what checks the output before a person spends attention on it. The vocabulary moved with it: from prompt engineering to context engineering and harness engineering.

What changed between 2025 and 2026

The 2025 loop

Prompt in, code out, human catches everything

• Developer writes a prompt against whatever the model happens to know.
• The model returns code.
• A person is the first line of defence against every class of error.
• Quality depends on how well individuals prompt.

The 2026 loop

Intent in, verified change out, human judges

• Intent and specification are version-controlled artifacts.
• Curated context makes the system legible to the agent.
• The agent acts, then deterministic checks answer it.
• Model review adds a semantic pass; human judgement decides.
• CI/CD carries the result on the same rails as everything else.

The chain, stage by stage

Each stage of delivery is a separate question with its own inputs, its own output, and its own answer to where a model helps. Which is why they are worth naming separately instead of calling the whole thing "the process". Most teams have not tried the last four stages at all. In my experience that is where the first strong return usually sits, because the outer loop around development is less contested than the code itself.

Where AI actually lands in each stage

Where AI actually lands in each stage

01DiscoveryAI-assisted refinement of the request itself.02PlanningSpec-driven development, not ticket-driven.03ArchitectureCodebase archaeology on demand.04DevelopmentA coding agent inside a bounded task.05TestingAgentic testing against the specification.06ReviewLayered review, one reviewer per concern.07Continuous integrationRemediation agents on a failed pipeline.08SecurityDeterministic scanning plus semantic review.09DocumentationThe change writes its own trail.10OperationsAI-assisted SRE on the signals you already collect.11MaintenanceContinuous gardening instead of a quarterly reckoning.

01 / 11

Discovery

The model reads a feature request the way a sceptical engineer would: looking for the ambiguity and the edge cases before anyone commits to building.

• Pull apart the request and name what it does not say.
• Propose acceptance criteria and the non-functional requirements nobody wrote down.

Hands overA request with its unknowns made explicit.

02 / 11

Planning

Requirement becomes specification, specification becomes design, design becomes tasks with a definition of done. Each step is reviewable on its own.

• Turn the requirement into a specification with invariants.
• Decompose into tasks an agent or a person can pick up.

Hands overA plan that can be checked against the intent.

03 / 11

Architecture

Reconstructing what the system already does is the expensive part of most changes. This is where a model earns its cost first.

• Dependency and impact analysis across the repositories a change touches.
• Draft the ADR, the migration plan, and the threat model for humans to argue with.

Hands overA decision record with the blast radius attached.

04 / 11

Development

The agent takes a task, investigates the repository, writes or refactors, and runs the checks before it hands anything over.

• Investigate first, change second. The change follows from what the repository actually contains.
• Run the project checks and iterate on its own failures.

Hands overA branch that already survived the cheap checks.

05 / 11

Testing

Tests written against the acceptance criteria rather than against the implementation, and failures analysed rather than merely reported.

• Generate and run unit, integration, and end-to-end coverage.
• Analyse the failures and separate a broken test from a broken change.

Hands overA green build with traceable coverage.

06 / 11Human gate

Review

Separate passes for correctness, security, performance, and architecture beat one general reviewer, because each pass can be evaluated on its own.

• A distinct reviewer per concern rather than one general opinion.
• Mandatory human review on every production change.

Hands overAn approved change with its review trail.

07 / 11

Continuous integration

A failed build is a well-specified problem with a reproducible signal, which makes it one of the most tractable places to let an agent work unattended.

• Investigate the failure, reproduce it, propose or open a fix.
• Keep write access bounded to what the workflow needs.

Hands overA diagnosed failure, often with a fix attached.

08 / 11Human gate

Security

The deterministic half (SAST, dependency scanning, secret detection) stays exactly where it was. The model adds the pass that reads intent rather than patterns.

• Run the deterministic scanners first and cheaply.
• Add a semantic security review on top, never instead.

Hands overFindings a person can triage.

09 / 11

Documentation

Documentation is the classic example of work that is always worth doing and never worth doing now. It is also work an agent can do from the diff.

• Turn a merged change into documentation, release notes, and ADR updates.
• Route the result to the owner as a pull request, never a direct write.

Hands overA documentation change a person can approve in minutes.

10 / 11Human gate

Operations

Logs and traces are exactly the kind of high-volume, low-structure evidence a model reads faster than a person under time pressure.

• Turn logs and traces into hypotheses ranked by likelihood.
• Draft the incident summary and a proposed remediation for a human to accept.

Hands overA timeline and a candidate remediation.

11 / 11

Maintenance

Dead code, dependency drift, duplicated abstractions, and architectural violations accumulate continuously, so they should be found continuously.

• Run on a schedule, detect deviations, classify them.
• Open small targeted pull requests rather than one heroic cleanup.

Hands overA steady stream of small, reviewable cleanups.

Context engineering is most of the work

An agent without context is expensive autocomplete. The practice that makes the difference is making engineering knowledge machine-readable and reachable, and that is mostly an organisational act rather than a tooling one.

repo
 ├── AGENTS.md              <- a short map, an index, not a manual
 ├── docs/
 │    ├── architecture/
 │    ├── product/
 │    ├── security/
 │    ├── reliability/
 │    └── decisions/
 ├── specs/
 ├── source code
 └── tests

Beyond the repository, the same principle extends to the systems that already hold the answers: issue tracker, knowledge base, code host, error tracking, logs and traces, product documentation, service catalogue, design system.

Specification as a version-controlled artifact

Ticket to specification to implementation is no longer a personal preference. Intent and constraints become an engineering artifact held in version control, near enough to source code that the same review discipline applies:

requirement → specification → acceptance criteria and invariants
    → technical plan → task decomposition
    → agent implementation → verification against the specification

A specification carries more than a user story: the domain entities, the approach, the structure, the operations, the norms, and the safeguards. The practical consequence is a different repair order. When the implementation diverges from the intent, you correct the specification first and regenerate the implementation, instead of patching the code until it passes.

Verification is where the engineering actually is

Generation is no longer the constraint. Verification is. Time saved writing code gets partly spent auditing what was generated, and throughput can rise at the same time as instability. That is the combination worth watching for. So the harness matters more than the model:

                     Human judgment
                  AI semantic review
              Architecture / security review
           Integration / E2E / mutation tests
       Unit tests / SAST / dependency checks
   Compiler / types / lint / formatting / secrets

The useful distinction is what kind of answer each layer gives.

The point of both is the same: a person should not be the first to discover an obvious mistake. The agent should get that feedback itself and take another iteration.

Architecture as an executable constraint

A rule in a document can be ignored. The same rule as a dependency check, an architecture test, a custom lint rule, or a CI policy comes back to the agent as something it can act on:

ERROR:
payments/domain must not depend on payments/infrastructure.
Move the adapter behind PaymentsRepository.
See docs/architecture/payments.md.

That is a message an agent can resolve on its own. It is also a message a new engineer can resolve on their own, which is the tell that this is good engineering practice independent of AI.

More than one agent, but only where it pays

The pattern is real: a planner, an implementation agent, a test agent, a security reviewer, a code reviewer. Or several agents in parallel on implementation, tests, security, and documentation, each in an isolated worktree so they do not collide.

Taking AI out of the inner loop

The shift I find most interesting is that the developer does not have to be the one asking. An event happens, an agent starts, reasons, and takes a bounded action:

• a failed pipeline → investigate, reproduce, fix, test, open a pull request;
• a dependency CVE → impact analysis, upgrade, regression run, pull request;
• a merged change → detect what became user-facing, update the documentation, open a pull request;
• a weekly schedule → inspect the repository for drift, dead code, and debt, open one targeted cleanup.

Issue triage, CI failure analysis, documentation, repository maintenance, and compliance are the workflows being run this way in production today, and the security model is the interesting part: read-only by default, sandboxed, with narrow sanitised write operations. This is where an agentic SDLC starts. Not with AI writing feature code.

The maturity ladder

If I were introducing this into an organisation, I would present a maturity roadmap rather than a tool roadmap. Tools change every quarter; the order of these stages does not.

The rule that holds the ladder together is the first principle above: autonomy follows verification capability. Stage 5 without stage 3 is how an organisation ends up auditing machine output by hand.

What I would actually do

A practical adoption order

1. 01

   Find the bottleneck and take a baseline

   Buying AI because it is AI is how you end up with an expensive assistant on a stage that was never slow. Take lead time, deployment frequency, change fail rate, recovery time, rework, review latency, escaped defects, and how the work feels to the people doing it.

2. 02

   Set the policy and limit the scope

   Set permitted models and tools, confidential data, secrets, intellectual property, and access permissions explicitly. Pick two or three workflows with measurable pain, not eleven.

3. 03

   Make knowledge reachable and build the harness

   Make engineering knowledge reachable in the structure above. Build the verification harness and branch protections before you open access up.

4. 04

   Start with the human in the loop

   Start human-in-the-loop, everywhere, without exception. Capture repeated corrections back into repository rules and tooling instead of correcting them again.

   Human gate

5. 05

   Measure, then raise autonomy

   Measure the outcome against the baseline. Only then raise autonomy, one class of change at a time.

Measuring it without fooling yourself

Do not measure lines of AI-written code, tokens consumed, prompts issued, suggestion acceptance rate, or pull requests per developer. Token consumption in particular is not a productivity metric, and none of these belong in an individual's performance review. The moment they do, they stop measuring anything except how people respond to being measured.

Underneath those sit the five delivery metrics DORA now uses: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Measuring the system before and after, rather than any individual AI-written ticket, is the same discipline that already applied to every other process change.

Where I think the boundary is