Run Only What Changed: Vercel CI Enters Beta for the Agent Pull-Request Era

In one line: CI has to keep up with how fast agents now work

On October 28, Vercel announced Vercel CI in beta, available on all plans. Its core idea is simple: run only the tasks your change actually affects, and pull everything else from cache. A one-line copy change should not trigger a full run of tests, type checks, and linting across the whole repository, and an agent opening twenty pull requests in a day should not have to wait behind nineteen full pipelines before the twentieth gets a verdict.

The timing is not accidental. Vercel opens its announcement with a blunt observation: coding agents are opening more pull requests than ever, and each one waits on CI before anyone can review or merge it. The bottleneck has moved. It is no longer mainly about how fast code gets written; it is about how long code waits for a check. Vercel CI targets that new bottleneck directly, and it does so by changing the unit of CI from the whole workflow to the affected task.

The short verdict is this: if you already use Turborepo, or your repository is a monorepo with a clear task structure, this beta is worth trying on one branch right away. If you maintain a large hand-written YAML CI matrix, the appeal is that configuration collapses into a file you already maintain. But if you have hard requirements on cache correctness or beta stability, or your CI includes many tasks outside Turborepo, run a small pilot first and do not move your main branch protection over in one jump. The rest of this article separates what Vercel actually announced, how it works in practice, and where to be careful.

What Vercel actually shipped

According to Vercel's official blog post, "Introducing Vercel CI," four facts can be checked one by one. First, the status is beta, not general availability, but it is available on all plans rather than reserved for large customers. Second, the configuration entry point is Turborepo's turbo.json; there is no separate CI workflow file to write. Third, execution is affected-only: tasks whose inputs have not changed come from cache, and the tasks that do need to run each get their own machine and start as soon as their dependencies finish. Fourth, inspection is available in three places: the Vercel dashboard, the Vercel CLI, and Vercel MCP, so a failure can be traced to a specific task, its blockers can be seen, and logs can be searched across recent runs to spot a test that has been flaky all week.

Vercel's own numbers should be quoted exactly, neither inflated nor dismissed. The company says that in its own repositories, time from git push to "CI passed" is 2 to 6 times faster than before, and that Vercel CI has already completed nearly 8 million tasks across its own repositories and the private beta. Both figures describe Vercel's own environment, not an independent benchmark and not a promise for every repository. The 2 to 6 times range itself is informative: the sparser the dependency graph and the higher the cache hit rate, the larger the speedup; if every change touches a core package used everywhere, the gain will sit near the bottom of the range.

The roadmap toward general availability is also stated up front, which is a useful honesty signal. Vercel plans to add advanced observability, a vc ci command for distributed execution before pushing code, and more granular test selection. In other words, the current beta solves "run less, run faster." It does not yet solve "reproduce the same result locally before pushing" or "run only the affected individual test cases." Judge it as a beta, not as the finished product it will become.

The setup is one line: tag a task with ci

The onboarding path is deliberately short. If you already use Turborepo, Vercel says there is no separate CI configuration to write: you tag the tasks you want CI to run in turbo.json. The example in the announcement tags a lint task, and the change is tiny. If you do not use Turborepo yet, you add turbo.json and the turbo package; single-package repositories work too, which rules out the misunderstanding that this is only for huge monorepos.

The sequence after a push matters, because it shapes how you debug. First, Vercel CI works out which tagged tasks the change touches. Second, tasks whose inputs have not changed are served from Remote Cache, which is on by default. Third, the remaining tasks each run on their own machine, powered by Hive, Vercel's compute layer, starting as soon as their dependencies finish rather than waiting for a whole batch. Fourth, Vercel CI posts a check to the GitHub pull request, so existing branch protection rules can block merges on failure exactly as they do today.

The command-line surface is already spelled out. vc ci ls lists CI runs for the repository, vc ci inspect lists the tasks in a run, vc ci logs pulls logs for a run and can be narrowed to one task and to stderr only, and vc ci grep searches recent run logs for a string. The real value is not the syntax; it is that the same path serves a human clicking through a dashboard and an agent working in a terminal. An agent can fetch a structured failure itself instead of pasting a wall of logs back into a chat and guessing.

The real shift: task-level CI instead of workflow-level CI

Traditional CI defaults to "one push, the whole workflow." You define jobs in YAML, a push triggers them in dependency order, and even a documentation-only change often runs type checks, unit tests, and end-to-end tests anyway. The usual workarounds are hand-written path filters, manually split jobs, and cache keys maintained by hand, and all of them drift away from the real task graph as the repository grows.

Vercel CI replaces that judgment with something Turborepo already knows: what the tasks are, which tasks depend on which, and whether a task's inputs changed. Because turbo.json is both the definition used for local development and the definition used for CI decisions, there are no longer two copies of the configuration to keep in sync. That is the substance behind the claim of "no workflow YAML to maintain." It is not that YAML has been hidden; it is that the CI decision has been delegated to the task graph you already use.

