AI has made software cheaper to build. It hasn't made technology easier.

Code now costs far less to produce. AI writes much of it, tests included, in a fraction of the time a team once needed. Technology has not become any easier to get right. The work that decides the result has moved upstream, to how precisely a business defines what it wants before the build starts.

That shift changes where the risk sits. When builds were slow, a weak brief cost time, but the team had months to notice and adjust. Now AI builds a slightly wrong brief quickly and in full, and the mistake looks finished when it arrives. A delivery process designed for slow builds puts its effort into the build and leaves the brief to whoever has time.

The build is no longer the slow part

AI writes code and tests from a specification, quickly and without fatigue. On one recent build, the team's whole process came down to two meetings a week: an internal call on Friday to show the week's work, and a session with the product lead. AI wrote the code. The team made sure it was right.

That speed exposes everything around it. Google's 2025 DORA report describes AI as an amplifier: strong teams get better, and weaker teams find their problems intensified. The same research found that AI adoption still has a negative relationship with delivery stability; DORA's explanation is that faster change exposes weaknesses downstream.

Rituals designed for slow builds now add delay. A two-week cycle made sense when the code took two weeks. When the code takes hours, the wait sits in the meetings, the backlog and the approvals.

Small errors now travel further

AI builds exactly what the brief says. It does not stop to ask what the business meant, and automated tests check the work against the same brief. A wireframe that covered most of the detail used to be enough, because experienced engineers filled the gaps as they went. Hand the same wireframe to AI and it fills the gaps with guesses, then builds those guesses at full speed.

Pilots know the problem. A plane that leaves London two degrees off course misses New York by nearly 200 kilometres. The error was small at the start; distance made it large. Speed does the same to a brief. The faster the build, the further a small error travels before anyone sees it, and the more finished work it touches.

Mid-market businesses have little room for that. A failed build lands on the same people who run the business, and it lands in the middle of the plan.

Judgement is the scarce part

Knowledge is cheap now. AI can draft requirements, map a process and suggest a design in minutes. What it cannot supply is judgement: which problem matters most, what the business will trade away, and what good looks like to the person who uses the product.

That judgement sits with the people who run the business and with people who have run delivery before. In our experience, few businesses can turn it into an AI-ready brief alone, and none should have to. The work goes better when a senior business lead and an engineer sit with the decision-makers from the first session. The engineer hears the reasons behind each choice and knows what the build will need. The business lead keeps the conversation on outcomes rather than features.

A prototype then gives everyone something real to react to before the full build starts. Once the brief is precise, the build can run in a straight line. Changes still happen. Each one goes straight into the work, with no wait for the next cycle.

Before the next build

Test the brief first, not the team. A useful brief describes the result in terms someone could check: who uses the product, what they need to do, and what changes for the business when they can. If the people who will build it cannot explain that in their own words, the build is not ready, however detailed the document.

Put your most experienced people at the start. Senior judgement used to sit at the end, in review and rescue, because that was where problems surfaced. With AI in the build, the problems start earlier and travel faster.

Then judge delivery by the time to a result people can use, not the speed of the code. A fast build of the wrong thing still costs the business the build and the correction, and the plan still waits.