The Industrial Revolution of Software Is Here

The Industrial Revolution changed much more than how goods were manufactured. It transformed how people worked, how businesses operated, how cities grew, and how economies created value.

I believe software engineering is approaching a similar transformation.

We are moving from a world where engineers primarily produce software themselves to one where engineers increasingly build and operate systems that produce software for them.

Coding agents are the catalyst, but the real transformation is much bigger than AI writing code. It is about changing the entire system through which software is designed, built, tested, and delivered.

To understand where we might be heading, it helps to look back at the original Industrial Revolution.

What changed during the Industrial Revolution?

Beginning in Britain in the second half of the eighteenth century, the Industrial Revolution transformed an economy dominated by agriculture, hand production, and small workshops into one increasingly organised around machinery, factories, and large-scale manufacturing.

Several fundamental changes drove this transformation.

1. Hand tools became machines.

Skilled craftspeople had traditionally produced goods by hand. New machinery allowed the same kinds of work to be performed faster and at a much greater scale.

2. Small workshops became factories.

Production moved from homes and small workshops into factories where machinery, workers, materials, and processes could be coordinated in one place. The factory became a new unit of production.

3. Human and animal power gave way to new sources of energy.

Steam engines, powered largely by coal, enabled machinery to operate at scales and in locations that had previously been impractical. Later, electricity transformed factories further.

4. Transport networks connected production at scale.

Canals, railways, and steamships made it possible to move raw materials and finished goods more efficiently. Factories could serve markets far beyond their immediate surroundings.

5. Standardisation enabled mass production.

Repeatable processes and increasingly standardised components made production more consistent and scalable. Manufacturing became less dependent on every individual craftsperson completing every step from beginning to end.

6. The organisation of work and the economy changed.

Factories created new roles, management structures, and patterns of employment. Human labour did not disappear, but its nature changed. People increasingly operated, maintained, managed, and improved systems of production.

The important point is that the Industrial Revolution was not simply a story about machines replacing manual labour.

It was a transformation of the entire production system.

And that is where I see a parallel with software engineering today.

The software industry's industrial revolution

Let's map these changes to software engineering.

1. Hand tools → Machines → Coding agents

In traditional software development, engineers are directly responsible for much of the implementation work. They translate requirements into code, write tests, debug failures, and make changes across a codebase.

Tools have always helped. Compilers, IDEs, libraries, frameworks, and CI/CD systems have made engineers more productive. But the engineer has generally remained the primary executor of the work.

Coding agents change that relationship.

An engineer can now delegate implementation, testing, debugging, code exploration, and other tasks to agents. Instead of manually performing every step, the engineer increasingly specifies the desired outcome, provides context, delegates work, and evaluates the results.

The shift is not simply from one coding tool to another.

It is from engineers using tools to produce software towards engineers directing agents that produce software.

2. Small workshops → Factories → Agentic software factories

A traditional software squad resembles a small workshop in some respects. A group of engineers collaborates to design, implement, test, and deliver a product or feature.

Hiring more engineers and creating more squads has historically been a common way to increase development capacity.

But what happens when a significant portion of implementation can be delegated to agents?

We can begin to imagine agentic software factories: production systems that coordinate agents across many tasks, repositories, and workflows.

Rather than scaling only by adding more human teams, organisations could scale by increasing the capacity of their agentic production systems.

A factory might coordinate hundreds or potentially thousands of agents, each working on specialised tasks, while shared infrastructure manages dependencies, execution, testing, verification, and delivery.

This does not mean that thousands of agents will automatically produce thousands of times more useful software. Coordination, context, dependencies, and verification all introduce constraints.

The opportunity is to create a production system that scales without requiring human execution capacity to grow proportionally.

3. Human and animal power → Steam engines → Compute and datacentres

Industrial machinery needed power. Steam engines and, later, electricity provided the energy that allowed factories to operate at scale.

Agentic software production has its own equivalent.

AI agents depend on models, inference, compute infrastructure, memory, storage, and electricity. Datacentres provide much of the physical infrastructure behind this new capability.

This changes the economics of software production.

In a traditional model, increasing implementation capacity often means hiring more engineers. In an agentic model, increasing execution capacity may also mean allocating more compute, using more capable models, and improving the infrastructure that coordinates agents.

Human expertise remains essential, but compute becomes an increasingly important production input.

And just as access to energy helped determine where and how industrial production could scale, access to affordable and reliable compute may influence how agentic software factories are designed and operated.

4. Canals and railways → Orchestration and automated workflows

Factories could not scale in isolation. They needed ways to move materials between production stages and connect suppliers with markets.

Agentic software factories need their own infrastructure for moving work.

Agents must receive tasks, access the right context, use tools, coordinate with other agents, and hand their work to subsequent stages. Their outputs must move through code review, testing, integration, security checks, and deployment.

APIs, task queues, orchestration systems, version control, CI/CD pipelines, and observability become the connective infrastructure of the factory.

The challenge is no longer only how to make an individual agent effective. It is how to move work reliably through the entire production system.

A highly capable agent inside a poorly designed workflow may accomplish very little. A well-designed system can combine specialised capabilities into a reliable process.

