AI SDLC: Why Your Bottleneck Moved to Review and Testing

TL;DR: In an AI SDLC, writing code is cheap, so the constraint on delivery has moved downstream to code review, testing and release confidence. GitHub's Octoverse 2025 reports 518.7 million pull requests merged in a year, up 29%, and every one of them still needs to be reviewed and verified. Teams that automate test creation, regression selection and failure triage first get the speed they paid for.

We talk to engineering leaders every week who rolled out AI coding assistants, saw developers write code faster, and then watched cycle time barely move. The code got done sooner. It just waited longer. This post walks through each stage of the lifecycle, shows where the queues now form, and lays out the order in which we would automate and restructure to clear them.

Quick answers

Where is the bottleneck when you add AI in the SDLC?
For most teams it sits after coding: in code review, in test creation and maintenance, and in deciding whether a build is safe to release. Generation speeds up, but verification capacity stays flat, so work queues up in front of it.

What should we automate first?
Start with the steps that block every change: regression test selection and failure triage. Then add AI-assisted test creation for new stories and a systematic process for flaky tests. Those four cover most of the waiting time in a typical pipeline.

Does QA become less important when AI writes the code?
No. QA becomes the function that sets release confidence for a much larger volume of change. The work shifts from writing and running scripts toward designing risk coverage, curating suites and owning quality signals.

How does an AI SDLC change each stage of delivery?

AI changes the cost of every stage, but not evenly. It cuts the cost of producing artifacts such as code, tests and documents far more than it cuts the cost of judging them. If you map it onto the classic phases of the SDLC, the pattern is easy to see: the generation stages get cheaper, and the verification stages inherit the extra volume.

Planning and requirements

AI drafts user stories, acceptance criteria and edge cases quickly. The risk is volume without precision. A vague story that once took an hour to write now takes a minute, and the ambiguity flows downstream into code and tests that are confidently wrong. Product and QA review of acceptance criteria matters more, not less.

Design and architecture

Assistants are useful for exploring options and producing diagrams, but design decisions still need a human who understands the system's constraints. We have seen little queueing here, because design was rarely the throughput limit to begin with.

Coding

This is where the gains are real and visible. The Stack Overflow 2025 Developer Survey found that 84% of respondents use or plan to use AI tools in their development process, up from 76% the year before. Code volume follows adoption. More pull requests, larger diffs and more parallel branches arrive at the next stage.

Code review

Review capacity is set by senior engineers' attention, and that did not double. The same survey found that 66% of developers name AI solutions that are almost right, but not quite as their top frustration, and 45.2% say debugging AI-generated code is more time-consuming. Almost right is exactly the kind of code that takes a careful reviewer longest to catch.

Testing

Every new change needs tests written, updated and run. When code arrives faster, test maintenance falls behind first, then regression runs get longer, then failures pile up waiting for someone to decide whether they are real. Testing is usually the stage where the queue is deepest and least visible.

Release and operations

Release managers now face more changes per release window with the same appetite for risk. Without better evidence from testing, the safe response is to slow releases down, which quietly cancels the speed gained at the keyboard.

Where do queues build up once code gets cheap?

Queues build up at the first stage whose capacity did not grow with input, which in most organizations is review and testing. This is the theory of constraints applied to software delivery: the five focusing steps developed by Eliyahu Goldratt say you identify the constraint, exploit it, subordinate everything else to it, elevate it, and then repeat before inertia becomes the new constraint.

The Atlassian State of Developer Experience 2025 report shows the effect at the organizational level. In that survey of 3,500 developers and managers, 68% said AI saves them more than 10 hours a week, yet 50% reported losing 10 or more hours a week to other friction, and developers spend only 16% of their time coding. Speeding up the 16% does little if the other 84% of the system stays the same.

These are the symptoms we look for when diagnosing where the queue sits:

• Pull requests waiting for first review longer than they take to write. That is the clearest sign generation has outrun review.
• Test debt growing every sprint. New stories ship with fewer automated tests than last quarter, and the backlog of tests to write keeps getting longer.
• Regression runs that gate merges for an hour or more. Engineers batch changes to avoid the wait, which makes failures harder to diagnose.
• Red builds nobody owns. Failures sit untriaged because no one can tell quickly if the cause is the code, the test, the data or the environment.
• Release dates set by confidence, not readiness. Code is done, but no one can sign off without another manual pass.

Notice that adding more AI at the coding stage makes every one of these worse. That is the core of the perfection trap many QA teams fall into when they wait for a flawless AI rollout before changing how testing works. The constraint needs attention first.

