Over the past few decades, software organizations have converged on a standard operating stack: work in a local IDE, ship code to GitHub, tickets in Jira or Linear, conversations in Slack.

But industry giants like Google and Meta have built an entirely different machine with their own version control, build systems, review tools, and more. They didn’t just want to be different; they had to: the standard stack literally breaks when tens of thousands of engineers are collaborating on a shared codebase.

Much of Google and Meta’s infrastructure for running software has already become mainstream. Google built Borg to manage its server fleet, which later became Kubernetes. Meta's internal experimentation system inspired Statsig. As other companies scaled to millions of users, they needed the same capabilities as the giants.

With coding agents, software companies will operate at giant scale from a developer perspective too. Today, it’s only the most forward-thinking teams like Artemis, where each engineer ships 250+ PRs each month. But soon, we think every company will have teams managing thousands of agent developers.

That means they'll also need Google-scale infrastructure and tooling for building software too. Some of it has been around for years: Google open-sourced its build system Bazel, as did Meta with its version control Sapling. For most companies, these tools were too complicated to justify the benefit. But now, they’re absolutely necessary.

So what does it look like for a startup to operate like a tech giant?

The Agent PR Traffic Jam

The clearest first problem is upgrading the infrastructure that breaks when you scale from tens to hundreds or thousands of PRs per day.

Version Control

Git assumes PRs are written at human speed, on a handful of branches, and get reviewed one at a time. Agents operate 100-1,000x faster, with dozens of forks per task and fleets running in parallel. That causes a few major issues:

• ‍Latency & Concurrency: Infra limitations slow down development at best, or outright break at worst (see GitHub’s recent downtime issues).‍
• State: The commit is too coarse. Agents will try, evaluate, and discard dozens of things for each task. Every step needs a snapshot it can rewind to, but today anything that didn’t make the commit is lost.‍
• Context: Code diffs are captured, but reasoning is not. When that code will be built on by future agents, the context really matters.

The future looks less like git and more like a database: every working state auto-snapshotted and addressable (it may look like Jujutsu's working-copy-as-commit model), with forks as pointers, conflicts stored rather than blocking, and agent reasoning saved alongside diffs.

CI and Testing

Even if git can handle PRs and merges, CI/testing today cannot:

• ‍Merge races: At thousands of merges a day, dozens will have landed in the time your PR’s tests run. That permanently breaks main.‍
• Cost: Running the full test suite for every change quickly becomes prohibitively expensive at agent scale.‍
• Feedback/Latency: When agents can write code much faster than it’s verified, they’ll either sit idle waiting for a test, or ship more and more code that just creates more backlog and merge pressure in the CI queue.

Google solved most of this years ago: PRs get tested in batches as part of submit queues, builds cache everything and recompile only what a change touched, and each change runs only the tests it could potentially break. Agents need this on steroids, meaning sub-minute feedback, continuous deploys, and automated rollbacks.

Workspaces

Today most companies have each developer check out code locally on their laptop. Agents will need something different to fix:

• ‍Cold start: A fresh clone and build can take minutes to hours. At thousands of tasks a day, this is unacceptable overhead.‍
• Isolation: If they share a workspace, multiple agents could collide on shared ports, databases, caches, etc. Each needs a real sandbox with scoped credentials, not a shared set of keys.‍
• Lifecycle: Agents pause, resume, fork, and abandon work constantly. They will need environments that can snapshot and dispose cheaply.

For years, Google's engineers have worked in cloud workspaces that expose the whole monorepo through a virtual filesystem, with builds served from shared caches. Now there are a maturing set of sandbox providers (Modal, E2B, Daytona, etc.), and apps like Claude starting to move toward cloud sessions. The approach is both more scalable, easier to monitor & govern, and a better experience for developers – who can start work on their laptop and pick it up on their phone.

Keeping Up With Autonomous Engineers

Building and shipping product isn't just merging PRs. You need to align on strategic priorities, collect information, decide what to build, and monitor it post-delivery.

Today, engineering is the constraint; with limitless agent engineers, it won’t be.

10x the amount of code doesn’t make an organization ship great software 10x faster; it just shifts the bottleneck. When execution is no longer the limiting factor, human attention will be. Some areas we’re thinking about:

‍Code Review

This is the lowest-hanging fruit, and already being tackled by a number of startups. Humans can only afford to look at a small portion of changes. Agents will do first-pass triage, then show humans only the borderline issues or aggregated/synthesized takeaways. The remaining human job usually won’t be correctness; it will be intent and coherence. Fifty agents building fifty features produce a product that feels disjointed. Humans keep it aligned with the broader product vision.

Product and Planning

Planning and prioritization were already a weak point of many orgs, and when engineering is no longer a constraint, product will be. Today’s norms are based around quarterly planning and biweekly standups. Future product teams will need to operate at AI velocity; instead of automation to write code, using agents to help them align on product direction, do customer discovery, and write requirements. More on this function to come!

Experimentation

With coding agents, the number of new features we build will explode. LLM-powered applications are already non-deterministic, and coding agents will enable dynamic generative interfaces, where the UX could actually be different for each user. This will create a massive need for new evaluation and experimentation tooling (right as the two major independent startups, Statsig and Eppo, got acquired).

Documentation

Docs are now read by agents on every single task, and stale information leads agents astray. Documentation moves from nice-to-have to production infrastructure, with agents managing its creation and maintenance across code and non-code context (e.g. Slack and meetings).

A Strange New World

The next generation of software organizations will look very strange indeed: small groups of people managing a massive number of AI teammates. Coordinating human and agent workstreams effectively will be what separates winners from losers. And productizing those capabilities will create generational new opportunities in infrastructure and developer tools.

If you're building infrastructure and tooling for the era of agent-native software teams, I'd love to hear from you: at@theoryvc.com.