Post-Agentic Code Forges: Why GitHub and GitLab Face an Existential Reckoning

The question of whether GitHub and GitLab are "dead-ded" or "alive-ded" in an era of autonomous coding agents isn't merely rhetorical—it's a technical assessment of whether their foundational assumptions still hold. When Thorsten Ball recently questioned GitHub's viability in a post-agentic world, he touched on a tension that's been building in engineering infrastructure for years. The answer, like most architectural questions, isn't binary but reveals a landscape where current solutions are becoming increasingly misaligned with emerging workflows.

The monorepo trend, which has accelerated dramatically with AI coding tools, exposes the first architectural crack. Monorepos provide the unified context that coding agents need to generate coherent changes across a codebase. When all code lives in a single repository, agents can reason about dependencies, understand cross-cutting concerns, and avoid the version drift that plagues multi-repo setups. This isn't theoretical—AI labs have been quietly migrating to monorepos because the productivity gains for agent-assisted development are substantial.

Yet this migration collides directly with how GitHub and GitLab handle mergeability checks. These services run computational checks to determine if a pull request can be merged cleanly into the target branch. In a traditional human-paced environment, this works well enough. But in a post-agentic world where thousands of coding agents might land changes per hour, the default branch becomes an information highway that constantly invalidates these merge-check results. The computational cost of running these checks repeatedly becomes prohibitive, and worse, the services often block merge buttons when results are stale.

The workaround that high-velocity monorepos have adopted is telling: they've abandoned the PR workflow entirely, replacing it with merge-bot accounts that push directly to main. These bots manage their own merge queues and speculative CI engines. The irony is palpable—organizations pay tens of thousands of dollars monthly to code forge services, only to build the most critical features themselves. This isn't just inefficient; it's a sign that the core product is no longer fit for purpose.

Code review faces an even more dramatic transformation. As coding agents become more reliable, the economics of human review break down. Ten human engineers cannot possibly review changes from 1000 agents running 24/7. The traditional purposes of code review—improving code quality, increasing ownership, and ensuring compliance—are being redistributed.

Code quality, in the traditional sense, becomes less relevant when agents generate consistently high-quality output. The "bus factor" concern diminishes when agents can quickly analyze and fix problems. What remains is compliance, and this is where the human element persists—but not in the traditional pre-merge gate.

The emerging pattern is a shift to pre-release review. Agents might work in their own branches or even separate default branches ("bot-main") before changes are aggregated for human review. The review interface itself changes: instead of line-by-line comments, humans get categorized checkboxes and LLM-assisted explanations of changes. The review becomes a batch process rather than a continuous gate, and the human reviewer's role shifts from quality control to compliance verification.

The most profound change, however, is in testing and continuous integration. Traditional CI systems are fundamentally incompatible with agentic workflows. They're slow, bloated, and wasteful of compute. When an organization reaches sufficient scale, it inevitably converges on hermetic build tools—Google's Blaze, Meta's Buck, Twitter's Pants, which evolved into Bazel and Buck2. These tools provide reproducible builds, enabling accurate caching and reuse of results across machines.

The key insight is that reproducible builds allow you to divide work into smaller, distributable tasks. Each task's cache key is built from a Merkle tree of all influencing factors: inputs, environment variables, tools, arguments. This means a build on your laptop, workstation, or cloud environment produces identical results. When you break builds into many small reproducible tasks, you can distribute them across a build farm and aggregate results efficiently.

This is precisely what Bazel and Buck2 provide out of the box, with additional telemetry and profiling. The diagram of Bazel's remote build setup illustrates how distributed caching and execution work: a local client communicates with a remote execution service, which manages a distributed build farm. Results are cached based on content-addressable keys, allowing massive reuse.

What's changed is that the "Big Code" problem—previously exclusive to tech giants—is now accessible to everyone. The computational demands of coding agents mean that even small teams will need hermetic build systems. This explains why major AI labs have been hiring experienced DevOps engineers with backgrounds in Bazel migration and distributed build systems.

The evidence is in the details. Codex, OpenAI's coding agent, has been adopting Bazel for its projects. In pull request #8875, they demonstrated how Bazel reduced test execution time from 9 minutes and 20 seconds with Cargo to just 1 minute and 37 seconds. This isn't just a minor optimization—it's an order-of-magnitude improvement that becomes critical when running thousands of agent-generated changes through CI.

Meanwhile, traditional code forges remain stuck in the old paradigm. They run hundreds of CI jobs unconditionally for each change, with no granular build graph invalidation. They lack confidence in test quality and struggle to scale for monorepos with more than 100 active users. The computational waste is staggering, and it only gets worse with agentic workflows.

Beyond these core issues, several other architectural shifts are emerging. Coding agents don't need file system snapshots—they need continuous commits and automatic pushes to the cloud. Meta's Mercurial design, with its push-rebase extension and Commit Cloud service, offers a blueprint for scaling forges. The ability to freely reposition commits within a queue, batching stacks of commits, could yield massive CI compute savings and accelerate agentic loops.

High-velocity merge queues will need distributed conflict-resolution caches. In Git, this might look like a distributed version of git-rerere. In newer systems like Jujutsu, resolution data is stored in commit headers. The goal is to avoid re-resolving conflicts that have already been handled, saving both time and compute.

We're also seeing the emergence of "Code Farms"—headless cloud workspaces exposed to agents rather than IDEs for humans. The constraints are similar: agents need isolated, reproducible environments. But the scale is larger and management easier, since agents won't accidentally install Dota 2 and cause disk space issues. The security challenge shifts from human error to prompt injection attacks.

As CI workload increases, code forges must find ways to distribute code changes without overwhelming the git storage layer. GitLab's struggles with sparse-checkout support and pull-through caching proxies reveal the pressure points. Canva's solution—forking google/goblet to add Gitaly's pack-object cache—shows one path forward. We'll likely see more multi-tier git cache setups (local disk, local network, global) and eventually peer-to-peer sharing systems similar to Sapling's Commit Cloud.

Even Git LFS, which many teams rely on for large files, becomes problematic at agentic scale. The bandwidth and storage costs multiply when agents generate and commit large artifacts continuously.

The conclusion isn't that GitHub and GitLab will disappear overnight. They're deeply embedded in the developer ecosystem. But their architectural foundations were built for a different era—one of human-paced development, small teams, and manageable CI workloads. The post-agentic world demands something different: systems designed for high-velocity, machine-generated changes, distributed computation, and fundamentally different workflows.

The companies that recognize this shift early—whether they're building new code forges from scratch or radically rearchitecting existing ones—will capture the next generation of development infrastructure. The rest will find themselves building the features they need on top of increasingly inadequate platforms, paying premium prices for the privilege of working around fundamental limitations.

The question isn't whether GitHub and GitLab are dead, but whether they can evolve fast enough to remain relevant. The evidence suggests that evolution will be difficult, and the window for new entrants is wide open.