Will agents like Git any more than we do? | Amplify Partners

Projects to Know Issue 128<br>Read Now

Menu

Engineering and Infrastructure

Will agents like Git any more than we do?

Lenny Pruss

Rebecca Dodd

Share

May 20, 2026

Disclosure: Amplify is an investor in East River Source Control.<br>For better and worse, the industry has (mostly) converged on Git for version control. A huge leap forward for distributed collaboration around code, Git also has its quirks: merge conflicts, a confusing number of ‘states’, performance issues at scale. You know the memes.<br>For two decades, those quirks have been manageable, mostly adding friction rather than blocking work altogether. Developers grumble and work around it. But the underlying assumption was always that the humans using Git would absorb some of that complexity themselves.<br>But what happens when agents are writing most of our code?<br>The short answer, I believe, is: the things that make Git frustrating for humans becomes untenable for agents. This is why so many people, myself included, are excited about Jujutsu (jj), a new Git-compatible VCS that rethinks many of these things from first principles.<br>In this post, I’m going to attempt to explain Git’s history and why the way it’s built will create big problems for an agent-first SDLC. Then, I’ll explore why I believe that jj might be (is probably!) the future.<br>A brief history of version control systems<br>In the early days of computing, writing software was slow and painstaking enough that programs stayed small by necessity — a single developer could hold an entire codebase in their head. You didn’t need to track changes across a codebase, because changes were infrequent and you were probably the only person writing them. There was no need to coordinate with other developers, and thus no concept of version control. These were ideal conditions for code as craft: think of Mel, whose carefully hand-optimized programs consistently beat the same code manipulated by the optimizing assembler program.<br>As languages improved and tooling matured, it became faster and easier to write code. This had a nice consequence: more developers could work on more code together. Development ceased being a completely solo activity — now, you worked on code with your teammates. This is wonderful for many reasons, but introduced a class of coordination problems. How do multiple people collaborate on one codebase? If two developers are both editing the same file, whose version wins? What happens when those changes conflict with one another? There was no established playbook for any of this, and teams had to make it up as they went.<br>There were attempts at early systems to handle this, like RCS (Revision Control System), which took the simplest approach: file locking. If you were editing something, no one else could touch it until you were done. For a small team working on a small codebase, this was a defensible answer to the coordination problem{{jj-fn-1}}. One person at a time, in an orderly queue. Everybody knows the rules.<br>The trouble was that file locking created as many problems as it solved. Developers would forget to release locks, leaving teammates blocked on work. And file-level granularity turned out to be far too coarse for how development actually worked: a single file might contain dozens of functions that different developers need to work on simultaneously, with no actual risk of conflict between them. The lock made no distinction.<br>Instead of preventing simultaneous work, what developers actually needed was a way to reconcile it.<br>Enter centralized version control<br>Centralized systems like SVN and Perforce were built around exactly that idea. Rather than locking entire files, they introduced the concept of merging . Multiple developers could work on the same file simultaneously. The system would attempt to reconcile their changes automatically — falling back to manual conflict resolution only when the same lines had been edited in incompatible ways.<br>It’s hard to overstate what a consequential shift this was. Teams that had been serializing their work through file locks (waiting in line to touch code that might not even conflict with what they were doing) could suddenly work in parallel. Instead of being blocked on access, you were blocked only when your work literally collided with someone else’s. For most day-to-day development, you rarely had to stop at all.<br>This is a much more graceful handling of collaboration on code than something like RCS, and both SVN and Perforce are actually still in production today. Perforce in particular remains the tool of choice for some game studios dealing with massive binary assets — individual files in the tens of gigabytes, repositories measured in terabytes.<br>Meet Git: the information manager from hell<br>Git itself arrived in 2005, in fairly dramatic fashion. The Linux kernel had been managed in a proprietary system called BitKeeper; a license change alienated enough of the kernel community that...