In 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, that's even more. I don't think any of this scales linearly in the amount of code or number of commits.
This is all in addition to the fact that the models are generally poor at storytelling, because that requires a theory of mind of the person you're communicating with. Authoring for review is storytelling, it's making changes in such a way as to build confidence in the reviewer. I believe current LLMs are still years away from this.
In my opinion, if you can't do these things, you're just cosplaying software engineering. Vibe coding has its uses, as does LLM programming, I do a lot of this! But we're kidding ourselves and dropping our standards dangerously low if we think that this is software engineering.
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 to my colleagues for their review.
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.
I think LLMs are actually great at breaking up work into workstreams and tasks. The issue is that tasks do not equal good PR stacks on their own. You’ll need to use feature slices instead (like do backend part -> PR it, etc). LLMs can do that, but you need to harness them into it.
I've had no trouble getting small PRs. No idea if I'm doing something different than you or the things I asked for just happened to be small. Next time I get a big one I'll consider trying to ask the AI to break it up after it's finished.
Most professional software developers (probably including you) never do any work that could legitimately be described as engineering. And that's fine because most software isn't very important anyway. There's very little software that requires true engineering practices. The exceptions are in domains like avionics and medical devices.
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
I mean, sometimes I don’t know how I want to write something until I’m finished. Huge refactors are often like this.
So, just like you said, rewrite the whole thing, THEN break it apart into bite size chunks that tell the story and feed it to others with acceptable and reasonable context.
It’s a skill that engineers need, and it pays dividends to all on the team, including you, when your coworkers ALSO start doing this back to you and you’re asked to review it.
This is exactly how I have always worked. I personally don't operate well breaking things up into small, bite sized PRs like people want. So instead I do the whole big project, and then break it apart into logical segments for my colleagues.
And this is often how I proceed when working with an LLM as well. We build the whole thing, and if I think it needs to be split apart, then in another session I work with the LLM to break it apart into reasonable chunks.
sometimes I don’t know how I want to write something until I’m finished
This is knowledge that goes back to the beginning of software development - "Plan to throw [version] one away".
I think this could potentially become a good practice. LLMs make it so easy and cheap to just get it working and build that v1. Then you can play around with it and see if works and read the code about what could be better. Throw away the LLM generated version and now this is the part where human expertise comes in. Based on what you've learned from the v1, now guide the LLM more closely about how to write the thing and help guide it so that making small PRs that are easily reviewable and understandable are the output.
Yes, totally. This is how I work as well! Frankly, it seems like LLMs are pretty good if you tell them after the fact to divide work like this too, "make stacked prs with model a, then model b, then service c" has done wonders for my mental health.
I have a completely different experience than you, but I have also invested quite a bit of effort into the issue. I will agree that with simple prompting and without reminders, models do not do this sort of thing well or consistently. On the other hand I have two skills that I use regularly `/atomic-commits` and `/split-branch` that do exactly what you're describing. It has been an exercise in taking the time to put to words the concepts you're describing, which has been very interesting because it's forced me to put to words many thoughts on the subject I had never formalized, and you're correct, there's a lot of theory of mind and considering of other people's perspectives that go into it.
* Does the series of commits tell a cohesive story of the feature, each commit building on the last one? It's surprisingly easy to have an ordering of commits where each one builds, but the ordering is nonsense.
* Is each commit scoped to the right size? Not too big of course, describes a single idea or concept. That same rule can also lead to commits that are comically small or separates two changes that can obviously be argued are "two different things" but that make more sense when seen together as a single conceptual change.
* When is it appropriate to split up disparate changes within a single file, interwoven together, and how to correctly orchestrate that with git commands.
I care _deeply_ about commit hygiene and presentation because it's a foundation for making code review a smooth process and in the Before Times™ I would spend a _substantial_ amount of time reworking my own commits to ensure they were up to my own standards. I can count on two hands the number of commits I've authored on my own in the last year, and the process is immediately replicated and standardized across our entire engineering organization.
It is perfect 100% of the time? No, every once in a while I'll hit some weird case and need to issue some corrective instructions, or more likely ask the model why things are like that to see if there's tuning we need to do.
Commits are effectively like automated code-formatting now. This isn't years in the future, this is already _old news_.
I've also had a ton of luck getting agents to make focused, (mostly) well crafted commits using my home-grown git-based task manager: https://github.com/chiefnoah/tsk
It's very easy to be like: /tsk <big prompt> . Break down the problem into focused tasks using tsk, include all context necessary to complete a task in the tasks body, then prioritize them. Then begin working on them in priority order until complete.
Works 9/10 for me, though I often split up the instructions a bit so I have time to review the resulting tasks/design. tsk itself encourages creating single commits per task because it tracks the commit a task is closed on and the agents are pretty good about doing that.
Agreed. Asking for small PRs or commits can backfire, unless the work is deliberately scoped into smaller pieces from the beginning. This requires a human design review and planning and is one of the reasons I don't outsource that part to an agent.
I can't be happier seeing how many posts are about AI making PR terrorists unhappy. They can no longer bully their teammates so they rant about it here
Comments
In 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, that's even more. I don't think any of this scales linearly in the amount of code or number of commits.
This is all in addition to the fact that the models are generally poor at storytelling, because that requires a theory of mind of the person you're communicating with. Authoring for review is storytelling, it's making changes in such a way as to build confidence in the reviewer. I believe current LLMs are still years away from this.
In my opinion, if you can't do these things, you're just cosplaying software engineering. Vibe coding has its uses, as does LLM programming, I do a lot of this! But we're kidding ourselves and dropping our standards dangerously low if we think that this is software engineering.
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 to my colleagues for their review.
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.
But the thin is that de dev don't review the generated code ... because, surely, that's the reviewer's job ... right ? /s
I think LLMs are actually great at breaking up work into workstreams and tasks. The issue is that tasks do not equal good PR stacks on their own. You’ll need to use feature slices instead (like do backend part -> PR it, etc). LLMs can do that, but you need to harness them into it.
I've had _some_ success by asking Codex write a full plan, broken up in to logical phases, complete with git commit points along the way.
It's probably not quite how I would approach doing git commits, but they're at least logical boundaries, and make narrative sense for a reviewer.
I've had no trouble getting small PRs. No idea if I'm doing something different than you or the things I asked for just happened to be small. Next time I get a big one I'll consider trying to ask the AI to break it up after it's finished.
A human should be able to take the work and break it up properly during rework though.
Most professional software developers (probably including you) never do any work that could legitimately be described as engineering. And that's fine because most software isn't very important anyway. There's very little software that requires true engineering practices. The exceptions are in domains like avionics and medical devices.
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
I mean, sometimes I don’t know how I want to write something until I’m finished. Huge refactors are often like this.
So, just like you said, rewrite the whole thing, THEN break it apart into bite size chunks that tell the story and feed it to others with acceptable and reasonable context.
It’s a skill that engineers need, and it pays dividends to all on the team, including you, when your coworkers ALSO start doing this back to you and you’re asked to review it.
This is exactly how I have always worked. I personally don't operate well breaking things up into small, bite sized PRs like people want. So instead I do the whole big project, and then break it apart into logical segments for my colleagues.
And this is often how I proceed when working with an LLM as well. We build the whole thing, and if I think it needs to be split apart, then in another session I work with the LLM to break it apart into reasonable chunks.
This is knowledge that goes back to the beginning of software development - "Plan to throw [version] one away".
I think this could potentially become a good practice. LLMs make it so easy and cheap to just get it working and build that v1. Then you can play around with it and see if works and read the code about what could be better. Throw away the LLM generated version and now this is the part where human expertise comes in. Based on what you've learned from the v1, now guide the LLM more closely about how to write the thing and help guide it so that making small PRs that are easily reviewable and understandable are the output.
This is the first time I've heard a use for LLMs that I think might be good.
Yes, totally. This is how I work as well! Frankly, it seems like LLMs are pretty good if you tell them after the fact to divide work like this too, "make stacked prs with model a, then model b, then service c" has done wonders for my mental health.
And then some of the time while breaking it up you realize you should have done it another way.
I have a completely different experience than you, but I have also invested quite a bit of effort into the issue. I will agree that with simple prompting and without reminders, models do not do this sort of thing well or consistently. On the other hand I have two skills that I use regularly `/atomic-commits` and `/split-branch` that do exactly what you're describing. It has been an exercise in taking the time to put to words the concepts you're describing, which has been very interesting because it's forced me to put to words many thoughts on the subject I had never formalized, and you're correct, there's a lot of theory of mind and considering of other people's perspectives that go into it.
* Does the series of commits tell a cohesive story of the feature, each commit building on the last one? It's surprisingly easy to have an ordering of commits where each one builds, but the ordering is nonsense. * Is each commit scoped to the right size? Not too big of course, describes a single idea or concept. That same rule can also lead to commits that are comically small or separates two changes that can obviously be argued are "two different things" but that make more sense when seen together as a single conceptual change. * When is it appropriate to split up disparate changes within a single file, interwoven together, and how to correctly orchestrate that with git commands.
I care _deeply_ about commit hygiene and presentation because it's a foundation for making code review a smooth process and in the Before Times™ I would spend a _substantial_ amount of time reworking my own commits to ensure they were up to my own standards. I can count on two hands the number of commits I've authored on my own in the last year, and the process is immediately replicated and standardized across our entire engineering organization.
It is perfect 100% of the time? No, every once in a while I'll hit some weird case and need to issue some corrective instructions, or more likely ask the model why things are like that to see if there's tuning we need to do.
Commits are effectively like automated code-formatting now. This isn't years in the future, this is already _old news_.
I've also had a ton of luck getting agents to make focused, (mostly) well crafted commits using my home-grown git-based task manager: https://github.com/chiefnoah/tsk
It's very easy to be like: /tsk <big prompt> . Break down the problem into focused tasks using tsk, include all context necessary to complete a task in the tasks body, then prioritize them. Then begin working on them in priority order until complete.
Works 9/10 for me, though I often split up the instructions a bit so I have time to review the resulting tasks/design. tsk itself encourages creating single commits per task because it tracks the commit a task is closed on and the agents are pretty good about doing that.
Agreed. Asking for small PRs or commits can backfire, unless the work is deliberately scoped into smaller pieces from the beginning. This requires a human design review and planning and is one of the reasons I don't outsource that part to an agent.
I can't be happier seeing how many posts are about AI making PR terrorists unhappy. They can no longer bully their teammates so they rant about it here
We've banned this account.
That's just like humans though. Find me a developer that loves maintaining code and I'll show you 10 that love rewrites or greenfield.