Why Software Factories Fail (or: harness engineering is not enough) (github.com)
97 points by dhorthy 4 hours ago
fishtoaster 2 hours ago
There's some good ideas and points in here, but this bit threw me:
> # 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.
tcoff91 an hour ago
Opus 4.5 was a massive step change in capability for sure. The opinions of anyone who hasn't bothered experimenting with these things post-Opus-4.5 are not worth a damn.
They still are far from perfect but they're massively helpful.
json_hero an hour ago
2001zhaozhao 2 hours ago
I had a bit of this impression when reading the post as well as the authors' product website. A lot of it does seem to be stuck in 2025.
For instance I think their post "long-context isn't the answer" on their website post straight-up isn't accurate, and gives me the impression they are just extrapolating previous performance to new models. In my experience, Opus 4.6 and newer have worked very reliably for long context to me (i don't perceive any intelligence drop at 700-900K tokens). Yeah it's extremely cost-inefficient, but it works.
dhorthy an hour ago
i think in high context windows you can keep high coherence if you only care about what's happened recently, but a coding agent that receives an instruction at 100k token mark and then doesn't act on it will be very unlikely to recall that instructions 500k tokens later
i think the core idea is not that you can't get decent results at long context, but that you will get better results if you mind your context window
i tried to highlight this in the post but essentially if you're trying to solve hard problems in complex codebases, you want to extract maximum intelligence from the model, which usually
dhorthy an hour ago
my perhaps controversial take is that opus 4.1 was smarter than 4.5 for complex engineering work, but 4.5 was faster and "squishier" - it responded better to simpler prompts, it read between the lines of user input better, and that this was really important to converting new users quickly
json_hero an hour ago
Did you even read further on? The section right after that addresses the step changes in current frontier models https://github.com/humanlayer/advanced-context-engineering-f...
dhorthy a minute ago
it is absolutely wild to me that this keeps floating to top comment thread when the guy very clearly did not read even the first half
rglynn 2 hours ago
To me, the thing that stands out about the whole state we're in here is PR review.
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.
4lx87 2 hours ago
Gating integration behind code review is futile. I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.
I think all these platforms chasing code review are doomed. My LLM doesn't need any of this tooling.
We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code).
The future of software production is more like Replit – not GitHub.
tripleee an hour ago
What's your job as an "engineer" in this post-automated world?
QA?
roncesvalles 6 minutes ago
4lx87 an hour ago
20k an hour ago
>I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.
This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant
The reason for human code review is:
1. So *you* understand what's going on, not the LLM, and people can ask you questions about it
2. Because LLMs are not that good at code review
It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?
dhorthy an hour ago
amannm an hour ago
0xblacklight 29 minutes ago
tcoff91 an hour ago
PRs sucked to review long before Agents were a thing, but now it really sucks because there are more to review.
xorcist 2 hours ago
> group file changes together based on theme, add some commentary
Isn't that what commits are? Or ... should be?
boron1006 an hour ago
I just dont think LLMs are very good at judging importance or summarizing code.
I tried experimenting with what is ultimately a treesitter based approach - https://github.com/0x007BA7/codebook
And really liked it. Definitely nowhere near production ready but I think theres room for a player to come in and do something similar.
dhorthy an hour ago
yeah that was another thing i hoped would pour through here - that deterministic systems are much better for evaluating quality (test, linters, cyclomatic complexity, etc) - but that we don't have such a system for code maintainability, at least not one that's widely accepted or adopted
claytonjy 27 minutes ago
thanks for pointing out the linear PR stuff, hadn’t seen that. Interesting that while a dozen other companies are trying to muscle in on the hosting/versioning side of github, rather fewer are working on the PR side.
2001zhaozhao 2 hours ago
I think the right shape is to review and merge directly from the agent window.
0xblacklight 28 minutes ago
reviewing code as it's being written & re-steering it > reviewing it once 20k lines have been written
WorldMaker an hour ago
> 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.
When $EDITOR = VSCode there's a shortcut on the GitHub PR page: if you type a . it opens in github.dev in a VSCode instance.
zingar 11 minutes ago
Enjoyed most of this but unconvinced by the program design part. If I see an agent writing function signatures or listing which functions to edit in a plan that tells me that I’ve given it too big a vertical slice. I always delete the code guesses. The thing that writes the code must always spend some time discovering where/what to write or it won’t have the right context. Or put another way: “decide first, act later” always feels worse than act-learn-act.
dhorthy 5 minutes ago
one thing I probably didn't mention is we do the program design having already done an in-depth codebase research, with current patterns and architecture surfaced - that actually seeds every step of the flow including even the product part -
but yes if you're working in very small slices then I think it's very feasible to skip program design and just review the code as you go, and resteer live. I do this all the time for tasks that are too big for a oneshot but on the smaller side overall.
firasd an hour ago
I think there is a fundamental issue here of what building software even means
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
claytonjy 20 minutes ago
> There are 'points of view' that emerge during coding
I know it’s a bit cliche at this point, but this harkens to “programming as theory building”[0] which I agree is easy to lose out on when embracing agentic coding today.
dhorthy 16 minutes ago
I have had the phrase "programming is building a theory" spinning in my head for days, especially since watching this pragmatic engineer pod with Kent Beck https://www.youtube.com/watch?v=ddHQQtjIOpw
dhorthy an hour ago
yeah I 100% agree - and I think the most popular coding agent workflows / skill kits are designed to pull those insights and intuition out of humans in a way that optimizes for the developer's experience building the plans or building the code, e.g.
- claude code plan mode - mattpocock/skills - obra/superpowers - research/plan/implement
etc etc
piker an hour ago
Hard to see them though if you’re not in the weeds and your agents are stacking abstraction on abstraction to pass tests.
dhorthy an hour ago
AmericanOP 24 minutes ago
The machine gives you what you ask for even when that thing doesn’t exist yet.
Rather than “lights off,” utilizing information theory, decision-making theory and creativity theory makes me better at asking for the right things.
Memory is not transcribed to weights like when humans sleep. Memory is notes handed to someone on groundhog’s day who can’t remember yesterday. We hope they believe us. Don’t be too surprised when a highly entropic system introduces entropy to a project over time.
jadar an hour ago
> So, why can't models do software maintainability?
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.)
Fordec an hour ago
I have a hunch it comes down to the training data. We have spent decades as an industry talking up the new shiny thing, deliverables, frameworks, features, performance improvements, the one thing you don't read copious amounts of prose about is "how I maintained our system so that nobody noticed".
dhorthy an hour ago
fair point, this is the thing I struggled most to extract out while writing it - if you can propose an RL environment that penalizes a model for bad design, then I'm all ears - right now there's no fast oracle/verifier for this (as stated in the post)
My current evolving take on "how would you build such a thing" is you need to tee up a roadmap of 20 features and feed them to a model one at a time, so it can't design up front for what's coming.
That way if it builds the first 10 features and the codebase goes to slop, it get's penalized when it can't build features 11-20, or when those features take wayyy more tokens/time/cycles than a model that maintains a clean codebase can do.
This is how most real software is built by most teams - incrementally, getting feedback from users along the way, and steering goals in response.
Robdel12 7 minutes ago
I 100% whole heartily agree with this. Anyone saying the models made a huge leap in fall 2025 / spring 2026 still aren't looking at whats going on. Just this weekend I thought I had a solid plan and evals/tests to let 5.6 sol work unsupervised over night while I slept and it made an absolute mess. Somewhere in the loop it had to make a decision and it made a wrong one. Making everything beyond that trash. The code 'worked' but it had the wrong system design and wrote the most brittle tests around its assumption, validating its own decision. It turned into a nasty feedback loop for the model. This is 5.6 sol high.
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.
dhorthy 3 minutes ago
> I spent a week or so and like a billion+ tokens trying to refactor and save it. It just wasn't worth it.
this is exactly what happened to github.com/humanlayer/humanlayer - it was overslopped and we reset from scratch to build it right - spent 2 weeks in VS CODE - not even cursor, plumbing the core patterns from scratch. codebase is part of the prompt, yada yada
> I wish people would be pragmatic about this
that might be the tl;dr for the whole post haha
vanuatu 2 hours ago
This is one of the best writeups I've seen of this
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)
dhorthy an hour ago
yeah i like this and others in the thread mentioned that understanding RL and RLHF and the shape of the data is really important (at least the fundamentals, I'm sure there's quite complex industrialization of RL inside labs as Nathan Lambert says)
mrbnprck an hour ago
I've recently started experimenting with grounding LLM driven implementation/verification on RFC based normative specifications, to avoid having to manually steer the LLM during implementation and dealing with reviewing sloppy pull requests.
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.
Lindby an hour ago
But do you actually gain anything if you need to write detailed specifications? That seems just as time consuming as writing code, but less gratifying.
Code is just detailed specifications on how things should operate.
mrbnprck an hour ago
Yes, actually that's what I'd had argued a few years ago as well.
It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.
As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.
Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.
dhorthy an hour ago
normative specifications can help, but the thesis here is that specs that define behavior of the product or even architecture are helpful but there's MORE that can be done and even though "program design" feels too in the weeds it's still essential if you care about maintainability
mrbnprck 30 minutes ago
Isn't maintainability mostly about applying basic engineering principles e.g. separation of concerns, single responsibility, dependency inversion, open-closed etc..? If these topics are addressed in the normative representation, and correctly translated by an LLM into code (especially by slicing up the specifications into measurable outcomes to set the intended foundation), then future change e.g. maintainability becomes essentially easy as well, no?
Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.
dhorthy 25 minutes ago
2001zhaozhao 2 hours ago
> When I say maintainability, I mean the specific thing where it becomes really, really hard to change one part of the codebase without breaking another part.
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.
throwatdem12311 an hour ago
Until you inevitably need a cross cutting concern.
“Oh just this one time”
Then an agent sees the pattern and assumes it’s a best practice. Then your beautiful architecture is ruined.
“Just this once” indeed.
dhorthy 37 minutes ago
this is 100% right. you have to guard the codebase patterns with your life. because the codebase is part of the prompt.
dhorthy an hour ago
yeah this is along the lines of what some friends of mine call "core vs. pragmatic modules" or even s/modules/codebase zones/
the idea that if you have a solid core and decoupled modules, you can have "zones" in your codebase where you allow the model to run wild and do a little slop, because you know the blast radius is contained
d_silin an hour ago
My radical opinion is that LLMs are harmful for software development - they are the ultimate "goto" operator. All actual code should be written by a human developer.
Instead, use them in adversarial mode - run QA scenarios using LLM agent as a substitute for end user to do bug discovery.
arm32 37 minutes ago
I love how we need to preface such an opinion as being "radical" nowadays.
0xblacklight 31 minutes ago
why?
sergiotapia 7 minutes ago
Personal anecdote: I was able to set things up in such a way that multiple non technical people at my job were able to build features into our project. One person even created our own CRM. And I'm not a turbo-genius savant.
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.
vkaku 2 hours ago
Necessarily, better data is what we need, more importantly, better collaboration and better specialization at all. While the title is a bit misleading and clickbait-y, the message is decent.
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.
ozhero an hour ago
This is a very well written article and he makes his arguments backed up by data.
We may choose to disagree but thats the point of healthy debate based on clearly expressed opinions.
Key point is I don't think this is AI slop which is way too common in long form articles these days and in keeping with the whole point of his article.
rapatel0 27 minutes ago
The dude is selling an IDE.
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.
dhorthy 8 minutes ago
and build it incrementally!
You don't have to build the entire software factory at once. You don't have to mastermind the whole future system, instead you're actually stacking and layering these small, isolated problems.
I think that's a really good approach to start getting value tomorrow or this week without saying, "I'm going to revolutionize how we ship."
It's just:
1. Find places where you can use agents.
2. Figure out where the right leverage points are for humans and where the right leverage points are for agents.
3. Just start building those things and plugging them into each other.
One day you'll wake up, and 80% of all of your stuff is automated.
AIorNot 2 hours ago
Wait these arent “software factories” they are strung together ai rube goldburg machines
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
dhorthy an hour ago
interesting - i'd say my main goal is to put the current "agentic software factory" hype in the historical context of "we've actually been rube-goldberging software deploys for a while now"
_doctor_love 2 hours ago
> I haven't been able to dig up any definitive data/findings from StrongDM on how that whole dark factory went. The weather-report has a few sparse updates between February and June of this year.
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.
edot 2 hours ago
“Seems like it went pretty well if a consulting company is now being started.”
You interpreted this backwards. Software companies offer consulting when their product cannot stand on its own. See Palantir, Salesforce, etc.
They are successful companies, yes, but not successful products. The product needs to be instantiated and maintained by sales engineers and consultants and customized into something so bespoke that it’s hardly the company’s product anymore.
jaytaylor 35 minutes ago
Hi, I'm one of the trio from the StrongDM AI Lab.
Just a minor thing I want to clarify about the Weather Report [1] - it's framed in kind of a negative light in the article ("sparse updates"), but we've been updating it as frequently as we find a meaningful improvement in a relevant dimension. Since we launched it in February it has averaged about one update per month, as frontier labs keep racing forward!
dhorthy 33 minutes ago
appreciate that context! I definitely did not mean to come out and say "its definitely not working" or anything, but would love to hear from y'all a retrospective on the ~5-6 month anniversary - what was right, what did we get wrong, etc
jaytaylor 9 minutes ago
stellar_jay 2 hours ago
> 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.
I found this to be exactly right, and in my work I’ve come up with a taxonomy of constraint mechanisms which I keep in mind when guiding agents: generative to constrain the output of the model, interpretive to constrain how the model ‘understands’ code, and elicitative to help it ask the right questions of users.
Full write up is here: https://www.research.autodesk.com/blog/constrain-agent-not-u...
_doctor_love an hour ago
That's an excellent writeup. Haven't gotten all the way through it yet but so far I'm with you.
sythe2o0 2 hours ago
Some more context on the consulting company: StrongDM was sold earlier this year, about a year after the dark factory was first announced, and the former CTO moved on to this (presumably) in order to continue the idea.
Disclaimer: I'm a former StrongDM employee
navanchauhan 35 minutes ago
apg?
dhorthy 41 minutes ago
> 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.
hard agree. But i don't think this is sufficient. Even formal verification has its limitations.
> 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.
hard agree. but also RL data is shaped differently than SFT data that has driven the majority of AI/ML innovations since ~2000, and its where there's so much room for innovation still. e.g. ImageNet was all just hand-labeled answer pairs.
> it's not a skill issue, it's an effort/laziness/rigor issue
I'm sorry but this feels like a semantic argument - the point of "skill issue" is "you didn't put in the effort or learn the techniques"
syndacks 2 hours ago
Dex you aren't part of the slop cannon, you _are_ the slop cannon
dhorthy an hour ago
i can't tell if this is a compliment or not
M4R5H4LL 2 hours ago
[flagged]
dang 2 hours ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
(and please particularly avoid personal attacks on this site)