The infrastructure question

For two years now, the entire conversation around AI coding agents has been framed as a problem of integration. How do we make Claude or GPT or whatever model du jour slot neatly into the workflows we already have? How do we teach agents to write good pull requests, to respect our branch strategies, to pass code review, to fit inside the process architecture we've spent decades refining?

It’s such a natural question .

There is an assumption buried at the foundation of every agent-tooling integration effort, every "AI-assisted development" feature, every startup pitching "agents that work with your existing stack." It goes like this: the tools stay the same; the agents adapt. Git remains git. CI/CD remains CI/CD. Code review remains code review. We just bolt an LLM onto the side and expect everything to hum along.

This assumption is wrong. And the industry is about to discover just how wrong it is.

The tools we use to build software were designed for human beings working at human speed. Git was born in 2005, product of a world where a developer might branch once a day, commit a handful of times, and merge when things were stable. Code review emerged from the open-source mailing list era — asynchronous, thoughtful, paced for people who need to context-switch between meetings. CI/CD pipelines assumed builds measured in minutes, not seconds, and deployments measured in hours, not milliseconds.

That world is already gone. We just haven't updated the infrastructure to reflect it.

An AI agent working on a non-trivial codebase does not branch once a day. It branches once every few minutes. It snapshots its state not when a developer remembers to stage and commit, but after every action — because the cost of losing context is catastrophic. It parallelizes work in ways that no human ever could: twenty branches exploring twenty approaches simultaneously, each one logging thousands of operations per hour. The scale differential between human-paced development and agent-paced development is not a factor of two or ten. It is closer to three orders of magnitude.

The natural response: agents already know git. They've been trained on millions of git histories. They can branch, commit, push, create pull requests. But familiarity is not optimization. Yes, an agent can invoke git checkout -b and git commit -m. It can generate a pull request template and fill in the description. It can make the motions. Watch what happens next: the agent creates fifty branches in an afternoon. Each branch sits in the remote as a full copy of the repository. Each one triggers CI. Each one waits for review that never comes, because no human can review fifty branches. The repository bloats. The remote becomes a swamp of stale branches. That process was designed for throughput of 5–10 branches per day, and now you're feeding it 500.

This is not a git problem. This is a fit problem.

What we are witnessing is the emergence of an entirely new category of infrastructure — not tools that make agents compatible with human workflows, but tools designed from the ground up for machine operators. Version control systems that don't clone entire repositories because machines don't need entire repositories — they need the files they're touching right now. Snapshot mechanisms that operate in microseconds, not milliseconds, because machines don't get distracted and shouldn't be penalized for the speed they're capable of. And audit trails that capture not just what changed, but why and under what context — because machines don't write commit messages that explain motivation. They write actions that need explanation retroactively.

These tools are not improvements to git.

They are alternatives to the assumption that git is the right abstraction for machine-paced development.

The infrastructure question that nobody is asking is this: what happens to the rest of the stack when version control ceases to be the central nervous system of software development?

Think about what version control anchors. Code review depends on diffs — the comparison of two states captured in git. CI/CD pipelines trigger on pushes to specific branches — events defined by git semantics. Deployment rollbacks assume a linear or semi-linear commit history that you can step back through. Testing strategies are built around the assumption of discrete, reviewable changesets. If the version control system itself changes — if it becomes something closer to a continuous, time-indexed recording of machine activity rather than a discrete, human-edited journal — everything downstream changes with it.

This is not a prediction of git's death.

Git will continue to work fine for human developers collaborating on human-scale changes, which is most of software development today and will remain so for years. The migration will be uneven, messy, contested.

Here is what I believe: the dominant operator in terms of commits, branches, deployments, and lines changed will soon not be a human. It will be a machine. And when the dominant operator changes, the infrastructure optimized for the minority operator eventually gets replaced by infrastructure optimized for the majority operator.

That is not a technology forecast. That is a historical pattern. Every industry that has faced a similar shift — from manufacturing to logistics to finance — has eventually rebuilt its tooling around the fastest, highest-throughput operator, not the one with the most institutional authority.

The tools we built for ourselves will not serve the machines we're building. Not because the tools are bad, but because they are ours — designed for our rhythms, our attention spans, our ways of thinking about code.

The next generation of developer tooling will not look like git with an AI plugin.

It will look like something we barely recognize: infrastructure where the default operator is not a person typing commands into a terminal, but an agent processing thousands of parallel operations, coordinating with other agents, writing code at a pace that makes human development look like handwriting letters by candlelight.

The question is not whether machines will learn our tools. The question is whether we are brave enough to build tools for the machines we've created.

That is the conversation we should be having — everything else is just optimizing the wrong abstraction.