Is CI/CD Dead? The Continuous Computation Architecture Revolution in the AI Agent Era

At the AI Engineer conference, NEA partner Madison and Namespace CEO Hugo Santos delivered a thought-provoking talk: traditional CI/CD is being completely shattered by the development pace of the AI Agent era, and an entirely new "continuous computation" architecture is emerging. This isn't a distant future — it's a transformation happening right now.

Why Traditional CI/CD Is Collapsing

The Human Developer's Rhythm Is Now History

The design logic of traditional CI/CD pipelines was simple: human developers submit one or two PRs per week, colleagues spend time reviewing them, GitHub Actions executes build, test, and deployment steps, developers fix failing test cases, then iterate. This process worked well at human pace — local caches were predictable, branch management was orderly, and merge conflicts were manageable.

The concept of CI/CD (Continuous Integration/Continuous Deployment) traces back to the early 2000s when Martin Fowler and Kent Beck proposed continuous integration practices within Extreme Programming (XP). The core idea was that developers frequently integrate code into a shared trunk, with each integration verified through automated builds and tests. As tools like Docker containerization (2013), Jenkins pipelines, and GitHub Actions (2019) matured, CI/CD evolved into standard infrastructure for modern software engineering. But the implicit assumption of this system never changed: the producer of changes is human, and the frequency, granularity, and predictability of changes all fall within human cognitive bandwidth. The entire toolchain — from branching strategies (Git Flow, Trunk-Based Development) to code review mechanisms (Pull Requests) — was designed around human work rhythms and collaboration patterns.

But when AI Agents enter the picture, everything changes. Agents use the exact same systems but can produce n PRs across n repositories. Thousands of short-lived branches simultaneously pull at the same codebase, making it nearly impossible to merge all these divergent changes together.

The speakers showed GitHub activity data from recent months: commit counts displaying a stunning upward curve, with lines added and deleted also hitting unprecedented peaks. This isn't incremental growth — it's a cliff-like paradigm shift.

The Merge Window Becomes a Fatal Bottleneck

Hugo Santos used an elegant analogy to reveal the core contradiction: PRs are fundamentally work units designed for human review, expecting delayed feedback and discrete handoff processes. Merging is increasingly resembling a high-performance database problem — you have a single ledger (the Git repository), each change needs serialized writes, and you need to lock the database to commit.

Git, as a distributed version control system, has a merge model that is essentially Optimistic Concurrency Control: each developer freely modifies their local branch, with conflicts detected only at merge time. This shares similarities with MVCC (Multi-Version Concurrency Control) in the database domain. When the number of concurrent writers is small, conflict probability is low, and the optimistic strategy is highly efficient. But when concurrent writers surge from a handful of people to hundreds of Agents, the situation resembles a database write hotspot — all transactions trying to modify the same row. Git's three-way merge algorithm resolves conflicts at the text level but cannot understand semantic conflicts (such as two Agents separately modifying the caller and implementer of the same API), making merge problems under massive parallel development far more complex than they appear on the surface.

When the operator is human, lock duration is long but frequency is low; when the operator is machine, lock duration is short but frequency is extremely high. The merge window (opportunity to merge) becomes critical because the rate of change increases dramatically, and any delay causes cascading conflicts.

New Architecture: From PR-Driven to Intent-Driven

The Current Transitional Form

Hugo described the workflow his team and cutting-edge companies (like FAL, ZED, RAMP, etc.) are already practicing: no PRs, starting from intent and plan.

The entire process is restructured as:

1. Intent & Plan: Define the objective — it might be written in a Linear ticket, it might be in Slack, but it must be codified
2. Agent Loop: The Agent (possibly Claude Code, AMP, Cursor, or Factory) checks out the code and begins implementing the plan
3. Internal Validation: The Agent leverages existing assets in the repository (build scripts, test suites) to self-verify the correctness of changes
4. Human Confirmation: After the Agent completes its work, it notifies the human, and the human says "continue" — this has become the most commonly used word
5. Merge Queue: Finally enters the ledger

The Ultimate Future Form

But this still isn't fast enough, because the external validation step still has humans in the loop. Hugo believes that within weeks to months (not years), we will see:

• Code generation: Inference speed will only get faster
• Internal validation: Builds and tests must complete at extreme speed — they can't take 15 minutes or even 45 minutes because that slows down the entire loop
• External validation: No longer performed by humans, but by other specialized Agents — security-focused LLMs, API consistency checking LLMs — providing feedback to the primary Agent within the loop

The key technical requirement is stateful environments. Memory matters, state matters. If you start from scratch every time, latency becomes unacceptable. Agents need to work incrementally, just like an engineer at their own workstation.

Stateful Environment is defined in contrast to the stateless, ephemeral execution environments prevalent in current CI/CD. Traditional CI pipelines spin up a fresh container or virtual machine on every trigger, starting from scratch with code pulls, dependency installation, compilation, and test execution. This design guarantees reproducibility and isolation, but at the cost of enormous time overhead. The concept of Incremental Computation comes from the build systems domain — tools like Bazel and Buck precisely track file dependency graphs to only rebuild the parts that changed. Extending this idea to the Agent's development loop means the Agent's working environment needs persistence: filesystem caches, compilation artifacts, dependency trees, and even the Agent's own context memory should be preserved across iterations. This creates an interesting tension with the cloud-native era's "cattle, not pets" infrastructure philosophy — Agent development environments are more like "pets" that need careful maintenance, rather than disposable "cattle."

