How to Introduce an AI-Augmented SDLC Without Disrupting Your Current Engineering Workflow

Author: Zartis Team
Categories: AI, Newest

Two studies published within months of each other tell opposite stories about the same technology. Harness’s case study of a GitHub Copilot deployment across 4,800 Accenture developers found pull request cycle time fell from 9.6 days to 2.4 days and merge rates rose by 11%. A randomised controlled trial by METR, run on 16 experienced open-source developers across 246 real tasks, found that AI assistance made them 19% slower, despite every one of them predicting a speed-up beforehand. Both studies are credible, and both are about the same class of tool. What separates them is what the organisation around the AI was doing before it arrived, and how the rollout was sequenced.

The thesis of this piece is straightforward: an AI-augmented SDLC pays off when it is introduced in stages, starting with human-reviewed specifications and the other stages where a wrong output is cheap to catch, and expanding only after each stage proves out under real monitoring, rather than switching on AI assistance across planning, coding, review, testing and deployment all at once.

DORA’s 2025 State of AI-assisted Software Development report, based on responses from over 5,000 practitioners, found adoption at 90%, up 14 percentage points year on year, with more than 80% reporting productivity gains. The same report also found that higher AI adoption correlates with increased delivery instability where the underlying testing and version-control discipline is weak. Its own framing is the clearest single sentence in the research: AI amplifies whatever engineering practice already exists. Teams with disciplined review and test coverage got faster and more reliable. Teams without it got faster and less reliable, which is a worse position than either faster-and-reliable or slower-and-careful. Sequencing decides which of those two groups a given rollout lands in.

Why simultaneous rollout produces the METR pattern

The instinct to give every team, every stage, and every developer access to AI tooling on day one is understandable. It is also the reason the METR result and the GitClear result exist.

GitClear’s 2025 analysis of 211 million lines of code found code churn rising from 3.3% to 7.1% and the share of lines that were genuine refactors, as opposed to new additions or copy-paste, falling from roughly a quarter to under a tenth. That pattern shows up when AI-generated code lands faster than a team’s review and test infrastructure can absorb it: nobody consolidates or refactors because everybody is busy keeping up with new volume. The Stack Overflow 2025 Developer Survey puts a number on the downstream cost: 84% of developers use AI tools, but only 29% trust the accuracy of what comes back, down 11 points on the previous year, and 66% say they now spend more time fixing “almost right but not quite” AI output than they saved generating it.

The tools do produce gains, as the Accenture numbers show. Turning them on everywhere before any single stage has demonstrated it can absorb the change safely produces the compounding risk the METR and GitClear numbers describe: every stage inherits the unmanaged risk of the stage before it, with no checkpoint that catches a problem before it reaches production.

The phased sequence: start where mistakes are cheap

A workable rollout sequence orders SDLC stages by two factors: how expensive a wrong output is to catch, and how reversible it is once caught. Stages that score well on both come first. Specifications score best of all, and everything later in the sequence builds on them.

Phase 1: Specifications and planning, with documentation, test generation and review assistance alongside. AI drafts the specification for a piece of work from the ticket and the existing codebase: scope, acceptance criteria, the parts of the system it touches, and an implementation plan. A named human (a tech lead or product owner) reviews and approves it before any code is written. A wrong spec at this point costs the time it takes to read and correct it, and a scoping mistake is cheaper to catch here than at any later stage of the lifecycle. The approved spec then becomes the reference for every phase that follows: tests are generated against its acceptance criteria rather than inferred from the code they are meant to check, reviewers compare AI-drafted code with what the spec said it would do, and the risk tiers in phase 3 can be read from what the spec says a change may touch.

Documentation, test generation and code review assistance start in the same phase. These are the stages Meta’s RADAR system and Salesforce’s nine-stage Agent Coding Maturity Curve both treat as entry points, and for the same reason: an AI-drafted test case or an AI-flagged review comment is checked by a human before it has any effect, so a wrong output costs a few minutes of a reviewer’s time. This phase builds the habit of checking AI output critically, which every later phase depends on, without any change to what actually ships.

Phase 2: AI-assisted coding against approved specs, within existing review gates. Developers and coding agents work from the approved spec, and every change still passes through the review and test process that existed before. This is where the Accenture case study numbers largely came from: throughput rose while the review gate stayed in place, with less mechanical work to do. This phase is also where the DORA report’s caution applies most directly. PR size and review load rise here, so it is the point to strengthen automated checks. A clear spec helps reviewers keep pace, because they are checking the code against a written statement of intent instead of reconstructing that intent from the diff.

