I think your engineering process is fundamentally broken if you are generating PRs with 230 files changed so regularly that you need to bolt on more AI.
You’re solving the wrong problem.
This is bananas. I've seen 25 year old software systems that haven't broken the 100k commits barrier. It feels like that ought to be enough for entire product lifecycles. What's going on that isn't simply wheelspinning?
This happens. I catch claude and codex committing broken code all the time, and then stacking micro fixes on top, still broken. You can go very long if you're in a harness until you realize it's just committing everything. Sometimes if you give it a goal, or a long task, this happens too, every little argument with itself, every finding, adjustment, is a new commit. None of them make sense, they happen anyway. One line nonsensical change, 20 line reassuring comment, committed.
My teammate insists that prompt and "context" engineering solve this. You just have to tell the agent "don't make any mistakes" and "keep it simple" and "don't add fixes on top of already broken code"
Code is there to be read and understood by the human developers who come later.
The git history is a similar record, that's why the commits that make it to main (the squashed PRs) should cover one(ish) thing each and be self contained.
Something covering 230 files should be a mechanical change like running a linter or the AI is moving an API from one signature to another.
If an LLM generated a 230 file change they are also capable of going back and breaking it up.
One thing they are bad at is comments that are succinct since they almost only ever add words.
Sadly, the hype is real and that's what's happening in many places. Businesses are eager to bet on AI cause they'd been promised x100 productivity = fire 99 or 100 devs = huge profit.
I expect one day some slopware will succumb to one of these weird production bugs, no LLM will be able to fix it, and when the biz guys ask me for a fix estimate, I'm going to say "3 years".
I went all in on it about a year ago, and I've gotten the hype out of my system now. It's now officially a love/hate relationship. Like everything else that is a mainstay in my life.
It is inevitable. We (coders) already did it to other engineering disciplines where machines do most of the work, no human could possibly review or understand the actual details, and only verification ensures it is correct.
> no human could possibly review or understand the actual details,
What are you talking about? - The developers understood it.
Did my car manufacturer do something to my discipline because I don't understand my car?
> Code is there to be read and understood by the human developers who come later.
Have you been under a rock in the last two years?? Code is written solely by AI now, and hence it needs to be understood by AI only. Humans can still give some feedback on architecture and high level design to feel important, but even that has its days counted already.
It's funny, because in my experience, the process often looks like:
1. Human gives high-level design.
2. Agent generates wrong code with misleading comments.
3. In further iterations, agent get mislead by said code and comments, ends up generating insane workarounds.
Sadly, I know (major) companies that insist it's the process that needs to be solved, because it improves velocity (for some definition of velocity that involves dropping pretty much all quality gates).
lm2s · · focus · HN ↗
ncruces · · focus · HN ↗
My dev branch got broken when I rebased to main after a week of drift.
I had to bisect over around a million commits to the monorepo to find the culprit.
pjc50 · · focus · HN ↗
figassis · · focus · HN ↗
ianmarcinkowski · · focus · HN ↗
ncruces · · focus · HN ↗
dbalatero · · focus · HN ↗
Thank god bisect is O(log n) at least...
realusername · · focus · HN ↗
stuaxo · · focus · HN ↗
Code is there to be read and understood by the human developers who come later.
The git history is a similar record, that's why the commits that make it to main (the squashed PRs) should cover one(ish) thing each and be self contained.
Something covering 230 files should be a mechanical change like running a linter or the AI is moving an API from one signature to another.
If an LLM generated a 230 file change they are also capable of going back and breaking it up.
One thing they are bad at is comments that are succinct since they almost only ever add words.
[deleted] · · focus · HN ↗
[deleted]
moffkalast · · focus · HN ↗
Tbf, once the codebase is slopped enough that becomes impossible and only LLM can come later.
latentsea · · focus · HN ↗
invader · · focus · HN ↗
I expect one day some slopware will succumb to one of these weird production bugs, no LLM will be able to fix it, and when the biz guys ask me for a fix estimate, I'm going to say "3 years".
latentsea · · focus · HN ↗
munksbeer · · focus · HN ↗
Why do you think coding is immune to this?
discreteevent · · focus · HN ↗
What are you talking about? - The developers understood it. Did my car manufacturer do something to my discipline because I don't understand my car?
munksbeer · · focus · HN ↗
latentsea · · focus · HN ↗
brabel · · focus · HN ↗
Have you been under a rock in the last two years?? Code is written solely by AI now, and hence it needs to be understood by AI only. Humans can still give some feedback on architecture and high level design to feel important, but even that has its days counted already.
Yoric · · focus · HN ↗
1. Human gives high-level design. 2. Agent generates wrong code with misleading comments. 3. In further iterations, agent get mislead by said code and comments, ends up generating insane workarounds.
Yoric · · focus · HN ↗
Sadly, I know (major) companies that insist it's the process that needs to be solved, because it improves velocity (for some definition of velocity that involves dropping pretty much all quality gates).