Is test maintenance eating the hours your team should spend on new coverage? See how ContextQA's AI-based self-healing keeps suites running when the UI changes.

What does a constrained pipeline look like in numbers?

A constrained pipeline shows rising throughput at the coding stage and flat or falling throughput at release. The arithmetic below uses illustrative numbers, not data from any real company, but the shape matches what we hear from teams.

Consider a hypothetical team of 40 engineers. Before AI tools, they opened about 120 pull requests a week. Their reviewers and test pipeline could comfortably clear about 130 a week, so queues stayed short.

1. After rollout, pull requests rise to 160 a week. That is a 33% increase from faster coding, and it feels like a win.
2. Review and test capacity stays at 130 a week. Nothing about the reviewers or the regression suite changed.
3. The backlog grows by 30 pull requests every week. After four weeks, 120 changes sit waiting, almost a full week of capacity.
4. Lead time rises even though coding got faster. By Little's law, wait time equals work in progress divided by throughput. 120 queued changes at 130 a week adds close to a week of waiting per change.
5. Failure triage adds hidden load. If one pipeline run in ten shows a failure that needs a person to investigate, and each takes 45 minutes, 160 runs a week create 16 investigations and about 12 hours of triage.

The fix is not to slow coding down. It is to raise capacity at the constraint. If the team cuts each regression run to a third of its tests on most changes and auto-classifies half of the failures, the same reviewers and testers can clear 160 changes a week, and the queue drains within a month.

Is that reduction realistic? Meta's engineering team reported that its predictive test selection system catches more than 99.9% of regressions before they reach trunk while running about a third of the tests that depend on the modified code, which doubled the efficiency of its testing infrastructure. Your results will differ, but the order of magnitude is achievable.

What should you automate first in testing?

Automate the steps that every change passes through and that consume human attention without needing human judgment. In our experience that means four things, in roughly this order of payoff.

1. Regression test selection

Running the full suite on every change is the most common hidden queue. Map code changes to the tests that exercise them, run that subset on each pull request, and keep the full suite for nightly or pre-release runs. This is the single largest lever on merge wait time.

2. Failure triage

When a test fails, someone has to decide whether the product broke, the test broke, the data changed or the environment flaked. That decision is pattern matching across logs, screenshots, network calls and history, which AI handles well. Our guide to AI root cause analysis for test failures covers how to set it up and what evidence to require before trusting a classification.

3. Test creation for new work

Generate draft tests from the same inputs developers use: stories, acceptance criteria, designs and API specs. Then have a QA engineer review and harden them. Writing tests during the sprint, not after it, is what keeps test debt from growing. Our in-sprint test automation guide explains how to fit this into a two-week cadence.

4. Flaky test handling

Flaky tests poison every other signal. Google's testing team reported that about 1.5% of all test runs report a flaky result, almost 16% of their tests have some level of flakiness, and about 84% of observed pass to fail transitions involve a flaky test. If most red builds are noise, reviewers learn to ignore red, and real regressions slip through.

Quarantine known flaky tests automatically, track a flake rate per suite, and fix or delete the worst offenders on a schedule. The flaky test playbook has a step-by-step version.

What we would not automate first: exploratory testing, risk assessment for new features, and release sign-off. Those need judgment, and they are where your best QA people should spend the time the automation frees up.

How should the QA role change when AI writes most of the code?

QA should move from producing test scripts to owning release confidence. When code volume rises, the scarce skill is deciding what needs to be proven before a change ships, and proving it efficiently.

In practice, that looks like a few concrete shifts:

• From writing tests to reviewing generated tests. QA engineers curate AI-drafted tests, add the edge cases models miss, and reject tests that only restate the implementation.
• From running suites to designing suites. Someone has to decide which tests are smoke, which are regression, which run per change and which run nightly. That design is what makes test selection work.
• From reporting bugs to owning quality signals. Flake rate, escaped defects, triage time and time to green become QA-owned metrics reviewed with engineering leadership.
• From a separate phase to embedded partners. QA engineers sit with squads during refinement, so acceptance criteria are testable before code is written.

Team shape matters here. A central QA group that receives finished work will always be a queue. An embedded or hybrid model, described in our piece on QA team structure, puts testing capacity where the changes are created. We think most teams adopting AI coding tools at scale will end up hybrid: embedded QA engineers plus a small platform group that owns frameworks, test data and pipeline tooling.

One opinion we hold firmly: do not cut QA headcount on the assumption that AI will cover it. The volume of change is going up. Cut repetitive work instead, and redeploy the people to risk coverage.

