He didn’t say that. He left and started building something else.

GitButler raised $17 million to rethink version control from scratch. When the person who built the cathedral starts drawing blueprints for something new, you should probably look at the blueprints.

In a recent interview with a16z, Chacon laid out the problem in terms that made me stop scrolling. GitHub was designed for humans. Specifically, for humans working at human speed. And that assumption is baked into everything.

The Pull Request Was Built for People

Here’s the deal with pull requests. They assume someone will read them.

You open a PR. A teammate gets a notification. Maybe today, maybe tomorrow. They click through, scan the diff, leave a comment or two, approve it, and you merge. The whole cycle takes hours or days. Sometimes weeks if the reviewer is busy or the PR is big enough to trigger “I’ll get to it later” energy.

This works when your team is five humans shipping a few PRs a day. It even works at scale, if the scale is more humans. GitHub handled that part beautifully. Issues, reviews, discussions, profiles, stars. The social layer that made open source collaboration feel natural.

But pull requests were never designed for a teammate that generates 200 of them before lunch.

What Happens at a Thousand PRs Per Week

Stripe merged over a thousand agent-generated pull requests in a single week. Let that number sit for a second.

A thousand PRs. In one week. From AI agents.

Now picture yourself as the human on that team. Your GitHub notification count doesn’t just go up. It becomes meaningless. The PR queue isn’t a todo list anymore. It’s a firehose pointed at your inbox.

Code review breaks first. Be honest: when you do code review, do you really read every line? Chacon asked this same question in the interview and the answer is what everyone already knows. Not always. Not even close. At a thousand PRs per week, “cursory glance” becomes “triage by title.” You’re not reviewing code. You’re reviewing your faith in the system that generated it.

Commit history breaks next. Git log becomes a wall of “fix: update component” and “refactor: apply suggestion” with no narrative thread. The story of how your codebase evolved disappears under a flood of mechanical changes. git blame points to an agent. The context that used to live in commit messages evaporates.

Notifications break last, because they were already broken. But now they’re broken at scale. The signal-to-noise ratio doesn’t degrade gracefully. It collapses.

Chacon put it simply in the interview: the whole model assumes human-speed collaboration. When you introduce participants that work at machine speed, the model doesn’t bend. It shatters.

The Pull Request Is the Wrong Unit

Here’s the question I keep coming back to: what replaces the pull request?

Not “how do we make pull requests better for agents.” That’s the wrong question. That’s like asking how to make horse-drawn carriages faster when someone just showed you an engine.

The pull request is a unit of collaboration designed around a specific workflow. One person makes changes. Another person reviews those changes. They discuss. They merge. It’s turn-based. It’s sequential. It’s fundamentally a conversation between two humans about a diff.

When the “person” making changes is twelve agents working in parallel, and they’re generating changes faster than any human can read them, the conversation model doesn’t apply. You don’t need a better conversation. You need a different unit of work.

Chacon’s answer at GitButler is interesting. They built what he calls a “mega-merge” system where multiple branches coexist in a single working directory. Agents can see what other agents are doing in real time. Conflicts surface before they happen, not after someone tries to merge.

That’s a version control answer. But the platform question is bigger. What does the server-side look like? What does collaboration look like when most of the participants aren’t human?

What the Next Platform Actually Needs

I don’t know what the next GitHub looks like. Nobody does. But I can see the shape of the requirements from here.

Real-time conflict detection, not post-merge. GitHub tells you about conflicts when you try to merge. By then, someone (or some agent) has already done the work. In a world with twelve agents writing code simultaneously, you need to know about conflicts as they form. Not after.

Agent provenance. Which agent wrote this code? What prompt generated it? What was the reasoning chain? Right now, the best you get is a commit message that says “Generated by Claude” or “Co-authored-by: Copilot.” That’s like listing “computer” as the author. You need the full trail: the intent, the context, the decision points.

Review at the intent level, not the diff level. Humans shouldn’t be reading thousand-line diffs generated by agents. They should be reviewing the intent: “I asked the agent to refactor the auth module to use JWT instead of session tokens.” Did it do that? Did it break anything? Let another agent verify the diff. The human reviews the goal.

Trust scores on commits. Not every change carries the same risk. A CSS color change and a database migration are not equal. The platform should know this. Flag the high-risk changes for human review. Let the low-risk ones flow through with automated verification.

