AI-Generated Code Demands Faster CI Pipelines

Continuous Integration and Continuous Deployment are often conflated into a single pipeline, but they answer different questions. CI asks "is this change correct?" by running lint, type checking, unit tests, and end-to-end tests before a PR merges. CD asks "is this change safe in production?" and handles deployment, rollout, and rollback after the merge. This article focuses on part 1: building a fast CI pipeline for frontend projects.

The traditional approach runs the entire test suite and build on every PR. For a typical monorepo app with a Dashboard, Settings page, Billing page, and shared components, changing a single line in Button.tsx triggers linting of every file, type-checking the whole project, running all 340 unit tests, and building the app—a 25-minute wait that cascades to every developer queued behind you. With AI now generating most code and favoring test generation, this exponential slowdown is becoming critical.

The author proposes computing which files are actually affected by the PR from the import graph. When Button.tsx changes, only Button's own tests and tests of files that import Button should run; Billing, which never imports Button, should not be touched at all. This requires three steps: first, ask git which files changed (git diff --name-only origin/main...HEAD); second, walk the import graph backward to find every file that directly or indirectly imports the changed files; third, hand that list to lint, typecheck, and test runners with wrapper scripts that handle three cases (everything changed, nothing changed, or the specific list).

A key implementation detail is that GitHub Actions path filters, which limit workflows to certain folders, do not scale—every feature requires a new workflow file, and every rename requires hunting down old references. Worse, required branch protection checks sit waiting forever if a workflow never starts, blocking merges on PRs that never touched those paths. The fix is to let every workflow run on every PR but conditionally skip jobs inside it.

The method works on a laptop but fails on the CI runner because actions/checkout uses fetch-depth: 1 by default, leaving only one commit and no origin/main to compare against. The solution is to set fetch-depth: 0 to bring down full history and filter: blob:none to skip file contents for commits you will never check out (git fetches them on demand if needed). The BASE_REF environment variable should also be set dynamically to origin/${{ github.base_ref }} rather than hardcoded, so that PRs targeting each other still work correctly.

With these changes, a button component change runs lint and typecheck on four affected files and test on two test files in seconds. A README change finishes all three jobs before npm finishes installing dependencies. Every required check reports a status on every PR, so no merge is blocked by a missing check. The article notes that dependency-cruiser can automate the import-graph walk by parsing TypeScript, reading tsconfig paths, and following dynamic imports, replacing the hand-written script with a single flag: npx depcruise src --affected origin/main --output-type json. The second part of the series will tackle CD—making rollout reversible.

The article identifies a real bottleneck: as AI generates code and especially tests, CI pipelines that run all checks on every PR create exponential slowdown. The problem is amplified by the structure of most CI workflows, which trigger on a path filter (e.g., only run Settings CI when src/features/settings/* changes). This approach fails at scale because it requires manual maintenance of workflow files for every feature, does not understand import relationships, and leaves required checks in a perpetual "waiting" state when they never start.

The author's solution inverts the problem. Instead of declaring which paths trigger which checks before examining the code, every workflow runs on every PR, but inside each job, a script analyzes git diff to find the changed files, then walks the import graph backward to compute which other files depend on those changes. Only the affected files are linted, type-checked, and tested. When a single button component changes, the script identifies the button's two importers and the tests covering them—four files total—rather than running every test in a 340+ test suite. When a README changes, all three jobs finish before npm finishes installing dependencies.

Google has already implemented a similar strategy, with the majority of its new code now AI-generated and engineer-approved. The article frames this as making "verification cheap and rollout reversible," which maps to the two halves of CI/CD: cheap verification here (only test what matters) and reversible rollout later (faster to roll back if a merged change breaks production).

No comments yet. Be the first to share your thoughts!