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:

  1. People write the changes, so the volume of change is limited by people. That is why a weekly change advisory board can keep up.
  2. Code is what changes, so reviewing the code means reviewing the change. That is what a pull request review relies on.
  3. The same input gives the same output, so a passing test proves something. That is what the test phase relies on.
  4. 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

  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. Anthropic. "A postmortem of three recent issues." 17 September 2025. https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
  3. 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/
  4. 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
  5. 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
  6. OpenAI. "Deprecations." Notice of 14 October 2026. https://developers.openai.com/api/docs/deprecations
  7. 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/
  8. 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/
  9. Regulation (EU) 2022/2554 (EU Digital Operational Resilience Act). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554
  10. Regulation (EU) 2024/1689 (EU AI Act), as amended by Regulation (EU) 2026/1744. https://eur-lex.europa.eu/eli/reg/2024/1689/oj