Parallel visibility. If three agents are working on the same codebase, each one should know what the others are doing. Not through pull requests after the fact. In real time. This is what GitButler’s mega-merge is trying to solve at the local level, but it needs to exist at the platform level too.

None of this looks like a pull request queue. It looks more like air traffic control. Multiple things moving at once, a human watching the board, stepping in when something looks wrong.

The Builder’s Question

GitHub won because it made one thing simple: collaborating on code with other humans. The entire product was built around that idea. It worked brilliantly for twenty years.

The next platform will win by making a different thing simple: collaborating on code with a mixed team of humans and agents. That’s a different design problem. The social features that made GitHub great (profiles, stars, discussions, PR reviews) were designed for people who have attention spans, opinions, and feelings. Agents have none of those.

Chacon said something in the interview that stuck with me. He said the constraint isn’t “can we produce the code” anymore. It’s “can we agree on what we want.” The bottleneck moved from implementation to communication. From typing to thinking.

If that’s true, the next collaboration platform isn’t optimized for code review. It’s optimized for intent. For specification. For making sure twelve agents and three humans are all building the same thing.

I don’t know who builds it. Maybe GitButler expands into the server side. Maybe someone we haven’t heard of yet starts from scratch. Maybe GitHub pivots faster than Chacon expects.

But I’m pretty sure of one thing. When it arrives, it won’t look like a pull request queue.

It’ll look like something we don’t have a name for yet.

FlexGen is an open source collaboration among the LMSys community, Stanford, UC Berkeley, TOGETHER, and ETH Zürich.

The high computational and memory requirements of large language model (LLM) inference traditionally make it feasible only with multiple high-end accelerators. FlexGen aims to lower the resource requirements of LLM inference down to a single commodity GPU (e.g., T4, 3090) and allow flexible deployment for various hardware setups. The key technique behind FlexGen is to trade off between latency and throughput by developing techniques to increase the effective batch size.

The key features of FlexGen include:

 High-Throughput, Large-Batch Offloading
Higher-throughput generation than other offloading-based systems (e.g., Hugging Face Accelerate, DeepSpeed Zero-Inference). The key innovation is a new offloading technique that can effectively increase the batch size. This can be useful for batch inference scenarios, such as benchmarking (e.g., HELM) and data wrangling.

 Extreme Compression
Compress both the parameters and attention cache of models, such as OPT-175B, down to 4 bits with negligible accuracy loss.

 Scalability
Comes with a distributed pipeline parallelism runtime to allow scaling if more GPUs are available.

 Limitations
As an offloading-based system running on weak GPUs, FlexGen also has its limitations. The throughput of FlexGen is significantly lower than the case when you have enough powerful GPUs to hold the whole model, especially for small-batch cases. FlexGen is mostly optimized for throughput-oriented batch processing settings (e.g., classifying or extracting information from many documents in batches), on single GPUs.

Learn more by checking out the FlexGen GitHub project and read the supporting paper.

I had to make some updates for jQuery and Bootstrap. “Software” does not age well. Even a lowly app like mine sitting in a GitHub repository needs attention to make sure they work.

Here are some features of the IoT Debugger App:

• ThingSpeak Data Logger and Channel Browser
• Particle.io Webhooks Manager
• Settings are saved in LocalStorage
• Built using HTML5, Bootstrap, and jQuery

I now host a demo of the app using GitHub Pages. Even if you don’t want to download the app and run it yourself, you can just point your browser to https://nothans.github.io/iot-debugger/app/thingspeak.html and use it from there. To use the app, start by entering a channel number. If the channel is public and has data, you should start seeing data on your screen. You can try ThingSpeak channel 1417. This is the channel that stores the CheerLights colors. Use the app to explore your channel data.

Feel free to suggest new features, submit bugs, and make your own changes. That is the awesome thing about open source. We are building this together. See you on GitHub.

Features of IoT Debugger

• ThingSpeak Data Logger
• Particle.io Webhooks Manager
• Settings are saved in LocalStorage
• Built using HTML5, Bootstrap, and jQuery
• Open Source!

Demo and download the source code for IoT Debugger on GitHub.

My super simple solution for tracking server disk space is to use Windows PowerShell and ThingSpeak. I went to the trouble of releasing the code to GitHub so that you can try this out for yourself. This can be used on any Windows Server as long as you can execute PowerShell scripts. ThingSpeak gives you a place to store data from anything. In this case, I am sending my disk-free space to ThingSpeak once per day by scheduling a Windows Task.

Check out the open-source code on GitHub!