Every diagram of the AI software development lifecycle looks the same. The familiar phases in the familiar order, each one now with a machine beside it, each one faster. The diagram is accurate and it is the wrong thing to be looking at.
The phases did not change. Requirements, design, build, test, release, operate. They are all still there and still in that order, because the order was never a convention that could be modernised away.
What changed is the ratio inside each phase between producing an artefact and checking whether it is right. Producing collapsed. Checking did not move. Almost everything teams currently find confusing about working this way follows from that one sentence, including why their delivery metrics have quietly stopped carrying information.
What the classic SDLC was actually for
It helps to be precise about what the old lifecycle was doing, because the popular version of the story has it backwards.
The phases were not a production line. They were a series of checkpoints, ordered by how expensive a mistake becomes if it survives to the next one. A misunderstanding caught while the requirement is being written costs a conversation. The same misunderstanding caught in production costs an incident, a rollback, and the trust of whoever reported it. Every phase boundary existed to catch the previous phase's errors while they were still cheap.
That thread runs through every reform of the lifecycle since. Winston Royce drew the sequential diagram in 1970, in a paper that then argued the sequential version was risky and invited failure, and recommended iterating instead. The Agile Manifesto in 2001 made the same argument more forcefully: you cannot get the requirements right in advance, so shorten the distance between building something and finding out. DevOps then attacked the last long gap, between a change being finished and a change being in front of users.
None of those movements was about producing artefacts faster. Every one of them was about finding out sooner whether the artefact was wrong.
The AI SDLC is the same phases with the producing time taken out
Go phase by phase and the pattern is consistent enough to be worth setting out plainly.
- Requirements. Drafting the document compresses enormously. Finding out what the customer actually needs does not compress at all, because that information is not in your repository and not in your prompt. It is in a conversation somebody has to have.
- Design. Producing options, diagrams and trade-off write-ups compresses. Deciding which constraint you are unwilling to break does not, because that is a commitment rather than an analysis.
- Build. The largest compression by far, and the real one. This is where the change is genuinely dramatic and where most of the excitement is correctly aimed.
- Test. Writing the tests compresses. Knowing what correct behaviour is does not, and a suite generated from the implementation asserts what the code does rather than what it should do.
- Release. Already automated before any of this arrived. Very little changed, which is worth noticing on its own: the phase that was already solved is the phase AI barely touched.
- Operate. Clustering alerts and drafting incident summaries compresses. Deciding what an incident means, and whether to roll back, does not.
Read the list as a whole and the shape is obvious
In every single phase, the part that compressed is the part where somebody already knew what they wanted and had to write it down. The part that did not compress is the part where somebody has to decide what is true, or what matters.
The lifecycle has not been replaced. It has been squeezed in exactly one direction, and the direction is the one nobody put on the diagram.
This is why the phase-by-phase acceleration story is misleading even though every individual claim in it is true. Yes, requirements are faster. Yes, code is faster. The acceleration is real and it is concentrated entirely in the half of the work that was never the reason the lifecycle had that shape.
Why a faster loop with the same review capacity learns less, not more
Here is the part that catches teams out, and it is arithmetic rather than opinion.
The value of a short feedback loop comes from the finding out, not from the going round. A loop is worth running because something comes back that you did not already know, and that knowledge arrives at the verification step: the review, the test result, the user's reaction, the incident.
So if the building half of the loop gets five times faster and your capacity to verify stays where it was, you do not get five times the learning. You get the same learning, arriving at the same rate, sitting on top of five times as much unverified output. The queue in front of the review step grows, and a queue is where value goes to wait.
There is a second-order version of this that is worse. Continuous delivery works because of small batches: when a small change breaks something, the diagnosis is short, because there is very little that could have caused it. Generation makes a large batch as cheap to produce as a small one, and the natural thing to do with a tool that writes a thousand lines as easily as fifty is to ask it for a thousand. That reverses the single discipline that made modern delivery reliable, and it reverses it for a reason that feels like efficiency at the time.
Keeping batches small is now a deliberate act of restraint. It used to be enforced for you, by how long the work took.
The new failure mode: artefacts that look finished when nothing was decided
The old lifecycle had a property nobody designed and nobody wrote down, and it is gone.
An unfinished artefact looked unfinished. A spec with an open question had a gap in it, or a sentence that stopped. A half-built design document was visibly half built. The artefact carried a signal about its own completeness, for free, because a person producing it could only get as far as their understanding went.
Generated artefacts arrive complete regardless of how much was actually understood. The model does not stall where the author would have stalled, because it has seen ten thousand documents of that shape and will produce a plausible sentence for the gap. What you get is a document that reads as though every question was answered, with no list of the ones that were not.
Every gate in the classic lifecycle depended on that missing signal. Design review assumed the design in front of it represented somebody's real thinking. Code review assumed the author understood the change they were proposing. Those assumptions were sound when producing the artefact required the understanding. They are not sound now, and almost nobody has redesigned their reviews to account for it.
We ran into this directly building the assessment engine for our own product. The instinct when assessing an engineer is to ask what they know: what a good design document contains, what the trade-offs of an approach are, how they would structure a suite. Those questions have well-known answers, and a well-known answer can now be produced fluently by anybody, whether or not they have ever done the work. What separated people was handing them a real artefact with a real problem buried in it and watching where they looked first. That is a verification skill, and it turns out to be the thing the whole lifecycle now runs on.
Which delivery metrics survive, and which stopped carrying information
If the ratio of producing to checking has inverted, the numbers on your dashboard were calibrated for a world that no longer exists. There is a clean rule for sorting them: metrics that measured production effort are broken, and metrics that measured outcomes still work.
- Velocity and story points. Broken. They estimated how long work would take a person, and that is precisely the quantity that changed most.
- Lines of code, commit count, pull requests opened. Always weak, now actively misleading, because they are the easiest numbers in the entire system to inflate by accident.
- Code coverage. Broken for the same reason as velocity. Coverage was a proxy for whether somebody had reasoned about the behaviour, and it worked only because writing tests was expensive.
- Cycle time. Still meaningful, but it now measures something different. Mostly it reports the length of the queue at your review step rather than the difficulty of the work, which is worth knowing as long as you read it that way.
- Change failure rate and time to restore service. Untouched, and more valuable than they were. They measure what happened in production, which no amount of generation can flatter.
- Escaped defects, and the share of review comments that find a real problem. Start tracking these if you do not already, because they measure verification directly, and verification is now the constraint.
Why effort metrics broke and outcome metrics did not
The reason is the same one running underneath this whole argument, and it is worth stating once on its own.
Effort metrics were always proxies. They were never interesting in themselves. They were interesting because producing output was expensive, so a lot of output implied a lot of thinking had happened somewhere behind it. Remove the expense and the proxy stops standing for anything at all.
Outcome metrics were never proxies. They measured the thing you actually cared about, so nothing happened to them.
This gives you a test for any number you currently report. Ask whether it was interesting because of what it measured, or because of what it implied about the effort behind it. If the answer is the second one, it has stopped working, and it stopped working without changing in any visible way. That is what makes it dangerous rather than merely useless.
What to do on Monday
None of this is an argument for using the tools less. The compression in the build phase is real, it is large, and a team that refuses it is choosing to be slower for no benefit.
- Put verification in the plan as work, with a name and an owner. It used to arrive free, bundled inside the time it took to produce the thing. A plan that budgets only for building is budgeting for the half that got cheap.
- Keep batches small on purpose. The constraint that used to enforce this has been removed, so it has to become a rule instead.
- Write down what was not decided. Before generating a spec or a design, spend fifteen minutes listing by hand the questions that would have to be answered for this to be right. That list is exactly what the artefact no longer gives you.
- Change the metrics before the volume rises rather than after. Once the dashboards are full of inflated production numbers, the argument about whether they mean anything becomes political rather than technical.
- Review as a reviewer, not as an author. Reading something critically that you did not write is a distinct skill from writing it, and until recently the same person did both in one motion, so nobody had to separate them. It is now most of the job.
The lifecycle was right about the thing that still matters
The people who built the classic SDLC understood that the expensive mistakes are the ones you find late. That has not changed, and nothing on the horizon changes it.
What changed is that the earliest phases now hand you finished-looking work at a speed the checking has no way to match. The gates are all still there. They are just being asked to pass judgement on artefacts that no longer show their own workings, at a rate they were never designed for.
The only question that matters is whether you notice that before production notices it for you.
