--- title: "Your locks were sized for people." date: 2026-11-06 url: https://remiam.co.uk/notes/your-locks-were-sized-for-people tags: [AI, Engineering, Systems] read_time_minutes: 5 description: "Remiam's take on GitHub Universe 2026: coding agents broke Git's write assumptions, and booking, stock and ledger systems built around human-rate writes are next. What we would change before agents arrive." --- # Your locks were sized for people. *Published 2026-11-06 · 5 min read · by Liam (Remiam)* At GitHub Universe this year, GitHub explained why it is rebuilding Git storage: agents now start more than 40% of pull requests, and a lock on a whole repository was never meant for thousands of writers. The systems we build for clients have the same lock, just smaller and better hidden. GitHub Universe ran in San Francisco on 28 and 29 October, and the most useful part of the opening keynote was not a product. It was an admission. GitHub said it had struggled with performance and reliability at points during the year, and then explained why: developers and agents produced more than seven billion commits in September alone, roughly five times the volume of a year earlier. Its Octoverse figures put agents behind more than 40% of September's pull requests, up from 17% in March. The fix is the interesting bit. The first improvement GitHub described was moving write coordination from locking a whole repository to locking only the branch being updated. That alone gave three to four times more write throughput for agents working on different branches. The longer job is a new architecture that separates storage from compute and keeps coordination to a minimum, which GitHub expects to move everyone onto by early 2027. ## A lock is a guess about who is writing Locking a whole repository was a perfectly sensible decision for most of Git's life. People write slowly. They push a few times a day, and two of them touching the same repository in the same second was rare enough that waiting in line cost nothing. The lock encoded an assumption about the writers, and the writers changed. Nearly every operational system we have built carries the same assumption somewhere. A booking system that locks the whole day while it checks for a clash. A stock count that takes a table lock during reconciliation. A ledger that recalculates the balance on every write because writes used to arrive one at a time from someone at a desk. None of these are bugs. They are sized for people, and they work because people are slow. > An agent does not push a few times a day. It retries, it fans out, and it runs at three in the morning. ## Where it shows up first Clients are already asking for agents that act on their systems rather than just read them: rebook the cancelled slots, chase the unpaid invoices, reorder the low stock. Each of those is a write, and an agent that has been given a list will try to do all of them at once. The first symptom is rarely an outage. It is a queue of timeouts, a duplicated booking from a retry, or a report that took four seconds last month and now takes forty. GitHub's own numbers show the scale of the gap. In a load test against the new architecture, 5,000 agents targeting a single repository sustained 7,200 writes per second, which GitHub described as 180 times its current throughput. Very few businesses need that. Most simply need their system not to fall over when one agent does in a minute what an office used to do in a week. ## What we would change before the agents arrive - Lock the smallest thing that can actually conflict. A slot, not the day. A line, not the order. That is GitHub's branch change, and it is usually a small piece of work. - Make every write safe to repeat. An idempotency key on each request means a retried booking lands once, however many times the agent tries. - Give agents their own identity and their own rate limit, so one busy agent cannot starve the people using the same system. - Move heavy recalculation off the write path. Record the change, then work out the totals in the background. - Load test with a script that behaves like an agent: many parallel writers, quick retries, no pauses for thought. ## Should clients care Yes, but calmly. Nobody needs to rebuild a working system because GitHub had a hard year. The useful lesson is that the change arrived faster than the people running the platform expected, on the platform that understands developers best. If agents are anywhere on your roadmap, the cheap moment to find the locks is now, while the only writers are still people. We would start with an audit rather than a rewrite: list every place the system takes a lock or recalculates on write, and ask what happens when a hundred requests arrive in the same second. The answers tend to be short, and the fixes tend to be smaller than the meeting about them. ## References 1. [DEV Community, GitHub Universe 2026: my recap from San Francisco (2026)](https://dev.to/playfulprogramming/github-universe-2026-my-recap-from-san-francisco-23hd) 2. [Global AI Community, GitHub Universe 2026: from coding assistant to software delivery system (2026)](https://globalai.community/blog/github-universe-2026-day-1) 3. [byteiota, GitHub Octoverse 2026: agents and pull requests (2026)](https://byteiota.com/github-octoverse-2026-agents-pull-requests/) 4. [Visual Studio Magazine, GitHub Octoverse: agents started more than 40 percent of September pull requests (2026)](https://visualstudiomagazine.com/articles/2026/10/29/github-octoverse-agents-started-more-than-40-percent-of-september-pull-requests.aspx)