Why Software Factories Fail (or: harness engineering is not enough)

Software factories can implement anything given a one-liner requirement. That one-liner requirement can be a complete app/product, epic, feature, bug, design change or refactoring. But these one liner requirements are requirements coming from a human who has an intent or requirement or direction for the product to evolve in mind. Can Software factories manufacture intent that reflects the exact requirements of the person using it or their vision of how the product or software should evolve?

Implementation in any language is as easy as generating a summary for an LLM. If coding is only math and there is only one way to translate a requirement into an implementation, the problem boils down to just providing or verifying generated intent. But, there is definitely more than one way to implement a thing and one of the ways leads to a design and architecture that is coherent with rest of the system, design and architecture that is extensible and evolves, code that you can keep in your head when you want to change things next time or tomorrow, software that can serve millions of users and securely guarantee millions of dollars of revenue. There is a combinatorial explosion of ways and the one right way is also subjective of the person and the problem. Software factories can of course improve Quality by generating more unit tests, more integration tests, fix code violations, generate Proof of work as videos, screenshots etc, but there is no feedback loop or test suite to verify and correct the other subjective notions of Quality.

> # We tried this > In July 2025 we went full lights-off

Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.

I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.

Yes, in an ideal world, PRs read well, are a joy to review, reflect what you discussed etc etc. We have to be real; there is only so much we can do to that end.

I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.

These days I think there's really no excuse for the awful UX. Linear (a company that isn't even in the domain of code review) put out a basic PR review feature[0] that is already better than what GH offers. It's simple: point a small model at the PR, group file changes together based on theme, add some commentary and sort by importance (schema changes > openapi spec).

Immediately, so much mental load has been reduced without the reviewer or the requester doing anything. This feature is pretty damn basic, and I think there are obvious next steps like generating visualisations which a dedicated product could find the time to implement.

Keen to hear others thoughts on why this is the wrong approach, or if there are tools in wide use that solve for this, or why this isnt the right problem to focus on.

0 - https://linear.app/docs/diffs#guides

Claude can write the code for you but it can’t understand it for you. That part has to happen at human speeds.

There are cases where you don’t have to understand everything, but I think that’s a more nuanced question.

All of the above is true even if Claude writes perfect code.

It reminds me of all the recent talk about "taste". Architecture "quality" may not be objective in a right/wrong sense, in the same way that fashion isn't right/wrong. It's like we are all going to have to relinquish reason/rationality to the machine and start to study up on aesthetics.

Even historically, my big struggles have usually been deciding between two nearly-equivalent options. I get this a lot now with LLMs because there is no break in-between these decisions that implementation used to force. I feel I'm constantly making "taste" calls between tradeoffs that have no clear objective criteria, and it is as exhausting as the code review this post (and my experience) suggests are still necessary, even with Fable/GPT-5.6 level models.

In many cases, I do what I've done with junior engineers whose code I reviewed pre-agent: make on-the-spot judgement calls. When I see a broken window, I call it out. But when I see minor issues, I sometimes just let it pass, note it in memory and tackle it wholesale once an accumulation of similar minor issues get to a certain size.

As a tangential aside, I consider two dev shops from pre-agent days. One decides to hire 7 extremely talented engineers and gets them to work closely together. The other decides to outsource to 100 decent engineers and tries to silo them into modules. I think we are facing a similar choice with agents. You can either work extremely closely with a handful of agents, collaborating on design, review, etc. Or you can spin up a fleet of sub-agents and YOLO, then try to separate the wheat from the chaff in some automated way. My taste is the former, small highly coordinated shop. But time will tell if I am right or wrong.

Its crazy to me people write these articles and create standards like this is some kind of engineering standard with years of research and experience

This is like calling these folks the experts on aviation: https://youtu.be/M9Yww9LG3gw?is=xgtA-xMpNy-09Asu

Its still so early in the game for de facto standards - engineering teams need to experiment and see what works for their own quality metrics not just parrot “standards and methodologies”

This is still the very early days of AI and AI engineering

If you think you can just assign Github tickets to AI agents and go drink daiquiris on the beach I think you'll find that you end up with more and more towers of abstraction and indirection. There are 'points of view' that emerge during coding I think. And at some point you as a human have to be like "wait... what if we use Redis here". "Wait.. the API is already returning the data we need". "Wait... let's not add customers to the report who have not been active in the past year". Stuff like that

