CI/CD Is Dead, Agents Need Continuous Compute and Computers — Hugo Santos and Madison Faulkner

What happens to build, test, and deploy infrastructure when the developers producing changes are agents? The proposal behind continuous compute is that faster code generation changes the shape of the development workflow, not just the number of jobs its runners must execute. Madison Faulkner introduces that proposal as an NEA partner focused on infrastructure and developer tools, describing her earlier work as a Meta AI researcher leading data and AI teams. Her co-presenter, Hugo Santos, is CEO of Namespace, which builds high-performance compute infrastructure; he previously led microservices at Google.

The starting architecture treats an LLM as one monolithic engine. As agents take on distinct responsibilities, that architecture begins to resemble microservices: multiple agents participate in software development rather than one model doing everything. They enter an already fragmented lifecycle containing planning tools, IDEs, autonomous engineering systems, traditional DevOps, and separate build, test, and deployment systems. Accelerating one participant does not automatically accelerate the connections between them.

The familiar pipeline starts with a human submitting a diff. Colleagues review the pull request, GitHub Actions runs build, test, and deployment steps, and a failed test sends the developer back to revise the change. Faulkner's illustrative human baseline is one or two diffs per week. Replace the human with agents producing N pull requests across potentially N repositories, and verification still takes roughly the same time unless the review process changes too. Review bots can help, but they introduce another moving part.

The difficulty is not simply provisioning more runners. Thousands of short-lived branches can compete over the same codebase, making their eventual reconciliation increasingly difficult.

Faulkner points to a GitHub activity chart as a sign of this pressure: a white line represents commits, alongside lines added and deleted, with a pronounced recent spike. She gives no numeric magnitude for it. The architectural question is how to absorb bursts of generated work without turning validation and merging into an ever-growing backlog.

The first step is incremental: accelerate the build, test, and deployment infrastructure underneath existing workflows, including GitHub Actions. In Faulkner's proposed architecture, the cache becomes an orchestration layer. Hardware and software must be designed together so work can reach the infrastructure that can execute it efficiently.

That path introduces several responsibilities in sequence:

1. Shape intake. Apply ingress shaping and rate limiting before bursts overwhelm the system.
2. Route through cached state. Use the cache when deciding which infrastructure should receive the work.
3. Manage agent identity and retries. Extend orchestration to identify agentic software and handle repeated attempts at scale.

These are responsibilities around the execution loop, not merely faster versions of individual CI steps.

The pressure extends to code hosting. Faulkner cites a proposal she attributes to HashiCorp founder Mitchell Hashimoto for fixing GitHub. In her account, it includes shutting down Copilot, adapting GitHub to the cloud era, and enabling inference at scale. She connects that criticism to calls for services that prioritize agent users and more agent-friendly code storage. Existing CI/CD frustration is the starting point for a broader infrastructure redesign.

Santos grounds the transition in Namespace's work with companies including fal, Zed, and Ramp. Looking back roughly six months from the talk, he describes a workflow in which people wrote code, packaged changes into pull requests, and waited for validation. Slow machines were tolerable because their latency was hidden behind the time humans spent writing and reviewing. As code generation becomes cheap and work becomes continuous, validation has to move into the inner loop.

The human was already acting as the agent: holding an objective in mind and carrying it through repeated feedback cycles. A pull request fails the team's formatting requirements, so the developer revises it. Tests fail, requiring another edit. A reviewer requests a different API, sending the developer around again. Finally, another contributor merges first, and the merge queue forces another pass. Each round prolongs the interval between starting work and integrating it.

At human speed, that interval can be relatively long because there are only so many concurrent changes. As the rate of change increases, the opportunity to merge becomes a central constraint: the repository continues moving while each candidate change is being prepared.

A pull request is a unit of work designed for human review. It assumes delayed feedback and discrete handoffs: send the change to a reviewer, wait, and receive it back. CI performs necessary checks within that arrangement: whether the change introduces regressions, whether it builds from a known source, whether concurrent changes conflict, and whether the change is allowed. Those requirements survive even if the pull request stops organizing the process.

With reviewers overwhelmed, merging starts to resemble a high-performance database problem. Santos uses a single ledger and a lock required to commit as an analogy for serialized integration. Machine-paced development needs a much shorter integration window than human-paced development. The analogy concerns ordering changes into shared history; it does not establish that GitHub holds a database lock throughout validation.