The design has a hard boundary, and it is worth stating plainly. It works best for tasks Turborepo understands. If a critical check lives outside turbo.json, for example a custom pre-deploy script, an external security scan, or an integration test that needs a special environment, you still need to decide who runs it and who enforces it. Vercel CI, at this stage, is best understood as the fastest and cheapest way to run the Turborepo subset of your checks, not as a one-shot replacement for everything. A sensible pilot scope follows from that: bring lint, type checks, and unit tests over first, and keep external checks in the existing pipeline as a supplementary gate.

Why agents change what CI is for

Agents change the shape of CI load. A human developer pushes a few times a day and usually runs something locally first. An agent can push relentlessly, and each push waits for a CI verdict before the agent decides its next step. If one agent runs ten tasks in parallel and each waits on CI, one minute of CI slowness becomes ten minutes of agent time stuck waiting. Worse, an agent does not "feel" that a change is small and should therefore be fast; it only acts on the verdict it receives. The slower CI is, the more expensive every agent trial-and-error loop becomes.

Seen that way, "run only affected tasks" is not just a cost-saving trick; it is a necessary adjustment so CI can keep pace with agents. Remote Cache on by default, one machine per task, and start-when-dependencies-finish together attack the queuing problem: unchanged work takes no machines, tasks that must run do not wait for each other, and failures can be located individually. Offering the same capability through the dashboard, the CLI, and MCP follows the same logic: CI results stop being a web page only humans read and become data an agent workflow can consume.

One sober note belongs here. Faster CI does not automatically make agents better. An agent can still submit logically wrong code that passes CI, and can still write tests that only cover the happy path. CI answers "how soon do we know," not "is the result right." Cutting CI time from twenty minutes to five saves waiting, not thinking. Task decomposition, test design, and review standards still decide agent output quality. Vercel CI is worth trying, but it is not a cure for agent quality problems.

A five-step pilot that is cautious without wasting time

Step one: pick a repository that already uses Turborepo, ideally mid-sized with a clear task graph, not your most critical and most frequently released repository. Step two: tag only lint and type checking at first, the two most standard tasks whose failures are easiest to diagnose, and watch them for a week, noting cache behavior and false alarms. Step three: bring unit tests in, keep the old CI running as a control, and compare the same pull requests on both sides for time and outcome, paying special attention to any divergence where Vercel CI passes and the old CI fails, since divergence is the signal that caching or task boundaries are wrong.

Step four: let a real agent task use the new chain end to end, from opening a branch and pushing, through waiting on CI, reading vc ci logs to locate a failure, fixing it, and pushing again, and confirm the agent can read the failure on its own rather than needing a human to translate a dashboard page. Step five: only then decide whether to switch the required checks in branch protection to Vercel CI's check. Before switching, confirm that branch protection recognizes that check and that failure-blocking behavior matches what you had before. Switching the gate is the last step, not the first.

During the pilot, track four numbers: median time from push to pass, cache hit rate, average time to locate a failure, and the count of "CI passed but a problem was found later." The first three measure whether it is genuinely faster and easier to debug; the fourth measures whether it is letting through problems it should have caught. If the fourth number rises, a faster CI is a net loss.

Three things to watch

First, cache correctness is the Achilles' heel of this whole category. Affected-task analysis is only as good as the completeness of each task's declared inputs. If a task quietly reads an environment variable, a file outside the repository, or some undeclared global state, the cache can wrongly classify it as unchanged. Turborepo provides input declaration mechanisms, but no mechanism survives a sloppy task definition. When you see "reproducible locally, passing in CI" during a pilot, suspect cache and input declarations before suspecting the code.

Second, beta means behavior and surface can change. The roadmap items, local pre-push execution and finer test selection, are not here yet, so the current shape is not the final shape. When writing Vercel CI into team documentation, mark it as beta with a review step before gate switches, and keep watching the changelog: pricing, quotas, and behavior at general availability could all change your cost model.

Third, think about platform lock-in early. The task graph itself lives in turbo.json, an open-source tool, so that layer is portable. But the execution layer Hive, Remote Cache, the GitHub check integration, and the MCP entry point are Vercel platform pieces. The more your CI depends on Vercel-specific observation and execution, the more adaptation a future move back to generic CI would require. That is not a reason to avoid the product; it is a reason to keep critical logic in the portable turbo.json layer rather than in corners only Vercel understands.

Judgment: worth trying, in beta fashion

Vercel CI's value proposition is clear and honest. It does not claim to rewrite all of CI; it replaces the increasingly expensive old default of "run everything on every push" with "run only affected tasks." An internal 2 to 6 times speedup, nearly 8 million tasks of beta mileage, and a one-tag setup cost together make a case that Turborepo users should take seriously.

The boundaries are equally clear: beta status, the Turborepo task subset, cache correctness depending on task definition quality, and general-availability features not yet delivered. For teams already in the Turborepo ecosystem, this is a low-cost experiment worth one repository, one week, and four numbers. For teams without Turborepo, evaluate the cost of adopting Turborepo itself before adopting CI that depends on it; do not restructure a build system to chase a beta feature.

The closing point is about where CI competition has moved. It is no longer mainly about whose feature list is longer; it is about who makes agents wait less and fail more transparently. Vercel CI enters that new race with a concrete mechanism, internal data, and an explicit to-do list. Each team now has to verify, with its own repository, how many points that entry actually scores.