I do spend a lot of time up front specifying what I want. My prompts aren't one-liners, but rather an interview process where we work through all the open questions and ambiguity.

I haven't hit the wall that the OP talked about (when agents just can't seem to make the right changes, and it's impossible for me to go in and change things manually). I used a lot of guardrails such as plan reviews, browser-based QA, adversarial reviews, unit tests, linters, typecheckers, post-commit hooks, and formal method traces. I also specified engineering principles that steers the code base to minimize state and side-effects: functional core; imperative shell, make impossible states impossible, use pure functional style, etc.

There are times, when I can feel a part of the code base is messy without looking at it, because the agent will make recurring mistakes in the same part of the code base over time. What I found the agent was doing over time is that it's been layering state variables as requirements were discovered. So what helps is to ask it to refactor all these state variables into a single sum type. And if the state machine for it is complicated, I'll ask it to write a formal model of the state in Quint. Then I'll generate traces that get run as unit tests, and ask it to write the code against that.

So while the code base isn't exactly Brownfield, it's over a year old now. As for the code base, there's a backend and a frontend. I think it helps that I established a clear pattern I wanted. You code are like memes: agents will just copy patterns they see in the code base. When it does have to create a new part of the system, I found Sonnet-level models tend to draw system boundaries in all the wrong places. Opus is better. I don't yet know about Fable.

Happy to answer any questions about my workflow.

On one hand, our core product is just simply not fit for them at its scale. We've tried but the project is large enough to require human input for every change. But we have AI automations for light code refactoring, writing tests, UI changes etc. and they work.

On the other hand, I started a number of small experiments to see how far software factories can be pushed and while the code produced so far is nothing spectacular I could easily imagine how this can be extended in the near future. Perhaps if you start from the ground up with the idea that the code will be written that way then you can come up with strategies and architectures that accommodate it. At least this is my thinking right now.

Anyway, it is all open source and documented here https://relentless.works/ I am not sure for long I will keep this running. I provide zero direction to where this is going. I have no idea what it will happen next. It is a fun experiment.

I have another such experiment with a trading agent. I thought it will loose all of the money in short time. For a while it was stuck with no open positions after it lost a bit. I decided not to intervene and just observe the behaviour. Recently it opened new positions which was an interesting development. It is still loosing money (~ -3%) but it has not lost all of them and given the current market circumstances I would say this ain't bad at all. It just shows that perhaps we might be a bit impatient when it comes to AI.

So I think it is probably possible to build software factories but we need new concepts and a bit of change of mindset.

I hope this helps.

Instead, use them in adversarial mode - run QA scenarios using LLM agent as a substitute for end user to do bug discovery.

If we are going in the Dark Software Factory route, why aren't we calling the code units as bos (bunch of shit) yet.

It works quite well, as it puts your entire focus on writing (hopefully) unambiguous specifications vs. having to discuss unwanted changes with an LLM during code-review. One flaw is that this only works great if you know exactly what you want, which is not always the case.

1) This guy has a track record (confessed) of making shit up, yapping on about it, and pushing it on the innocent. He's done a bunch of damage with his bullshit and now wants us to pay attention again. I mean - something something off fella.

2) There is NO EVIDENCE AT ALL that his ideas are good. He's just making stuff up.

Give me a reason. Also shouldn't he be ostracised and stripped of his wealth for his previous rubbish?

a lot of the model's constraints come down to how they are RLed. Discussions online would be a lot better if everyone understood how the labs train the models in a high level (or did a lil data labeling)

The one downside was that it required their computers to install dev dependencies, postgres, infisical for secret management, etc.

That's the next frontier. What I'm working on now independently. I plan to open source this solution, but again I'm not a savant genius. I guarantee many people are working on the same thing it's converging. Our job as engineers is becoming more of a higher level facilitator and AI "plumbing" maintenance work. How can we get the AI to empower everybody at the company while keeping the wheels turning. That's my aim.

And a benchmark to measure against!

Imagine a "MaintainabilityBench" that rewards models which detect code duplication while working on a task and perform some refactor instead of glibly duplicating; or that detect the need for a new architectural layer, or that hoist a type constraint so there's no need for dumb casts. You can keep on imagining scenarios.

There are probably a few hundred distinct elements to RL for. The books "Working With Legacy Code" and "Architecture of Open Source Applications" would be great fodder.

Sadly don't have time to build it, there's this mountain of reviews in front of me...