Phase 3: Risk-tiered CI/CD autonomy. Only once phases 1 and 2 have run long enough to generate real data on defect rates and review load does it make sense to let AI-touched changes progress with reduced human gating, and only for a defined subset of changes. Meta’s RADAR pipeline auto-approves low-risk diffs, classified by a model trained on the link between past diffs and the incidents that followed them, while routing anything higher-risk to a human reviewer. A trust-tier framework for AI-augmented CI/CD describes the same principle at the pipeline level: autonomy is earned per class of change, based on demonstrated reliability, and release authority stays with a named human throughout. Concretely, that means defining tiers (a documentation fix or dependency bump versus a change to authentication or payment logic) and writing down, in policy, which tier can progress with automated checks alone and which requires sign-off. Neither Meta’s nor the CI/CD paper’s model removes a human decision maker; both narrow which decisions still need one.

As autonomy extends, human attention moves upstream. Engineers spend a growing share of their review time on specifications and plans, and automated checks within the agreed tiers handle more of what follows. That end state depends on spec review having been a team habit since phase 1. A team that introduces AI into planning last arrives at phase 3 without the written statements of intent that make reduced gating safe. The quantified evidence on AI in the planning stage is thinner than for coding and review, so it is worth tracking a spec-stage measure from the start, such as how often an approved spec has to be reopened during implementation.

Governance attached to each phase

A phased rollout only works if governance is attached to each phase rather than added afterwards as a single company-wide policy. Three practices recur across the research:

Explicit risk tiers, written down. The line between “can auto-progress” and “needs a named human sign-off” should be documented per class of change, instead of being left to individual judgement on a given pull request. A specification-driven governance framework for AI-augmented development argues that the gap between expected and actual reliability narrows when governance is tied to a written specification of what a change is allowed to do, rather than to a generic “AI output gets reviewed” rule. The specs approved in phase 1 supply that written statement.
Monitoring before each expansion. Each phase needs its own metrics, tracked before the next phase begins: defect rate, PR cycle time, review load, and revert rate are the four DORA and GitClear both treat as leading indicators of whether a stage is ready to expand. For the specification stage, add the reopened-spec rate described above.
A rollback path as cheap as the change it protects. Feature flags, staged deployment, and clean revert paths matter more once autonomy increases in phase 3, because the cost of getting a tier wrong falls sharply if the wrong decision is reversible within minutes rather than requiring a hotfix cycle.

The organisational piece the case studies undercount

The productivity numbers get the attention, but McKinsey’s research on scaling AI in software development found that 57% of top-performing organisations invest in hands-on workshops and coaching for their engineers, against 20% of the weakest performers, and separate EPAM analysis puts the pilot failure rate at 80%, with only 37% of organisations investing meaningfully in change management alongside the rollout itself. Sequencing the technology correctly and skipping the training are a half-measure: the trust gap the Stack Overflow survey documents does not close on its own, and a developer who does not trust AI-generated tests will not build phase 3 autonomy on top of them, regardless of how sound the tiering policy is on paper. Writing and reviewing specifications that an AI agent can work from is also a skill in its own right, and it needs the same coaching.

How Zartis helps

Zartis works with engineering leadership on both halves of an AI-augmented SDLC rollout: the advisory work of mapping a team’s existing workflow into a phased sequence with the right risk tiers for its codebase and regulatory context, and the delivery work of building the specification practice, tooling, gates, and monitoring that make each phase work in practice. That includes structured AI Training and Enablement built around Claude, powered by Anthropic, for engineering teams adopting agentic coding tools directly in their day-to-day workflow (delivered through Zartis’s Claude Code Workshops), and ongoing AI-Enabled SDLC delivery once the phased rollout is running. Zartis is a Preferred Services Partner in the Claude Partner Network, which means this work is advised and delivered directly rather than handed off. We build the pipeline and the review discipline alongside your engineers until your team is running it unassisted.

If your organisation is weighing where to start an AI-augmented SDLC, or is already mid-rollout and seeing the DORA pattern of faster delivery and rising instability, that is a sequencing problem with a known set of fixes. Talk to Zartis about auditing your current stage-by-stage AI exposure and designing the phased rollout that gets you the Accenture numbers rather than the METR ones.