What is a sensible rollout plan for AI in the SDLC?

Roll out in the order of the constraint, not in the order of vendor demos. Measure the queue first, relieve the tightest stage, and only then push more volume into the system.

Phase 1: Measure the queue (weeks 1 to 2)

• Record time from pull request opened to first review, to approval, to merge and to release.
• Record regression run duration, failure rate per run and time to triage each failure.
• Count tests written per story over the last three sprints to see whether test debt is growing.

Phase 2: Exploit the constraint (weeks 3 to 6)

• Introduce change-based regression selection on pull requests, keeping full runs nightly.
• Quarantine known flaky tests and publish a weekly flake report.
• Add automated failure classification so humans only see failures likely to be real product bugs.

Phase 3: Subordinate the rest (weeks 7 to 10)

• Set a work in progress limit on open pull requests per team so coding does not outrun review.
• Make test creation part of the definition of done, with AI drafts reviewed by QA in the same sprint.
• Agree on a small set of evidence that must accompany every change before review starts.

Phase 4: Elevate and repeat (week 11 onward)

• Add self-healing for locator and UI changes to cut maintenance on stable suites.
• Expand AI-assisted test generation to APIs and design files, not just stories.
• Re-measure. When review and test queues are short, the constraint has moved, perhaps to requirements or to release approvals, and the cycle starts again.

A quick scorecard to check progress

• Time to first review under one working day for most pull requests.
• Regression gate under 20 minutes on most pull requests.
• Flake rate falling quarter over quarter, with a named owner per suite.
• Triage time measured and trending down, with most failures classified automatically.
• Test debt flat or shrinking, measured as untested stories per sprint.

The targets above are starting points we suggest, not industry benchmarks. Set your own based on the Phase 1 baseline.

How does ContextQA help relieve the testing bottleneck?

ContextQA is an AI test automation platform built for the stages where AI-driven volume now queues: test creation, test selection, maintenance and failure diagnosis. Here is how it maps to the plan above.

• Test generation from many sources. The platform documents AI test generation from Jira tickets, Figma designs, OpenAPI specs, URLs, video recordings, plain text and code changes, so QA starts from a draft instead of a blank page.
• PR impact analysis. It maps GitHub pull request changes to affected tests, and a reviewer chooses what to run before execution. That is regression selection with a human in the loop.
• Self-healing tests. When the UI changes, healing finds the equivalent element so the run continues, and every repair is logged with before and after context for review.
• Root cause analysis. Failures are analyzed across visual, DOM, network, code and data layers, related failures are clustered across builds, and diagnoses point to a likely file and fix.
• Pipeline fit. It plugs into Jenkins, GitHub Actions and GitLab, so results land where developers already work.

None of this replaces QA judgment. It removes the repetitive work in front of it, which is the point of exploiting a constraint. If maintenance is your biggest drain, start with self-healing and measure the change in time spent fixing broken tests.

Ready to move your bottleneck? Book a ContextQA demo and bring your Phase 1 numbers. We will show you which stage to tackle first.

Bottom line

AI in the SDLC did not remove the bottleneck. It moved it. Code generation is cheap now, and review, testing and release confidence absorb the extra volume. Teams that keep pouring more AI into coding will see busier engineers and the same release dates.

Find the queue, relieve it with regression selection, automated triage, in-sprint test creation and flaky test discipline, and give QA ownership of release confidence. Then measure again, because the constraint will move once more.

Sources

1. 2025 Stack Overflow Developer Survey: AI, Stack Overflow, https://survey.stackoverflow.co/2025/ai. Cited for 84% AI tool adoption, 66% almost right frustration and 45.2% debugging AI code taking longer.
2. Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1, GitHub, https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/. Cited for 518.7 million pull requests merged, up 29% year over year.
3. Atlassian research: AI adoption is rising, but friction persists (State of Developer Experience 2025), Atlassian, https://www.atlassian.com/blog/developer/developer-experience-report-2025. Cited for 68% saving 10+ hours a week, 50% losing 10+ hours, and 16% of time spent coding.
4. The Five Focusing Steps, Theory of Constraints Institute, https://www.tocinstitute.org/five-focusing-steps.html. Cited for Goldratt's five focusing steps.
5. Predictive test selection: A more efficient way to ensure reliability of code changes, Meta Engineering, https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/. Cited for catching more than 99.9% of regressions while running a third of dependent tests.
6. Flaky Tests at Google and How We Mitigate Them, Google Testing Blog, https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html. Cited for 1.5% flaky test runs, 16% of tests with flakiness and 84% of pass to fail transitions involving flaky tests.