The Electrification of Factories: What Software Teams Can Learn From the Transition
Factory electrification reshaped production only after owners redesigned the floor. AI software teams need the same shift in workflow, review, and verification.
Evan MarshallCTO
In June, Anthropic bragged that Spotify is shipping over 4,500 PRs per day thanks to Claude. Yet, 5.5 million views and countless comments roasting them later, the case study became an example of industry-wide frustration rather than success.
Teams are producing more code with AI, but the gains in shipped product quality and organizational throughput are much harder to see.
That bears out in anecdata, such as the comments from frustrated Spotify users and in research: Linear found that Silicon Valley product teams, its primary customer base, see a 111% increase in opened PRs and triple their weekly PRs if they connect a coding agent. And yet, who can say their product is three times better than it once was? Who's even used a product that's three times as good as it was before AI?
This long road from new technology to real gains isn't new. We've heard “AI is the new electricity,” but what we're not seeing yet is electrification. Electricity, like AI, seems like a clear technological step change. But at the turn of the 19th century, electrification took decades to reach widespread adoption and truly significant gains in output.
We should expect to see the same pattern with AI, so we set out to learn from the history of electrification and why factory owners had such a hard time turning this new technology into power and profit. The truth: The missing ingredient wasn't a new technology. It was a different factory floor.
The long road to electrification
Electricity. It's hard to imagine a time without it. And yet, when electricity emerged, people didn't get a lightbulb-above-their-heads epiphany and start integrating it into everything. Even factory owners didn't immediately see the benefits of what seems so obvious to us now.
Looking back, we see factory owners making limited improvements, hitting constraints, and iterating until they finally experienced breakthroughs. Those breakthroughs were never electricity itself, but the factory design and workflows that channeled electricity in new ways.
For this history, we rely primarily on Warren D. Devine, Jr., an engineer the United States government tasked with researching the rise of electrification. His analysis identifies five primary stages, moving from steam and water power to true electrification. Stage 1: Steam and water power through a central line shaft
“By 1929, just 45 years after their first use in a factory, electric motors accounted for over three-quarters of total power capacity used to drive machinery,” Devine writes.
That's a steep rise. But it took almost half a century.
What happened? Or, more accurately, what didn't happen?
Before electrification, factory production machines were connected directly to the power sources that drove them. Not by wires, of course, but by pulleys and leather belts that were suspended from the ceiling and ran all the way to a central water wheel or steam engine. It's as chaotic as you can imagine:
Devine writes, “The entire network of line shafts and countershafts rotated continuously, from the time the steam engine was started up in the morning until it was shut down at night, no matter how many machines were actually being used.” If any part of this system broke, the entire production had to be d until repairs were made.
At this point, a failure in the central system could stop the entire floor, and the factory layout followed the machinery rather than the most efficient flow of materials or workers. The old production system was an interconnected constraint, not a power source factory owners could just swap out. That shaped how factory owners thought about electricity once they had access to it.
Stage 2: An electric motor replaces the central steam engine
The first way people think to use a new technology is to use it like the things they already use. That applies to asking AI to write your code the way you do, and to replacing a steam engine with an electric motor spinning the same rotors. Humans are, by nature, skeptical of new technologies and new systems. No one wants to (nor often can afford to) change too much at once. As Devine writes regarding electrification, we see “the usual juxtaposition of a new technology upon the framework of an old one.”
In the 1890s, for example, clothing and textile manufacturers took to electricity relatively quickly. But those factories used a single large electric motor to turn the same shafts and belts. Power became electric, but the factory still had the same layout, downtime dependencies, and mechanical losses.
Factory owners hadn't yet thought about the new and novel ways to use electricity. That meant that electrification didn't immediately lead to much in the way of useful gains and impact.
This is a close equivalent to giving every developer an AI coding assistant while preserving every downstream process. We shouldn't be surprised, in either case, that the gains weren't significant. A new technology layered on an old workflow provides an incremental benefit, not a new operating model.
Stage 3: The group drive shifts factory layouts
In the early 1900s, factory owners finally started designing factories around electric power distribution, treating electrification as a first principle rather than a bolted-on improvement. Electrification led to smaller machines, so they could cluster inter-related machines together on the same group drive, reducing reliance on one central drive and giving operators more control. Unlike in the steam engine era, tools were starting to drive workflows rather than workflows being limited by power constraints.
With electricity, factory owners could consolidate operations and increase specialization, and these changes (enabled but not caused by electricity) started to trigger factory-level transformation. “Electrification of mechanical drive and factory reorganization went hand-in-hand,” writes Devine.
We again find a parallel between electrification and AI: Breaking one monolithic workflow into smaller units is progress, but it retains some inherited constraints. Still, this stage proved to be a critical intermediate step to unit drives, where things really take off.
Stage 4: Unit drives increased workflow flexibility
Factory owners only started to realize electrification's full potential when they started redesigning how workers used power within their factories. With the electric unit drive, factory workers no longer needed to rely on a central machine. Instead:
Each machine got its own motor.
Operators could turn machines on and off, reposition them, and control them independently.
Operators no longer needed to rely on a centralized engine or the shafts, belts, and structural supports once required to transmit power.
If one machine needed worked on, upgraded, or changed out, no other machine would be impacted. What now seems so obvious to do became inevitable only when factory owners realized electricity brought flexibility, not just cost savings. “Because of this flexibility,” Devine writes, “Manufacturers could turn their attention away from problems of power production and distribution and toward improving the overall efficiency of their operations.”
Stage 5: The factory is redesigned around new capabilities
Once machines no longer need to cluster around shafts or connect to central engines, factories could use lighter building materials, single-story and linear layouts, more efficient materials handling, and flexible machine placement.
It was only with the electric unit drive, Devine writes, that “processes could be arranged within factories to maximize throughput; plants could be more readily expanded; and a better working environment and improved machine control increased both quantity and quality of output.”
In other words, the full economic benefit of electrification followed from factory reorganization, not from lower power bills.
For example, the images below show two different hat factories, giving you a sense of how much the layout and working environment could change after the introduction of electric motors. Tim Harford, an economic journalist, explains, “You couldn't get these results simply by ripping out the steam engine and replacing it with an electric motor. You needed to change everything: the architecture and the production process.”
What does this mean for software factories?
The takeaway for companies looking to benefit from AI is that it's not as simple (and has never been as simple) as swapping in a new technology. Gains will be uneven, unpredictable, and even disappointing until you redesign and rebuild your processes.
A conventional SDLC with AI coding agents integrated is essentially a factory at the electric line-shaft stage. Teams that add agents to isolated steps, such as drafting tests or triaging tickets, are experimenting with group drive-level work.
The next step is getting to the AI equivalent of unit drive. What work can run independently with clear goals, safe environments, and reliable verification? Answering that question will require a redesigned software factory that changes the flow of work, the role of review, and the conditions for human intervention.
Turning from the distant past to the near future, we can see emerging patterns as companies experiment with redesigning their factory floors. These are the kinds of ideas you can take back to your team to start experiencing some of the real gains from the use of AI.
Example 1: Change where work begins
Traditionally, a customer reports an issue, the complaint populates in a Slack channel, and a human writes a ticket based on the message, eventually leading to a developer's task and a developer's PR.
If we rearrange how work flows and change where work begins, an agent could turn a Slack conversation into a draft issue, investigate the relevant code paths, propose a plan, and prepare a PR in an isolated environment. Then a human developer could decide whether the task matters and review only the work output that requires judgment. Linear did a similar redesign when it built self-driving bug management. Now, a Linear Agent creates a new issue, automatically adds context, and tasks a Cursor Agent to draft a fix.
It would be nice if simply having AI write the code was a major gain for teams. It is a new way of working, but that alone does not product significant gains. Instead, the biggest gains come from removing administrative steps, finding places where AI can work independently across multiple stages of work, and only involving developers where and when they need to be.
While some companies may do this inefficiently through endless meetings, for many teams these improvements are measured in only minutes gained. Example 2: Make verification a continuous, independent loop
Many companies have embraced AI, but now face verification bottlenecks. An agent writes a PR and a human reviews it, but the work gets stuck in a queue that seems to constantly get longer. And if you simply skip your engineers reviewing it, or they get tired and a bit sloppy, problems are found later in production at the expense of your customers' experience.
But if we rearrange things, the bottleneck resolves. An agent writes a change, starts a production-like environment, runs targeted behavioral checks, fixes failures, and repeats until it has evidence that the change works. Human review comes only after, and the review focuses on product judgment, architecture choices, risk, and exceptions rather than mechanically checking every routine PR for basic issues.
Addy Osmani, for example, uses AI to generate more code but then makes human review more selective. “Agents do the first pass,” he writes, “and humans cover the blast radius.”
More generation requires more independent verification. Maintaining the same level of verification just leads to a bottleneck that prevents experiencing the speed gains teams (and AI-frenzied executives) are seeking.
Example 3: Run cheap experiments that were previously not worth a developer's time
It wasn't that long ago that we were all used to development resources being scarce, and experimentation was necessarily limited. Product improvements often had to be small, and they actively competed with core roadmap work.
When we treat AI as a first principle and redesign the factory floor around it, experimentation becomes cheap. Teams can give agents bounded, reversible experiments to run overnight. Humans can assess the evidence and keep only the strongest results.
For example, developers at Gamma, an AI design platform, will have an idea in the morning, a prototype to test by the afternoon, and an idea worth building or killing by the end of the day. Lower marginal cost changes the kinds of work that are rational to attempt, just as distributed electric motors changed which factory layouts were rational.
Just remember: with this change comes responsibility to clean up after yourself. All that experimentation can lead to a better product, if you remember to remove the things you added that don't work.
That didn't use to be much of a problem, because you simply couldn't run that many experiments. Now, with this new process, it becomes essential, or you'll very quickly have a bloated mess of a product.
Example 4: Separate work by risk, rather than treating every PR identically
Typically, most, if not all, work passes through the same basic review process, whether that's a documentation correction, or a change to a core authentication system. That can mean slowing down the former and missing checks on the latter.
But if we redesign and separate work by risk, we can maintain different throughput levels. Low-risk, well-instrumented changes progress through automated implementation and verification. No need for a human. Ship it as fast as AI can write it and run basic checks.
Meanwhile, high-risk changes trigger stronger controls, deeper review, and explicit human approval.
We can speed up on one end and de-risk on the other.
Augment Code, an AI coding platform, lays out a workflow that emphasizes risk-gated handoff between humans and agents. Every PR gets classified before work begins, and the loop learns across every step.
This approach helped their team triple their code output, and dropped merge times by two-thirds.
Similarly, Duckbill, a cost management services provider, found itself with a painful backlog of over sixty open PRs for a team of five. To resolve it, they implemented a risk-based system (along with stronger guardrails) to let agents do the code review for them.
This work led to a 94% increase in PRs merged per week, and a 17% increase in PRs merged within one hour.
As you build your software factory, you need to create different lanes for different risk levels, not blanket autonomy. Just as electrification let workers use new, more flexible electric tooling where it was beneficial, development teams can rely on AI more for some tasks and use more human judgment for others.
Example 5: Change the plant from “smarter operators” to a harness
Today, many teams try to deliver more output by giving individual developers better models and better prompts. When model gains were more often seismic, this often made sense, but model progress is plateauing. Now, it's more practical to build a harness than to wait for the next 3-4 point gain in the IQ of your model of choice.
If we restructure things, you can treat the agent like a machine on your factory floor. You can write agent skills, add sensors (such as tests, linters, and evals), bound retries, set permissions and escalation paths, and keep memory outside the model. The model becomes the motor, and the harness becomes the wiring and your interface. Lamis Mukta, a member of Anthropic's technical staff, laid this out in a talk, where she explained how to build a graph that runs itself.
If a loop is one agent doing one job continuously, a graph is a team of agents, orchestrated by something like OpenAI's Codex or Claude's dynamic workflows, that splits the work, runs tasks in parallel, and checks the results as they go. Remember, after electrification was first introduced, the real step change came after rearranging the factory floor to take advantage of newly cheap, controllable power. Similarly, after coding agents, the step change won't result from a better prompt or a slightly smarter model. It will result from the graph, the loops, the permissions, and the evals you place around the model.
Iteration is the only way to see the future
No one wants to be the Paul Krugman of AI. Back in 1998, he predicted the Internet would have little impact on the economy, and he's been an example of the famously wrong ever since.
The good news is that hardly anyone in the software world faces this fate. The bad news is that merely refusing to be a luddite, to experiment with AI instead of avoiding it, isn't enough.
The history of electrification is full of factory owners who tried electric motors but got stuck in the second stage; replacing steam and water power with electric motors that turned the same central shafts didn't make enough of a difference on its own.
Many teams and vibe coders are experimenting, and they're showing us glimpses of what the future will be for everyone. Some are heading down dead ends, and others are sketching the blueprints that will one day be used to design new factories.
These structural changes are coming sooner than you might expect. The tools will keep getting cheaper, more available, and more capable.
The companies that benefit most will be the ones that use this period to redesign how work moves through your factory. An iterative approach lets you try more ideas and see what works and what doesn't as we all navigate the idea maze of AI software development.
Electricity required iteration, too, but AI is advancing faster. Don't get left behind with a more efficient steam engine.
Frequently asked questions
A coding agent speeds up code production. Your company still ships at the pace of its slowest necessary step. That typically happens during review, verification, CI, product decisions, or release management. More generated pull requests can make that constraint worse by adding work to a later step in your software development lifecycle. The throughput gain arrives when you redesign the flow around the new volume: smaller bounded tasks, independent evidence loops, limits on work waiting for review, and clear human gates for decisions that need judgment.
Humans should review changes with a large blast radius: work that touches critical workflows, changes core architecture, affects security or customer data, or could impact key customers. Small, low-risk, reversible changes with clear verification evidence from AI tools can move through an automated lane without the need for human review. This helps prevent a review bottleneck from building up, because it saves your engineers from reviewing things that were easy to verify without them.
Let an agent ship without human approval when the change has a low blast radius, is easy to reverse, and has verification evidence that shows an AI checked the work and approved it. A copy correction or a small, well-covered UI change (like a button name or color change) can move fast. Changes to authentication, billing, data, critical workflows, or a key customer's experience need a human reviewer, even when every test passes. Set those risk lanes before agents start work so they do not decide for themselves when a change is safe to ship. Don't make your customers become your QA team. A better model can write stronger code, but it still needs a workflow that tells it what it can and cannot do, how to prove the result, and when to stop. Without that structure, agents lose context, retry the wrong thing, build beyond the scope you wanted them to work in, and hand you a result that is hard to trust. Give agents clear goals, bounded permissions, isolated environments, and checks that produce evidence you can review. That structure is what makes their work reliable enough to run at scale and goes well beyond the prompts you wrote or the model you choose to use for a task.
Share:
Found this post helpful? Share it:
Enjoyed this? Subscribe.
Never miss a post on the latest in AI-driven software development, code review, new models, and more.
Connect your repo and Ito starts testing pull requests right away. Each PR includes a full QA report with video, screenshots, and failure details directly in the PR.