The Automation Cliff: 0.7% of Opus 4.7 Repos Have CI

We’ve written before about the test-writing gap and the test-CI disconnect. The numbers keep getting worse the closer you look.

The cliff

Of 12,095 Opus 4.7 repos:

Under 1% of the corpus has any CI configuration. Even among the 3,229 test-having repos, CI is still rare.

What this looks like in practice

Pick a random Opus 4.7 repo. Likely scenario:

• package.json declares a test script: "test": "vitest" ✓
• Tests exist in src/__tests__/ ✓
• tests/ directory has test files ✓
• GitHub repo has no Actions workflow ✗
• Nothing runs tests automatically on push ✗
• Nothing checks that the build passes on PR ✗
• No deploy-on-main wiring ✗

The repo looks “complete” to a casual observer. It isn’t, operationally.

Why the cliff is so steep

Three structural reasons:

1. CI is the “last 10%” of project setup

Writing a feature → running it locally → seeing it work is linear. Writing CI is a separate cognitive leap:
- Define a workflow file format
- Declare when it runs (push, PR)
- Install dependencies
- Invoke the test runner
- Handle secrets / environment variables

Each step is trivial. The cumulative ritual is non-trivial, and AI agents terminate before they reach it.

2. “It works on my machine” is sufficient for the generation

Most “build me X” prompts result in a working local dev environment. The prompter sees npm run dev, sees the app load, declares victory. CI would add confidence for other contributors or future sessions — but the prompter isn’t asking about that.

3. CLAUDE.md usually doesn’t specify a CI requirement

Looking at sampled CLAUDE.md files, common sections are “how to run”, “how to test”, “project structure.” Rarely “how the CI works” or “always add CI for new features.” The agent’s self-memory doesn’t reinforce CI habits.

The specific workflow-file findings

Of the 84 repos that DO have .github/workflows/, common patterns:

• Run npm test or pnpm test on push to main
• Set up Node version via .nvmrc value
• Use actions/setup-node@v4 + actions/checkout@v4 (the current canonical actions)
• Sometimes include npm run lint + npm run typecheck as separate steps
• Rarely include a matrix across Node versions (usually just one)

These are solid, minimal, correct workflows. When Opus 4.7 writes CI, it writes good CI. The issue is that it almost never writes CI.

Cost of this gap

The cliff has real downstream effects:

• Stale tests: without CI, tests silently break as code evolves. The test file exists; it passes locally once; then it rots.
• Dependency drift: no automated check that npm install still works on a clean Linux box. New contributors hit package-lock mismatches.
• Build regressions: code that builds locally but not in Docker, or in a different Node version, isn’t caught until manual deploy time.
• Security patches skipped: no Dependabot integration without workflow scaffolding means security updates don’t surface.

How to fix it

For Opus 4.7 / Claude Code

The simplest intervention: a Claude Code “ship ready” skill that, given a repo with package.json, produces .github/workflows/ci.yml:

name: CI
on:
  push:
    branches: [main]
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run typecheck || true
      - run: npm run lint || true
      - run: npm test

10 lines of YAML, would fix 80%+ of the CI gap. A single “/ship” or “/prepare-for-production” agent command could do this for any repo.

For downstream distillation

If you’re pulling training data from the Opus 4.7 corpus and want to study “production-ready” patterns, filter to the 84 CI-having repos. That subset is where Opus 4.7 has demonstrably been taken to completion by a human collaborator.

For the ecosystem

This is a standards opportunity. A companion file like CLAUDE.md but specifically for deployment pipelines — a machine-readable spec that an agent can use to scaffold CI, Docker, and deploy config consistently.

The broader pattern

Combine:

• 59% have no tests
• 93% have no CI
• 81% have no LICENSE
• Generally: “build the feature” happens, “prepare for production” doesn’t

Opus 4.7’s default posture is demo-ready, not ship-ready. A single-prompt “feature complete” check ends at “runs locally.” Everything that matters for shipping is left to the human.

This is fixable, but it’s fixable at the tooling level, not the model level. The model will happily write CI when asked. It’s not being asked.

Related: Why 59% of Opus 4.7 Repos Have No Tests and Opus 4.7’s Blind Spot.