Many companies think they are building a software industry. They actually ship bugs faster.

Industrial factories changed the way the world produced material things: more output, lower costs, faster than anything that had come before. Now the same change is happening with software.

LLMs have lowered the coding barrier, increased individual output, and pushed organizations to think of software development as a production process. Traditional software development lifecycles and CI/CD processes that have held up for decades will not hold up under that pressure. This is where the software industry comes in – and like virtual factories, it needs more than speed to really work.

The concept of a “software industry” has taken hold over the past year. This is Luca Rossi’s place "The Era of the Software Factory" made the case clear: AI isn’t just changing the way people quickly write code — it’s changing the entire production process around software.

A concept can mean different things: a collection of coding agents and capability files; immediately CI/CD; better review systems; or more automation around software delivery. A better framework is to think of it less as a toolkit and more as a set of principles. The software industry cannot simply be a loose collection of notifications, agents, and plugins. It requires a framework that describes how work flows through the system and how code is created, updated, tested, tracked, deployed, and improved when something goes wrong.

Otherwise all you do is put one more machine in an empty room and call it a factory.

Why is this happening now?

There are several forces all hitting at once.

Companies have always wanted more software than developers can produce. That’s why tools like Excel exist: They often replace a lot of software that many companies wish they could do.

AI is also lowering the barrier to entry for creating code, and this is the area that everyone is focused on. Creating code is now easier, although not always cheaper or better, as evidenced by many high-end companies worrying about their high AI bills. The barrier to writing functional code has been successfully folded.

More importantly, a single developer can produce more code than he could a few years ago. That changes the bottle: it’s no longer “How fast can someone write this?” or, in some cases, “Can someone understand how to code?” Instead it becomes, “Should this be written?”

More importantly, can we create end products that are durable and reliable and don’t just create technical debt? Or are we churning out AI slop faster than ever? This is where the danger lies.

The dangers of the modern software industry

This all sounds good. Industrialization, after all, made production faster and more consistent.

They made more cars and products to be built, which were inexpensive, which led to more people being able to buy cars and products. Putting the environmental implications aside, you could argue that this is good.

But like most things in engineering, there are always trade-offs, and in this case, there are new risks.

When you increase one person’s productivity with machines, digital or otherwise, you also increase the errors that can be made by either the person or the machines. The speed at which code can be released is on an industrial scale. Even small organizations can suddenly have code bases that are the size of tech company code bases a decade ago.

The data is already showing problems. Faros AI found that while the workload per developer increased by 33.7% and the PR integration rate increased by 16.2%, the incident-to-PR ratio increased by 242.7% and bugs per developer increased by 54%. Google’s DORA study found that more AI adoption was actually associated with worse delivery stability.

As the chief data officer, I was brought in to address these issues directly. In the past year alone, I’ve worked on two projects where the AI-generated data infrastructure slowly began to evolve over time.

Between many engineers trying to move quickly and the lack of standards, these designs became unmanageable. Code bases usually go through a certain level of evolution, but as different styles converge, LLMs also start to make their own changes. Codebases developed five to six different styles within months – a process that previously took years. Layer by layer, the engineers slowly stopped understanding what was going on.

The pattern echoes what happened a decade ago with self-service tooling: early productivity benefits masking downstream complexity.

And that’s why the software industry won’t be up to speed.

What makes the software industry work

There are several important principles to consider when building a software industry.

Platform on tools: Many teams are gradually applying AI to their edge coding workflow – adding a PR review agent or skills file to their environments. But building a real software industry requires a platform, not a set of tools at the edge. The platform provides a unified foundation where tools are not scattered in different corners. Instead, they actively share data, discuss, and work as one integrated system — standards, processes, and the work itself are all interconnected.

Reusability and traceability: A real platform needs the ability to go back to any run, identify what went wrong, and start again – that’s why agents come out once and don’t make a factory. The system needs to support taking the serial ID, looking it up, and tracking how it got to the product that produced it. That’s why state machines make more sense than AI workflow loops: they make it much easier to restart the process and understand what happened at each step.

Safety and security: Factories are not safe places. It is not a software industry. As more people develop on these platforms, better guard lines and safety measures must be created. Inspection and quality control must be pushed ahead of the process — catching bugs at the lowest point reduces repair costs and limits the radius of the explosion.

Configuration: At the enterprise level, every codebase has its own flavor. Layering helper code on top of non-standards produces style integration. Configuration should be built into the system from the start.

Quality control: In older manufacturing models, quality control occurs at the end of the line. The product was built, tested, bugs were found, and later fixed. Toyota’s approach was different. Quality was pushed into the system itself – workers were expected to stop the line when something went wrong. The goal was not to catch mistakes in the end; it was to prevent them from flowing downstream in the first place.

The same is true for the software industry. QC needs to be baked into the entire process, starting with how the spec is written. That means integrating static code analysis that catches obvious errors and provides templates to LLMs so they know what design to follow. Otherwise, the bottleneck becomes the final update – or teams just release AI slop.

Speed ​​without quality is not productivity

Improving the output speed of your code is not a real product if the downstream problems are not controlled. The company is not very productive because it produces millions of cars, and sees them all split within 100 miles. And it’s not very productive if all it does is generate an endless stream of proof of concept that doesn’t make it into production.

Real productivity is when a software factory takes ephemeral tokens and turns them into long-lasting output. It’s easy to talk about lines of code and how fast your team is moving.

The software industry that wins is not the one that produces the most code. It is the one that causes the fewest problems downstream.