i felt this. My majority of time correcting claude is making it stop the stupid verbose doc comments which are completely contemporary. I can add skills/memories and claude.md hints that i want, but every time it continues with those unnecessary doc comments of 5+ lines explaining some situation which should definitely not be in a doc comment.
Stop sending me huge PRs; a rant
101–110 of 116 posts
Re: Stop sending me huge PRs; a rant
#102In my experience the models perform substantially worse if asked to create small PRs or commits. They lack the ability to sequence work and understand dependencies efficiently enough to manage it – it's not that they can't do small PRs, it's that doing them takes vastly more resources which then hits context limits etc. And if you want to then go back and edit a stack of commits or PRs, rebasing work into the middle,…
I have had some success with asking the LLM to rewrite the commit history after the feature was written. I often have a good idea of a good conceptual split, and the LLM has no problem doing the soul-crushing work of manually pulling out individual files or hunks into a sequence of commits and making sure each builds. I need to do this before I can even review the code myself, and I review everything before I send it…
the even more soul crushing thing is to get the agent/claude to think in this atomic commits kind of thing. It just doesn't. At least opus doesn't IME. can you force it to do it after the fact, sure, still soul crushing to nudge it that way. Also it F's up branch-on-branch development style. I had to tell claude to use `git rebase --rebase-merges --update-branches`, add skills or memories you want, the hit ratio is abysmal.
I have this issue more often, if you want Claude to get off the beaten path, because you reallllly know a better way, memories just don't hit. In this case the agent instructions on how to get along with git is just too burnt into the agent it seems.
Re: Stop sending me huge PRs; a rant
#103Earlier quoted context omitted.
I like this comment. I also have a lot of experience with lazy (my accusation!) reviewers who ask me to split a PR into smaller PRs. At some jobs, I felt like it was a strategy to sabotage my work (slow me down). In my experience, the best was to ensure your code will be approved (ok, maybe some minor tweaks) is to assign a code reviewer before you start writing code. You (the coder) performs some quick analysis, the…
Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers. The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
> It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
Re: Stop sending me huge PRs; a rant
#104I know someone working on a smaller open source who has same thing. They have considered just blocking all PRs outside known contributors because AI spam even on their tiny open source project is too much. At work, I've gotten into fights about PR approvals. If they are beyond us humans to review, screw it, remove the approver requirement and if CI passes, merge it.
> If they are beyond us humans to review, screw it, remove the approver requirement and if CI passes, merge it. Approvals are probably required by SOC 2 or other compliance requirements.
Yes, it’s compliance that forces the behavior. Another reason SOC2 is mostly worthless.
Re: Stop sending me huge PRs; a rant
#105Re: Stop sending me huge PRs; a rant
#106Earlier quoted context omitted.
Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers. The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
"There's no trust or reputation in OSS" is a pretty interesting take.
What I'm trying to get at is if a PR comes in that looks decent at a glance, well in the past that was a strong signal and now it's not. But you can fall back on the relationship you have with the author. Trust , reputation. In OSS often you have no relationship with the author (of course ex established contributors or people who have well established public reputation). Whereas in a typical workplace you will quickly establish a relationship with those you work with
Re: Stop sending me huge PRs; a rant
#107Earlier quoted context omitted.
Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers. The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.
> It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic. Have you heard about Linus Torvald's opinion about using AI/LLMs for Linux kernel patches? He seems quite open-minded about it. Roughly: "It is a useful tool."
Yes I think his stance works well for established contributors who have a reputation. For infrequent contributors, with no rep, it's a large liability to try to figure out if their plausible-at-a-glance work is actually slop. Such a liability with uncertain ROI hence the sentiment in OSS frequently banning or at least heavily policing AI usage
Re: Stop sending me huge PRs; a rant
#108This to me reads less as there being some objective level when a PR becomes "huge" and more about the tension between a system's ability to absorb change vs. our tools' ability to create change.
By way of analogy consider the relative impact on an ecosystem of one person fishing with a fishing line vs. a commercial fishing boat trawling the ocean. Of course, one person fishing is unlikely to have a huge impact on the ocean so it's generally permitted. Trawling (agentic coding) can be done in a way that's destructive to ecosystems but it can also be done sustainably!
So with the analogy in mind let's bring back the "sensible trawling" idea to agentic coding. What might it look like to solve the "huge PR bad" constraint in another way: by increasing our codebases' ability to absorb change, so what "a huge PR" is, becomes bigger?
Probably needs solves at many levels: assistance quickly comprehending the PR (AI driven walkthroughs, multiple media expected from the PR submitter not just text - eg. a screencast walkthrough of it), it requires rethinking how the code is read (better review tooling); it requires integrations with code-review automation tools (both you home-grown checklist and third-party tools) it requires rigorous testing (comprehensive automated e2e; test-driven; functional tests; etc); it requires putting the actual "in the loop" so post-release fast-follows can be expedited (eg. product signals and Sentry and metric anomalies are fed back in for quick follow up releases)
If you can be so much more responsive to the customer and market. Eg. you can unlaunch features just as easily as you launched them - and you can finally clean up all that tech debt. Better for the business better for the codebase and better for developer happiness.
Not all these strategies work for every situation - you can't do post-release in the loop if the shit needs to work first time! But the whole idea creates so much richness in applying human judgment and engineering solutions and it's all brand new because we never needed to deal with this much change before
Think of it as "releases in the loop".
If opportunities to rethink the stack to support MORE change excite you, congratulations! You're ready for the future that's coming. If you don't like this - get yourself into a job where you can say no a lot, or where shit needs to work first time, and you can be happy. Test-driven, strongly reviewed.. there's ways with agentic coding to also make super high quality stuff. But you can also shoot product from the hip more accurately and more often than ever before.
It won't be applied correctly everywhere - it's still heavily judgmental dependent and we're all fallible - but there'll be a much wider spectrum of options for how to build products. I think this is a really exciting future!
Re: Stop sending me huge PRs; a rant
#109In my experience the models perform substantially worse if asked to create small PRs or commits. They lack the ability to sequence work and understand dependencies efficiently enough to manage it – it's not that they can't do small PRs, it's that doing them takes vastly more resources which then hits context limits etc. And if you want to then go back and edit a stack of commits or PRs, rebasing work into the middle,…
> In my opinion, if you can't do these things, you're just cosplaying software engineering.
This standard would significantly reduce the number of software engineers I've worked with.
Not that I'm saying you're wrong about this; it was obvious even during my degree that "software engineers" were trying to have their cake and eat it with regards being counted as "being an engineer" without any of the real responsibility if the code you wrote was dangerously bad. Case study we went over at the time being https://en.wikipedia.org/wiki/LASCAD
Re: Stop sending me huge PRs; a rant
#110I recently started stacking my PRs, makes life easier https://docs.github.com/en/pull-requests/how-tos/stacked-pul...
LLMs will still produce huge PRs even in a stack if you are not careful enough.