DEV Community: Jay Shetty

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

Jay Shetty — Fri, 06 Nov 2026 11:00:53 +0000

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.

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

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.
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.
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.
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.
Every week, sample a fixed share of what passed without a human, and treat what you find as data about the checks.
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

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
Altas, D. "The End Is Nigh for Code Review." Semgrep, 9 October 2026. https://semgrep.dev/blog/2026/end-is-nigh-for-code-review/
Böckeler, B. "Harness engineering for coding agent users." martinfowler.com, 2 April 2026. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
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
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
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
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
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
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
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
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
Google Cloud DORA research. "Streamlining change approval." Finding from the 2019 research programme. https://dora.dev/capabilities/streamlining-change-approval/
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
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
Kim et al. "Correlated Errors in Large Language Models." ICML 2025. https://arxiv.org/abs/2506.07962
Latent Space. "Shopify's AI Phase Transition," with Mikhail Parakhin, Shopify CTO. 22 April 2026. https://www.latent.space/p/shopify
Open Policy Agent. Project website. https://www.openpolicyagent.org/
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
Skidmore, R. "Orchestrating AI Code Review at scale." Cloudflare blog, 20 April 2026. https://blog.cloudflare.com/ai-code-review/
Tufano et al. "Deep Learning-based Code Reviews: A Paradigm Shift or a Double-Edged Sword?" ICSE 2025. https://arxiv.org/abs/2411.11401
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/
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/

The software lifecycle was built for human pace. AI broke it twice.

Jay Shetty — Fri, 06 Nov 2026 10:52:52 +0000

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

I build with Claude Code. On Signal Radar, a live platform I run, Claude Code writes the code, and I direct the architecture and review what ships. Deciding what may ship has become the real work. This series looks at the same shift in large organisations, where the volume is far higher and the controls were built for a slower pace.

TL;DR

The software lifecycle rests on four unwritten assumptions: people write the changes, only code changes, the same input gives the same output, and a person checks each change.
AI breaks all four from two sides: it now builds the software, and it now sits inside it.
In my view the answer is a lifecycle designed as a control system, deciding continuously what may change and on what evidence. Someone has to design it across teams.

Two stories, one cause

In April 2026, Google said that "75% of all new code at Google is now AI-generated and approved by engineers". Engineers approve it. The open question is what approval means at that volume.

On 25 April 2025, OpenAI rolled out an update to GPT-4o in ChatGPT that made the model "noticeably more sycophantic". Its offline evaluations "generally looked good", and a small number of users in A/B tests liked it. Some expert testers said the model "felt" slightly off. OpenAI shipped it on the strength of the positive signals, without announcing it, because it "expected this to be a fairly subtle update". It later called that "the wrong call" and rolled the update back. The automated checks passed. The question there is what a passing check proves.

These look like unrelated stories. One is AI writing software, the other is software made of AI. I think they share a cause: change is arriving faster, and in less visible forms, than the controls we built were designed for.

The assumptions underneath the SDLC

In my years as an architect, the software lifecycle has rested on four assumptions nobody writes down. Waterfall, agile and DevOps changed the rhythm, but not these, and each one carries a control we rely on:

People write the changes, so the volume of change is limited by people. That is why a weekly change advisory board can keep up.
Code is what changes, so reviewing the code means reviewing the change. That is what a pull request review relies on.
The same input gives the same output, so a passing test proves something. That is what the test phase relies on.
A person can look at each change before it ships, so a sign-off on a change ticket is a real control.

The first and fourth are about human capacity. The second and third are about what a change is. And in the large organisations I have worked in, the controls themselves vary: hundreds of repositories, each with its own route to production, some with no pipeline at all.

AI undoes all four, from two directions.

First break: AI builds the software

Throughput is up. Google Cloud's DORA research (DevOps Research and Assessment, no relation to the EU regulation with the same initials) found in 2025 that AI adoption "now improves software delivery throughput". A preprint study of one enterprise under a "2x mandate" found output per developer at 2.09 times the earlier baseline. At Meta, changes per developer rose 51% in a year, most of it from agentic AI, and Meta describes its review capacity as "constrained by human attention".

Stability has not kept up. The same DORA report, a survey that describes associations, finds that AI "still increases delivery instability". Its authors read that as a sign that "underlying systems have not yet evolved to safely manage AI-accelerated development".

That breaks the first and fourth assumptions. People no longer limit the volume of change, and people can no longer look at every change.

Second break: AI sits inside the software

The second break is quieter. When a product contains a model, its behaviour can change without anyone touching a line of code. Prompts, retrieval data and model versions behave like code: change any of them and the behaviour can change, whether or not anyone raised a pull request. The FSB noted in its October report that "small linguistic changes to the input (prompt) of a LLM can significantly change the output".

