// Lofty

So GitHub is struggling to handle… *checks notes* 450 commits per second…..? There are blockchains with more throughput than that.

GitHub has been around since April 10, 2008 Agent's came out yesterday yes, GitHub was in fact NOT designed for Agents

Yup, platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.) GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week. So we're pushing incredibly hard on more CPUs, scaling services, and strengthening GitHub’s core features. And as a fine purveyor of hand-crafted shit code for many years, I'm not gonna weigh in on that. 🤣

Git and traditional databases were designed around a very specific assumption where a human is the primary actor. An AI agent completely breaks that assumption. Humans work in bursts. We make a few edits, commit occasionally, and query databases relatively infrequently. Agents don't. They operate continuously, generate thousands of tiny actions, and often need to branch, retry, backtrack, and coordinate with other agents. That's a very different workload. Take Git. Git is brilliant for human collaboration because commits are meaningful milestones. An agent, however, might generate hundreds of intermediate states while exploring possible solutions. Forcing every one of those states into Git is like using a filing cabinet to store CPU registers. Technically possible, deeply cursed. Git also assumes merge conflicts are exceptional. For multi-agent systems, conflicts are normal. If ten agents are simultaneously modifying code, configuration, and prompts, merging becomes the default operation rather than the edge case. Git's line-based merge algorithm starts sweating immediately. Databases have a similar mismatch. Most OLTP systems were built for short, deterministic transactions initiated by users or applications following predictable patterns. Agents are stochastic. They speculate, roll back, fork execution paths, and maintain rich context across long-running workflows. A single agent task might involve: querying multiple knowledge stores, spawning sub-agents, testing hypotheses, reverting failed branches,merging successful outcomes, preserving the entire reasoning lineage. Traditional relational databases can store this. Sure, but they're not native to it. You're essentially forcing a graph-shaped, versioned, probabilistic workflow into rows and tables. The deeper issue is state management. Human systems optimize for CRUD: Agent systems need something closer to: Fork, Simulate,Evaluate,Merge,Rewind, Provenance-track That's a fundamentally different abstraction. This is why entirely new infrastructure is emerging: Agent-native memory systems Versioned knowledge graphs Branchable execution stores CRDT-based collaboration layers Event-sourced agent runtimes Think of it as moving from "document editing" to "continuous world simulation." Git stores snapshots of files. Agents need snapshots of cognition. Databases store current truth. Agents need evolving hypotheses. Git answers: "What changed?" Agents ask: "What was explored, why, and what worked?" A future agent-native storage layer would likely combine ideas from: FoundationDB for transactions, CRDTs for concurrent collaboration, append-only logs like Apache Kafka, graph databases like Neo4j and helixDB and content-addressable storage inspired by Git itself. Git and SQL aren't obsolete, they're just too human-shaped. The same way relational databases weren't ideal for web-scale search, they're not ideal for agent-scale cognition. We're probably at the "mainframes before personal computers" stage of agent infrastructure. The primitives exist, but the abstractions are wrong. The companies that build the first truly agent-native state layer will own an enormous part of the stack.

What is unclear to me is what people actually want some new GitHub to be. To me, the biggest challenge GitHub has always had is that it is trying to serve two very different worlds. On one side, it is a social network around code and open source. On the other, it is infrastructure for companies building software. Those two groups operate almost in opposite ways, so the product has always been some kind of compromise between them. Because those users are so far apart, it can fail both of them in different ways. Inside a company, you mostly just want to review and merge code. You are not discovering new code, and you are probably not forking things. You may have a monorepo, a known team, and a trusted environment. What you want from GitHub is efficiency and safety: PRs, review, ownership, CI, Actions, tests, security checks, and a clear path to getting code merged. Open source is different. It is much more public and much less trusted. You need better ways to figure out who is contributing, what to accept, how to manage the project, how to handle issues, and how to maintain trust with people you may not know. So are people asking for a new open source code hosting and social network, or do they want better private infrastructure for software teams? Or both? I would never choose to build both from the start. I think every product gets better when it is more purpose-built and designed around a specific need. You could maybe imagine some nested model, where private repos have a much simpler and more focused mode, but you can still exit that mode and browse around the public space.

Everyone’s out here tokenmaxxing and ignoring what their agents spend tokens on every single session.