Industrialized factories changed the world’s production of physical goods: more products, lower costs, faster than before. Now, a similar change is happening with software.
LLMs lowered the barrier to coding, increased individual productivity, and encouraged organizations to think about software development as a production system. Decades of standard software development cycle and CI/CD practices will not hold up under this pressure. This is where the software factory comes in, and like physical factories, it requires more than speed to actually work.
The idea of a “software factory” has gained traction over the past year. by Luca Rossi "Software factory era" made the point clear: AI isn’t just changing the speed at which people can write code, it’s changing the entire production system around software.
The concept can mean different things: a collection of coding agents and skill files; faster CI/CD; better inspection systems; or more automation around software delivery. A better framework is to think of it more as a tool category and more as a set of principles. A software factory can’t just be an empty collection of prompts, agents, and plugins. You need a platform that defines how work moves through the system and how code is created, reviewed, tested, tracked, deployed, and improved when something goes wrong.
Otherwise, all you’re doing is placing another disposable machine in an empty room and calling it a factory.
Why is this happening now?
There are several forces all hitting at the same time.
Companies have always wanted more software than engineers could produce. That’s why tools like Excel exist: They often fill a software void that many companies can’t.
AI has also lowered the barrier of entry for creating code, and that’s the part everyone’s focused on. Generating code is easier now, but not always cheaper or better, as many top companies prove worried about high AI scores. The barrier to writing functional code has effectively collapsed.
More importantly, a single engineer can create more code than just a few years ago. This changes the bottleneck: it’s no longer “How fast can someone write this?” not. even in some cases “Can anyone figure out how to code?” Instead of “Should this be written?”
More importantly, can we create end products that are durable and reliable and not just creating technological debt? Or are we reaping the benefits of artificial intelligence more than ever? This is where the danger lies.
The perils of the modern software factory
This all sounds great. Factories, as a result, made production faster and more consistent.
They made it possible to produce more cars and products at a lower cost, which led to more people being able to buy cars and products. Environmental impacts aside, you could argue that this is a positive.
But like many things in engineering, there are always trade-offs, and in this case there are new risks.
When you increase a person’s productivity, digitally or otherwise, you increase the amount of error that both the individual and the machine can make. The speed at which code can now be extracted is industry-leading. Even smaller organizations can suddenly have codebases the size of tech company codebases a decade ago.
The data already shows the problems. Faros AI found that while task throughput per developer increased by 33.7% and PR merge rate by 16.2%, the PR rate of events increased by 242.7% and bugs per developer increased by 54%. Google’s DORA study showed that more AI was being adopted associated with worse delivery stability.
As a keen data executive, I am drawn in to solve these exact problems. In the last year alone, I’ve worked on two projects where AI-generated data infrastructure has slowly begun to change over time.
Between too many engineers trying to move quickly and the lack of standards, these projects became unruly. Codebases go through a certain level of evolution, but as different styles mix, LLMs in turn begin to generate their own mutations. Codebases have developed five to six different styles over the course of months—a process that used to take years. Over and overengineers will slowly stop understanding what is going on.
The pattern repeats what happened with self-service tools a decade ago: early productivity gains masking downstream complexity.
And that’s why a software factory can’t just be about speed.
What makes the software factory work?
There are a few key principles to keep in mind when building a software factory.
Platform on Tools: Many teams are slowly applying AI to their coding workflows at the edges—adding a PR research agent or skills file to their repos. But building an actual software factory requires a platform, not a set of tools at the edges. The platform provides a single foundation where tools are not scattered in separate corners. Instead, they actively share information, talk to each other, and work as a single, unified system—the standards, processes, and work itself are interconnected.
Reproducible and traceable: A true platform requires the ability to go back to any job, figure out what went wrong, and get it working again – so one-shot agents don’t build a factory. The system must support retrieving the serial identifier, searching for it, and tracing how it gets to the output it produces. This is why state machines make more sense than loops for AI workflows: they make it much easier to re-enact a process and understand what’s happening at each step.
Safety and guardrails: Factories are not safe places. Not any software factory. As more people develop on these platforms, better guardrails and security measures must be established. Testing and quality control should be at the forefront of the process — catching errors at the lowest possible stage reduces the cost of fixing them and limits the radius of the explosion.
Standardization: At the enterprise level, each codebase has its own flavor. Layering a code helper without standards creates a fusion of styles. Standardization should be built into the process from the beginning.
Quality control: In older production models, quality control took place at the end of the line. The product was built, tested, defects were found and then fixed. Toyota’s approach was different. Quality was pushed into the process itself—employees were expected to stop the line when something went wrong. The goal was not to catch the flaws in the end; in the first place was to prevent them from flowing downstream.
The same applies to the software factory. QC should be incorporated into the entire process, starting with how the specification is written. This means integrating static code analysis that detects obvious errors and providing templates to LLMs to know the structure the code should follow. Without it, the bottleneck becomes the last look – or teams just push more AI damping.
Poor speed is not productivity
Improving code output speed is not actual productivity unless downstream issues are managed. A company is no more productive because it produces millions of cars, only to see them all fall apart within 100 miles. It’s less productive if it generates an endless stream of proofs of concept that never make it into production.
Actual productivity is when the software factory takes ephemeral tokens and turns them into durable results. It’s easy to talk about lines of code and how fast your team is moving.
The software factory that wins is not the one that generates the most code. It is the one that causes the least defects downstream.
