We build software with AI agents every day. The AI-SDLC process we use ourselves, implemented with your team and measured before and after.
Agents, an AI reviewer and CI checks that block failing merges in 2-3 areas of your delivery, tracked on five team numbers. AI-SDLC: the software development lifecycle run with AI agents.
You prepareYour CTO and 2-3 tech leads, one pilot team, read-only access.
We deliverDiscovery and analysis, then 2-3 areas improved (for example code review or testing), measured, handed over.
Your goals, your delivery flow, the data to read.
Goals agreed, your ticket-to-production flow mapped, data access ready.
You prepareYour CTO and 2-3 leads; the self-check report, if you ran it.
We deliverA facilitated workshop, the flow map and the data plan.
your team us agreed together
Agenda
- Frame
Goals, rules of the engagement, the 16 areas and the maturity ladder.
- Self-check walk-through
If you ran it: the likely blocking area and the questions it leaves open.
- Map the delivery flow
From ticket to production: where work waits, where AI is used today.
- Known problems
One list, each problem with an owner on your side.
- Data plan
Tickets, git host, CI and incidents for the last 3-6 months; access, the data agreement, the formula of each of the five numbers.
- Close
Participants and date of the maturity workshop.
Who takes part
CTO or VP Engineering, 2-3 tech leads, the product or ticket owner (optional); we facilitate.
Data rules first
A signed data agreement before any access:
- which tools may read the data
- where it stays and how long it is kept
- deletion after
- no client code trains a model
Numbers are per team, never per person; in Germany the data use is agreed with the works council first (CMS).
Where it sits
Step 1 of Phase 1, Discovery and analysis (1-2 weeks). Covered by the Discovery and analysis plan and by the AI-SDLC Package.
Sixteen AI-SDLC areas scored on your tickets, git, CI, incidents and interviews.
A draft level per area from your data; the lowest marked.
You prepareRead-only access to tickets, git, CI, incidents and scanner alerts; short interviews with 2-3 leads.
We deliverDraft scores with evidence, the baseline, each problem marked: AI can fix it, partly, or not.
Baseline: five team numbers and one security number demo
Per team, split into AI-assisted and other work. A number your history cannot give gets its baseline from the first 2 weeks of Implementation.
Plus one security number, from your scanner and git history: . Measured the way the Verizon DBIR 2026 measures it; its median is 43 days. Your security team already tracks it, and it drops within weeks once upgrade pull requests are opened overnight (Security).
Example
The data shows AI pull requests waiting 21 h for a first review, other pull requests 13 h, so Code Review is drafted as the lowest area.
Problems marked
Level criteria per area
L1 Ad hoc: a person writes and checks. L2 Guided: an agent writes, a person checks all. L3 Systematic: an agent writes, the pipeline checks first. L4 Optimised: an agent ships when the checks pass; people approve only flagged exceptions.
Customer case
Test-automation SaaS company.
- The analysis run found that only 0.7% of finished tickets were linked to a release, so no before/after claim on AI delivery gains could hold.
- Fix: the deploy pipeline writes the release onto the ticket, as the first change.
Next: Maturity workshop
Your leads score the 16 areas together against these drafts, place the team on the team ladder and agree the weakest area. Maturity workshop →
Your leads agree each area's level, the team's average level and the weakest area.
One agreed team level and one weakest area, checked on evidence.
You prepareYour CTO, 2-3 tech leads, QA and release owners.
We deliverFacilitation, the evidence check, the agreed level and weakest area.
The delivery process is how a team moves from 2 to 3.
After the workshop
- Choose the delivery process →
Spec, agents, CI gate, chosen on the agreed scores.
- Report and roadmap
Scores, baseline, ranked changes, the chosen process.
- You decide
Stop, go alone, or continue to Implementation →
Agenda
- Frame
Area levels L1-L4, target L3; the team ladder.
- Score together
For each of the 16 areas the leads read the criteria and tick what the team meets, with evidence: a file, a setting, a report.
- Evidence check
We show what the analysis of your data found; a score is corrected where the evidence disagrees with a tick.
- Place on the ladder
Average level below 1.5 is Ad hoc, below 2.5 Guided, below 3.5 Systematic, otherwise Optimised.
- Agree the weakest area
And why it blocks the others.
- Rank and choose
Problems ranked by expected gain; the CTO picks 2-3 areas for Implementation.
Duration: TIME_PLACEHOLDER. Groups above 8 people split for the first rating of each area, then agree one score.
Who takes part
CTO or VP Engineering (opening and close), 2-3 tech leads (all blocks), QA lead, DevOps or release owner; a security contact for the governance block (optional). We facilitate.
Report and roadmap
- Scores with evidence, the baseline, the weakest area.
- The chosen delivery process and its set-up list.
- Ranked changes, each marked "you alone", "with us" or "not an AI problem".
- For each number: a formula, a window, a target and a guardrail.
- A debrief, TIME_PLACEHOLDER.
Your decision
Stop and keep the report, make the changes alone, or continue to Implementation for 2-3 areas each passing its agreed checks. The Discovery and analysis plan ends here; the AI-SDLC Package continues.
Demo team
Average area level 2.1, so Guided on the team ladder. Moving up starts with Code Review: a written rule for which changes need a person, then AI pre-review of every change and a pull-request size limit. Each rung usually moves the bottleneck: at Guided it is review, at Systematic it is planning and release, at Optimised it is the decisions only people make.
One path for agents from ticket to merge.
One delivery process and the agent setup that runs it, chosen on your data, in the roadmap.
You prepareYour stack, a ticket sample, existing architecture decision records (ADRs), specs and your rules file.
We deliverOptions scored against your criteria; the choice written as an ADR.
Your maturity scores and stack
A ticket sample and your ADRs
Size of a typical change
Approvals and audit trail you need
Who writes requirements
Spec Kit documents, Claude Code subagents (one agent per task), your CI as the gate
Recorded as an ADR; goes into Report and roadmapInputs
- Maturity scores and the team's place on the team ladder
- Stack and the coding agent you allow
- A ticket sample
- Existing ADRs, specs and your rules file
Criteria
- Place on the team ladder
- Typical change size
- Code base age and size
- Stage approvals and audit trail
- Who writes requirements
- Licence and upkeep
Options and when each fits
- Default: Spec Kit documents, Claude Code subagents, your CI
- A constitution filled from your ADRs, then spec.md (the product requirements document, PRD), plan.md and tasks.md per change.
- One implementer and one reviewer subagent per task.
- The pull request merges only when CI passes and a person approves.
- Small changes take a light path: a one-page spec.
- Chosen for its user base (140,000+ GitHub stars), MIT licence and plain Markdown any agent can read.
- OpenSpec
Large, old code base where most work is small changes: one change folder per change, spec deltas.
- cc-sdd
Team ready for unattended runs at the Systematic level: parallel batches, a reviewer per task.
- AWS AI-DLC
Approval per stage and an audit trail are required, as in regulated work.
- BMAD Method
Nobody writes requirements: it drafts the brief, PRD, architecture and stories first.
- Superpowers
A packaged runner on Claude Code with a fixed workflow is wanted.
- Kiro specs
An AWS shop that wants one supported, paid IDE.
- Agent OS
Added to any option when agents ignore team conventions.
Who and when
After the maturity workshop, inside the 1-2 weeks of Phase 1. We propose; your CTO and tech leads agree it at the Report and roadmap debrief.
Set up in Phase 2
With the pilot team:
- spec, plan and task templates
- the PRD and ADR standard in docs/prd and docs/adr
- implementer and reviewer agents within the guardrails
- the code-review, security-guidance and tracker plugins
- the CI gate
The first 2-3 pilot tickets run through it. In Hand over, one of your tech leads becomes its owner.
What the evidence does not show
No published study shows that a spec step improves delivery outcomes. So we propose it, and Measure reports tickets run through it apart from the others; the pilot team decides whether it stays.
2-3 areas changed with one pilot team in 4-8 weeks.
Changes merged in your repositories, each passing its agreed checks.
You prepareA sponsor, one pilot team and an owner per area.
We deliverGuardrails, the delivery process, then 2-3 areas changed with your team.
your team together with us
Typical changes
- Tickets
Small changes with an acceptance check and a readiness check; work starts after a person approves the plan (AWS AI-DLC).
- Rules and context
A short rules file per repository, versioned and reviewed, kept only where a test shows it helps (Gloaguen et al.).
- Code Review
AI pre-reviews every change; a person reviews every risky one; nobody approves their own; a size limit (OpenSSF Scorecard).
- Testing and CI on main
AI changes ship with tests; checks block invented packages (Spracklen et al.) and unlicensed open-source matches (LiCoEval).
- Tracing
Every finished ticket links to the deployment that shipped it.
- Security and governance
Each agent has a name, an owner, least-privilege access, a sandbox, an audit log, a switch-off and a spend cap (OWASP LLM06, LLM10).
Every change has a rollback step.
- People
Training and paired sessions; the sponsor explains the change to the wider organisation (BCG).
Order of work
- Guardrails first: agent access, review rules, data rules.
- Set up the delivery process chosen in Phase 1 with the pilot team: spec templates, the PRD and ADR standard, implementer and reviewer agents, the CI gate. The first 2-3 pilot tickets run through it.
- Then the 2-3 areas, ranked by expected gain, then cost: settings and written rules before tools, tools before custom builds.
What is read first
Review wait and started tickets that reached release move first, then Lead time; Change failure rate and the guardrail numbers must not get worse.
The same five team numbers, plus days to fix a critical flaw, before and after the AI-SDLC change.
Five numbers from your tickets, git and CI (baseline, weekly, final), plus days to fix a critical flaw before and after.
You prepareThe same read-only access as in Phase 1: tickets, git, CI, incidents, scanner alerts.
We deliverThe same numbers measured again the same way; the 16 areas re-scored; any number that did not move is named with its reason.
baseline, Phase 1 after, week 8
The AI-SDLC change for each number
Weekly loop
Each week we measure the five numbers per team, pick the one off target and agree one action; the next week shows whether it worked.
Weekly reading, week 6 (demo)
- Team splits pull requests over 400 lines; we tune the AI reviewer to flag large pull requests first.
- Week 7: review wait 12.5 h, on target.
- Smaller pull requests wait less for review (LinearB 2026, vendor).
Why a weekly reading
Each week the team compares one number with its baseline. Without a baseline, a pilot's effect cannot be shown.
How the numbers are taken
- Tickets run through the delivery process are reported apart from the others, so the pilot team decides whether it stays.
- Sample numbers, not a client result; targets are set on your baseline in Discovery and analysis.
- Cost per change is measured from your baseline, failed attempts included.
- For a fleet of agents we also track pull-request approval rate, review rework and model version drift, to catch quality slipping early.
- Days to fix a critical flaw: median days from the scanner's first alert to the fix running in production, for flaws attackers already use. This is how the Verizon DBIR 2026 measures it; its median is 43 days, and only 26% of such flaws were fully fixed.
- If a number cannot be measured yet, installing the data link is the first task.
- Numbers per team, never per person: in Germany, numbers per developer usually need the works council (CMS).
A named owner in your team runs each AI-SDLC change after we leave.
Every change has an owner; the numbers are read monthly.
You prepareAn owner for each change, for the delivery process and for the monthly review.
We deliverA handover note, the first monthly review, a plan for the next teams.
your team us, only if you ask
Who owns what after we leave
- Each change
Its area owner approves edits to its rules and answers for its number.
- The five numbers
Your CTO or tech lead reads them every month, per team, never per person.
- The delivery process
Chosen in Phase 1, set up in Phase 2. A tech lead of yours owns its templates, agent set-up, CI gate and ADR, and approves every change to them.
- Guardrails and agents
Each agent keeps a named owner, a spend cap and an audit log.
- Next teams
Your sponsor runs the roll-out plan; our support is optional.
Duration
Phase 3, Measure and hand over: TIME_PLACEHOLDER.
Why a monthly review
An AI management system must improve continually (ISO/IEC 42001); the review matches the Measure and Manage functions of the NIST AI RMF.
What the AI-SDLC sets up at each stage of your delivery line
One setup per delivery stage.
You preparePick the stages where your team loses time.
We deliverEach chosen setup running in your pipeline, with its check.
What runs at each stage
- Ticket: agents build and check; a person reviews every risky change.
- Rules: a short rules file and a map of which folder owns what.
- Agent: permissions keep merges and protected paths with people; a router picks the model per step, and when a model or a whole tool stops, the next on your list takes over.
- Review: AI pre-reviews every change; only risky changes wait for a person.
- Tests: each test must fail when the code is broken on purpose.
- Security: the merge is blocked and an agent opens the fix.
- CI: gates check every pull request; a merge queue tests each change against the latest main.
- Release: one trace links ticket, scope, approval and release.
- Measure: cost per change is measured and capped; long sessions are kept short.
The problem each setup answers
- Who does what: unclear AI steps.
- Delivery process: vague tickets.
- Goal convergence: agent drift.
- Rules and context: ignored rules.
- PRD and ADR: forgotten decisions.
- Agent permissions: unattended agents.
- Model routing: one provider.
- Multi-agent: usage limits.
- Implementer and reviewer: self-approval.
- Cross-review: blind spots.
- Code Review: review queue.
- Testing: weak tests.
- Security: vulnerable dependency.
- Quality gates: flawed AI code.
- CI on main: red main.
- Tracing: untraced changes.
- AI cost levers: rising AI bill.
- Token savings: long sessions.
- Kill verbosity: unreadable reports.
Customer case
Test-automation SaaS company.
- More than half of its classified production incidents came from its own changes, and the share rose as output rose.
- Fix: the existing incident-cause field goes on the weekly board, so each change, agent-built or not, is measured against what comes back.
Before the first ticket: who acts at each step of the line, and when a person decides.
Delivery flow: agents build and check, a person decides on risky changes
A person approves the ticket's acceptance check, reviews risky changes and signs off protected paths as code owner.
You prepareA ticket template, branch protection and your risky paths.
We deliverA second-model review, merge checks and sign-off rules.
Example: DS-142 passes to a person three times: acceptance check, review, sign-off
Customer case
Test-automation SaaS company, ticket agent.
- Nobody knew which tickets the agent should take.
- Fix: hand it small fresh tickets the week they are written; people keep the rest.
- Fresh tickets closed in a median of 2 days, backlog tickets in 67 (fresh tickets are also smaller).
Enterprise device maker.
- Seven steps: ticket, design, build, check, pull request, review, merge.
- Three gates where a person decides: design, code and merge, which agent pull requests pass too.
- The author is never the reviewer.
Software platform company.
- The check moved from reading the diff to just before deploy (tests, evaluations, a watched feature-flag rollout).
- One person reads the AI review and CI results.
- Merges rose about 4.5x (self-reported).
Runs alone
- Build: an agent writes the code and its tests on its own branch, with no production keys.
- Second model checks: another model reads the change and flags the lines a person must read; it never fixes or approves.
- Tests, security, CI: a failed gate goes back to the agent, up to 3 rounds; then the ticket returns to the developer.
- Release: in steps, watching health, rolling back by itself; the version is written on the ticket.
- Watch: after release, a script compares the error rate and CI failures with their normal range. When one leaves it, the agent drafts a ticket with the evidence, and that ticket takes this same path.
Always a person
- Ticket: the acceptance check that proves it is done. No check, no agent start.
- Review: AI pre-reviews every change; risky ones wait for a person other than the requester.
- Sign-off: risky changes (payments, login, personal data, infrastructure, over 400 lines) need the code owner. Low-risk changes skip it.
- Any change that weakens a test, a gate or a rule.
One list shows every ticket waiting for a person, the step it stopped at, and why.
Who can override
- A failed check: only the code owner, with a written reason kept on the ticket.
- An agent: never.
- Anyone on the team can stop a release; rollback is one step.
Release needs every check passing and the required signatures. Retry limit, risky paths and the 400-line threshold are our defaults, tuned from your numbers.
The line starts at the ticket: it becomes a written spec.
Each ticket reaches a reviewed pull request from its requirements note (PRD)
A written spec drives each change to a reviewed pull request.
You prepareA requirements note per ticket (PRD) and your recorded decisions (ADRs).
We deliverSpec Kit artifacts, an implementer and a reviewer agent, CI as the gate.
Example: ticket DS-142, add retry to the payment webhookThe spec states what must be true, each line with its checkThe plan keeps to the accepted ADRThe tasks split the work, one per acceptance checkAn implementer agent builds one taskA reviewer agent checks it against the spec and sends problems backCI and the code-review plugin check the pull requestA reviewed pull request, every spec line checked
The reviewer agent sends a problem back before the pull request opens
Default and alternatives
Default: three files in the repository (spec, plan, task list, from GitHub Spec Kit: spec.md, plan.md, tasks.md), run by Claude Code agents, gated by your CI and the official code-review plugin. Spec Kit supplies the commands and files, not a runner; we configure the implementer and reviewer agents.
Alternatives and when each fits: Choose the delivery process.
How it works
/speckit.specifyreads the approved PRD and writesspec.mdwith its acceptance checks.- The plan command reads the accepted ADRs and writes
plan.md. /speckit.taskswritestasks.md; the task template set up in Implementation gives one task per acceptance check.- Before writing the plan, the agent checks the code, so it never asks for what exists; one plan once asked for tests already written.
- The main Claude Code session gives each task to a separate implementer agent.
- A reviewer agent checks the diff against
spec.mdandtasks.md; problems go back to the implementer. - When the work departs from
plan.md, the plan is updated in the same commit.
The pull request then meets your CI and the code-review plugin. Branch rules keep the merge with a person.
Where it fits in the AI-SDLC
- Choose the delivery process (Discovery and analysis) picks it from your maturity scores, stack and tickets; small changes take a light path, a one-page spec.
- Set up the delivery process (Implementation) gives the pilot team the templates, the two agents and the gate.
When it does not help
- Thoughtworks and Martin Fowler's site find the full artifact set heavy for small work.
- No published study shows that a spec step improves delivery outcomes, so the pilot measures the five delivery numbers before and after.
The spec defines done; the task board keeps the agent off side work until each check passes.
A task closes only when its acceptance checks pass
Side work waits as a new task; an automatic check closes each task.
You prepareThe PRD, or your request in your own words; one repository.
We deliverA task board with a goal, cited priorities and an automatic check.
Example: the agent drifts into refactors; you state the goal onceEach task gets an acceptance check and a priority you wroteA timed check points the agent back to the top taskA refactor or tool idea waits as a new taskThe task closes only when its acceptance check passes
The side job becomes task 3; task 1 closes only when its check passes
How it works
Three files hold the work: the task board (what is left, an acceptance check per task), the decisions (your rulings), the work log (what happened).
Only a sentence you wrote can raise a task to the top priority; the agent cannot promote its own work.
An automatic check validates the board; a timer re-reads the files so a long session stays on them.
Where it fits in the AI-SDLC
Implementation. The pilot team's agents work the roadmap tasks from Discovery and analysis, and each task's acceptance check becomes a number checked in Measure and hand over.
Result
No published number yet. This site's own proposal was built on the same board.
When it does not help
A single-step task, or work where a runnable test already decides what done means.
To work each task, the agent reads your rules and code map.
Rules file and code map speed agent investigations
Investigations: two days to 30 minutes at a social network (published case).
You prepareYour rules file, folder owners, build and test commands.
We deliverOne short rules file, a folder map and a CI check per rule.
billing-ui/, amounts in centsExample: without the map the agent edits the wrong module
Customer case
Social network company, data pipelines.
- Agents lacked the team's unwritten knowledge of a four-repository, three-language pipeline.
- Each investigation took about two days.
- Fix: agents read 4,100+ files and wrote 59 reference files, graded by separate critic agents.
- Investigations fell to about 30 minutes; tool calls per task fell by 40%.
Ride-hailing and delivery platform. With a code map the same question to an agent took 38 seconds and was right; without it, 20 minutes and wrong.
Enterprise device maker. One command writes the project's agent rules file; company, project and personal rules load in that order.
- Agents reach company systems only through approved connectors; unapproved tools stay blocked, so security knows what agents can read.
When a rules file pays off
- Generic context files add over 20% to model cost with no general gain in task success (Gloaguen et al.), while a map written for one specific codebase cut a reverse-engineering estimate from 6 weeks to 2 for about 10,000 lines of COBOL (Thoughtworks).
- So a rules file helps only when it is short and specific to your code.
- We back each rule with a CI check and drop rules that do not change the agent's work.
- A mistake the agent repeats becomes a rule, with its CI check.
- When the rules file, the scripts that run around each agent step, or the model change, the checks rerun on past tasks with known good results; a lower pass rate stops the change.
Besides the rules file, the agent must respect decisions you already made.
A change that breaks a recorded decision is stopped
The conflict goes to the ticket; only a person lifts it, with a new ADR.
You prepareA PRD per ticket and an ADR per decision, in your repository.
We deliverBoth templates, and agents set up to read, follow and check them.
docs/adr/0003-retries-live-in-the-webhook-handler.md
Decision
Retries stay in the webhook handler; the queue only carries messages.
Confirmation
A test fails unless maxReceiveCount is 1.
Example: on ticket DS-142, ADR-0003 keeps retries in the handlerLess code would be a queue setting in config/queue.yamlIt contradicts ADR-0003, so the agent does not make itOnly a person lifts the stop, by recording a new ADR
The agent does not make the change that contradicts ADR-0003
The PRD next to it
docs/prd/DS-142-webhook-retry.md lists what must be true when the ticket is done, each line with the check that proves it.
- Line 1: WHEN no 2xx answer THE SYSTEM SHALL retry up to 8 times (check:
npm test -- webhook). - Line 2: the wait never exceeds 30 s.
- Four more lines follow, each with its check.
Each PRD line becomes a task on the board (Goal convergence).
PRD template
File docs/prd/<ticket>-<slug>.md, one page. Sections: Status, Owner, Decisions (the ADRs that bind it), Problem, Users, Scope (the paths the agent may edit), Acceptance checks, Out of scope, Open questions.
- Each acceptance check is one behaviour in one fixed sentence shape: WHEN a condition, THE SYSTEM SHALL a result (EARS).
- It ends with the Check that proves it: a command, a test or a query.
- A line with no Check is rewritten before work starts.
An open question names an owner and the line it blocks. The agent stops on that line and asks; it does not guess.
ADR template
File docs/adr/NNNN-<slug>.md, next unused number, never reused. Sections: Status (proposed, accepted, rejected, deprecated, superseded by ADR-NNNN), Decided by, Context, Decision, Options considered, Consequences, Confirmation.
- Confirmation is required: it is the test or review question that shows the code still follows the decision.
- An accepted ADR changes only its status line.
- Reversing a decision adds a new ADR and marks the old one superseded.
How agents follow it
The repository rules file carries four lines:
- Read the PRD and every accepted ADR before editing.
- Work only on files in the PRD's Scope.
- If a change contradicts an accepted ADR, stop and report the ADR number and the conflicting line.
- An answer from a person that sets a rule becomes a new ADR in the same pull request.
- Each acceptance check becomes a task on the board (DS-142 gives six); the goal closes when all six pass together.
- A separate reviewer agent checks the diff against the PRD (Checks, Scope, Out of scope) and each ADR's Confirmation.
- A person still merges.
Where it fits in the AI-SDLC
- Choose the delivery process (Discovery and analysis) records the choice as the first ADR.
- Set up the delivery process (Implementation) puts both templates in docs/prd and docs/adr and adds the rules file lines and the reviewer check.
- Each roadmap task then starts as a PRD.
Before the agent touches your branches, permissions set what it may change.
Agent permissions keep merges with your people
Agents cannot merge, edit protected paths or close tickets alone.
You prepareYour protected paths and who may approve a merge.
We deliverAgent permissions set in branch protection, code owners and scripts that run around each agent step.
config/prod.yaml, asks to mergeticket DS-142Example: an agent edits a protected deploy file and asks to merge
The merge is refused until the code owner approves
Customer case
Test-automation SaaS company, ticket agent.
- The agent posted the same failure into one ticket three times and kept going.
- The written "stop after three failures" rule never fired.
- Fix: one failure counter per ticket, and dispatch stops when daily use passes a set limit.
Enterprise device maker.
- Agents could drift in quality and cost.
- Fix: three failures call a person.
- An agent never merges or approves its own work.
- Roll back when cost passes 150% of budget.
- Stop when complexity grows 40%.
Cloud services provider.
- An agent fixing a bug rebuilt a live environment and caused a 13-hour outage of one service (press report; the company calls it user error).
- Fix: a person approves before any production change.
The permissions
- Merge: an agent never merges or approves its own pull request.
- Protected paths: CI config, infrastructure, secrets and payment code need the code owner's approval.
- Tickets: an agent attaches the passing check's output; a person closes the ticket.
- Priority: only a person raises a ticket's priority.
- Git: no force push or history rewrite on shared branches.
- Failures: after three failed attempts the agent stops and calls a person.
- Budget: the agent stops when its spend passes the set limit.
- Riskiest code: changes to login, cryptography and billing need reviews from two people.
The platform team owns the permission file; an engineer's local settings cannot widen it.
A rule is text the agent reads and can work around, so the hard limits sit in its environment: the agent runs in a sandbox, holds no production keys and reaches only approved hosts.
Permissions set what the agent may do; routing sets which model does each step.
Model routing: lower cost, fallback on failure
Routine steps go to a small model; errors fall to the next.
You prepareYour AI tasks and the providers you allow.
We deliverA router (OpenRouter by default) with model order, fallbacks and caps.
Example: one provider rate-limits and the pipeline stops
The problem
A strong model on every step overpays for easy work; a single provider that goes down or rate-limits stops the pipeline.
How the router works
- Model choice. A priority list per task: a small model for routine steps, a strong one for critical review.
- Fallbacks. On errors, rate limits, context-length limits or downtime the next model on the list answers (OpenRouter fallbacks).
- Provider rules. Order, price, throughput or latency, a price ceiling, and a no-data-retention requirement (OpenRouter provider selection).
- Cost caps. A spend limit per key and per team, with alerts before the cap is reached.
Sourced behaviour
By default the router sends most traffic to cheaper providers, and a provider with an outage in the last 30 seconds goes to the back of the line (OpenRouter).
Lesson. With your own provider key, keep the request pinned to that provider: a fallback to a paid route needs credit on the router account, and without it the call is refused.
Where it sits in the AI-SDLC
- Implementation: the router and the model list per task go into your agent setup.
- Measure and hand over: Cost per change per model shows where to move work; your team edits the list.
Routing swaps models inside one tool; a whole tool can also hit its usage limit.
When one AI tool hits its usage limit, another takes over
Usage limit on one tool: the next takes over; the switch is logged.
You prepareAccounts for the AI tools you allow.
We deliverFallback chains and a log of which model answered.
Example: a usage limit on one tool stops the work
The problem
One vendor, one agent, one point of failure: a usage limit stops the work.
How the agents split the work
- Claude does the main work in the repository (Claude Code subagents).
- Codex and Gemini continue the work when Claude reaches its limit (Codex CLI, Gemini CLI).
- Fallback chains. A usage limit on one tool falls to the next instead of stopping work.
- Cost rule. The strongest model is used only when asked for, never picked automatically.
Lesson: the silent fallback
- Problem: a usage limit on Codex silently fell through to Gemini, so one model answered both "independent" checks.
- Fix: every answer is logged with the model that gave it; a substitution is flagged, and strict mode refuses it.
Where it sits in the AI-SDLC
Implementation: fallback chains and the model log go into your agent setup. Measure and hand over: the log shows which model answered each check, and your team owns the chains.
The change is built; the first check comes from an agent that did not build it.
A separate agent verifies each change before it is done
Whoever builds the change does not sign it off.
You prepareOne scoped task with a written acceptance check.
We deliverAn implementer agent and a separate reviewer agent.
Example: an agent marks unfinished work done; you write what done meansOne agent makes the changeAnother agent checks it and files numbered problemsThe implementer must answer each problemDone only when the reviewer verifies every number
The reviewer reopens problem 2; the implementer cannot close it alone
How it works
Two actors on one scoped task: the implementer changes the product, the reviewer measures it and files numbered problems.
The tool refuses a round where the implementer and the reviewer are the same agent.
Extra work the implementer spots goes to the reviewer as a numbered question; the reviewer rules on it.
Where it fits in the AI-SDLC
Implementation. Each change in the pilot is built by one agent and checked by another before a person approves it, so the before/after in Measure and hand over counts verified work only.
Result
First real round, on research findings: an automatic check accepted 22 findings once each carried its source reference; the reviewer read 6 by hand and found none supported by its source. The check alone would have shipped all 22.
- A separate reviewer asked why a function silently returned an empty result when a required input was missing.
When it does not help
A reviewer copied from the implementer's session shares its blind spots. With one actor only, the substitute is a review by a different model.
A reviewer on the same model shares the implementer's blind spots.
A second model reviews the first model's change
A different model reviews it; a record shows which one answered.
You prepareThe change and your rules file.
We deliverReviews by a second model family, findings compared.
Example: the author model misses a camelCase/snake_case mismatchThe reviewer gets the change and the rules, not the reasoningA model from another family reads it freshA record shows which model answered, and flags when another model stood inThe second model flags the mismatch; findings side by side
The second model finds the name mismatch the tests missed
How it works
One command sends a review, diagnosis or research task to another model family: Gemini, Codex or OpenRouter models.
The reviewer sees only the change and the project rules, not the author's reasoning.
A record names the model that actually answered and flags a substitution.
Where it fits in the AI-SDLC
Implementation. Every pilot change gets a second-model review before a person approves it; findings feed the Code Review area.
Result
Enterprise device maker. A second model caught a camelCase/snake_case mismatch the author model missed.
- A model reviewing its own output reads about 70% less before editing; a second model restores it.
When it does not help
- A silent stand-in: the same model answering twice is not a cross-check.
- Unchecked answers once produced five confident findings about code that did not exist.
- The record of which model answered, and a check of the examined lines, catch this.
The AI review is done; what is left is deciding which changes a person reads.
Risk labels: only risky changes wait for a person
Merged pull requests a week doubled in a published case (self-reported).
You prepareYour review checklist and folder owners.
We deliverRisk labels and an AI first pass; risky changes go to the owner.
Merged pull requests a week
Every pull request waits for a person to read all of it.
Risk label; risky changes (see Who does what) also need the code owner.
Customer case
Five-person cloud-cost consultancy.
- 60 pull requests were open, two days of review for five people.
- Fix: a script labels changes that touch the public API, login, the design system, the database schema or agent skills; only those need a person.
- Lint rules, an 85% coverage floor and end-to-end tests came at the same time.
- Merged pull requests rose from 80 to 154 a week (self-reported).
European fashion e-commerce platform. Low-risk pull requests queued behind risky ones. A review bot approves the low-risk third; lead time fell 20% to 40%.
Test-automation SaaS company, review bot.
- 46 bot comments were 28 distinct findings, and half cited the wrong line.
- Fix: a gate drops a finding whose quoted code is not at the cited line.
Enterprise device maker.
- Four review layers (domain, tests, architecture, good practice) caught three runtime bugs in a 121-file pull request before merge.
- A design touching over 20 files gets a plan that splits it into ordered pull requests.
- Review comments are questions, one concern each, placed inline on the code line.
Readable AI review
The review agent lists a few style comments and counts the rest, and skips what CI already checks. Its findings never block a merge on their own; a person decides.
Try the change first
Where the team has preview environments, a change to a screen or an API opens one, and the reviewer uses it before reading the code.
Industry
AI-written pull requests wait about 16 hours for a first review, against about 200 minutes for others, across 8.1 million pull requests (LinearB 2026, vendor).
Review reads the code; tests prove it works.
Tests proven by planted bugs catch agent bugs
Planted bugs check each test before code reaches main.
You prepareYour test suite and read access to CI.
We deliverMissing tests from your acceptance checks, each proven by a planted bug.
qty > 10 → qty >= 10Example: all 12 tests pass on code broken on purposedemo
Customer case
Search and cloud company, bug-fixing agent.
- 73% of agent patches passed the tests, but only 43% were correct when checked by hand.
- Fix: validate a patch before showing it and hold back the ones unlikely to be accepted.
- Usable results rose by up to 39 points.
Internal AI-tooling team.
- One check run returned 15 tidy verdicts, 11 of them wrong, while every check passed.
- Fix: each test must fail on a planted bug before its result is trusted.
Ride-hailing and delivery platform. Generated tests worked for 80% of Python code but 20% of Java. Fix: measure per language, not one headline rate.
Fixing a bug: test first
For a bug, the test that reproduces it comes first.
- We write the failing test and commit it.
- The agent fixes the code.
- A script blocks the agent from editing that test.
The test cannot be loosened to pass, so green means the bug is gone.
Why coverage is not enough
Line coverage of 90% can sit beside tests that catch nothing. Test strength counts how many planted bugs a test catches; the threshold is 75%.
Each production incident leaves a test behind, so the same failure cannot return unnoticed.
Social network company: 73% of tests generated for privacy testing were accepted by its engineers in a trial (published 2025).
Tests check behaviour; security checks dependencies, reachable flaws and leaked secrets.
Vulnerable packages blocked before merge; newly disclosed flaws fixed the same day
A vulnerable new dependency never merges; when a fixed version of a new flaw is out, running code gets a tested, approved upgrade the same day, not next sprint.
You prepareYour scanners, read access to every repository, who may approve a merge, and tests good enough to trust an upgrade.
We deliverA dependency gate, and an overnight run that turns each new flaw into tested upgrade pull requests.
Example: Spring4Shell (CVE-2022-22965) in a new dependency
Example: a new flaw in a shared library, already running in production
The dependency scan blocks the merge until the agent bumps the version
Why it matters
- Known-exploited flaws took a median 43 days from detection to full fix, and only 26% were fully fixed (Verizon DBIR 2026).
- Fewer than 1 in 10 dependency flaws can be reached from the application's code (Endor Labs, vendor data). Checking whether your code actually calls the flawed function cuts a flood of alerts to the few services that need a fix; we measure your own share in Discovery and analysis.
- It is an agent job teams welcome: it removes an unplanned day of searching and upgrading, a person still approves, and it reuses the gates, merge line and approvals you already have. A team that sees it work trusts agents with the next step.
- No fixed version yet: the agent lists the exposed services and proposes a temporary block (switch off the feature, change a setting or add a firewall rule) until the fix ships.
- Limits: your release process still deploys, and the upgrade is only as safe as your tests (Testing); every fix has a revert (CI on main).
Customer case
Test-automation SaaS company.
- 737 security tickets were open across five projects, the oldest over two years.
- The written rule (no Medium or higher merges) differed from the gate that ran (Critical only).
- Fix: sweep and close done-but-open tickets, triage new reports first, and make the written gate match the one that runs.
Large internet company. 76% of a static analyser's alarms were false, so real ones were ignored. A model filter removed 94-98% of false alarms on 433 real alerts.
Search and cloud company. An agent that drafts fixes opened 72 security fixes in six months; a person reviewed every one before it landed.
The example
- Spring4Shell: data binding can reach the class loader and let an attacker run code.
- The order controller binds request fields, so the path is reachable.
- The scanner decides; the model explains the finding in the pull request.
45% of tests where AI-written code carried a security flaw, across 100+ models (Veracode 2025, vendor).
The EU Cyber Resilience Act sets reporting and vulnerability-handling duties for products with software (European Commission).
Secret scan
- The same gate runs a secret scan (gitleaks).
- A key in the diff blocks the merge the same way.
- The agent moves the key to an environment variable and rewrites its own unmerged branch, so the key is in no commit.
- The key's owner rotates it.
Tests and security scans help only if a failure blocks the merge.
Quality gates stop flawed code before merge
Security, quality and test checks run on every push; failures block merge.
You prepareRepository read access and CI settings.
We deliverGates live on every pull request, a blocked-change report.
Example: the agent's pull request adds a package that does not existSecurity gate blocks the mergeAgent removes the package, the gate reruns and passesComplexity, duplication in limitsTests cover the changeMerged after the block; the invented package never shipped
The security check blocks the merge until the agent drops the invented package
Customer case
Enterprise device maker, scanner evaluation software.
- A misspelt prediction key scored every barcode dataset at zero.
- Fix: one gate command (lint, tests, coverage, security, branch name, title) runs before a pull request opens.
- A person approves design, code and merge.
- On that ticket the gate passed 997 tests at 93% coverage before a person saw the pull request.
Same company, agent pull requests. The agent's pull request runs the same gate as a person's, on every push, so nothing passes only on a laptop.
Search and cloud company, code migration. A change across 5,359 files cannot be read line by line; machine checks decided what passed, and 87% of the AI-written code landed unchanged.
The gates
Security, Code quality and Automation, four checks each. Complexity and duplication stay in limits; tests cover the change. You choose which checks block a merge. A new check starts as a warning; you make it blocking once its false alarms are rare.
A change can pass every gate and still break against what others merged meanwhile.
Each change retested on the latest main; a repair agent fixes breaks
Changes wait in a merge queue and are tested one by one on the latest main.
You prepareYour CI pipeline and branch rules.
We deliverA merge queue; each red build fixed by pull request.
Example: a dependency bump turns main reddemo
Customer case
Test-automation SaaS company.
- CI broke the same few ways after each platform migration, and each team rediscovered the fix alone.
- Fix: a red pipeline is matched to a break already fixed elsewhere, and the same fix arrives as a pull request.
Same company, reverts. One team reverted three dependency bumps from production in three months. Fix: every break lands as a pull request with its own revert.
Ride-hailing and delivery platform. An agent reads the failed job and opens the fix; a person reviews it.
The rule
The repair agent starts read-only: it explains each failed build on the pull request and flags flaky tests. It starts fixing once its explanations prove right.
Each break is fixed by a new pull request, never by a direct push. The 90% main-branch success threshold is checked on your own pipeline.
Industry: 70.8% main-branch success in 2026 and 72 minutes to get back to green (CircleCI 2026, vendor).
After the merge comes the release; later, someone must show what shipped and who approved it.
Every agent change traced to approval and release
Each release is written on its ticket, with pull request and approver.
You prepareTicket ids in branch names and folder owners.
We deliverA trace per ticket: pull request, approval, release.
Example: 99.3% of finished tickets at one client had no release link
The ticket ends with its plan, pull request, approver and release on one record
Customer case
Test-automation SaaS company.
- Of 5,297 resolved tickets, 38 (0.7%) carried a release version, so nobody could show what a customer received, agent-built changes included.
- Fix: the deploy pipeline writes the version onto the ticket.
Same company, agent register. Two agents running in production had no register entry. Fix: each agent gets a name, a budget and an owner.
Enterprise device maker. Every agent pull request carries its ticket in the branch and title, an ai-assisted label and a named approver, checked before the pull request opens.
What the trace gives you
- Compliance: who approved each change, on record.
- Record: the trace keeps agent steps, files changed and approvals.
- Debugging: replay the steps to find the cause.
Every stage so far runs agents; their bill needs a number per change.
Agent cost tracked per change, with a cap and alerts
Cost per change on your board, with a cap; alerts fire before the cap is reached.
You prepareYour agent usage export and who owns the budget.
We deliverLevers chosen from your usage export, Cost per change on your board.
Example: agent requests grew 9.4x in six months at one platform
Customer case
Ride-hailing and delivery platform.
- Weekly users grew 7x and agent requests 9.4x.
- Fix: automatic compaction, medium reasoning effort by default, a one-hour prompt cache.
- Live session cost in the terminal; alerts at 50/80/100% of expected spend.
- With the model held fixed, cost per session fell 52% from its peak.
Same platform, tool calls. Each tool call cost one model round trip. Running batched scripts instead cut tokens by 55% to 71% in a five-query test.
Test-automation SaaS company.
- One unwatched agent session cost about twice the whole matching backlog in a day.
- A shared monthly budget drained in days with nobody told.
- Fix: a hard cap per agent account, with warnings before it.
The levers
- Prompt caching and short sessions: see Token savings.
- Batch processing: about half price for work that can wait.
- Model routing: a smaller model for easy steps; 35% to 85% lower cost at 95% of the large model's quality in public chat, knowledge and maths tests (RouteLLM).
- Open-weight models: no per-request fee; code stays in your network, and you pay for the hardware.
- Context control: less for the model to read.
- Team budgets: caps heavy users, with alerts before the cap.
Detail: Token savings (session and cache rules) and Model routing (model choice and fallbacks).
Once cost is measured, the biggest lever is fewer tokens per session.
Caching and short sessions lower agent cost
Caching cut cost 41-80% over 500+ agent sessions (external benchmark).
You prepareYour agent usage export and one typical working day.
We deliverSession and cache rules, Cost per change tracked.
Example: a long session re-reads every earlier turn on each call
Why the bill grows
- Each call re-sends the whole conversation, so a long session re-reads every earlier turn.
- A pause longer than the cache lifetime throws the cached part away; it is paid again at full price.
The four rules
- Stable prompt first. Tools and rules first, the changing part last, tool results kept out of cached blocks (arXiv 2601.06007).
- One task, one session. Clear the context between tasks instead of carrying it (Claude Code costs).
- Handover note. The agent writes what is done and what is next; a fresh session reads the note, not the transcript.
- Cache lifetime fits pauses. A ride-hailing platform moved from a 5-minute to a 1-hour cache because idle gaps kept discarding it. Short sub-agent tasks kept 5 minutes (engineering blog).
Model choice and batch: Model routing and AI cost levers.
Sourced results
Published study. Caching cut cost 41% to 80% over 500+ agent sessions on four models (arXiv 2601.06007).
Security-tooling company. Static prompt on a 1-hour cache, conversation on a sliding window: cache hit rate rose from 7% to 84%, savings 59%, then 66%, then 70%.
Caution. Caching everything, tool results included, sometimes slowed execution.
Where it sits in the AI-SDLC
Implementation: session, handover and cache rules go into your agent setup. Measure and hand over: Cost per change shows the effect, and your team owns the rules file.
Long agent reports cost tokens and your reading time.
Shorter AI reports, checked against the original
Numbers, paths, names and rules checked against the original.
You prepareOne long report your team has to act on.
We deliverThe short version, the original kept, a lost-detail check.
Example: an agent report longer than its length targetRepeats, filler and hedges are markedEach section is cut to its word targetEvery number, path and rule is checked against the originalThe reader gets the short version first
The fact check finds one lost number and puts it back
How it works
A script finds the padding; agents rewrite one section at a time.
Each rule has its own specialist, because one agent holding 35 rules applies about four.
A check compares numbers, paths, identifiers and rules with the original and keeps the original until you confirm.
Where it fits in the AI-SDLC
Measure and hand over. The Discovery and analysis report, the roadmap and the before/after report reach your leads shortened to the target length.
Result
Runs land at 1.11 to 1.27 times the target length across 16 samples and four model backends; a second pass removes only 0% to 11% more (mean 6%, nine samples).
When it does not help
A document with under 5% padding: three runs on one 8,545-word log removed 3.3%, 0.6% and 0.3%.
Tool
Self-check: find which of 16 AI-SDLC areas holds your delivery back
You get, as you answer: a level per area, the area where agent work waits today, and the first change that gets it moving.
You prepareOne tech lead, about 10 minutes: yes or no to 48 statements about what the team does today.
We deliverA report (PDF or link) with the first change for each weak area and the number it should move; it opens the discovery workshop.
- New tickets carry an acceptance check a person can run
- Every active repository has a rules file for agents
- An AI pre-review comments on every pull request before a person looks
- CI runs the tests on every pull request
- Code Review L2: A written rule says which changes need a person's review
- Code Review L3: An AI pre-review comments on every pull request before a person looks
- Then Testing and Security
- AI pre-reviews every change; only risky changes wait for a person.
- Example team: review wait 16 h to 12 h (example numbers)
The weakest area is the first topic of the discovery workshop and the first change of Phase 2.
Start the self-check: 10 minutes →The story, step by step
- To find which area holds AI work back, you answer yes or no to 48 statements in 16 delivery areas in about 10 minutes; the answers stay in your browser.
- Each area gets a level from L1 Ad hoc to L4 Optimised.
- The lowest area is named, with the reason AI work stops there. In the example, Code Review is at L1: agents write changes faster than people review them, so AI work waits before release.
- The report names the next fix for the lowest area and the matching plan: Phase 1, Discovery and analysis, or the AI-SDLC Package when several areas are below L3.
- The lowest area becomes the first topic of the discovery workshop and the first item of the roadmap.
How it connects to the AI-SDLC
- No call needed: the result is yours to keep and to bring to the discovery workshop.
- Its report is the input to the discovery workshop.
- The analysis of your data then checks the self-reported levels against tickets, repositories and CI.
- The maturity workshop agrees the weakest area with evidence.
- The area you fix first is the one that stops agent work from reaching release, so the first change in Phase 2 lands where it pays.
What stays private
Answers are kept in the page address and never sent. Copy the snapshot link to share the result with your team or bring it to the discovery workshop.
Your AI-SDLC maturity report, lowest area first
Gap to the next level
Next steps, lowest area first
Start your AI-SDLC with Discovery and analysis
In 1-2 weeks: a baseline, a chosen delivery process, a roadmap.
You prepareOne call and read-only access.
We deliverPhase 1, Discovery and analysis.
Start the AI-SDLC with Phase 1, or run all three phases with us.
Phase 1 has a fixed scope and duration; Phases 2-3 are sized from its findings. Due diligence is a separate track: the same read-only analysis, for a company you invest in or buy.
You prepareYour goal, a sponsor, and read-only access to tickets, git and CI.
We deliverPhase 1: a report and roadmap. Package: changes running and measured. Due diligence: a decision report.
- Two workshops and the analysis of your data
- Report and roadmap, baseline of five numbers
- Phase 1, then 2-3 areas (for example code review or testing) set up with one pilot team
- Changes running and tested in your pipeline; the five numbers before and after
- Architecture, code, AI use, team, scalability, risks
- Decision report with red flags and recommendations
Remote by default · optional onsite days: PRICE_PLACEHOLDER · Contact →
Discovery and analysis (Phase 1)
- Covers: discovery workshop, analysis of your tickets, git and CI (read-only), maturity workshop on 16 areas, choice of the delivery process.
- You get: report with the weakest area agreed, a roadmap with measurable milestones, the baseline of five numbers (lead time, started tickets that reached release, review wait, change failure rate and cost per change).
- Then you decide: stop with the report, or continue to Implementation.
AI-SDLC Package (Phases 1-3)
- Covers: Phase 1; Implementation in 2-3 areas (for example code review or testing) with one pilot team, guardrails first, weekly check-in (4-8 weeks); Measure and hand over.
- You get: report and roadmap, tools and practices fitted to your stack, changes running and tested in the agreed areas, the five numbers before and after, owners for each change.
- Implementation runs with our consultant inside your team, not as a report handed over.
Due diligence (Light or Full)
- Light (~1-2 weeks): architecture and code, for smaller or early-stage companies; a first view and whether Full is needed.
- Full (~2-4 weeks): a decision report with red flags and conditions; architecture, code quality and technical debt, team and its capacity to grow the product, scalability, risks (dependencies, vendor lock-in, IP, open-source licences).
- You get: a decision report with red flags and a recommendation (proceed, proceed with deal conditions, or stop); optional Q&A debrief with the deal team.
- Duration depends on access to the company's repositories and team.
Phase 1 alone, then you decide.
In 1-2 weeks: baseline, weakest area agreed, a roadmap.
You prepareThe CTO and 2-3 leads, and read-only access to tickets, git and CI.
We deliverTwo workshops, the analysis of your data, the delivery process chosen for your team and recorded as a decision record (ADR), the report and roadmap.
Price: PRICE_PLACEHOLDER · continue later with the AI-SDLC Package → · Contact →
All three phases, from discovery to hand over.
Changes merged and tested in 2-3 areas (for example code review or testing), measured before and after.
You prepareYour team size, a sponsor, one pilot team and read-only access to tickets, git and CI.
We deliverA report and roadmap, changes running and measured in your pipeline, and the five numbers before and after.
Price: PRICE_PLACEHOLDER · Phase 1 alone: Discovery and analysis plan → · Contact →
Our read-only code and delivery analysis, for a company you invest in or buy.
A technical recommendation on the software you invest in or buy.
You prepareLight: read-only repository access and one CTO interview. Full adds ticket, CI, cloud and incident access, and interviews with the leads.
We deliverLight: a first view and whether Full is needed. Full: a decision report with red flags and conditions.
Open points, each with a proposed decision
Each open point has a proposed decision and its reason.
You prepareA yes, or a change, per point.
We deliverThe AI-SDLC Package and Due diligence offers, updated with your answers.
Each request, mapped to its process step.
The requests map onto one AI-SDLC rollout.
You prepareA yes or a change on each answer.
We deliverThe AI-SDLC Package and Due diligence offers, updated with your answers.
Concepts behind the AI-SDLC
Each concept: its place in the AI-SDLC and how it helps adoption.
You prepareThe concept your team questions first.
We deliverThat concept mapped to your repository in Discovery and analysis.
How to read this list
Concepts are grouped by what they do: find where to start, run the work with agents, keep every change safe.
Sources: research and market data, standards, tools and methods, and cases by industry.
Why the AI-SDLC needs a process, not only a tool
Agents speed up writing; the process decides what reaches release.
You prepareThe question your board asks about AI in delivery.
We deliverThe number that answers it, its source and where we act on it.
more releases with coding agents, while commits grow far faster. We measure started tickets that reached release, not commits.
NBER w35275 · →of AI-generated code samples failed security tests. We run security checks on every pull request.
Veracode 2025 (vendor) · →Adoption: share of work agents already do
- Pragmatic Engineer: How Uber uses AI for development 11% of Uber's pull requests are opened by agents (March 2026).
- Google, Alphabet Q3 2024 earnings remarks More than a quarter of new code is generated by AI, then reviewed by engineers.
- Anthropic: recursive self-improvement More than 80% of merged code was authored by Claude (May 2026).
Release: code written is not code shipped
- Demirer, Musolff, Yang: Writing Code vs. Shipping Code (NBER WP 35275) Commits rise about 240% with coding agents; releases about 30%.
- DORA 2025: State of AI-assisted Software Development AI amplifies the strengths and weaknesses of the delivery system.
- Sadowski et al.: Modern Code Review at Google 9 million reviewed changes: review absorbs the change volume.
Security: every agent change needs a check before merge
- Veracode: 2025 GenAI Code Security Report (vendor) 45% of AI-generated code samples failed security tests.
- Spracklen et al.: package hallucinations Invented packages in 5.2% (commercial) to 21.7% (open-source) of samples.
- Liu et al.: LiCoEval 0.88-2.01% of outputs closely match open-source code.
Measurement: only measured numbers count
- METR 2025: AI and experienced open-source developers Randomised study, 16 developers: tasks took 19% longer with AI.
- DORA software delivery metrics Lead time, deployment frequency, recovery time, change fail rate, rework rate.
- Forsgren et al.: The SPACE of Developer Productivity Productivity is not one metric.
Cost: predictable as use grows
- Ong et al.: RouteLLM Routing between a strong and a weak model: 35% to 85% lower cost at 95% of the large model's quality in public benchmarks (RouteLLM); measured on chat.
- Chen, Zaharia, Zou: FrugalGPT A model cascade matches the best single model at much lower cost.
- OWASP LLM10:2025 Unbounded Consumption Quotas and anomaly detection against runaway use.
Research and market data behind each step of the AI-SDLC
Each finding names the AI-SDLC step it supports.
You prepareThe claim about AI in delivery your team doubts.
We deliverThe study behind it and the step where we act on it.
How the groups are built
Each line: the source, what it shows for the AI-SDLC, and where we act on it. Vendor reports are marked; preprints are research that is not yet peer-reviewed.
The market group lists analyst and industry sources only.
The standards each AI-SDLC check maps to
Every gate, trace and report names the standard it follows.
You prepareThe standards your customers or auditors ask for.
We deliverEach check mapped to them, in the report and the handover note.
Why standards
A check that cites a standard is easier to approve: security, audit and works-council reviews read a shared vocabulary instead of our own terms.
Some ISO pages block automated readers; their content is confirmed from the standard's public summary.
The tools we set up, by AI-SDLC step
Each tool supports one step of your delivery line; we pick only what fits.
You prepareThe tools your team already uses and those you allow.
We deliverTools chosen on your stack, set up in your repositories.
How we choose
We start from what your team already runs and add a tool only where a step has no check. Vendor tools are listed for what they do, not as a recommendation.
Published cases: one AI-SDLC step at work in each industry
Each case shows one AI-SDLC step running at a named company.
You prepareYour industry and the step your team worries about.
We deliverThe closest published case and how it maps to your team.
About these cases
Each case is published by the company itself; numbers are self-reported. Our own client cases are described by industry; details on request.