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.
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.
lm2s · · 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]