The concept of a software factory has started to take shape over the past year, with the idea being that AI is changing the whole production system around software, not just how fast people write code. According to the report, this shift is similar to how industrialized factories changed the production of physical goods, resulting in more output and lower costs.
A software factory can be thought of as a set of principles, rather than a tool category, and it needs a platform that defines how work moves through the system and how code is generated, reviewed, tested, and improved.
Companies have always wanted more software than engineers can produce, which is why tools like Excel exist, filling in the gap for a lot of the software that many companies wish they could make.
AI has lowered the barrier to creating code, making it easier for individuals to generate more code than they could a few years ago, but this has also changed the bottleneck from “How fast can someone write this?” to “Should this be written?” and “Can we actually create end products that are durable and reliable?”
The data is already showing problems, with Faros AI finding that while task throughput per developer is up 33.7% and PR merge rate is up 16.2%, the incidents-to-PR ratio has risen 242.7% and bugs per developer are up 54%.
CI/CD practices that have held for decades won’t hold up under the pressure of increased code output, and that’s where the software factory comes in.
They can’t just be about speed, as the dangers of the modern software factory include increased mistakes and tech debt, and the pattern echoes what happened a decade ago with self-service tooling: early productivity gains that masked downstream complexity.
There are several key principles to consider when building a software factory, including platform over tools, rerunability and traceability, safety and guardrails, standardization, and quality control.
Related: Intuit to showcase AI infrastructure rebuild at VB Transform 2026
A real platform requires the ability to go back into any run, identify what went wrong, and rerun it, which is why one-off agents don’t make a factory, and state machines make more sense than loops for AI workflows like agent permissions.
Safety and guardrails need to be built into the process, with testing and quality control pushed to the front of the process, catching bugs at the lowest possible stage reduces the cost to fix them and limits the blast radius.
Standardization has to be built into the process from the start, and quality control needs to be baked into the entire process, starting with how the spec is written, integrating static code analysis and providing templates to LLMs so they know the structure the code should follow.
Improving the speed of your code output is not actual productivity if the downstream issues aren’t managed, and actual productivity is when the software factory takes ephemeral tokens and turns them into durable outputs.
The software factory that wins isn’t the one that generates the most code, it’s the one that generates the fewest defects downstream, and companies need to focus on building a software factory that prioritizes quality and durability over speed.
According to the report, a fractional head of data has worked on two projects where AI-generated data infrastructure slowly started to morph over time, becoming unruly and developing multiple styles within months, a process that previously took years.
This highlights the need for a software factory that can handle the complexity of AI-generated code and ensure that the output is durable and reliable, rather than just focusing on speed and productivity, much like Marlin Research Agent does.
They must adapt.
Leave a Reply