The corollary of agents being bad at maintainability but good at coding is that you can vibecode all the parts where maintainability doesn't matter.

So if you build a (domain-specific) modular architecture for your software first you can then just let your software factories loose on building the modules.

This was easy to find out I thought. And just with an old-fashioned google search too, no deep research agent needed. See here: https://diffusion.io/

Seems like it went pretty well if a consulting company is now being started.

I agree with a lot of what Dex Horthy is saying here but on some fronts I feel like he's missing something. Coding well with LLMs, it's not a skill issue, it's an effort/laziness/rigor issue.

In order for coding with LLMs to go well, there has to be more rigor, more discipline, more good engineering hard-assedness. To reiterate, the teams seeing the best results with AI were already high-discipline and high-hygiene.

AI works on data. The better the data, the better the likelihood of a desirable outcome. Code is data. If you have bad code, no matter how awesome the model you let loose on it, you can't get as good a result as if you had good code to start with. This principle has been well known in AI/ML circles since the 20th century.

e.g., if you are doing spec driven development and not seriously investigating formal verification, IMHO you will come up short. Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.

Now, if you've got a really good model you can get much further with dead reckoning compared to a worse model. But a model is not reality so no matter how good it is, so without feedback eventually you still run into this problem no matter what.

I imagine that's a lot like what goes on in these agentic loops.

I feel like the explanation does nothing to actually elucidate why models can't do it. Is it an inherent weakness of LLMs? Training processes? The typical "this is crap" that we constantly hear? It goes on to write about RL and how there's no penalty for bad design. But that sort of side-steps the question and makes you ask: "why not do RL and make a penalty for bad design?" Of course the models aren't good at it ... they're not good at anything until you've tuned them and put them in a harness that rewards good edits and throws away (improves) bad edits. That doesn't explain why "models can't do software maintainability." The real question is why harnesses can't do software maintainability, and how to build a system that can do it. (I suppose that's the purpose of the ad at the bottom of the page.)

Doesn’t this gloss over the fact that token subsidization is a thing? I assume the reason a lot of people switched from other harnesses to CC was all the weirdness around setup-token and whether third party harnesses would continue to work without api pricing.

The models write good/great code. I'm very happy to never write code again but models are no where near good enough to run off on their own without a human in the loop. Models LOVE to cheat. Just peek at the tests they write.

And before you come at me, I have built 7 products in the past 1.5/2 years with agentic engineering, all with users. One of those projects is _dead_ because I let the vibe go too hard at the same time Anthropic decided to nerf both their harness and their models silently. If you care to look at the source: https://github.com/Robdel12/OrbitDock I spent a week or so and like a billion+ tokens trying to refactor and save it. It just wasn't worth it.

I wish people would be pragmatic about this. I get the dream is to let it do everything and not to be in the loop, because being in the loop is exhausting. But if you want to make whatever you're building be robust and survive more than 6 months, you have to. I don't care how good your tests, plans, skills, etc are. At some point the model will have to decide something and it'll be the wrong one. Compounding the slop from there forward.

People have no idea that 2 years ago we hit peak performance with omni models. We won competitions with GPT-4o-mini, mini... it does not matter. Context matters. Discipline matters. Observability matters. Most of all, PEOPLE matter.

All of the fools who tried this and laid people off. Fools. It's about empowering your team, making their lives easier, less frustrating, and higher impact.

[1] - this course: https://www.coursera.org/learn/machine-learning/home/welcome

https://softwaredoug.com/blog/2026/07/09/write-code.html

>I was pretty excited for a world where we could just ask for things and let the models cook and not read the code and get beautiful production software

I feel so disconnected reading those things. Reading and writing code is what brings me joy. I'd never feel "bummed" or "stuck" with it.

I disagree with the way that big models are trained on noisy relationships and RL is applied to tone it back down, it represents a stupid amount of compute thrown at this problem at a scale that is often unnecessary.

The rest of it is on point.

What a surprise! And here I was thinking that loops had only just been invented, to use in agent harnesses, as described in the famous paper “Loops Are All You Need.”

Absent those skills, the agile movement is flailing with GenAI.

Also it's missing the point of a software factory concept

A software factory will not work infinitely forever for everything. A software factory isn't a solve anything button (aka god).

In a conventional factory, things break and fail. Process machines get poluted. Extruders get jammed.

You still need to establish intent, define what you care about, define guardrails, and of course manage the factory.