What is CI/CD and why do I need it for vibe coding?

What does CI/CD mean?

The abbreviation stands for two things that belong together:

• Continuous integration (CI): every change is automatically merged, built and tested – not just shortly before the release.
• Continuous delivery or deployment (CD): whatever passes all checks is ready for approval (delivery) or is shipped automatically (deployment).

Think of an assembly line with quality control: no part leaves the hall without passing the inspection stations. If a station fails, the line stops – before the faulty part reaches the customer.

Why especially for vibe coding?

If you build with Cursor, Lovable or Claude Code, you're fast. That's exactly the risk:

• AI produces more code than people read. A change to the sign-in can break invoicing on the side – and nobody notices.
• It happens that keys end up directly in the code, or that outdated libraries with known security vulnerabilities get built in.
• Without a test pipeline, all of this only shows up when users complain.

With a test pipeline, it shows up on the next push. The team stays as fast as before – just with guardrails.

The stages of a test pipeline

1. Build: Can the app be built at all?
2. Test: Do the most important workflows still work – sign-in, saving, payment?
3. Check the code: Linters and type checks find typical bugs before they run.
4. Check security: A secret scan looks for passwords and keys, a dependency check for known vulnerabilities in the libraries you use.
5. Try it out: The change runs on a test environment before real users see it.
6. Approve: A human signs off.
7. Ship and verify: After the release, a short smoke test checks that everything is reachable.
8. Roll back: If something does go wrong, the previous version is back within minutes.

What does that look like in practice?

On GitHub the tool is called GitHub Actions, on GitLab it's GitLab CI. A first, simple test pipeline for a Node project can look like this – as the file .github/workflows/checks.yml:

name: Checks
on:
  pull_request:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm audit --audit-level=high

The commands npm run lint and npm test assume that your project defines these scripts. A secret scan, for example with gitleaks, comes in as an additional step. Test environment, approval and delivery depend on where your app runs – many hosts offer preview environments per change.

What CI/CD can't do

• Tests only find what they check. Without tests for the important workflows, the pipeline is an assembly line without inspectors.
• It doesn't replace understanding. But it prevents things nobody understands from going live unchecked.
• It needs maintenance. If runs stay red and everyone ignores them, the pipeline protects nothing anymore.

How to start small

1. Protect the main branch: changes only via pull request or merge request.
2. Set up a workflow that builds the app and runs a test for the most important workflow.
3. Add a secret scan and a dependency check.
4. Give every change a test environment.
5. Decide who approves and how you roll back.

A tip for AI assistants: write down in the project rules – for example in a CLAUDE.md or in the Cursor rules – that every change must pass the test pipeline. Then the AI knows what to stick to, too.