A Motor Per Machine

Power stations opened in the 1880s. By 1899, electric motors still provided less than 5% of the mechanical power in American factories.

For the next twenty years, factories did the obvious thing. They took out the steam engine and put one big electric motor in its place. Same drive shafts along the ceiling, same belts down to every machine, same building designed around a single source of power.

Productivity growth in US manufacturing stayed under 1% a year.

Then, roughly between 1919 and 1929, factories started putting a motor on each machine. Once power didn’t have to travel down a shaft, the building didn’t have to be laid out around one. It could be laid out around the flow of work. Productivity grew more than 5% a year, about 65% over the decade.

Same technology. Five times the gain. The economic historian Paul David made this point in 1990, in a paper called “The Dynamo and the Computer”, about why computers weren’t showing up in the productivity numbers either.

I keep coming back to it because it’s the most accurate description I know of where most companies are with AI.

The One Big Motor

Most of what gets called AI-native today is the one big motor. A chatbot on the existing product. An agent bolted onto the implementation step of the existing process. Same discovery, same tickets, same handoffs, same org chart, with a faster engine at one point in the chain.

It helps a little. It also explains why so many companies are spending a lot and getting little back, which I wrote about in July. You don’t get the motor-per-machine gain while keeping the one-motor building.

So here’s the definition I use. It’s short on purpose:

AI does the work by default. People set the goal and the limits, and own the outcome.

And a test, which I find more useful than the definition: take the models away. An AI-enabled company loses some features. An AI-native one loses its way of working.

The Numbers

In July I said we were changing how we build, and that I’d write about it once I was confident it was working and not just interesting. This is that part: first the numbers, then what they forced us to change, which matters more.

We built a complete new platform in seven months, end to end. I built it alone until the summer, then four engineers joined. 96% of its 7,300 changes are co-authored by an agent (Claude Code, in our case).

We estimated what it would have taken without agents three different ways, mostly because I didn’t trust any one of them.

The strongest of the three counts what the system does rather than how much code it has: about 3,300 function points across 137 tables, 513 operations, 448 queries and 14 external systems. At industry productivity rates, that’s about fifteen people for two years. Our own plan from April 2025, made before we committed to building this way, said two years or more. And COCOMO II, the standard model that works from lines of code, puts 162,000 lines at about 26 people for two and a half years.

All three land in the same place: about twenty people for over two years.

The comparison I trust more is against ourselves. At the pace we built our original platform between 2014 and 2020, five engineers would have needed about ten years for this. That’s roughly 25 times our pre-AI output per engineer.

Discount it as hard as you like. Lines of code are a poor measure, and agents inflate them. The original platform was running a live business while it was being built, and this one hasn’t faced production load yet. We’re also better engineers than we were in 2014. It’s still not a 20% improvement. It’s a different order of magnitude.

That’s not a judgment on the people who built the first platform. It’s a judgment on the layout they had to work in.

Reorganizing the Factory

The number isn’t the point, and it didn’t come from typing faster. One person could not have done this with an agent bolted onto the old process.

Writing the code turned out to be the smallest part of the change. The rest of the factory had to be rearranged around it.

Most of our review effort moved from the code to the plan.

What we want to build, why, and what correct looks like get settled before an agent writes anything. Agents check every change against our architecture and our rules, the deterministic building blocks I wrote about last year, so people can spend their attention upstream.

Everything around the code moved too: how we work with the business and other stakeholders, how decisions get made, and who makes them. A team this small only works if it can take the call itself, in days, not weeks, instead of waiting for a meeting to approve it. The person who decides what to build is the person who builds it.

And we haven’t hit the limits yet. Last week Anthropic wrote about replacing Git in its own monorepo. Merges went from about 2,500 a day in May to over 30,000 in September, and the tooling built for human scale couldn’t keep up. In their words, coding is no longer the bottleneck. The infrastructure around it is.

We haven’t touched any of that. We’re still on plain Git. The 25x came from redesigning how we work, on tools built for the old way. In factory terms, we’ve rearranged the floor and kept the old machines. Most of the new ones haven’t been built yet.

That’s the part I can’t stop thinking about.

The Layout Is the Team

Here’s where I’d stretch the analogy. This part is my argument, not Paul David’s.

The factory was laid out around the cost of moving power. Software companies are laid out around the cost of implementation. That’s where our shape comes from: a specialist per layer, handoffs between them, someone to write the ticket, someone to prioritize it, someone to build it, someone to check it.

