We Bolted the Motor Where the Engine Was

In 1899, eighteen years after the first commercial power station opened, electricity drove less than five percent of the mechanical power in American factories.¹

Not because it did not work. It worked. Factory owners bought the motors, installed them, and waited for the productivity everyone had promised them.

It did not come. It did not come for another twenty years.

I think about those twenty years constantly.

The borrowed words

Engineers have started calling each other doomers and accelerationists. Both words are on loan.

They come from the argument about whether artificial intelligence ends the human species. Effective accelerationism was revived in 2022 by Guillaume Verdon, who writes as Beff Jezos and puts the odds of an AGI catastrophe at zero or near zero.² The doomers he is arguing with think the odds are considerably worse. It is a real argument, conducted by serious people, and it has almost nothing to do with whether your job exists next year.

The two questions are not even correlated. Someone can believe the models are on track to kill everyone and still expect to be employed until it happens. Someone can dismiss extinction risk entirely and tell you, cheerfully and without malice, that your craft is finished.

So when an engineer says he has become a doomer about his career, he has borrowed a frame that cannot hold what he is feeling. It flattens a question about work into a question about survival, and it hands him two teams to join. What he needs is a better question.

Here is the better question. Not whether the models are good. Where the craft went.

The bottom rung

The crisis is real. It is also documented, and worth looking at squarely before anyone theorises about it.

Stack Overflow surveyed developers in 2025.³ Eighty-four percent use AI tools or plan to. In the same survey, trust in what those tools produce fell to twenty-nine percent, down eleven points in a year. Forty-six percent actively distrust the accuracy of what they are given. The most common complaint, from forty-five percent of them, is code that is almost right but not quite, and two thirds report spending more time fixing almost-right code than they used to spend writing it.

The most experienced engineers are the most sceptical of all. Two and a half percent say they highly trust the output. Twenty percent highly distrust it. The people best equipped to judge the work are the least willing to sign their name to it.

Here is the objection, and it is the one I would raise first. That survey is from 2025, and the engineers answering it were judging Claude 3.5 and 3.7 Sonnet in a chat window. Since then we have had GPT-5.6 Sol, which OpenAI calls its best coding model yet,⁴ alongside Opus 5 and Fable 5. Quoting 2025 trust numbers at 2026 models is quoting a different technology, and I will not pretend otherwise. What I want to argue with is the inference: better models, therefore a better outcome. I take that up two sections from here.

Then there is the part nobody enjoys. Stanford’s Digital Economy Lab went through ADP payroll records covering millions of workers, up to July 2025.⁵ Employment for software developers aged twenty-two to twenty-five is down close to twenty percent from its peak in late 2022. For more experienced workers in the same occupations, employment held steady or kept growing.

That is not a profession shrinking. That is a profession closing its bottom rung.

Deedy Das at Menlo Ventures describes engineers in an identity crisis bordering on depression, and a class divide opening between people who prompt and people who build.⁶ Anyone reading the same forums has watched it happen.

I want to be careful here, because I am writing from the side of that data that grew. Nothing I say next is advice to anyone twenty-three years old sending applications into a market that stopped answering.

The dynamo

Electricity is the comparison everyone reaches for. Andrew Ng put it in a sentence in 2017 and it has been repeated to death since: AI is the new electricity.⁷ It is true, and it has stopped being useful, because the part people repeat is the part that teaches nothing.

The useful part is the delay.

The economist Paul David worked out why it happened, in a 1990 paper about the computer age that is really about the dynamo.¹ The technology was not the bottleneck. The building was.

A steam-powered factory was organised around its engine. One enormous engine turned a system of overhead shafts, and every machine hung off those shafts by a leather belt. Where a machine sat had nothing to do with the work and everything to do with reaching the shaft. Factories were tall for the same reason, stacking floors around a single source of power.

When electricity arrived, owners did the obvious thing. They bought a large electric motor, removed the steam engine, put the motor in its place, and connected it to the same shafts. Same building. Same layout. Same belts. New power source.

It barely helped. It could not. They had bought a technology whose entire advantage was that power no longer had to come from one place, then used it in a building designed around power coming from one place.

