# AI across the SDLC Source: https://manaienko.com/how-i-work/ai-sdlc/ Author: Artem Manaienko The industry moved from prompting to context and harness engineering. Here is what that means stage by stage, what I would build first, and where I think the evidence stops. ## My principles 07 operating rules 1. [01 Autonomy follows verification capability](#practice-ai-sdlc-principle-1) 2. [02 The environment is the product](#practice-ai-sdlc-principle-2) 3. [03 Treat the request as a hypothesis, the specification as the artifact](#practice-ai-sdlc-principle-3) 4. [04 Fix the specification, not the code](#practice-ai-sdlc-principle-4) 5. [05 Architecture becomes an executable constraint](#practice-ai-sdlc-principle-5) 6. [06 Add a machine gate on top of the human one](#practice-ai-sdlc-principle-6) 7. [07 Measure the system, before and after](#practice-ai-sdlc-principle-7) ### Autonomy follows verification capability The question is never "should we give the agent more freedom and see what happens". It is whether we can automatically prove correctness for this class of change. Where we can, autonomy goes up. Where we cannot, it stays where it is. ### The environment is the product A coding agent without context is expensive autocomplete. The work is making the engineering environment legible to humans and agents alike, as structured, version-controlled knowledge instead of a longer instruction file. ### Treat the request as a hypothesis, the specification as the artifact A free-form request is a hypothesis, and an agent implements a conclusion very faithfully, including the parts that contradict the codebase, the previous ticket, and the product principle nobody wrote down. So the input gets checked against the current product definition, the code, the tests and the architecture, then frozen before planning starts. Specific enough to evaluate, small enough to revise. ### Fix the specification, not the code When an implementation diverges from the intent, correct the specification and regenerate rather than patching code until it passes. A patched implementation leaves intent and code quietly disagreeing, and the next change inherits the disagreement. The specification is the version-controlled thing a person can argue with, and the code is derived from it. ### Architecture becomes an executable constraint A rule written in a document gets ignored by a model as easily as by a person. The same rule as a dependency check, an architecture test, or a CI policy comes back to the agent as an error it can act on. Adoption pushes an organisation from conventions towards executable policy. ### Add a machine gate on top of the human one Deterministic checks and model review both sit below human judgement, not in place of it. What changes is that a person should no longer be the first one to notice an obvious defect. ### Measure the system, before and after Not accepted suggestions, tokens spent, or PRs per engineer. Delivery outcomes for the team, with quality and cost sitting next to throughput, because a change that raises speed and instability together has not paid for itself. 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 interesting engineering moved out of the prompt and into the harness around it: the environment where an agent can understand the system, change it, check itself, and correct before a person is involved. ## 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 stage01 Discovery AI-assisted refinement of the request itself.02 Planning Spec-driven development, not ticket-driven.03 Architecture Codebase archaeology on demand.04 Development A coding agent inside a bounded task.05 Testing Agentic testing against the specification.06 Review Layered review, one reviewer per concern. 07 Continuous integration Remediation agents on a failed pipeline.08 Security Deterministic scanning plus semantic review. 09 Documentation The change writes its own trail.10 Operations AI-assisted SRE on the signals you already collect. 11 Maintenance Continuous 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 / 11 Human 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 / 11 Human 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 / 11 Human 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. Eleven stages, one gate discipline. The marked stages are the ones where a wrong change is expensive enough that a person still signs it. ## 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. The index, not the mega-prompt The failure mode is turning `AGENTS.md` into a five-thousand-line instruction file. It should be an index. The authoritative knowledge belongs in structured, version-controlled documents that humans read too. The goal here is making the engineering environment legible to both humans and agents, not teaching engineers to prompt better. ## 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. | Kind of check | What it is | Property | | --- | --- | --- | | **Computational sensors** | Type checker, lint, tests, SAST, dependency rules, coverage, mutation | Deterministic: the same input gives the same answer | | **Inferential sensors** | Architecture review, maintainability review, security and code reasoning | Probabilistic: useful, never authoritative | 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. Orchestration is a cost, not a feature More agents is not automatically better. Each one adds cost, latency, coordination complexity, and nondeterminism. Add orchestration only where the separation of concerns measurably improves the output. Otherwise it is a diagram that bills by the token. ## 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. | Stage | What happens | | --- | --- | | **0 · Baseline** | Measure the SDLC you already have | | **1 · Assist** | IDE assistants, codebase Q&A, test generation | | **2 · Standardise** | Policy, shared instructions, curated context, approved models | | **3 · Harness** | Tests, linters, architecture rules, security gates | | **4 · Delegate** | Specification to autonomous draft pull request | | **5 · Automate** | Event-driven agents: CI, documentation, maintenance, triage | | **6 · Optimise** | Measure return, remove bottlenecks, raise autonomy where proven | 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. The adoption sequence starts with a delivery problem and baseline, then raises autonomy only after the boundaries and feedback loop exist. ## 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. | Layer | What it answers | | --- | --- | | **Utilisation** | Active users, which workflows use AI, how often | | **Impact** | Time saved, lead time, review time, deployment throughput | | **Quality** | Change fail rate, rework, escaped defects, incidents, maintainability | | **Economics** | Model and tool cost against engineering time and value delivered | 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 | Mature enough to adopt | Maturing quickly | Still experimental | | --- | --- | --- | | Coding assistants, codebase Q&A, test generation, AI review, documentation, CI diagnosis, bounded coding agents | Specification to autonomous pull request, specialised multi-agent setups, event-driven workflows, maintenance agents | Fully autonomous end-to-end delivery, long-running agents without a serious harness, architectural decisions without people, broad autonomous production remediation | Where these claims come from The industry positions on this page are drawn from published material by DORA, Thoughtworks, GitHub, OpenAI, and Anthropic, and from my own delivery experience where it is marked as such. The five DORA delivery metrics are verified against DORA's own guidance; the remaining attributions are as reported by those organisations rather than measurements I have reproduced. Where I am stating a position rather than a finding, I have written it in the first person. The delivery system I run this way is one person's, on a private pre-launch product, under a rule that permits no force-push, merge commit or gate bypass. That says the discipline holds under load. It says nothing yet about how it transfers to a team.