The software lifecycle didn't get shorter. The gaps did.

Ask anyone who has managed a software project where the time went and they will describe the stages: discovery, design, build, test, release. Ask them to add up the days actually spent doing those things and the total is embarrassingly short compared to the elapsed calendar.

The rest is gaps. Waiting for a specification to be signed off. Waiting for a developer to be free. Waiting for the review. Waiting for a test environment. A question asked on Tuesday and answered the following Monday. A handover document that took a week to write and an afternoon to misunderstand.

The stages themselves have not changed much in thirty years, and mostly they should not. You still need to understand the problem before you build the solution. You still need to test the thing before you give it to customers. What has changed is the cost of the gaps.

Where the gaps came from

Nearly every gap in a traditional project exists because work has to move between people. Each handover needs a document, a meeting, or both. Each person has a queue. The queue is where the calendar goes.

A typical small build might involve a business analyst, a designer, two or three developers, a tester, and someone who looks after the infrastructure. Six people, each with other commitments, each needing the previous person's output before they can start. Even with everyone doing excellent work, the project runs at the speed of its slowest handover.

What changes with AI in the loop

When a small team of experienced engineers orchestrating AI can produce the specification, the implementation, the tests, and the deployment configuration in the same working day, the handovers disappear and the stages stay.

On one of our projects it works like this.

Discovery and specification happen in the same week. We sit with you, we write the spec together in plain English, and by the end of the week there is a working skeleton of the system you can click around. Questions that would have waited for a follow-up meeting get answered by showing you the thing.

Build and test are the same activity. Every change comes with its tests, because writing the tests is no longer a separate chore that gets cut when time is short. The test suite runs on every commit. A regression is caught in minutes rather than found by a customer.

Release is boring. The deployment pipeline is built in the first week. Staging exists from day one. By the time we go live, the system has been deployed dozens of times.

Documentation exists. It is generated alongside the code and reviewed by the same person, so it describes the system that was built rather than the one that was planned.

What does not change

The compression does not come from skipping steps. Skipping review, skipping tests, and skipping the security conversation are exactly how you get the fragile software that has given "built with AI" a bad name.

The compression comes from removing the waiting. Everything that used to take a week of calendar time and a day of actual effort now takes a day. The day is still there.

What this means for a six-month project

A project that would have been quoted at six months by a conventional agency is, in our experience, six to ten weeks of work. Nobody works harder and the software is no smaller. The calendar is no longer full of Tuesdays spent waiting for Monday's answer.

That has a knock-on effect on cost and on risk. A shorter project is cheaper, obviously. It is also far less likely to be overtaken by events. Requirements that were true in January are often not true by July. In a six-week build they usually still are.