AI made code cheap. It didn't make approval cheap.

Part 2 of 3: The SDLC reimagined for the AI era

TL;DR

• AI has increased how much code teams ship, while review and approval still run at human pace in many organisations.
• More human gates is the wrong answer. Place each check in the cheapest layer that can be trusted with it: automated gates, AI judgement measured per task, people for risk.
• Decision for the next leadership agenda: which changes may ship on automated checks alone, and who signs off the rest. It starts with a baseline every repository must meet.

More code, same approval

In Part 1 I argued that the software lifecycle rests on assumptions AI has broken, and that the bottleneck has moved from building software to deciding what may change. This part takes the first of two problems: what happens when AI writes the code. Part 3 covers software that contains AI.

Shopify's CTO said in April that good models, he would claim, now write code with fewer bugs on average than the average human, "but since they write so much more of it, ... more of it will make it into production."

Deciding whether that code is safe to ship still runs at human pace in many of the organisations I have worked in: a Jira change ticket, a four-eyes approval on every pull request, a static security scan whose report someone reads afterwards, and a weekly change advisory board (CAB).

The old gates fail in two ways

Google Cloud's 2025 DORA research (the DevOps research programme, not the EU regulation) names the precondition: "Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

Push AI-sized volume through gates built for human pace and two things happen. First, queues grow. Meta says its review capacity is "constrained by human attention". A preprint study, "AI Writes Faster Than Humans Can Review", followed one enterprise's "2x mandate": the load on each reviewer roughly doubled and automated review overtook human review, although merge and revert rates held steady. Faros AI's 2026 research, drawn from 22,000 developers, found that once a review starts, the median time spent on it is up 441.5%. Second, approvals get thinner. Semgrep, writing about the same 2x-mandate study, reports that silent approvals per reviewer roughly doubled. A skim still produces a signature, so on paper the control looks intact.

Veracode's 2026 tests found AI-generated code passing syntax checks almost every time but security checks only 56% of the time. Faros's newer report, drawn from the same developers, shows a 76.3% rise in pull requests merged with no review at all, although incidents per pull request rose only 14.5%. That is vendor data and a relative rise, and the incident figure cuts the other way, but the review gap fits the DORA warning above.

More human gates is the wrong answer

The reflex is to add an approval step for everything. DORA's research on change approval, which dates from 2019, looked at exactly this kind of heavyweight approval by people outside the team, such as a change advisory board. It found no evidence that it lowers change failure rates, and found that it hurts delivery. So the weakness predates AI. AI raises the volume until it can't be ignored.

Putting a human after an AI reviewer doesn't fix it either. In a controlled experiment with 29 experts, reviewers who saw an AI review first "tend to focus on the code locations indicated by the LLM". They found no more of the serious issues and saved no time. It is one study, of 2024-era tools, but my reading is that a signature after the AI is not automatically a second opinion.

So the question is where each check belongs.

Three layers of control

The way I would frame it: send every check to the cheapest layer that can be trusted with it.

1. Deterministic gates. Tests, static security scans, dependency checks, data contracts and schema checks, policy as code. They need no judgement, so there is no trust question. Automate them fully, make them blocking in the pipeline rather than reports someone reads later, and move more checks into this layer than you have today.

2. AI judgement, trusted per task. You trust an AI reviewer for a task you have measured it on, not in general. That means a narrow brief, a model from a different family than the one that wrote the code, and its calls compared with human calls before it gets any authority. Research across more than 350 models found that on one benchmark, two models that are both wrong give the same answer 60% of the time, and that larger models share errors even across providers. Code review was not tested, but the lesson carries. And re-measure the reviewer whenever its model or prompt changes: an AI reviewer is itself software with AI inside, the subject of Part 3.

Model diversity is not enough on its own. Two AI reviewers can inherit the same stale requirement or the same wrong assumption, whatever their model family. For consequential changes, the stronger check is independent evidence from reality: tests that actually ran, deployment receipts, production telemetry and the system of record itself.

One rule I would add: an AI reviewer may block a high-risk change, but never approve one. Some teams already let an AI reviewer approve changes; Cloudflare's can approve as well as block, with a human override. For routine changes that can be fine. High-risk and regulated code is where I would keep approval with a person. And in my design, if the AI reviewer is slow, down or behaving erratically, the change waits or goes to a person. It never passes by default.

3. Human judgement: on the loop, not in the loop for every line. Accepting risk, irreversible or high-criticality changes, and exceptions. And checking the checkers: regularly sampling what the AI reviewers let through, rather than re-reading everything they passed.

