Industrialized factories changed the way the world produced physical goods: higher output, lower costs, and faster than anything before. A similar change is now happening with software.
LLMs have lowered the barrier to writing code, increased individual output, and pushed organizations to think of software development as a production system. The standard software development lifecycle and CI/CD practices that have been in place for decades will not withstand that pressure. That’s where the software factory comes in, and like physical factories, it needs more than just speed to function.
The idea of a “software factory” began to solidify over the past year. Luca Rossi "The era of the software factory" He put it clearly: AI is not only changing how quickly people write code, it is 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 review systems; or more automation around software delivery. A better framework is to think of it less as a category of tools and more as a set of principles. A software factory cannot simply be a loose collection of messages, agents, and plugins. You need a platform that defines how work moves through the system and how code is generated, reviewed, tested, tracked, deployed, and improved when something goes wrong.
Otherwise all you’d be doing is putting another single machine in an empty room and calling it a factory.
Why is this happening now?
There are some forces that collide all at the same time.
Companies have always wanted more software than engineers can produce. That’s why tools like Excel exist: they often fill the void of much of the software that many companies wish they could make.
AI has also lowered the barrier to entry to creating code, and this is the part everyone is focused on. Creating code is now easier, although not always cheaper or better, as demonstrated by many high-profile companies. Worried about their high AI bills.. The barrier to writing effectively functional code has fallen.
More importantly, a single engineer can generate more code than a few years ago. That changes the bottleneck: it’s no longer a question of “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 really create end products that are durable and reliable and don’t simply generate tech debt? Or are we just throwing out more AI junk faster than ever? That’s where the danger lies.
The dangers of the modern software factory
This all sounds great. After all, factories made production faster and more consistent.
They made it possible to make more cars and products at lower costs, which led to more people being able to afford cars and products. Environmental impacts aside, one could argue that this was positive.
But as with many things in engineering, there are always trade-offs and, in this case, new risks.
When you increase a person’s output with machinery, digital or otherwise, you also increase the errors that the individual or the machinery can make. The speed at which code can now be released is on an industrial scale. Even the smallest organizations can suddenly have codebases that reach the size of tech companies’ codebases a decade ago.
The data already shows problems. Faros AI found that while task throughput per developer increased by 33.7% and PR merge rate increased by 16.2%, the The incident-PR ratio has increased by 242.7%. and errors per developer increased by 54%. Google’s DORA research found that greater adoption of AI was actually needed. associated with worse birth stability.
As a fractional chief data officer, I was brought in to solve exactly these problems. Last year alone, I worked on two projects where the AI-generated data infrastructure began to slowly transform over time.
Between several engineers trying to move quickly and a lack of standards, these projects became unruly. Codebases tend to go through a certain level of evolution, but as different styles are combined, LLMs, in turn, begin to create their own mutations. Codebases developed five to six different styles in a few months, a process that previously took years. Layer by layerThe engineers would gradually stop understanding exactly what was happening.
The pattern echoes what happened a decade ago with self-service tools: early productivity gains that masked later complexity.
And that’s why the software factory can’t just focus on speed.
What makes a software factory work?
There are several key principles to consider when building a software factory.
Platform about tools: Many teams are slowly implementing AI into their edge coding workflows, adding a PR review agent or skills file to their repositories. But building a real software factory requires a platform, not a collection of tools at the edges. A platform provides a unified foundation where tools are not scattered in separate corners. Instead, they actively share data, talk to each other, and work as a single cohesive system: standards, processes, and the work itself, all connected.
Remunerability and traceability: A real platform requires the ability to go back to any run, identify what went wrong, and run it again; which is why sole agents do not create a factory. The system should allow you to take a serial ID, search for it, and trace exactly how you arrived at the result you produced. That’s why state machines make more sense than loops for AI workflows: they make it much easier to rerun a process and understand what happened at each step.
Safety and railings: Factories are not safe places. Neither is a software factory. As more people develop on these platforms, best railings and security measures must be incorporated. Testing and quality control must come to the front of the process: detecting errors at the lowest possible stage reduces the cost of correcting them and limits the explosion radius.
Standardization: At the enterprise level, each codebase has its own style. Placing a code helper on top without standards produces an amalgamation of styles. Standardization must be built into the process from the beginning.
Quality control: In older manufacturing models, quality control was performed at the end of the line. The product was built, inspected, found to have defects and subsequently repaired. Toyota’s approach was different. Quality was introduced into the process itself: workers were expected to stop the line when something was wrong. The goal was not to detect defects at the end; Firstly, it was to prevent them from flowing downstream.
The same goes for the software factory. Quality control must be integrated into the entire process, starting with how specifications are written. That means integrating static code analysis that detects obvious errors and providing templates to LLMs so they know the structure the code should follow. Without that, the bottleneck becomes the final review, or teams simply eliminate more AI waste.
Speed without quality is not productivity
Improving the output speed of your code isn’t real productivity if you don’t manage downstream issues. A company is not more productive because it produces millions of cars and watches them all fall apart within a 100-mile radius. You’re also no more productive if all you do is produce an endless stream of proofs of concept that never go into production.
Real productivity occurs when the software factory takes ephemeral tokens and turns them into lasting results. It’s easy to talk about lines of code and how fast your team moves.
The software factory that wins is not the one that generates the most code. It is the one that generates the least downstream defects.
