I fully agree with the sentiment, but is it attacking a strawman or are people really building "software factories"? this is the first time I've even seen the term used in the context of LLMs. what would a software factory on top of an LLM even look like?
I know a few entrepreneurs and they all independently started building these kind of factories around the same time, so this is definitely not a straw-man.
I'd say give it another couple of months and you won't be able to move for announcements about this kind of thing.
The "sales pitch" is that factories are to agents what agents were to models; Personally I'm not convinced we need an extra automation layer, with all the downsides that come with even more disconnection from the product being built, but some people are starting to swear by them.
I guess it depends on what people define it as. But I've seen many devs build custom harnesses of sorts, and spend lots of time on that to wire it all together, to then really not achieve much with them. Examples being tools or stuff that got superseded once mcps became a thing. Or spend hours making gigantic folder of skills that specified loads of stuff that the next generation model just could infer. Or build a gigantic parallel agent suite when the bottleneck wasn't the agents in the first place.
None of those things sound like anything I have in mind for a software factory. If anything they have the anti-factory ethos in mind.
The meaning is in the name. It is a factory for software. You have actionable work items that are put in a queue (assembly line) to be worked off (along dedicated stations). Then you have a quality assurance process at the end that rejects faulty parts.
And the goal of the developer is to optimize the process instead of the end result because you can regenerate the end result from scratch as many times as you want, not too different from a compiler.
If agents have excellent single shot performance then it would be best to lean in on it and build cattle software instead of wasting human time with AI written pet software.
In my head it's a bit like people ending up making a game engine when they set out to make a game. It's funnier to spend time on the techy stuff than the other stuff. So in this sense, you spend time making lots of automations and build the factory, but very little time actually building the product.
I have my own dark factory for a small company I work in several projects.
The factory is: agent orchestration and swd.
Basically I refine the work to do, create a bunch of tickets on day 1 and the factory deliver the work during the rest of the week.
So first off, talking about "LLMs" is kinda a yellow flag that you might be a bit behind the times, here: in ~April of this year[1], "agentic engineering" became truly tractable for serious work. We've all been playing with LLMs for coding and research since ~2023 of course, but they were mostly limited to the chatbot paradigm; even after years of Claude Code "harnesses", most engineers were still not trusting them to perform significant tasks on their own due to inevitable quality issues.
Now, that has changed. This isn't just better models, it's a qualitative improvement in capabilities, a step-change, an inflection point; what the MLrs like to call emergent capabilities, in a loose sense.
To pick just one very tangible example close to my heart: This is why the three.js subreddit[2] has exploded in popularity, showcasing demos by non-engineers that blow any three.js app I saw pre-singularity out of the water, which took hundreds of hours of specialized engineering to make (ask me how I know...). The community is reacting[3] much like the mathematicians, understandably.
---
Ok now to answer your actual question (sorry -- that was the intention, originally!) as concisely as I can. "Software factories" are any system you setup to help you build software in deeply agentic ways. All the major harnesses and "ADEs" like Zed could arguably fit here already, but there's a massive ecosystem of other takes, as this article implies. I don't want to give them too much credit for just snagging the name, but the "Factory" startup does embody the idea pretty well: https://docs.factory.com/
They often (though not necessarily, IMHO) include some services that spawn their own agents after deterministic checks ("latent services", in my lingo) and services that use DL models more subtly to empower otherwise-symbolic services ("semilatent services").
In my biased experience, they often focus on a few central usecases, solving the problems that individual devs run into when trying to run multiple harnesses on multiple projects without friction, longterm decoherence, token wastage, or bottlenecks:
1. Code review. This is the big one and far trickier than it seems (trust me!), so often tried then abandoned. There's a huge startup just for this: https://www.coderabbit.ai
2. Cross-harness syncing of settings, hooks, and/or various flavours of very important markdown -- AGENTS.md files, skills, and subagents personas being the big ones.
3. Cross-agent, harness-agnostic coordination and communication. This just recently reached both the main harnesses, but it seems internal for now; a `BULLETIN.md` helps me a TON.
4. More generally, cross-agent coordination when it comes to worktrees, resource sharing (e.g. OCR queues on my 4090, for me), persisting agent-facing content (e.g. reports, trackers, scratch files, .jsonl blobs) in a convenient place that doesn't clog up the repo, and other technical details that might otherwise have to be figured out again and again by each agent.
5. Enforcing standards, either through hooks (blockers, nudges, or revertable fixes) or the aforementioned services. Think commit messages, prose simplicity, doc conventions, etc., though the sky's the limit, here. Like an intuitively-intelligent, more complexly triggered, agent-only precommit setup, in a way.
6. Finally, there's a whole ecosystem of tooling for agents, which I like to call "ACIs"/"Agent-Computer Interfaces". The sky is both the ground and the limit, here; it's really whatever the dev finds their agents to be oddly inefficient about, or just straight up bad at. I personally some to make edits "self-healing", normalize post-OCR cleaning, and capture quick screenshots w/ optional aesthetic critique[4], if that gives you a sense.
TL;DR: Fun stuff to make that speeds you up because it's tailormade to how you work! I made a bunch because I've been ""self-employed"" and thus had the time to explore myself[5], tho I understand why a more realistic after-work paradigm would make this kind of work wasteful.
On that note, back to writing cover letters -- apologies if the long message bothers anyone. I really should start a blog or get a hobby or something, huh
Your entire post is a huge red flag that tells me you don't know anything you are talking about just based on the first paragraph.
There is no qualitative change whatsoever. The training dataset now contains more agentic sessions and that alone was enough. Most model architectures that came out this year haven't meaningfully changed anything in terms of making models more expressive, if anything they took steps backwards in the name of inference optimization.
So it literally is better models in the form of better data and nothing else, otherwise it wouldn't have been so easy for competitors to clone leading capabilities.
Also LLM just means it is a large model that can output language and technically the LLM archetype was replaced by almost every new model being a VLM (vision language model) which is a meaningless nit pick.
> talking about "LLMs" is kinda a yellow flag that you might be a bit behind the times, here: in ~April of this year[1], "agentic engineering" became truly tractable for serious work
It's still LLMs though? This feels like saying we've moved on from using compilers now that we have IDEs; that's just a wrapper and we're still using the first thing.
so first off, i'm not an AI avoider - i use LLMs all day at work, and have several personal projects i'm likewise using claude for. but a single, interactive session produces code as fast as i can handle, if i want to keep a tight rein on the quality of the output - i often find myself having to look at the code generated from some intermediate stage and course-correct.
i do use agents for code review but again in a very human-in-the-loop manner; i will ask for a review and then read it over before feeding it to my coding LLM session and asking it to read and iterate on it. as you say, it can be surprisingly tricky to get right, and i like the confidence of the human being the coordinating reviewer.
thanks for all the examples, though - that does give me a lot more context for what people mean by "software factories" (and the assurance that they don't fit the way i work).
