Is it still useful to let AI do the Git maintenance?

Friday afternoon question, so feel free to answer it with a beer in hand 🍻

Something we notice more and more: AI is taking over the Git side of the work. Claude Code writes the change, creates a branch, commits, pushes and opens the PR. Over the past months that part has quietly moved out of my hands.

Human in the loop still matters, especially around pull requests. That is where I want a person to look at what is about to be merged. At the same time I check fewer and fewer individual files. The review is moving up a level, towards the change as a whole 🤖

Which brings me to the question I keep circling back to. An agent spends tokens creating a branch, then commits to it, pushes it and merges it back into main. On a small change that whole cycle is close to a formality, and every step of it costs another prompt.

Worktrees are the one place where the branching clearly pays off for me. Running two agents in parallel, each in its own worktree, keeps them out of each other's way 🌳 The single small change on its own branch is where I start doubting.

So I am curious how others handle this:

  • Do you still let the agent do the branch, commit, push and merge, or have you moved that into a script or a hook so the model never touches it?
  • Does a branching strategy like GitFlow or trunk-based still earn its keep when the commits come from an agent?
  • And how do you keep the PR a real review moment once nobody reads every file anymore?

Curious what you have settled on 😄

Tags:
AI Software development

Answers

An agent spends tokens creating a branch, then commits to it, pushes it and merges it back into main. On a small change that whole cycle is close to a formality, and every step of it costs another prompt.

Agreed. But the PR review process, for me, was always about multiple things. Some are less relevant now, but not all of them.

  1. A learning opportunity. Developers can review code, ask questions, see how to scope a feature improvement or bugfix.
    I think this still applies, but I was always a fan of collaboration and learning earlier than the PR.
  2. A code quality gate. Teams review PRs to ensure the project doesn't begin to diverge from the standards and requirements they agreed on.
    This has been largely addressed by AI agents. Assuming the codebase is in good shape, has maintained documentation, and the agentic development tools (e.g. skills) leverage the standards and requirements, the code should arrive in the PR already meeting the quality bar.
  3. A bug or regression firewall. Someone looks at the code or runs it locally to validate it behaves as expected, that those expectations are right, and that the change didn't introduce a regression.
    As developers and product managers overlap more, developers might try a branch's code locally to see if it meets their UX and taste expectations, so this scenario still applies. However, I think the testing part can and should be largely handled by AI authored test automation. For Xperience projects, I think E2E tests are the right place to invest.

For teams that want to automate the low-level technicalities of software development, using a PR and CI pipeline run to execute E2E tests is key to moving quickly and with confidence, so the branch > commit > PR process still provides a lot of value in keeping your project bug free and deployable.

  • Do you still let the agent do the branch, commit, push and merge, or have you moved that into a script or a hook so the model never touches it?

Yes, I use agents to branch, commit, push, and use a skill to ensure the PR description is as useful as possible to humans and agents.

Depending on the task, I might instruct the agent to do these things or it might do them itself.

  • Does a branching strategy like GitFlow or trunk-based still earn its keep when the commits come from an agent?

I never liked GitFlow - I first used it over 10 years ago and our team always saw giant long lived feature branches that were painful to merge, review, and keep regression free. I've stuck with trunk-based development since then, focusing on merging well scoped updates, faster.

  • And how do you keep the PR a real review moment once nobody reads every file anymore?

It's less of a mandatory "lead dev reviews every line" gate the way it used to be. I rely more on:

  • Automated tests running on a "deployed" instance of the app (deployed within the CI pipeline) to model non-local environments as well as possible
  • AI assisted reviews of the PR (using a different model than the one that generated the code)
  • Prioritize rolling-forward over rolling-back when the bugs inevitably appear. I try to keep the project always deployable and deploy often so it's "just another weekday deployment" vs "we haven't done this in 4 months, and everyone's scared to push the button".

Happy Friday! No beer in hand for me, but I love this topic.

I feel Claude Code is the best and the worst tool for operational tasks😀Ideally you'd want to use something like Haiku for clear, structured processes like that, but between convenience and a lack of built-in router, I have definitely had my share of Opus High Effort Git operations. At the same time, since it's the 5h usage windows for our plan it usually makes no difference.

Over the past year, we've also had to question some of our development practices (we don't YOLO commit code, don't worry), and also question the purpose and scope of a code review. It's still a real review for us, but it has definitely evolved.

I have a few takeaways:

  • Our commit messages have massively improved. You won't find a "fixes" commit message, and our PR templates are always filled in nicely.
  • I've had merge conflicts a few times (🫣) and I can't believe how easy they were to resolve with agents.
  • A few developers are really against agents doing the git operations as they feel they lose ownership and they let agents drive a critical part of the system. I have a different view on this personally, but I completely understand where they're coming from.
  • The human PR review is potentially the wrong place to reinforce quality, but a really good place to reinforce ownership. Humans will miss things, it happens. We're implementing more automated checks for each PR, and the human's job is to essentially say "Yes I'm confident in owning these changes".
  • We had this thought exercise: "How far are we from reviewing plans & prompts instead of the outputs." The answer for us was "far from that." Unless the change is small enough that it almost doesn't matter if a human reviews it, you will probably not be able to consider every aspect of the implementation before the implementation happens 🤔

I think there's an "agentic Git" waiting to happen, and I'm really curious how the SDLC evolves. Even if Git remains mostly unchanged, I can imagine a near future where I'm building the same feature 3x or 5x and the PR review is about easily reviewing the best solution and cherry picking the parts we like from each into my merge commit.

At the very least I'm glad agents made the full Git feature suite way more accessible.

To response this discussion, you have to login first.