Checklist
The 10-check vibe-coding safety net
Ten yes/no checks that turn a CI pipeline into the reviewer a solo founder or small team doesn't have. About a day of setup.
I'm starting to see the same pattern in products built fast with an AI assistant. They ship by hand, with no tests. A secret lands in the repository in week two, and the packages never get a review. When something breaks, nothing records what changed.
These ten checks make the pipeline act as the reviewer. They cost close to nothing and take about a day to set up. The starter workflow on this site covers most of them.
From the talk: Ship fast, break nothing: CI/CD for vibe-coded startups
The ten checks
Each yes scores one point.
- 1.We protect main. Every change arrives through a pull request, even with one approver. The pull request is where the pipeline gets to say no.
- 2.Format, lint, and type checks run on every pull request. The same rules apply to code from a human and code from an assistant.
- 3.Tests run and must pass. The assistant writes the tests too. The pipeline makes them count.
- 4.The build runs on every pull request. A change that doesn't build never reaches main.
- 5.Secret scanning with push protection is on. It blocks a key at git push, before it reaches the repository history.
- 6.Dependency review and updates run automatically. Dependency alerts, automated update pull requests (Dependabot or Renovate), and a dependency review on every pull request. This catches outdated and invented package names.
- 7.Static analysis runs. CodeQL or Semgrep. It catches unsafe query building, path handling, and other patterns assistants copy from old code.
- 8.Only the pipeline deploys, with OIDC. No cloud keys on a laptop, in a .env file, or in a chat window.
- 9.Every pull request gets a preview deployment. We click through the change before it goes live.
- 10.Production has an uptime check and error tracking. Problems reach us before customers email.
What the score means
| Score | Where we stand |
|---|---|
| 9 to 10 | A pipeline that can handle AI-written code. |
| 7 to 8 | Good. I'd close the gaps before the next big feature. |
| 0 to 6 | I'd start with protecting main, secret scanning, and OIDC deploys. They stop the mistakes that are hardest to undo. |
What I leave out on purpose
I leave out Kubernetes, extra environments beyond preview and production, a staging copy of the database, and end-to-end test suites. Each one costs more time than one person has. The ten checks above catch more for a lot less.
Next step
Under seven? I highly recommend a thirty-minute call with your repository on screen. I'll show which three checks to add first and which ones can wait. Which of the ten is missing in your repository today?
Book a callThese takeaways are an engineer's reading of the rules and the tools. I wrote them to help teams decide what to build. They aren't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.
Other takeaways from this talk
Template
Starter GitHub Actions workflow
A copy-ready CI workflow: lint, types, tests, build, dependency review, CodeQL, and an OIDC deploy from main with no stored keys.
Worksheet
DORA metrics in 15 minutes
A one-page sheet to measure deployment frequency, lead time, change failure rate, and time to restore from your Git and deploy history.
Policy template
Agent permissions in one page
What an AI coding agent may and may not do in your repository, cloud, and data, with how to enforce each line. Ready to copy into a policy.
Let's talk.
A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?
Prefer email or phone? hello@netninjas.eu or +31 6 45984313