Meta has published a system close to the first two layers: a funnel of rules, an AI risk score, LLM review and deterministic checks, which has landed more than 331,000 changes without waiting for a human reviewer, keeping code in scope for SOX financial controls out of that path. Changes reviewed this way had a third of the revert rate and a fiftieth of the incident rate of other changes, though Meta calls that "not a causal estimate" and limits it to "low to medium complexity diffs that are eligible".

In my own work the scale is smaller. On TraceGov, a Quantamix Solutions platform where I am technical architect, we let AI do most of the work from an approved plan to production. Every hour, a builder agent takes the next approved item, builds and tests it, and opens a pull request. Two AI reviewers, one on a different model, check it against a written rubric and record a verdict on that exact commit. Nothing merges without both approvals and green tests. Changes to identity, sign-up or shared code still go to the platform owner. In the first ten days, the reviewers sent back more than a third of the backend pull requests. One approved change still broke document upload in production. It passed review and tests, but the deployed package held an old copy of a library the diff never showed. Evidence from production caught it, and a one-line fix shipped about four hours later.

Who decides what

Every role in delivery now has to decide what it checks itself, what it lets AI check, and what it stays accountable for.

• CTO or CIO: sets the risk appetite, funds the controls and not only the tools, and measures stability and cost per validated outcome rather than approval speed.
• Product owner: owns intent. When agents build from a story, a vague story now costs a stream of wrong changes. As Birgitta Böckeler of Thoughtworks puts it, "Correctness is outside any sensor's remit if the human didn't clearly specify what they wanted in the first place."
• Engineers, risk and compliance: engineers own the gates and stay accountable for code they didn't type. Risk and compliance turn policy into automated checks, for example in a policy engine such as Open Policy Agent, and sample instead of reviewing at the end.
• Architect: Someone has to hold this together as one design, in two parts. First, a minimum baseline that every repository must meet, across business units. Then the tiers on top: which check sits in which layer and what evidence counts, kept consistent across teams, tools and vendors, with every gate leaving evidence that flows into the risk register and audit trail. Compliance can then follow the pipeline instead of waiting for a review. Without that, each team writes its own pipeline rules, and the CIO's risk appetite does not reliably reach production.

Binding rules ask for proportionate control, not a human on every line

Regulated organisations are not starting from zero. In financial services, the technical standard on ICT risk management under the EU Digital Operational Resilience Act already requires testing "commensurate to the criticality" of the systems involved, and approval functions independent of those that request and implement a change. On my reading, it does not require a human to read every change.

The pattern holds outside finance. The Commission's rules under the EU NIS2 cybersecurity directive ask digital providers to test and assess changes based on a risk assessment, and since 15 August 2026 Dutch law has required other essential and important entities, healthcare among them, to apply change management demonstrably. On my reading, none of these texts asks for a human to read every line.

Non-binding guidance is less settled, and the public bodies that have written about AI-written code don't agree on how much human review that means. ENISA's draft technical advisory asks for the same security assurance as for developer-written code, scaled to risk, and keeps "the human decision to accept the change" with a person. UK government guidance for its own developers requires human peer review on every merge to the main branch. One NCSC blog post, by its CTO for Architecture, said in March that a mitigation "sometimes suggested", that "all code written by AI must be reviewed by a human", is already "creaking at the seams for organisations that want to build aggressively".

So the open question is the same for every organisation: what proportionate, independent control looks like when one agent wrote the change and another pre-reviewed it.

Where I would start

1. Map your paths to production. List the repositories that ship, which of them have a pipeline and blocking checks, and who decides when a change goes live. You can't tier what you can't see.
2. Agree a minimum baseline, with one named owner across business units (an architect is a natural choice): a pipeline, blocking tests and static security scans, and a recorded release decision for every repository that ships. Bring teams onto it in waves, starting where AI use and risk are highest.
3. Sort changes into two or three risk tiers, and write down which tier may ship on automated checks alone. That list is your risk appetite, in a form engineers can use. Changes that only ever need the baseline checks can then come off the CAB agenda.
4. Run any AI reviewer in shadow mode for a quarter. Compare its calls with your reviewers' decisions before it gets any authority, and use a different model from the one that wrote the code.
5. Every week, sample a fixed share of what passed without a human, and treat what you find as data about the checks.
6. Track change failure rate, rework and incidents next to throughput, and feed the results back into the tiers.

One decision

If I were a CIO, I would put one decision on the next leadership agenda: which changes may ship on automated checks alone, and who signs off the rest. Without it, every team improvises its own answer.

That decision has a second half. An action gate decides whether a change may proceed. A learning gate decides, once the change has shipped and been checked against what actually happened, whether its result may shape the next approval. Without the second gate, a pipeline gets faster at approving but never better at it.