Pre-Merge Queue: The New Coordination Layer

As the number of parallel changes explodes, an entirely new concept emerges — the Pre-Merge Queue. Changes don't go directly into the repository upon completion; instead, they enter a pre-merge queue. This queue solves the serialization problem: ensuring all changes can be written to the ledger back-to-back.

Merge Queue is not an entirely new concept. GitHub officially launched its Merge Queue feature in 2023, and Shopify's internal tools, Google's Submit Queue, and Uber's SubmitQueue were early implementations. The core mechanism is: when multiple PRs are waiting to merge simultaneously, the system automatically queues them and tests each one sequentially against the latest trunk, ensuring every post-merge state is green. But traditional Merge Queues handle scales of tens to hundreds of PRs per day. The Pre-Merge Queue proposed in the talk needs to handle orders of magnitude more change flow, with changes coming from Agents rather than humans. This requires the queue system to have smarter conflict prediction, semantic grouping, and priority scheduling capabilities — essentially upgrading merge coordination from a simple FIFO queue to a real-time scheduling system.

The human role at this stage undergoes a fundamental transformation: no longer reviewing code itself, but reviewing the match between intent and outcome. The result might be a video of a feature running, or a security LLM's analysis report. And the object of review isn't a single commit or PR — it might be multiple changes from multiple Agents working independently, semantically grouped and then presented to humans.

Hugo revealed that his team's "PR" volume is already 4x what it was before, and human reviewers simply cannot examine each PR individually.

Multiverse Development: The Ultimate Vision

An even more radical vision is the "multiverse" mode: the Agent's starting point is no longer the latest commit of the repository, because the latest commit is constantly moving and has multiple candidate versions. Agents might work simultaneously on multiple commits, exploring different implementation paths for the same plan.

This pattern has deep theoretical roots in computer science. It's essentially Speculative Execution applied to software engineering — CPUs have long used branch prediction and speculative execution to improve pipeline efficiency, with the trade-off of discarding completed computation when predictions are wrong. Similarly, multiple Agents simultaneously explore different implementation paths, ultimately adopting only the optimal solution while discarding the rest. This pattern also has parallels in search and optimization: Monte Carlo Tree Search (MCTS) finds optimal solutions by exploring multiple paths in parallel. But unlike CPU speculative execution, each Agent exploration consumes real computational resources (GPU inference, cloud environment runtime), with costs far exceeding transistor-level waste. This makes the intelligence of the exploration strategy — when to fork, when to prune, how to evaluate candidate solutions — the key factor determining the economic viability of this model.

This means the inner loop must be extremely fast, while resource consumption will also explode — because you're simultaneously exploring a large number of candidate solutions. The Namespace team is investing heavily in maintaining this loop's efficiency: not doing unnecessary work, not starting from scratch every time, letting Agents work incrementally.

CI Hasn't Disappeared — It's Merged Into the Loop

At the end of the talk, Hugo made an important clarification: CI's core principles haven't died — they've shifted position.

• Validation is no longer a separate stage; it happens in every iteration of the loop
• Invariants still need enforcement — for compliance reasons, you still need to guarantee starting from a known checkout point and preventing unreviewed code from slipping in
• Coordination is decoupled from CI and becomes part of the overall loop
• Governance is elevated to the Agent orchestration layer, with a harness guiding changes to follow the team's codified processes

Agent Orchestration is one of the most active directions in AI engineering in 2024-2025. From LangChain's LangGraph, Microsoft's AutoGen, to CrewAI, various frameworks attempt to solve scheduling, communication, and state management problems in multi-Agent collaboration. The "harness" concept mentioned in the talk — a governance layer that guides Agents to follow team-codified processes — reflects core concerns in enterprise AI adoption: Auditability and Compliance. In regulated industries like finance and healthcare, code changes must have clear audit trails, and every line of code entering production needs to be traceable to an authorized decision. When Agents become the primary code producers, governance can no longer be a post-hoc compliance check — it must be embedded in every decision cycle of the Agent. This is why the speakers emphasized that governance needs to be "elevated to the Agent orchestration layer."

This isn't the death of CI/CD — it's its deconstruction and reassembly. The fundamental needs of building, testing, and validating will always exist, but the architecture carrying them is evolving from discrete pipelines into continuous computation loops. As Hugo said: "This is a crazy world, and we need to be ready for it."

Key Takeaways

• Traditional CI/CD pipelines were designed for human development rhythms; the massive parallel PRs and short-lived branches produced by AI Agents are breaking through their design limits
• The new architecture shifts from PR-driven to intent-driven, with Agents executing continuous loops of code generation and internal validation in stateful environments, while external validation is handled by specialized security and compliance Agents replacing humans
• Pre-Merge queues become the new coordination layer, solving the serialized merge problem for large volumes of parallel changes; the human role shifts from reviewing code to reviewing the match between intent and outcome
• CI's core principles (validation, invariants, governance) haven't died — they've moved from discrete pipelines into continuous computation loops, becoming built-in elements of every iteration
• The future may enter a multiverse development model where multiple Agents simultaneously explore implementation paths for the same plan on different commits, placing extreme demands on computational resources and loop efficiency