An excavator in the canal age
In early 2026 I worked through a thought experiment that changed how I use AI.
Picture England in the canal age, in the second half of the 1700s. Every mile of canal was dug by hand, and each labourer was expected to shift something like 20 tons of earth a day with a shovel and a barrow.

Now drop a modern excavator into that world. What happens?
The first thing that happens is that someone starts counting tons. One machine can move in an hour what a team of men can move in a week, so the obvious move is to keep the machine, let the labourers go, and carry on digging canals quicker than ever.
The obvious move, and why it loses
That's the move most organisations are making with AI right now. They take the work they have always done, point the new tool at it, and count how many people they no longer need. It's the same canal, dug with fewer hands.
It isn't wrong, exactly; it is just small. Look at what actually happened once excavators existed: we stopped building canals. Instead, we started building roads, railways, airports and whole cities. Excavators didn't put an end to people building; they lifted what people could deliver to a whole new level. And what did people do with these powerful new tools? They built far more complex and demanding things than any amount of hand labour could ever have produced.


So the winner isn't the business that fires its people and keeps digging the same canal. The real winner is the business that empowers its people with the new tools to re-evaluate existing problems and deliver solutions nobody else is even considering yet.
My canal
I didn't see this straight away. Two years ago, I was among the first people on a large government account to bring AI agents into live production, and what I built there was a very good canal.
I would establish a pattern, build guardrails around it and make sure it was solid engineering that worked. Then I fed the agent the levers I wanted it to work through, within the confines of that pattern. Constrained by the guardrails, I could get the agent to add polish and refinement at almost no cost, something that was never economic when we coded by hand, and feed those refinements back into future work, refining and improving as I progressed. The guardrails narrowed the agent's options so sharply that quality went up instead of down. I had given it a pit of success, and productivity rose by around 40%.
The result was speed and quality that hadn't been possible within the cost constraints before. It was a genuine step forward. It was also still a canal: the same kind of work, done faster and better. But an idea had taken root in my mind.
The shift was in my head
The change, when it came, wasn't a new model or a new tool. It was a change in mindset.
I realised I could build more for less, at a higher quality, with complete documentation and test coverage, with consistency across everything, and with features that would be too expensive, too complicated and too time-consuming for a normal project. Better still, I could add those features with minimal impact on delivery and a huge impact on the customer.
Once you see that, the question changes. You stop asking how to deliver this project with fewer people. You start asking what you could deliver that was deemed impossible before. And from there, you start seeing hundreds of business problems in a whole new light.
My first motorway
I decided to test my theory, and to combine it with an opportunity to significantly grow my personal capabilities and build a commercial product of my own, all in one project. Working as a one-person delivery team, I built an agentic form-building service for UK councils: a citizen form runner, an officer portal, a form designer, and a pipeline that turns a council's existing PDF form into a working digital one.
The easy way to describe that is a team's work done by one person, but that's still counting tons. The real point is that even a large team would never have built it. It isn't the effort. It's the cost of the effort against the reward it brings. A service like this is too high-risk, and the customer polish it needs is too expensive, so a normal project cuts it back, ships something plainer, and never gives it the refinement and customer focus that create its real business value.
But when the cost of that refinement collapses, the sum changes. Polish and usability focus that no typical business case would ever fund become affordable, and the risk shrinks to something one person can carry. And the core engine, the part that reads a paper form and produces a working one, couldn't exist at all without a language model constrained by the right harness. That isn't a canal dug faster. It's a whole new method of transport.
The way it works matters as much as what it is. People do more of what they excel at, and the AI does what it excels at. Together that's a relationship neither achieves on its own. This isn't about better search or a chat window bolted onto a product. It's about using AI to lift people into new ways of working with information.
Who it lifts
In the world this service points towards, we can change the work of stakeholders for the better:
- Council officers spend less time on mundane, repetitive toil like re-keying paper forms, and can instead focus on decisions only they can make.
- Engineers spend less time typing code and more time shaping the work, making the refinements that add real value to the end users.
- Delivery leaders plan around a new cost of building, not the old one, opening up markets where the old cost never made the value add up.
- The customers paying for the outcome stop carrying the value risk. Today they commit to the cost and hope for the delivery. When building costs this much less, it becomes realistic to pay on delivery instead, and value moves to the front of the relationship.
The economics have changed
That last point is where this stops being an interesting idea and becomes a risk.
The economics of solving problems have changed. Some organisations have built their whole business on the way problems used to be solved. They sell canal boats. At some point, someone somewhere will look at the same problems from a different angle, find a way to solve them that delivers far better value to the customer, and undermine the incumbents' business model.
The answer is to re-evaluate your problems from another perspective before someone else does. Not "how do we do this with fewer people?" but "now that the cost of building has collapsed, what would we build if we were starting today?"
Seeing the motorway
The hard part isn't the technology. The hard part is being the first to see what a motorway is, or an airport, when all you have ever known is canals.
Nobody standing on a canal bank in 1770 was asking for an airport. They didn't have the concept. The same is true now: the most valuable things AI will make possible are mostly things we don't have names for yet. You find them by keeping the people who understand your problems best, giving them the new tools, and asking them to look again.
I stopped building canals. The rest of this series is about what I've been building instead, and how. The next article, The horse that couldn't count, starts with the how: how I became a software producer, and the working methods that keep a team of AI agents building the right thing.