Agents removed most of that cost.

The drive shaft is still there, and in most companies it’s the org chart.

So becoming AI-native isn’t mainly about choosing tools. Every company has access to the same models. It’s about reshaping the company around the people who can work without the shaft.

Who We Build Around

AI multiplies people with high agency. One proactive builder can do what used to take a team. That’s who we want, and what we reward:

• Proactive. Move first. See the problem and act on it, without waiting to be asked.
• Builder. Ship the solution. Turn problems into working solutions, whatever the tool.
• High agency. Get it done. Own the outcome end to end, until it’s done.

We reward what gets done, not which tools did it.

That’s also why “AI replaces the team” is the wrong reading: this took five of us, not one.

A Shift of Mentality, Not of Tools

I wrote in July about how we all became cogs. This is the shift out of it:

The industrial era: told what to do	What we need now: think, build, get it done
Taught what to do, and exactly how	Think outside the box
The same process, the same way, every time	Find the problem and own it
Replaceable by design	Get it done, end to end

The left column describes a system, not the people in it. Most of us were trained in it, me included.

That system made sense when implementation was the bottleneck: you needed a lot of hands, and hands needed instructions. AI does very little for someone waiting for a ticket.

People like that will be the hardest thing to find, inside the company and out. Not because they’re rare, but because most of our industry spent twenty years training them out of people.

Some people will make the shift. It won’t be quick, and it won’t come from a training course. Years of being told what to do, and exactly how, take real effort to unlearn.

Running the Whole Thing

It would be convenient to stop at building software, while everyone else carries on as before. That’s the one big motor again, one level up.

The same reshuffle applies to how the company operates. Almost everything around the decisions themselves can be streamlined, so far fewer people spend their days on repetitive work. Agents take that work on. People oversee it, approve what needs a human, own the outcome and make the calls.

We’re further along in how we build than in how we run or in what we sell. Building is where it’s easiest to get there first, because engineers adopt tools fastest and the feedback loop is tight. Operations and product are harder, and more valuable.

What Goes Wrong

A motor on every machine also means anyone can run one, whether or not they know what they’re making. Two things go wrong with that.

Confident slop. Some people are going crazy with AI, shipping work they’re sure is their best: code, docs, decks and dashboards nobody asked for. Fluent, plausible, unchecked.

They don’t see it, because it’s Dunning–Kruger on steroids. AI makes everyone sound expert, and the most AI-fluent are the most overconfident. An Aalto University study found exactly that: people using AI scored better on reasoning tests but overestimated how well they did, and the more AI-literate they were, the worse it got.

And everyone else pays for it. Reviewers, maintainers and customers inherit work that is duplicated, harder to change and sometimes wrong. GitClear measured duplicated code blocks up 81% since 2023.

High agency without judgment is exactly how you get there.

Judgment over volume: you own what you ship, whoever typed it.

Choosing becomes the bottleneck. When anyone can build, the scarce thing is deciding what’s worth building. Making software got cheap. Owning, securing and auditing it for years did not, as I argued in July. Before building anything, decide whether it’s a throwaway answer or something you’ll own for years.

Seven months of building this way didn’t make either risk smaller. It made both more obvious, because the volume goes up and the review capacity doesn’t. That’s why our review moved to the plan.

What Comes Next

I want to be careful about what this proves.

It proves the method works on one project, with a small team working this way, on a new codebase with no customers yet. That’s the easiest case for it, and I’d be overselling if I claimed more.

It doesn’t prove the same numbers will hold everywhere. The rest of SeQura runs a live business on systems built the old way, and that’s harder: more history, more people, more at stake every time something changes.

But it’s proven enough to bet on, and we are. This is how we’re going to work across the company. Not by bolting agents onto what we have, but by doing the harder thing: changing the layout, team by team, with the people who are already here.

We’ll get parts of it wrong, and the 25x won’t show up the same way everywhere. I’d rather say that now than find out quietly later.

Taking Out the Shaft

Electricity took about forty years to show up in the productivity numbers. The motors were ready decades earlier. What took the time was rebuilding the factories around them.

I don’t think anyone gets forty years this time. But the problem looks the same. The models will keep getting better without any help from us. The layout, and the people who can run it, are the part you have to build yourself.

The hard part is taking out the shaft, and finding the people who can work without it.