Some of those changes arrive on someone else's calendar. OpenAI's stated minimum notice before retiring a generally available model is six months. Its notice of 14 October retires GPT-4o and GPT-4.1 snapshots on 14 January 2027, three months later. Some arrive with no model change at all. Anthropic traced degraded answers in 2025 to bugs in its serving infrastructure, and wrote that "the evaluations we ran simply didn't capture the degradation users were reporting." And the same prompt need not give the same answer twice.

That breaks the second and third assumptions. Reviewing the code doesn't show you the change, and a passing test proves less than it did.

From a production line to a control system

The SDLC we inherited is a production line with a quality check near the end. The one we need is a control system. A control system senses what is happening, compares it against a limit, acts, and feeds the result back. Applied to software, it decides continuously what may change, who or what may approve it, and on what evidence.

Meta's published design is the nearest public example I know. Its system, RADAR, sorts changes by risk and lets eligible ones land without waiting for a human reviewer. Its reported results cover low to medium complexity changes, and code in scope for SOX financial controls is excluded and still goes to people.

Five shifts follow from thinking this way:

From a verification phase to verification at the centre. Building is cheap now, so deciding what ships is where the work is.
From stage gates to layered control. Each check goes to the cheapest layer that can be trusted with it: automated gates, AI judgement measured per task, and people for risk and exceptions.
From testing to evaluation. You measure behaviour, including how often the system is confidently wrong, not only whether a test passes.
From release to controlled exposure, followed by a learning loop that feeds what actually happened back into the controls.
From authors and approvers to designers of the controls and owners of the risk.

Someone has to design this as one system across teams, tools and vendors: which checks run where, what evidence each one needs, how a model or prompt change gets caught, and how what happened in production flows back into the controls. In my view that is where architecture is most useful now.

Why this is still unsettled

I could find no organisation in a regulated sector that has published how it changed code review or change control for AI. I looked hardest at banks and insurers. Nor could I find a named enterprise that has published defect or rework rates for AI-written code against human code. Some of the data on review bottlenecks comes from vendors who sell the fix. If your organisation has changed its controls for AI, or you know one that has, I would like to learn how it went.

Regulators have the principles but not the specifics. The EU Digital Operational Resilience Act already requires financial firms to control every change to their ICT systems, and the FSB asks for "documented change management processes throughout the AI lifecycle". The EU AI Act's rules for high-risk systems such as credit scoring apply from 2 December 2027, after this year's amendment. None of them yet sets out how to control AI-written code, and the FSB only asks firms to consider how a vendor handles model updates.

Google Cloud's DORA research calls AI an amplifier that "magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones". I read the gap as organisational maturity, and in large organisations it varies from one team to the next.

What comes next

The bottleneck has moved from building software to deciding what may change, and it has moved in two places at once.

The next two articles take one each. Part 2 sets out three layers of control for AI-written code: who approves it, why more human gates is the wrong answer, and the learning gate that closes the loop. Part 3 sets out how to decide by irreversibility when the software itself contains AI: why a model upgrade or a prompt edit is a change, how testing becomes evaluation, and what the architecture has to provide.

Where I describe something I have built, I say so. The rest is my proposal.

Which of these four assumptions does your team's change control still depend on? I'd like to hear in the comments.

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

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
Anthropic. "A postmortem of three recent issues." 17 September 2025. https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
Financial Stability Board. "Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final Report." 15 October 2026. https://www.fsb.org/2026/10/sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-final-report/
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
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
OpenAI. "Deprecations." Notice of 14 October 2026. https://developers.openai.com/api/docs/deprecations
OpenAI. "Expanding on what we missed with sycophancy." Update rolled out 25 April 2025; post date not shown on the page (widely reported as 2 May 2025). https://openai.com/index/expanding-on-sycophancy/
Pichai, S. Cloud Next '26 keynote post. Google blog, 22 April 2026. https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/
Regulation (EU) 2022/2554 (EU Digital Operational Resilience Act). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554
Regulation (EU) 2024/1689 (EU AI Act), as amended by Regulation (EU) 2026/1744. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

DEV Community: Jay Shetty

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

TL;DR

More code, same approval

The old gates fail in two ways

More human gates is the wrong answer

Three layers of control

Who decides what

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

Where I would start

One decision

Sources

The software lifecycle was built for human pace. AI broke it twice.

TL;DR

Two stories, one cause

The assumptions underneath the SDLC

First break: AI builds the software

Second break: AI sits inside the software

From a production line to a control system

Why this is still unsettled

What comes next

Sources