5. Craft production → Standardisation and repeatable processes

Mass manufacturing did not emerge simply because factories acquired more machines. Production also became more repeatable.

Agentic software production faces the same challenge.

Agents need clear specifications, stable interfaces, appropriate context, reusable capabilities, and objective ways to evaluate their work.

Without these, adding agents can multiply inconsistent implementations, conflicting changes, and rework.

Standardised workflows and automated evaluations make it easier to delegate work without requiring a human to intervene at every step.

This is also where software architecture becomes particularly important. Good boundaries allow work to be divided into tasks that can be performed and verified independently. Poor boundaries create dependencies that make parallel execution difficult.

The lesson is straightforward: scaling production requires designing the work so that it can be reliably delegated, integrated, and checked.

6. Manual production → Factory operation and management

Perhaps the most important change concerns the role of the engineer.

Industrialisation did not eliminate humans from manufacturing. It changed what they did.

People designed factories, installed machinery, maintained equipment, managed production, controlled quality, and improved processes. Machines performed more of the repetitive physical work, but the system still required human direction and expertise.

The same distinction matters for software.

Engineers will not simply disappear from the production process. Their responsibilities may increasingly move towards designing and operating the systems that produce software.

And this leads to the central idea of this article.

Engineers will build the factories that build software

Consider a modern car factory.

Robots assemble components and perform repeatable operations with speed and precision. But the factory itself was designed by humans. Humans selected and installed the robots, designed the production line, defined its operating procedures, established quality controls, and created the systems that coordinate the process.

Humans also decide which cars to build, how they should work, and what quality standards they must meet.

The robots manufacture the cars. Humans build and operate the system that makes this production possible.

I believe agentic software engineering is moving towards a similar model.

Agents will increasingly perform implementation work, but humans will design the architecture, build the orchestration systems, establish the specifications, create verification mechanisms, and operate the production environment.

The distinction is between building software and building the system that builds software.

These are related, but they are not the same discipline.

In a traditional workflow, an engineer might receive a requirement, design the solution, write the code, test it, fix defects, and deliver the change.

In an agentic workflow, an engineer might instead define the desired outcome, break the problem into verifiable tasks, establish constraints, delegate implementation to agents, and ensure that the resulting changes satisfy the required standards.

The engineer is no longer necessarily the person performing every operation. They become the person responsible for making sure the production system performs those operations correctly.

This does not mean that every engineer will stop coding. Direct implementation will remain valuable, particularly for complex problems, architecture, debugging, and situations where agents cannot reliably complete the work.

But the centre of gravity can shift.

Engineers won't just build software. They'll build the factories that build software.

The engineer becomes a factory architect and operator

If this transformation continues, several capabilities may become increasingly important.

Designing for delegation. Software architecture will need to support work that can be divided into well-defined, relatively independent tasks. Clear boundaries, contracts, and interfaces will help agents work in parallel without constantly conflicting with one another.

Defining intent and specifications. Agents need to know what to build, what constraints to respect, and what success looks like. Ambiguity that a human team might resolve through conversation can become expensive when propagated across many agents.

Building verification systems. Producing code is not the same as producing correct software. Automated tests, static analysis, security checks, integration tests, and higher-level evaluations become essential parts of the production system.

Orchestrating work. Engineers will need to decide how tasks are decomposed, assigned, prioritised, coordinated, and integrated. More agents do not necessarily mean more useful output if they are working on conflicting or poorly defined tasks.

Operating and improving the factory. Engineers will need to understand throughput, bottlenecks, failure rates, rework, latency, compute consumption, and cost. The goal is not to maximise the number of agents running. It is to maximise the amount of valuable, verified software the system can deliver.

Retaining human judgment and accountability. Product decisions, architectural trade-offs, risk acceptance, and responsibility for outcomes cannot simply be delegated away. Automation changes how work is executed, but organisations still need people accountable for what they deliver.

In other words, the engineer's job increasingly becomes designing the conditions under which software can be produced reliably.

Why the Toyota Production System matters

This brings me to a subject I explored in my previous article, Revisiting the Toyota Production System (TPS) in the Age of Coding Agents.

The Toyota Production System is relevant because it focuses on how to organise production, not merely on the capabilities of individual machines.

Two factories can have similar equipment and very different results. The way work flows through the factory, how defects are detected, how quality is maintained, and how the system improves over time all matter.

The same is true of agentic software engineering.

Giving an organisation access to powerful coding agents does not automatically give it an effective software factory.

We need production systems that make it possible to detect failures early, prevent defective work from moving downstream, limit unnecessary work in progress, and continuously improve the process.

Several ideas from manufacturing are especially relevant.

Jidoka: build quality into the process.

In the Toyota Production System, automation is paired with the ability to detect abnormalities and stop when something goes wrong. The aim is not to manufacture defective products faster.

For software agents, the equivalent is to make verification part of the workflow. An agent's output should not automatically be treated as completed work simply because the agent says it has finished. Failed tests, violated constraints, security issues, and integration problems should prevent work from progressing until they are addressed.

Just-in-time production: avoid accumulating unfinished work.

