Vercel CI Skips Most Tasks, and the Internet Can't Stop Staring at That Green Check

Vercel has launched CI, in Beta, available on all plans.

The one-sentence version: use Turborepo as the foundation, run only the tasks affected by this change, and get results for the rest straight from cache. According to Vercel, its internal repos are 2 to 6 times faster from push to showing “CI passed.”

The configuration is almost suspiciously unlike CI. Just tag the tasks you want to run in turbo.json:

{
  "tasks": {
    "lint": {
      "tags": ["ci"]
    }
  }
}

There is no workflow YAML to maintain, and no problem of CI config and turbo.json telling different stories. Remote Cache is on by default. Repos not using Turborepo can also use it, and single-package repos are supported too; just install turbo, write a turbo.json, and you're done.

On the execution side, each task gets its own machine, running on Vercel's compute layer Hive, and starts as soon as its dependencies finish. Vercel says that during Beta, with internal repos added, it has already run nearly 8 million tasks.

Jared Palmer brought up old history on Twitter/X. This was his original vision when he built Turborepo in 2021: run the same build locally and in the cloud, stay close to the codebase itself, and keep configuration as minimal as possible. Even then he thought traditional YAML CI didn't make sense, and he thinks so even more now. The reason it didn't take off back then was very concrete: moving work scattered across bash into the dependency graph and turning it into proper packages was too painful. Now that this can be handed to an agent, it becomes very easy.

This product primarily serves agents

Coding agents are already opening more PRs per day than humans can review, and every PR gets stuck waiting on CI. Traditional CI runs the whole pipeline whether you changed one line or three hundred. The more agents push, the more waiting is wasted. So Vercel CI's pitch is straightforward: filter out tasks nobody touched.

The CLI and MCP are also built around how agents work. vc ci ls lists runs, vc ci inspect shows the tasks in a run, vc ci logs pulls logs, and vc ci grep searches a string across runs—for example, to check whether some test has been flaky all week. You can also tell an agent in the repo to run npx skills use vercel/ci@setup to configure it and open a PR itself. GitHub checks still appear on PRs as usual, and branch protection rules don't need to change.

The comment section is not letting the skipping go

Jeff Bruchado said skipping is great—until a bad cache hit hands an agent a green check it didn't earn.

auuutoo put it more concretely: turbo only recognizes the inputs you declared. If a task reads a file that isn't listed as a dependency, or reads an environment variable, it won't be triggered when that changes, and it will be skipped when it should run.

These two concerns aren't contrived. The whole model rests on the premise that “you declared the task's inputs.” If the declared boundary is wrong, caching is more dangerous than not caching.

Harjot Rana made an image that sums up the mood: the pipeline reaches the Tests step, the status is skipped, the note says “agent says they pass,” and a small line underneath says satire.

Vercel says that before GA it will add finer-grained test selection, stronger observability, and a vc ci command that can distribute tasks before push. The direction is clear: let agents open PRs themselves, run CI themselves, read logs themselves, and fix things themselves. Humans keep the branch protection field, click merge, or don't.