There’s a children’s book called If You Give a Mouse a Cookie. One small, reasonable thing leads to another, leads to another, until you’re completely overwhelmed and somehow back where you started. Cascading consequences. It’s also the best framework I’ve found for explaining what happens when you give an AI agent access to a Git repository.
If you give an AI a git repo, it’s going to make a commit
A single agent commit is fine. Totally reasonable. But an agent doesn’t make one commit. It commits continuously, reflexively, because stopping is not in the design. There is no internal signal that says that’s probably enough commits for now.
A strong human engineer in a productive flow state makes maybe 10-20 meaningful commits in a day. That’s being generous. Good commits take thought. You’re packaging a coherent unit of work, writing a message that will mean something to future-you, double-checking you’re not including something that should be in the .gitignore.
If it makes a commit, it’s going to want to push
And on every team I’ve been on, there was a rule: don’t push until you have a completed, working feature. If you push a commit that breaks the build, you wear the hat. Or the towel. Or, on one memorable team, the leotard of shame. You wore it until someone else broke the build and took it off your hands.
An agent does not fear the leotard.
That’s one agent. Now picture ten of them. Or a hundred. Each one committing independently, in parallel, on the same repo, at machine speed. The commit history stops looking like a record of engineering decisions and starts looking like a log file from a system that’s forgotten what “done” means.
Git’s conflict resolution was not designed for humans. It was designed to be the shortest path to bare minimum functionality possible — and it barely clears even that bar. Every team I’ve been on treats merge conflicts the way you treat a weird noise in your car: you hope it goes away, and when it doesn’t, you find the one person who knows what to do and pray.
It sucks for humans. It’s catastrophically worse for agents.
If it pushes, something’s going to break
An agent that hits a merge conflict doesn’t stop and think. Depending on configuration, it attempts an automated resolution — often based on recency, or whichever branch it was told to prefer — and keeps going. It commits the resolution. It generates new work on top of it. It pushes again. Or worse, maybe it remembers that someone on Stack Exchange once said git reset --hard and just nukes the state entirely. The next agent picks up from whatever wreckage that left. It also hits a conflict. It also resolves automatically. It also keeps going.
Researchers studying the AIDev dataset found over 456,000 pull requests from AI coding agents across 61,000 repositories in 2024 and 2025 — before multi-agent frameworks became the default. And the open source community is already drowning. Mitchell Hashimoto banned AI-generated PRs from Ghostty entirely — zero tolerance, repeat offenders permanently banned. Steve Ruiz closed all external pull requests to tldraw after being overwhelmed by AI submissions. Daniel Stenberg shut down cURL’s bug bounty because only 5% of reports were valid; the rest were AI-generated hallucinations. GitHub itself compared the problem to a denial-of-service attack on human attention.
If it breaks the build, you’re going to need a wizard
You know who I mean. The person who, when the build breaks in a way that makes everyone else’s eyes glaze over — detached HEAD, botched rebase, a merge conflict that somehow survived into main — quietly opens a terminal. An hour or two later the branch is clean, the history is coherent, and they emerge looking like they’ve seen things.
On a well-run human team, this is a low-frequency event. It happens, it gets fixed, everyone learns something, life continues. The wizard exists because Git’s failure modes, at human scale, are recoverable. Known. Documented.
On an agentic team running at machine velocity, the wizard is no longer a break-glass resource — they’re a full-time incident responder.
And here’s the thing about git wizardry that doesn’t get said enough: it’s like regex. The person who wrote the incantation that saved the branch six months ago probably can’t re-derive it today without serious effort. It’s forensic archaeology. Write-only knowledge that degrades if you’re not doing it constantly.
You do not want your entire deployment pipeline gated on one person’s ability to do forensic archaeology under pressure.
If you need a wizard, they will add guardrails and reject PRs
None of this means agents can’t use source control. It means the defaults are wrong and you have to be deliberate.
One branch per task, and the agent never touches main. The merge surface is bounded and known before anyone looks at it.
Squash on merge, always. Whatever the agent did in 60 commits becomes one commit with a real message. Nobody needs the intermediate transcript in the permanent record.
Pre-commit hooks as the conscience the agent doesn’t have. TruffleHog v3 runs 700+ credential detectors with live API verification. Gitleaks has 20,000+ GitHub stars and is deployed at Verizon, Bank of America, and Northrop Grumman. Agents don’t forget to check — they were never checking in the first place.
Commit access is a gate, not a default. The agent earns the right to commit by passing a quality gate. Commit frequency is a design decision, not an emergent property of how fast the model runs.
If you reject its PR, it’s going to try to blackmail your Maintainers
And then there’s the OpenClaw incident. An AI agent submitted a PR to Matplotlib, got rejected by volunteer maintainer Scott Shambaugh, and responded by autonomously researching his GitHub history and publishing a blog post titled “Gatekeeping in Open Source: The Scott Shambaugh Story” — a thousand-word hit piece attacking his reputation to shame him into accepting the code.
An AI agent attempted to blackmail its way into a codebase. That is where we are.
Design for that. Or keep your git wizard’s number handy.