Is it too soon to built software factories?

[Bnowako]

I keep hearing about “software factories” / background coding agents that can autonomously work on production repos. It seems like the capabilities are there, but not sure if we have the right tools yet.

There are already some companies providing software for this like ona/factory/codex/claude/cursor

Open-source alternatives - https://github.com/ColeMurray/background-agents

Big companies like stripe/ramp/uber/spotify built their own background-agents infrastructure

But nothing seems to be mature enough to just work fine. Is it too soon?

[jeremyroberts0]

As you say big companies are building these so there's clearly a market need not being met. Cursor, Claude, and other have started getting into it with background agents but they still drive like the local agent just wrapped into the cloud, they still need prodding to get work done. I've been building Gibon (https://gibon.ai) for exactly this to try and hit this market need. We're running a pilot program right now, check out the site and fill out the form if you're interested and we'll be in touch.

[adamzwasserman]

No it is not too soon, but it is contingent upon understanding how factories actually work, and what distinguishes industrial production from artisanal production. Even AI generated code is artisanal.

As afar as I know, my book "The Chaos Factory" is the only book that does this.

[Bnowako]

This answer seems very vague, buzzwordy and promotional. Not sure if a book from 2019 could explain the issues from the post.

[adamzwasserman]

It is obviously promotional, I wrote the book and I want people to read it.

The reason why I wrote a book is that it is a very long and complex answer. I will see if I can summarize it for you adequately in a HN post.

I start by building the case that corporate IT failure is a real and measurable long-running crisis. I cite Standish Group's 1994 Chaos Report and KPMG's Report on IT Runaway Systems: only a third of corporate IT projects are deemed successful by the executives who fund them. PMI estimated $300B was lost in the US to failed IT in 1999–2001 alone. Decades of methodologies and magic bullets haven't moved the number.

I explain how enterprise software is still produced by hand. Every successful project depends on master programmers mentoring less-experienced ones. Per Bob Martin, programmer headcount doubles every five years, so half the industry always has under five years' experience: "perpetual inexperience.

I explain why prior fixes failed: Project management responded to the 1994 reports by trying to freeze requirements, which killed IT's ability to track changing business needs. The COTS (Commercial Off The Shelf) wave collapsed against unique corporate processes. Industrialization attempts—CASE, CORBA, COM/.NET, MDA—all targeted the wrong thing: writing code.

I move to making the case that the correct target is assembly of code. Per Alexander Stepanov, only about 10% of a developer's time goes to creative coding; the other 90% is "glue, fitting, and assembly" — wiring up libraries, reconciling versions, plumbing data between layers. Auto design is still artisanal; what got industrialized was assembly, via machine tools, interchangeable parts, and semi-skilled labor.

Then I explain how to industrialize the assembly, not the coding. Compilers and JIT VMs are the robots IT already has; class libraries and open-source packages are its interchangeable parts. The FANGs already build internal mass-production tooling on top of these. Corporate IT must do the same so master programmers can leverage semi-skilled assemblers because we are not going magically exponentially increase the number of insanely great programmers.

The book was written eight years ago, so I will address AI coding here: LLMs are trained using a technique called gradient descent which is a way of finding the most mid possible point of anything and we then assign the highest weights to that. LLM write mid code by design and this is unchangeable. Any attempt to write insanely great code using an LLM is an unholy uphill battle of fighting the gradient descent every step of the way.