Live data from Hacker News

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

github.com

201–210 of 296 posts

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

#201
post #179

Earlier quoted context omitted.

You either need to quit or keep your head down, I can’t tell which.

If you need to actively keep your head down, you need to quit. Doesn’t matter whether ‘the problem’ is the employer, the employee, both, or neither. They’re a bad fit for each other.

Keep your head down, while you look for alternatives. No need to pre-emptively quit, if you can coast and collect a paycheck.

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

#202

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 be…

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 conte…

> Yeah it's extremely cost-inefficient, but it works.

And competition is fixing that as we speak.

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

#205
post #8

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…

I'm not sure how the best teams do PR review..

They don't do them. They discuss the changes as the team are doing them (software design and architecture), they automate all the things that would be nitpicks (linting, formatting, etc), and they adhere to a strict 'Do not break the build' rule so merging in something can't be disastrous (with a lot of automated checks and tests to prove that's true). They also make sure there's a robust rollback process just in case.

Once you do all that the PR process is pointless. It never catches anything useful. The team can trust one another to merge without that gate.

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

#206

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 be…

I just listened to a podcast last week with the author (Dex Horthy) on as the guest. Humanlayer (his company) is constantly trying to push the limits with agents and he's very into using them.

He's well aware of exactly how good the models are today and I'm sure that if he thought they were good enough now to make the dark factory idea work, they'd be trying again.

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

#207

I call it the Intent-Implement-Quality problem. 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 inten…

[dead]

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

#208
post #152

Earlier quoted context omitted.

It's even worse: Customer says I want X! One or more of the following can be true: - Customer really wants X - Customer doesnt actually need X at all - Customer wants Y not X but couldnt express himself - Customer B and C do NOT want X at all - Customer is just messing with you for no reason

Also quite common for me is like someone says X is good (usually a PM) but common sense says it's crap, and when you actually ask the user they also say it's crap. If only LLMs could email a bunch of people for second opinions.

Or fire the PM?

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

#209

I call it the Intent-Implement-Quality problem. 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 inten…

[flagged]

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

#210
post #21
post #8

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…

PRs sucked to review long before Agents were a thing, but now it really sucks because there are more to review.

Like you said, they sucked back then but it was more rare to get PRs of many thousand lines to review multiple times a day in my experience. But I also run into a problem now in which I have coworkers in two camps. There are some that, when they send me a PR and I have serious concerns about it, it's because they disagree with me fundamentally on some concept and we need to chat and discuss it. And then there's some coworkers who send me with a PR I have serious concerns about because it's very clear they never reviewed the LLM output before making a PR. Those people also tend to take my comments, run them against their LLM session, and slack me back some Claude list-of-questions stuff, and often also respond to me with LLMese.

I firmly believe there's no reason to employ the latter group. I have several coworkers like this that I could replace with a Claude session or two every week and I'd still have to push back on work and review a lot, but I'd still wind up saving time because then I'd talk directly to Claude.

So I guess my point is that I dislike AI era code review because for some subset of it, I basically can't even assume a human has ever looked at it, and that by doing so, I'm doing the work for one of my coworkers who is probably doing his grocery shopping at 2PM as I read it.

Post reply on HN