A Software Leader architect put a real project plan on screen during one of our community sessions.
Roughly 800 person-days of work. A network of activities with dependencies, resources and a critical path. Beyond about three extra engineers, adding people bought nothing.
Then he ran the experiment everyone is arguing about. He made every coding and unit-testing activity 50% faster.
The delivery date moved from about 5.5 months to about 4.1.
Half the coding effort gone. A little over 20% off the schedule.
He then shaved 30% off detailed design as well. The date barely moved again.
Nobody on the call was shocked, but it was still not intuitive, even to the person who built the model. We are used to thinking of coding as the work. A schedule shows you otherwise. Coding sits between activities that do not get faster just because typing does: understanding the problem, agreeing on interfaces, integrating, testing the whole, waiting on the people who decide.
The numbers from the field point the same way. What architects hear from organisations measuring honestly is a gain of a few percent across the company, before token costs. Far from the claims of ten times faster.
A schedule model is the quickest way to make that visible.
"People always think we are coding 100% of our time."
We never were. Depending on who you ask, design and analysis were somewhere between half and most of the work. It just did not look like it, because it happened in the same hours as the typing. You thought while you wrote. The keyboard hid the thinking.
AI takes the typing away. What is left is the thinking, now exposed.
There is a thinking step you cannot skip. Someone has to decide what the system does, where its boundaries are, and what happens when two requirements collide. A model can draft options. It cannot know which trade-off your business is willing to make.
That is why the speed-up feels smaller than the demo promised. The demo shows code appearing. The project is mostly decisions.
The same session produced a small, telling moment. Non-technical colleagues, enthusiastic about prompting, asked whether they could put conditional logic in their prompts.
The answer: "It's called an if statement."
The work does not disappear. It shows up again under a new name.
There is a second reason the date does not move: the scope does.
We have seen this before. When building a website got easier, responsive design did not become optional. It became the default. Every gain in productivity was absorbed by a higher expectation of what software should do.
AI will follow the same path. Features that were too expensive last year, like a generated weekly digest or a personalised summary, will simply be expected next year.
As someone put it on the call: you would only be faster if you stay in the past with the new tools.
So the honest question is not how much faster we build the old system. It is how much more the new system is expected to do, and whether the design can carry it.
.png)
You may have seen the stories: someone built Minecraft in a day with an AI coding tool.
It is impressive. It is also a special case.
The word Minecraft carries an entire specification. Blocks, crafting, mobs, day and night, thousands of rules described across the internet and absorbed by the model. One word delivers a thousand requirements. "Build me our own Slack" works the same way.
Your business has no such word.
Your claims process, your pricing rules, your onboarding exceptions are not on the internet. Nobody has written ten thousand forum posts about them. The model has nothing to lean on except what you tell it. That is the work: making the specification explicit, because there is no shared word that does it for you.
This is also where architects see AI deliver real value. In one example from the session, a team had spent two days clicking around to confirm a bug was fixed. A single AI session traced the code and found the same logic was called from another function nobody had checked. The tool was fast because the question was precise.
If the bottleneck is thinking, AI should help where the thinking happens. That is not only in engineering.
A roadmap that is a slide deck with no text behind it slows a project far more than slow typing ever did. Encourage business people to use AI on their own work: to write the story behind the roadmap, to explore options, to sketch five interfaces and compare which one works best.
They will also build things. A marketing dashboard built in a day, reading the database straight from the browser, has no backend, no business logic and no events. Let them build more. They will reach the wall, and come asking for help. If nobody will support it, it has not really been built.
The same discipline applies to our own tooling. Prototype with the model, then harden what works into scripts. When I get tired of non-deterministic behaviour in a skill, I pin it down in code. Most of what makes an agentic tool reliable is the harness around the model, not the model.
AI is a genuine gain. It just lands in the part of the work that was never the constraint.
If you want the date to move, look at what actually sits on the critical path: unclear requirements, late decisions, integration and dependencies between teams. Those are design problems, and they respond to design.
That is the work we practise in the Software Leader Master Builder Clinic: modelling the business process and the system first, so that faster code actually turns into earlier delivery.
Halve the coding if you can. Then design for the deadline.