An IBM training slide said to date from 1979 is quoted a lot these days: "A computer can never be held accountable." That is still true, which is why people have to decide in advance what a machine may check.

Part 3 turns to the other half of the problem: software that contains AI, where a model upgrade or a prompt edit can change behaviour without a single line of code changing.

Which changes does your organisation let ship on automated checks alone today? And who decided that? I'd like to hear in the comments.

Thanks to Harish Kumar from Quantamix Solutions for reviewing a draft and contributing the ideas on independent evidence and the learning gate.

Researched and drafted with the help of AI tools. The views and experience are mine, and every source was checked.

First published on LinkedIn.

Sources

1. Adams et al. "Automating Low-Risk Code Review at Meta: RADAR, Risk Calibration, and Review Efficiency." arXiv 2605.30208, May 2026 (v2 June 2026). https://arxiv.org/abs/2605.30208
2. Altas, D. "The End Is Nigh for Code Review." Semgrep, 9 October 2026. https://semgrep.dev/blog/2026/end-is-nigh-for-code-review/
3. Böckeler, B. "Harness engineering for coding agent users." martinfowler.com, 2 April 2026. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
4. Chismon, D. "Vibe check: AI may replace SaaS (but not for a while)." UK National Cyber Security Centre blog, 24 March 2026. https://www.ncsc.gov.uk/blogs/vibe-check-ai-may-replace-saas-but-not-for-a-while
5. Commission Delegated Regulation (EU) 2024/1774, regulatory technical standards on the ICT risk management framework under the EU Digital Operational Resilience Act. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj
6. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, technical and methodological requirements under NIS2. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2690
7. ENISA. "ENISA Technical Advisory on AI-assisted software development." Draft, version 0.4, September 2026. https://www.enisa.europa.eu/sites/default/files/2026-09/ENISA%20Technical%20Advisory-AI-assisted-software-development-draft.pdf
8. Faros AI. "AI Engineering Report 2026: The Acceleration Whiplash." April 2026. https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf
9. Faros AI. "The most expensive number in our new AI Engineering report." 9 October 2026. https://www.faros.ai/blog/the-most-expensive-number-in-our-new-ai-engineering-report
10. Faros AI. "The Speed Trap: 8 takeaways from our latest AI engineering research." 18 September 2026. https://www.faros.ai/blog/ai-speed-trap-takeaways
11. Google Cloud. "Announcing the 2025 DORA report" (State of AI-assisted Software Development). September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
12. Google Cloud DORA research. "Streamlining change approval." Finding from the 2019 research programme. https://dora.dev/capabilities/streamlining-change-approval/
13. GOV.UK. "AI Insights: AI coding assistants for developers in HMG." Updated 3 August 2026. https://www.gov.uk/government/publications/ai-insights/ai-insights-ai-coding-assistants-for-developers-in-hmg-html
14. He et al. "AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate." arXiv 2607.01904, 2 July 2026. https://arxiv.org/abs/2607.01904
15. Kim et al. "Correlated Errors in Large Language Models." ICML 2025. https://arxiv.org/abs/2506.07962
16. Latent Space. "Shopify's AI Phase Transition," with Mikhail Parakhin, Shopify CTO. 22 April 2026. https://www.latent.space/p/shopify
17. Open Policy Agent. Project website. https://www.openpolicyagent.org/
18. Rijksoverheid. "Cyberbeveiligingswet en Wet weerbaarheid kritieke entiteiten vanaf 15 augustus 2026 van kracht." 7 July 2026. https://www.rijksoverheid.nl/actueel/nieuws/2026/07/07/cyberbeveiligingswet-en-wet-weerbaarheid-kritieke-entiteiten-vanaf-15-augustus-2026-van-kracht
19. Skidmore, R. "Orchestrating AI Code Review at scale." Cloudflare blog, 20 April 2026. https://blog.cloudflare.com/ai-code-review/
20. Tufano et al. "Deep Learning-based Code Reviews: A Paradigm Shift or a Double-Edged Sword?" ICSE 2025. https://arxiv.org/abs/2411.11401
21. Veracode. 2026 GenAI Code Security Report, press release. 28 July 2026. https://www.veracode.com/news/llms-are-getting-smarter-but-not-safer-veracode-2026-genai-code-security-report-finds-ai-generated-code-security-has-stalled-at-56%25-pass-rate/
22. Willison, S. "A computer can never be held accountable." 3 February 2025, quoting an IBM training slide said to date from 1979. https://simonwillison.net/2025/Feb/3/a-computer-can-never-be-held-accountable/