Launching hundreds of agents simultaneously may look impressive, but it can create a large inventory of partially completed changes that compete for attention and integration capacity.

The objective should be to deliver work when it is needed, in manageable increments, while keeping work in progress under control.

Poka-yoke: make mistakes difficult to propagate.

Mistake-proofing means designing a process so that common errors are prevented or caught automatically.

In software factories, this might mean enforcing interface contracts, requiring automated checks, restricting permissions, validating outputs against specifications, and preventing unsafe changes from reaching production.

Kaizen: continuously improve the production system.

Every failed task, rejected change, integration conflict, and repeated agent mistake provides information about the factory.

Rather than treating every failure as an isolated incident, we can use it to improve specifications, tools, tests, workflows, and reusable agent capabilities.

These principles become more important as execution scales. If an agent makes a mistake, the impact may be limited. If a poorly designed workflow allows thousands of agents to repeat that mistake, the problem becomes systemic.

The more automated the factory becomes, the more important it is to engineer the production system itself.

The new bottleneck is not necessarily coding

If agents make implementation cheaper and faster, what becomes scarce?

It depends on the problem, the technology, and the organisation. But several constraints may become more prominent.

Knowing what to build. A factory can produce enormous quantities of output without creating much value if it is producing the wrong things. Product judgment and problem selection remain critical.

Providing clear context. Agents need access to relevant requirements, architectural decisions, existing code, and constraints. Missing or contradictory context can undermine even capable models.

Coordinating parallel work. Some tasks can be performed independently; others have dependencies that limit how much parallelism is useful. More agents can introduce coordination overhead rather than remove it.

Verifying correctness. Generating an implementation may become relatively inexpensive, while proving that it is correct, secure, maintainable, and fit for purpose remains difficult.

Managing cost and resources. Agent execution consumes compute and other resources. A system that generates more code but requires disproportionate verification and rework may not be economically attractive.

This is why I don't think the defining metric of an agentic software factory should be the number of agents it runs or the volume of code it produces.

The more meaningful question is:

How much valuable, reliable software can it deliver, at what cost, and with what level of human intervention?

That is a production question, not merely a coding question.

From engineering capacity to production capacity

Traditionally, organisations have often treated engineering capacity as a function of team size. More developers mean more potential implementation capacity, although coordination costs and other constraints complicate the relationship.

Agentic software factories introduce another possibility.

A relatively small group of engineers could operate a production system that delegates substantial implementation work to agents. The organisation's capacity may depend increasingly on the quality of its architecture, workflows, verification mechanisms, and compute infrastructure.

This does not guarantee that teams will become smaller or that software development will become cheaper in every case. Requirements still need to be understood, complex systems still need to be designed, and generated changes still need to be integrated and maintained.

But it changes the potential economics of building software.

If implementation becomes cheaper, organisations may be able to pursue projects that were previously too expensive, maintain more software, experiment more frequently, or build more specialised products.

At the same time, cheaper production could encourage organisations to generate far more software than they can meaningfully maintain. Without good production controls, lower implementation costs could simply create larger maintenance burdens.

The objective is not to maximise software production at any cost.

It is to make the production of useful software more scalable.

The factory is not the datacentre

One distinction is worth making.

Datacentres provide the compute infrastructure that powers AI models and agents, but they are not the software factory itself.

A software factory is the complete system that turns intent into verified software. It includes the agents, models, tools, codebase, specifications, workflows, orchestration, tests, deployment mechanisms, monitoring, and human operating model.

Two organisations could have access to similar models and compute resources but achieve very different results because their production systems differ.

One might have agents making overlapping changes, producing inconsistent implementations, and relying on humans to discover defects late in the process.

Another might use explicit task boundaries, isolated execution environments, automated verification, controlled integration, and feedback loops to improve reliability.

The difference is not simply the intelligence of the agents.

It is the quality of the factory.

That is why I believe building and operating agentic software factories will become an important engineering discipline in its own right.

The Industrial Revolution is about the system, not the machine

The historical analogy is not exact. Software is not a physical product, AI agents are not industrial robots in every meaningful respect, and software production has different constraints from manufacturing cars or textiles.

Nor does every software organisation need thousands of agents. The right degree of automation will depend on the work being performed, the cost of mistakes, and the economics of the system.

But the underlying parallel is compelling.

The original Industrial Revolution transformed production by combining machines, energy, factories, transport networks, standardisation, and new ways of organising labour.

The emerging transformation in software combines coding agents, compute infrastructure, orchestration, reusable capabilities, automated verification, and new ways of organising engineering work.

The breakthrough is not any one component. It is how the components work together.

And the human role remains central, although it may change substantially.

Humans designed the factories that allowed machines to manufacture goods at scale. In an agentic software world, engineers will increasingly design, build, operate, and improve the factories that allow agents to produce software at scale.

We should therefore spend less time thinking only about how to make an individual coding agent more productive and more time thinking about how to build a production system that reliably turns ideas into working software.

The future of software engineering may not be about having more engineers writing code. It may be about having more engineers building better systems for producing software.

The Industrial Revolution of Software Is Here.