The gain required a rebuild. Put a small motor on each machine, none of them a match for the engine they replaced, and the shafts become unnecessary. Once the shafts are gone, machines can sit wherever the work flows best. Once machines sit where the work flows, the building can be one wide storey instead of five narrow ones. That was called unit drive. It took a generation, and mostly it took new factories rather than converted ones, because the people who owned the old ones could not see past the floor plan they had.

The drop-in motor

Sixteen experienced developers. Two hundred and forty-six real tasks in repositories they had worked in for years, each assigned at random to allow or forbid AI tooling. This was METR, in 2025.⁸

They were nineteen percent slower with the tools.

They believed they had been twenty percent faster. Economists and machine learning researchers, asked to predict the result in advance, had guessed a thirty-eight to thirty-nine percent speedup.

That study gets waved around by everyone who wants this to be a bubble. I think it is the most important result we have, and I think it says the opposite of what they think it says.

Look at what was tested. Early 2025 tooling, in a chat window, beside an editor. A developer types, a model suggests, the developer reads, accepts, corrects, moves on. The model is the new power source. The workflow is the old line shaft. Every suggestion still travels down the same belt: through one person’s attention, one line at a time, at the speed that person reads.

That is the large motor bolted where the steam engine was. Of course it did not help.

Now the objection from two sections back comes due. Sol and Opus 5 would not leave those sixteen developers nineteen percent slower, and METR themselves changed the experiment design in early 2026.⁸

Grant all of it. A better motor is still a motor bolted where the engine was. It turns the same shafts and drives the same belts, and every suggestion still arrives at one reader, one line at a time. Improve the model and you improve what travels down the belt. You do not widen the belt.

That is the whole claim. The ceiling in that experiment was never model quality. It was the shape of the work.

The perception gap is the part I cannot get out of my head. Those developers were not slightly wrong. They were wrong by thirty-nine points, in the flattering direction, about their own working day. The finding is about self-report, not about those sixteen people. It applies to mine. That is why this essay puts no figure on what any of it did for me.

Unit drive

The distinction between prompting an agent and engineering around one is already drawn. Simon Willison, Kent Beck, Armin Ronacher and DHH have all drawn it. Beck calls agents genies that grant your wish with side effects you did not ask for.⁹ There is a vocabulary for it now, and it arrived in layers.¹⁰ Context engineering, for what goes into the window. Harness engineering, for the boundaries around it, which Mitchell Hashimoto put in one sentence: when an agent makes a mistake, you engineer a solution so it never makes that mistake again. Loop engineering, for the system that dispatches work and verifies what comes back. And lately graph engineering, for wiring many loops into a network where they constrain each other rather than each drifting off alone. That last one is a few months old and still argued over.¹¹

Four names for four layers, none of which existed as a discipline two years ago. That is the tell. This is not a settled practice with best practices to copy. It is a field being built while people work in it.

I have been building in it, and not alone. Engineers at Anthropic and OpenAI have said publicly that essentially all of their code is model-written now.¹² Microsoft and Google put their own figure nearer thirty percent.

Here is what I am experimenting with, and what has survived contact so far.

Isolation over locks. Every piece of work gets its own git worktree: its own checkout, its own stack, its own everything. When two of them collide my instinct is to add a lock, and that instinct is almost always wrong. A mutex is a confession that something is still shared. Unit drive was not a rota for the line shaft. It was getting rid of the shaft.

A gate decides, not me. One command, one exit code, nothing reaches the main branch without a pass. Not ceremony. It is the only reason an agent can merge while I am asleep, and removing it caps the whole system at the speed I can read diffs.

Verification has to reach the real interface. A headless suite exercises logic beautifully and tells you almost nothing about what a particular role can see and do on a real screen. That gap is where compliance failures and embarrassing bugs both live.

Silence is a failure. A gate that says nothing where it has no rule is worse than no gate, because you read the green tick as a verdict when it was only ever an absence. Fail loudly where your own coverage ends.

The loop runs unattended, but never feeds itself. Work gets dispatched, run, gated, merged and closed without me. What it may never do is decide for itself what to work on next. A human puts work into the queue, always.

Every one of those came from something breaking, and I expect half of them to be replaced by something better within the year.

Notice what none of them is about. The model.

Put a mid-tier model in a harness that gates its work and tells it exactly how it failed. Let it try again. It will finish work that a frontier model in a chat window will not. Not because it is smarter. Being wrong costs it a retry, where being wrong in a chat window costs me an afternoon. Most of what looks like capability is really the price of a mistake.

