Live data from Hacker News

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

github.com

41–50 of 296 posts

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

#41
post #22
post #18

Earlier quoted context omitted.

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

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

blake smith has a really good post on this - that mental alignment among the team is the primary purpose of code review - https://blakesmith.me/2015/02/09/code-review-essentials-for-...

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

#42
post #22
post #18

Earlier quoted context omitted.

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

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

It seems weird to get angry about a change that is happening and will continue to happen due to what the market demands from software, which I believe will be the speed/ability to solve problems, rather than its own stewardship

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

#43
post #3

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)

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)

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

#45
post #18

Earlier quoted context omitted.

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

What's your job as an "engineer" in this post-automated world? QA?

Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.

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

#46

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…

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...

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

#47
post #19

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…

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.

[deleted]

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

#48
post #19

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…

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.

read. https://github.com/humanlayer/advanced-context-engineering-f...

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

#49
post #37

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

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.

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.

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

#50

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

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.

Post reply on HN