Claude Code CI and testing setup

Why CI matters more with an agent

On a solo human project you can sometimes get away with a loose CI setup - you remember what you changed, you notice when something looks off. With an agent in the loop, that slack disappears. The agent edits broadly, moves fast, and will confidently tell you a change is done when it has only confirmed that the code ran, not that it is correct.

Real gates close that gap. A type error, a failing test, or a lint violation that surfaces in CI is a fact the agent cannot talk its way past. The check fails, the agent reads the output, and it fixes the actual problem instead of declaring victory. This is the same discipline that runs through every part of a setup done right, from Claude Code best practices to the structure of the repo itself - automated truth beats good intentions every time.

The CI matrix, in order

A trustworthy pipeline is not one giant test step. It is a short sequence of independent gates, each one cheap and each one catching a different class of error:

• Install with a frozen lockfile - pnpm install --frozen-lockfile fails the build if the lockfile and package.json have drifted, so CI installs exactly what you committed and never silently resolves a different dependency tree.
• Type-check - tsc --noEmit across the project catches the whole category of mistakes that runtime tests miss: a renamed field, a wrong import, a shape that no longer matches.
• Build - a real production build proves the thing actually compiles and bundles, not just that the dev server tolerates it.
• Test - vitest run in CI mode (no watcher) executes your unit and integration tests and fails loudly on the first red.
• Lint - eslint enforces the rules a type-checker cannot, including the ones that keep an agent from quietly reformatting files or leaving dead code behind.
• Format-check - prettier --check verifies formatting without rewriting anything, so style is settled by a tool and never argued over in review.

Running these as distinct steps matters: when the build goes red you see which gate failed at a glance, instead of digging through one monolithic log. Keep each step fast and the agent gets feedback in a minute, not ten.

Green from commit one

The cheapest time to make CI pass is before there is anything to fix. If types, lint, tests, and the build are all wired and passing on the first commit, every later change is measured against a known-good baseline - a red build means you broke something just now, full stop. Bolt CI on three weeks in and you inherit a backlog of warnings everyone has already learned to ignore, which is the same as having no gate at all.

This is also where structure pays off. A Turborepo and pnpm monorepo lets the same matrix run across every workspace with caching, so adding a package extends the existing gates instead of standing up a new ad-hoc pipeline. The CI you set up at the start is the CI you keep.

Deploy verification, not blind deploys

Passing CI on a branch and shipping to production are two different claims. A build can be green and a deploy can still fail - a missing environment variable, a platform-specific build step, an output the host rejects. If nobody is watching, that failure is silent until a user finds it for you.

The fix is a deploy-check step that verifies the deploy actually succeeded after every push, so a failed deploy surfaces immediately instead of becoming a surprise. It is the same principle as the rest of the matrix, extended one stage further: confirm the real outcome, do not assume it. Treat a failed deploy verification exactly like a failed test - it blocks, and it gets read.

Where this fits in the whole setup

CI is one layer of a project that was set up correctly, and it leans on the others. It is far more useful next to a project where the conventions live in files the agent reads and the repo is structured for both humans and agents - which is exactly what a complete Claude Code project setup puts in place.

That is what claudesetup does in a single command: it scaffolds the full CI matrix - frozen-lockfile install, type-check, build, test, lint, and format-check - already green, with deploy verification wired in, alongside the monorepo and the context discipline the rest of the setup depends on. You start from a baseline that is genuinely correct, and you own every file of it.