Not one of those small motors could have driven a factory on its own. That was never what they were for.

The factories of the 1920s were not laid out by people who knew what a factory should look like. They were laid out by people who had electricity and a building that had stopped making sense, and who got it wrong for twenty years first. That is roughly where we are. I am not describing the new floor plan to you. I am one of the people in the building trying to work out what it is.

Not thirty percent faster

It is not thirty percent faster. That framing belongs to the old floor plan, where the only question is how quickly one person moves through one queue.

Several isolated environments working while I am asleep is not a percentage improvement on a person typing. It is a different mode of production, and it is worth being precise about what changed: not my typing speed, but how much work can be in flight at once and how much of it proceeds without me.

The constraint moved with it. I am no longer limited by how fast I write code. I am limited by how precisely I can specify work and how well I can verify what comes back. That is a different skill, and I was trained for it by accident, over the same twenty years the factories took.

Which brings me to the part I cannot resolve.

The ladder

There is one objection I cannot answer, so I will state it plainly.

I can build these systems because I spent those twenty years building the other kind. I know what correct looks like. I know which failure is interesting and which is noise. I know when a generated answer is subtly wrong, and I know it fast, because I have written that bug myself and paid for it. Every harness I build rests on judgement I acquired by hand, slowly, in jobs that no longer exist in the same form.

Junior employment is down twenty percent.⁵ The rung I climbed is being sawn off while I stand above it explaining that the climb was the valuable part.

I do not have a resolution. Apprenticeship in this profession was always mostly accidental, a side effect of work that had to be done by someone and might as well be done by the cheapest person available. AI removed the work without removing the need for what the work taught. Nobody has replaced it, and I have not seen a convincing proposal.

If my argument is right, this is the part that should worry you most.

Where the craft went

The old way is dead.

Writing production software by hand, line after line, as the primary way value gets made, is finished. Not because it is not enjoyable. Because a system with an agent, a test suite, and a person who knows what correct looks like will beat it, and the gap widens every time I look at it.

But craftsmanship is not dead. Craft moved. It went from the typing to the thing that governs the typing. From the line to the harness. From what you produce to what you refuse to accept.

Which is exactly what happened in those factories. Nobody argues that engineering died when the line shafts came down.

The engineers I know in real distress are not the ones who lost an argument about how good the models are. Most of them think the models are extraordinary. They are the ones whose craft stayed in their hands while the work moved somewhere else, and who have not yet gone to find where it went.

It went into the floor plan. It is still craft. It is still hard. Almost nobody is good at it yet.

References

Paul A. David, The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox, American Economic Review 80, no. 2 (1990), pages 355 to 361. ↩ ↩
What’s the deal with Effective Accelerationism (e/acc)?, LessWrong. ↩
2025 Developer Survey: AI, Stack Overflow, 2025. ↩
GPT-5.6: Frontier intelligence that scales with your ambition, OpenAI. Sol is the top model of the family, announced 26 June 2026 and generally available from 9 July 2026. ↩
Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab, 2025. The paper’s headline figure is a sixteen percent relative decline for ages twenty-two to twenty-five, across the most AI-exposed occupations. The near-twenty percent figure is for software developers specifically, measured from their late-2022 peak. Updated continuously on the Canaries dashboard. ↩ ↩
Software Engineers Are Facing an Existential Crisis As They Drown In Horrendous AI Code, Futurism. ↩
AI is the New Electricity: Insights from Dr. Andrew Ng, UC Berkeley Sutardja Center, 2017. ↩
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, July 2025. See also their February 2026 note on changing the experiment design. ↩ ↩
TDD, AI agents and coding with Kent Beck, The Pragmatic Engineer. ↩
Loop, Harness, Context Engineering: The Terms Explained, codecentric. Harness engineering is Mitchell Hashimoto’s framing; Addy Osmani coined loop engineering on 7 June 2026. ↩
Graph Engineering: Wire Multi-Agent Orgs After Loops, explainx. Published 18 July 2026, and the framing is still contested rather than settled. ↩
Anthropic, OpenAI Engineers Say AI Now Writes 100% of Their Code, eWeek. These are individual engineers describing their own work, not audited company figures. The Microsoft and Google numbers come from Satya Nadella (April 2025) and Sundar Pichai, both around twenty to thirty percent of new code. ↩