This article expands on one of the themes from a recent presentation I gave at MAP TALENT. The images in this article are available as slides here.
Whenever a new technology reaches the masses, society tends to grab it and insert it into whatever is the current norm. Existing thing + new exciting thing = “This is going to change everything”. In our case, AI software delivery.
But first, let’s think about cars. The first cars weren’t designed to be cars as we now think of them. They were designed to be horse-drawn carriages, but without horses. Or, motorised carriages.
Coachbuilders, Wheelwrights, Blacksmiths/Farriers and Trimmers who had spent their lives working on horse-drawn transport suddenly faced an uncertain future. Some undoubtedly disappeared with the industry. Others became motor mechanics. Society adapted. (Out of that list, I only recognised two professions before researching this article).
The technology changed quickly, but the way of thinking did not.
The FORD Model T
The Ford Model T is one of the most important products in history. It was not the first car, but it transformed transport, manufacturing and society as a whole.
Before the Model T was the Benz Patent-Motorwagen and before that, there was a patent granted for the Horsey-Horseless (this is not a joke) which had a replica of a horse’s head placed on the front.
The Model T was the first mass-produced car and if you look at it today, even though it was a lot more forward thinking than the Horsey-Horseless, it still resembles a horse-drawn carriage more than it does a car. It wasn’t designed by asking “What should personal transport look like?”. It was designed by asking: “How do we roll out motorised carriages to the masses?” It was the right thing to do. It made motorcars accessible and gave us enormous productivity gains while allowing society to feel familiar with the new technology. People could now run businesses constrained by how far they could travel, and how quickly their car could take them there, rather than their horse.
People who previously worked with carriages pivoted to other roles and horses are still very much horsing around.
Right now, software teams are going through this same timeline, albeit at a much more accelerated rate.
The DeLorean DMC-12
By 1980, the automotive industry had matured and distinct market segments had emerged. VW and Cadillac has already defined iconic segments. Manufacturers had stopped thinking in terms of carriages. Now they were experimenting and had been for decades. Pretty much every French car was an experiment in some way (and still are). But the DeLorean DMC-12, named after its creator John Delorean, is perhaps my favourite example.
By almost every objective measure it was a poor car. It was slow and heavy. Unreliable and expensive. Poor visibility. Commercially, it failed for many reasons. Yet people still regard it as iconic and I believe this is regardless of it being in a movie. Why? Because it represented a radically different way of thinking about what a car could be.
By this point, we were no longer trying to improve the horse-drawn carriage, nor were we even trying to improve the cars that came immediately before it. John Delorean’s vision was to break away from traditional automotive conformity.
It was experimentation. Most experiments fail. And this experiment both failed and succeeded at the same time. Regardless, without experimentation, you never discover what comes next.
Then the technology became boring
After decades of experimentation, cars converged. Manufacturers started to borrow the best ideas from each other. I believe cars peaked in 2020 but I give no evidence for this. By this time, regardless of brand, most cars had become remarkably similar. Different styling and badges, but fundamentally all providing the same features.
Electric vehicles are following the same pattern
Electric vehicles could have been an opportunity to rethink everything. But all we have really done is remove the engine and insert a battery. There is no reason for electric vehicles to have long bonnets (hoods). Currently, manufacturers are in a race to see who can add the most touchscreens to the dashboard and we are not yet at the point where anyone is rethinking the electric vehicle from the ground up. Electric vehicles are still largely following the carriage-to-car pattern rather than rethinking personal transport altogether.
AI software delivery
Software development in the age of AI is going through exactly the same transition.
For decades we’ve used the Software Development Lifecycle:
- Requirements
- Design
- Development
- Testing
- Deployment
It works and has worked for a long time. When AI arrived and became accepted enough for organisations to use it, the first thing we did was add the new exciting thing (AI) to the existing thing (SDLC).
The lifecycle remains almost unchanged. We’ve simply bolted AI onto it and expected everything to change.
Productivity gains have not matched the hype.
The evidence so far paints a more nuanced picture than many expected.
We know that AI accelerates individual tasks (including workshop preparation), yet those gains don’t always translate into proportionally more software reaching customers. Recent research following more than 100,000 GitHub developers found that autonomous AI coding agents increased coding activity by up to 180%, but this translated to only a 30% increase in software releases. The authors of the research attribute this gap to downstream human bottlenecks in review, integration, testing and release.
Perhaps that shouldn’t surprise us. Making one activity faster doesn’t automatically make the entire system faster.
And as team members, if we can now do our tasks faster, are we all going to volunteer for more work?
Or, are we going to be happy that we can expend less effort and get paid the same money?
The only obvious way around this would be to monitor and micro-manage employees and this would slow down teams for other reasons.
The DeLorean phase of AI software delivery
Recently, other ideas have started appearing in organisations. Such as Specification-Driven Development (Spec-Driven Development, or SDD).
Spec-Driven Development takes the essence of vibe coding, which is inherently risky, and adds structure and guardrails to it.
Teams can use artefacts like “Constitutions” and “Memory files” to ensure that AI agents follow guidelines and immutable rules. This enables organisations to use AI in delivery with a lower likelihood of unpredictable behaviour, such as when this AI agent deleted a Production database.
The strictness of these guidelines informs the level of human intervention required in development.
Once the above guardrails have been established, the process now follows an iterative loop. This replaces the SDLC:
- Specify: Detail the business intent, user journeys, non-goals, and constraints.
- Clarify: Refine the spec, surfacing gaps or contradictory logic. AI agents or humans can review the spec for contradictions before coding begins.
- Plan: The AI Coordinator breaks the requirements down into implementation-ready tasks.
- Implement: Sub-agents execute the plan while strict architectural and design guardrails remain in place.
- Validate: Verification agents continuously test the generated code against the specification to ensure it meets original intent.
In Spec-Driven Development, instead of developers writing every line of code, humans spend more time describing behaviour, constraints, business rules and expected outcomes. AI (groups of AI agents operating according to the guardrails) execute the specification.
Early evidence suggests this approach can deliver greater productivity gains than simply using AI in the traditional SDLC.
Spec-Driven Development is our DeLorean. It is valuable because it demonstrates that people have already stopped asking: “How do we add AI to the SDLC?” and started asking: “If AI exists, should software delivery still look like the SDLC at all?”
What comes after the DeLorean?
I don’t believe Spec-Driven Development is the end of AI software delivery. Just as the DeLorean wasn’t the final evolution of the automobile.
It is an experiment. And it has come about a lot quicker that we expected. Some of its ideas will survive and others won’t. We are not sure what any of this means for traditional roles. Regardless of how delivery evolves, organisations will still need to understand what stakeholders actually want. As long as stakeholders exist, someone (or something) will need to synthesise their requirements into clear specifications.