Industrialized factories changed the way the world produced physical goods: more output, lower cost, faster than anything before. Now a similar change is happening with software also.
LLM has lowered the barrier to writing code, increased individual output, and inspired organizations to think about software development as a production system. Standard software development lifecycles and CI/CD practices that have been in place for decades will not hold up under that pressure. That’s where the software factory comes in – and like physical factories, it needs more than speed to really work.
The idea of a “software factory” began to solidify last year. Luca Rossi’s "Software factory era" To state the matter clearly: AI is not just changing how fast people write code – it’s changing the entire production system around software.
The meaning of this concept can vary: a collection of coding agents and skill files; fast CI/CD; better review systems; Or more automation around software delivery. A better framework is to think of it less as a tool category and more as a set of principles. A software factory can’t just be a loose collection of prompts, agents, and plugins. It needs a platform that defines how work moves through the system and how code is generated, reviewed, tested, detected, deployed, and corrected if something goes wrong.
Otherwise you’re just putting a one-and-done machine in an empty room and calling it a factory.
Why is this happening now?
There are a few forces attacking at the same time.
Companies have always wanted to be able to produce more software than engineers can produce. That’s why tools like Excel exist: They often fill the void of a lot of software that many companies wish they could create.
AI has also lowered the barrier of entry to code, and that’s the part everyone focuses on. Code creation is now easier, though not always cheaper or better, as evidenced by the many high-profile companies saddled with their high AI bills. The barrier to writing functional code is effectively eliminated.
More importantly, a single engineer can generate more code than was possible just a few years ago. This changes the constraint: it is no longer “How fast can someone write this?” Or even, in some cases, “Can anyone understand how to code?” Instead it becomes, “Should this be written?”
More importantly, can we actually create end products that are durable and reliable and don’t just create technical debt? Or are we putting AI into decline faster than ever? This is where the danger lies.
Dangers of the Modern Software Factory
All this feels very good. Eventually, factories made production faster and more consistent.
They made it possible to make more cars and products for less money, which enabled more people to buy cars and products. Putting the environmental impacts aside, you could argue that this was positive.
But like many things in engineering, there are always tradeoffs, and in this case, new risks.
When you increase the output of a single person over machinery, digital or otherwise, you also increase the mistakes that can be made by that person or machinery. The speed at which code can now be entered is on an industrial scale. Even small organizations’ code bases can suddenly grow to the size of a tech company’s code base a decade ago.
The data is already showing problems. Pharos AI found that while work throughput per developer increased by 33.7% and PR merge rate increased by 16.2%, the incident-to-PR ratio increased by 242.7% and bugs per developer increased by 54%. Google’s DORA research found that greater AI adoption was actually associated with worse delivery consistency.
As a partial head of data, I have been brought in to fix these exact issues. In the past year alone, I have worked on two projects where AI-generated data infrastructures began to slowly change over time.
With many engineers trying to move quickly and a lack of standards, these projects spiraled out of control. Code bases go through some level of evolution, but as different styles mix, the LLMs in turn begin to create their own mutations. The codebase developed five to six different styles within months – a process that previously would have taken years. Layer by layer, engineers would gradually stop understanding what was really going on.
This pattern mirrors what happened with self-service tooling a decade ago: initial productivity gains that masked downstream complexity.
And that’s why the software factory can’t just be about speed.
What does a software factory do?
There are several key principles to consider when building a software factory.
More platforms than tools: Many teams are slowly implementing AI into their coding workflow at the edge – adding a PR review agent or a skills file to their repos. But building a true software factory requires a platform, not a collection of tools on the edge. A platform provides a unified base where tools are not scattered in different corners. Instead, they actively share data, talk to each other, and work as an integrated system – standards, processes, and functions are all connected.
Reusability and Traceability: A true platform needs the ability to go back to any run, identify what went wrong, and run it again – this is why one-off agents don’t build a factory. The system needs help taking a serial ID, looking it up, and figuring out how it got to the output it produced. This is why state machines make more sense than loops for AI workflows: they make it much easier to replay a process and understand what happened at each step.
Safety and Railings:Factories are not safe places. Nor is there any software factory. As more people grow on these platforms, there is a need to create better guardrails and security measures. Testing and quality control need to be brought to the front of the process – catching bugs at the earliest possible stage reduces the cost of fixing them and limits the explosion radius.
Standardization: At the enterprise level, each codebase has its own flavor. Putting a code helper on top without standards produces an amalgamation of styles. Standardization should be included in the process from the beginning.
Quality Control: In older manufacturing models, quality control occurred at the end of the line. The product was manufactured, inspected, defects were found, and later corrected. Toyota had a different approach. Quality was built into the process itself – workers were expected to stop the line if something went wrong. The goal was not to ultimately find fault; This was to prevent them from flowing downstream in the first place.
The same is true for software factories. QC needs to be involved in the entire process, starting with how the specification is written. This means integrating static code analysis that catches obvious errors and provides templates to LLMs so they know what structure the code should follow. Without it, the hurdle becomes the final review – or teams moving further down the AI slope.
Speed without quality is not productivity
Improving the speed of your code output is not real productivity if downstream problems are not managed. A company is not more productive because it produces millions of cars, only to see them all disintegrate within 100 miles. It’s also not much productive if it simply generates an endless stream of proofs of concept that never enter production.
Real productivity happens when the software factory takes short-term tokens and turns them into sustainable outputs. 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 produces the most code. This is the one that causes the least amount of faults downstream.
<a href