Santos describes a workflow his team and other early adopters already use without pull requests as the organizing unit. It begins with intent and plan: write down the goal as a specification, perhaps in a Linear ticket or Slack message. Feed that specification into an agent harness such as Claude Code, Amp, Cursor, or Factory. Namespace often uses Amp. The harness checks out the repository and starts implementing the plan.

The checkout must begin at a well-known commit. The agent then uses the repository's existing build and test assets for internal validation. A minimal shell boundary for a repository with a Makefile can make that sequence explicit:

#!/usr/bin/env bash
set -euo pipefail

: "${BASE_COMMIT:?Set BASE_COMMIT to the vetted starting commit}"
: "${WORK_DIR:?Set WORK_DIR to a new worktree path}"

base=$(git rev-parse --verify "${BASE_COMMIT}^{commit}")
git worktree add --detach "$WORK_DIR" "$base"
printf 'Starting commit: %s\n' "$base"

cd "$WORK_DIR"
"${EDITOR:-vi}" .
make build
make test

Here the editing step stands where the harness applies the plan; the build and test commands use repository-defined targets. Resolving BASE_COMMIT identifies the starting revision—it does not itself establish that the revision was vetted.

After internal validation, the agent asks the human whether the result looks right or needs further work. Approval or another instruction sends it forward or around the loop again; Santos describes “continue” as a frequent response. Eventually, completed work enters the merge queue and then the Git repository, which serves as the ledger.

This arrangement is faster, but human external validation remains on the critical path. That remaining delay motivates the next architecture.

Santos forecasts the next transition over weeks to months from the talk, rather than years. Faster inference makes slow validation increasingly expensive because the entire generation-and-feedback loop waits for it. He uses 15-minute and 45-minute test runs as examples of unacceptable loop delays, not measured Namespace results.

In this proposed loop, other agents take over external validation:

• Security evaluation: a security-focused LLM examines the change and returns findings.
• API conformance: an LLM checks whether the implementation follows the required API contract.

The main harness incorporates their feedback into the code and iterates. The evaluators become active participants in development instead of reviewers waiting at a later handoff.

Persistent state makes rapid iteration possible. Starting the environment from scratch on every attempt adds delay, so the loop needs memory and retained working state. It also receives signals from outside: the plan changes, or another contributor commits a change. The harness adapts its intent and plan, then begins another cycle. Even when implementation is complete, the result does not immediately enter the repository; the team has not yet accepted it.

Completed changes enter a proposed pre-merge queue: work that could otherwise have merged waits while the system reconciles concurrent edits. Many agents may have modified the same parts of the codebase. Their individually completed results must become a sequence that can enter the repository ledger coherently. Santos frames that requirement as serializability. The pre-merge layer is a proposed architecture, not an established product feature in this account.

Human approval comes after that reconciliation and focuses on intent and result rather than inspecting every code change. Evidence might be a video of a working feature or the output of a security evaluator. The approval unit can span several commits or independently developed features, grouped semantically into something a person can assess.

Santos reports that his team's volume of work equivalent to former pull requests is four times its previous level. That is an internal work-volume observation, not a measured productivity gain; he supplies no baseline period or counting method. Its practical consequence for his team is that a human reviewer cannot inspect every former PR-sized unit individually.

Further out, Santos imagines a “multiverse” of candidate repository states. If the ledger tip moves quickly enough, the latest commit may no longer be the only useful starting point. Agents could apply the same intent and plan to multiple candidate commits simultaneously, exploring implementations against several possible integration states. This remains a forecast.

That exploration requires extremely fast inner loops and substantially more capacity: each additional candidate consumes resources. Efficiency therefore depends on avoiding unnecessary work, preserving state instead of restarting, and making incremental progress much as engineers do during a working session. Persistent compute is especially consequential when several candidate futures are being developed at once.

CI does not disappear; validation becomes part of every iteration. Checking whether the code works moves from a separate phase into the ongoing development loop. Provenance requirements remain too: for compliance, a checkout must begin from a known revision rather than from unvetted code that someone inside the company happened to introduce. Those invariants need continuous enforcement.

Coordination moves out of a separate CI process and into the overall loop, where changes and their passing tests are managed together. Governance also remains, but more of it lives in the harness: the harness steers each change toward the requirements the team has codified. Continuous compute changes where these guarantees are enforced and how quickly feedback arrives, while retaining the obligations to validate, control provenance, and govern the resulting software.