CI/CD für AI-generierte Features: Verification als Pipeline-Step

AI-generierter Code braucht ein Verification-Gate in der Pipeline. Konkrete GitHub Actions und GitLab CI Configs für Intent-Based Verification mit Aletiq.

René Nowotny

— 7 min read
CI/CD für AI-generierte Features: Verification als Pipeline-Step

AI-generierte Änderungen brauchen einen Verification-Gate in der CI/CD-Pipeline — sonst landen Bugs direkt in Production. Aletiq lässt sich als Pipeline-Step in GitHub Actions und GitLab CI einbinden: Kein Merge ohne PASS auf allen kritischen Intents. Setup in 10 Minuten, keine Testdateien, keine Selektoren.

Dieser Artikel zeigt die konkrete Einrichtung: YAML-Configs für GitHub Actions und GitLab CI, welche Intents als Gate laufen sollten, wie du mit FAIL und UNCLEAR umgehst — und wie dein AI-Agent Pipeline-Failures selbst fixt.

Warum reicht die bestehende CI/CD-Pipeline nicht für AI-generierten Code?

Weil die typische Pipeline syntaktische Korrektheit prüft — nicht funktionale. Und AI-generierter Code ist fast immer syntaktisch korrekt.

Was deine Pipeline heute wahrscheinlich prüft:

  • Linting — Code-Style, Formatting, Import-Reihenfolge. AI-Agents produzieren sauber formatierten Code. Linting findet keine funktionalen Bugs.
  • Type-Checking — TypeScript-Compiler prüft Typen. AI-generierter Code besteht Type-Checks, weil Agents TypeScript verstehen. Ein Button ohne onClick-Handler ist typkorrekt — aber funktional tot.
  • Unit-Tests — Prüfen isolierte Funktionen. Wenn der Agent eine UI-Komponente refactored, laufen die Unit-Tests für die Backend-Logik weiterhin grün. Dass die Navigation kaputt ist, sieht kein Unit-Test.
  • Build — Kompiliert das Projekt. AI-generierter Code kompiliert fast immer. „Compiles" heißt nicht „funktioniert".

Was deine Pipeline nicht prüft:

  • Führt der CTA zur richtigen Seite?
  • Funktioniert der Checkout-Flow end-to-end?
  • Laden die Dashboard-Daten nach dem Login?
  • Sind alle Navigationslinks intakt?

Diese funktionalen Fragen beantwortet kein Linter, kein Type-Checker und kein Unit-Test. Dafür brauchst du eine Schicht, die die laufende Anwendung beobachtet — ein Verification-Gate.

Was ist ein Verification-Gate?

Ein Pipeline-Step, der PRs blockiert, wenn kritische Software-Flows nicht mehr funktionieren. Nicht basierend auf Test-Code, sondern auf Intents in natürlicher Sprache.

Der Ablauf:

  1. Entwickler (oder AI-Agent) pusht Code und erstellt eine PR
  2. Pipeline startet: Lint → Build → Unit-Tests → Verification-Gate
  3. Verification-Gate: Aletiq startet die App, verifiziert definierte Intents, gibt Verdicts
  4. Alle PASS → PR kann gemergt werden
  5. Ein oder mehr FAIL → PR wird blockiert, Entwickler sieht Verdicts mit Begründung

Der Unterschied zu einem klassischen E2E-Test-Step: Kein Testcode der gewartet werden muss. Die Intents sind stabile Beschreibungen in natürlicher Sprache — sie veralten nicht, wenn der AI-Agent die UI umschreibt. Ein Intent wie „The checkout flow should be completable" funktioniert unverändert über Monate und Jahre, egal wie oft die Implementierung sich ändert.

Das Verification-Gate ist die letzte Verteidigungslinie vor Production. Linting fängt Style-Probleme, Type-Checking fängt Typ-Fehler, Unit-Tests fangen Logik-Fehler. Das Verification-Gate fängt: „Die Software tut nicht mehr, was sie soll."

Wie sieht ein Aletiq-Step in GitHub Actions aus?

Eine konkrete, copy-paste-fähige Config:

name: Verify
on: [pull_request]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Build and start app
        run: |
          npm run build
          npm start &
          npx wait-on http://localhost:3000 --timeout 60000

      - name: Run verification gate
        env:
          ALETIQ_API_KEY: ${{ secrets.ALETIQ_API_KEY }}
        run: |
          aletiq verify "All main navigation links lead to their respective pages" \
            --url http://localhost:3000

          aletiq verify "The signup flow is completable" \
            --url http://localhost:3000/signup

          aletiq verify "The pricing page displays all plans with working CTAs" \
            --url http://localhost:3000/pricing

          aletiq verify "The login flow works and leads to the dashboard" \
            --url http://localhost:3000/login

          aletiq verify "The primary CTA navigates to signup" \
            --url http://localhost:3000

Was passiert:

  1. Checkout und Dependency-Installation (Standard)
  2. App wird gebaut und gestartet
  3. wait-on wartet bis die App auf Port 3000 erreichbar ist
  4. Aletiq verifiziert 5 kritische Intents gegen die laufende App
  5. Bei FAIL: Step schlägt fehl, PR wird blockiert

Der API-Key wird als GitHub Secret gespeichert — nicht im Code. Die Intents stehen direkt in der Pipeline-Config — kein separates Testverzeichnis, keine Testdateien.

Wie sieht ein Aletiq-Step in GitLab CI aus?

Dasselbe Prinzip, GitLab-Syntax:

verify:
  stage: verify
  image: node:20
  variables:
    ALETIQ_API_KEY: $ALETIQ_API_KEY
  script:
    - npm ci
    - npm run build
    - npm start &
    - npx wait-on http://localhost:3000 --timeout 60000
    - |
      aletiq verify "All main navigation links lead to their respective pages" \
        --url http://localhost:3000
      aletiq verify "The signup flow is completable" \
        --url http://localhost:3000/signup
      aletiq verify "The pricing page displays all plans with working CTAs" \
        --url http://localhost:3000/pricing
      aletiq verify "The login flow works and leads to the dashboard" \
        --url http://localhost:3000/login
      aletiq verify "The primary CTA navigates to signup" \
        --url http://localhost:3000
  only:
    - merge_requests

Die Config ist nahezu identisch. Der API-Key wird als GitLab CI Variable konfiguriert (Settings → CI/CD → Variables). Die Intents sind dieselben — plattformunabhängig, weil sie die App beschreiben, nicht die CI-Plattform.

Welche Intents sollten als CI-Gate laufen?

Nicht alle — nur die, deren Ausfall echten Schaden verursacht. Ein Verification-Gate das 50 Intents prüft wird zum Pipeline-Blocker. Eines das 5 kritische Flows prüft ist ein Sicherheitsnetz.

Immer als CI-Gate (Prio 1):

# Diese Flows dürfen nie kaputt sein
aletiq verify "The signup/registration flow is completable"
aletiq verify "The login flow works and leads to the dashboard"
aletiq verify "The main navigation leads to all major sections"
aletiq verify "The primary conversion CTA works correctly"

Bei relevanten Änderungen als CI-Gate (Prio 2):

# Diese Flows sind wichtig, aber nicht bei jedem PR nötig
aletiq verify "The checkout flow is completable"        # nur bei E-Commerce-Changes
aletiq verify "The settings page allows profile updates" # nur bei Settings-Changes
aletiq verify "The search returns relevant results"      # nur bei Search-Changes

Nicht als CI-Gate (Dev-Loop statt Pipeline):

  • Styling-Checks — verlangsamen die Pipeline ohne kritischen Schutz
  • Content-Verification — „Zeigt die About-Seite den richtigen Text?" ist kein Merge-Blocker
  • Edge-Case-Flows — „Funktioniert Passwort-Reset?" ist wichtig, aber nicht PR-blockierend

Faustregel: Maximal 5 bis 8 Intents als CI-Gate. Alles weitere im Dev-Loop über MCP-Integration. Wie du die MCP-Integration einrichtest: MCP-Server für Testing.

Wie schnell ist Verification in der Pipeline?

Schnell genug, dass du es nicht merkst. Aletiq verifiziert einen Intent in durchschnittlich 4,5 Sekunden.

Rechenbeispiel für 5 Intents:

SzenarioDauer
5 Intents sequentiell~23 Sekunden
5 Intents parallelisiert~5-8 Sekunden
8 Intents sequentiell~36 Sekunden
8 Intents parallelisiert~8-12 Sekunden

Zum Vergleich: Eine typische Playwright-Suite mit 20 E2E-Tests dauert 2 bis 5 Minuten. npm install dauert oft länger als die gesamte Verification.

Parallelisierung:

Intents die verschiedene Seiten prüfen können parallel laufen. In GitHub Actions:

- name: Run verification gate
  run: |
    aletiq verify "Navigation works" --url http://localhost:3000 &
    aletiq verify "Signup works" --url http://localhost:3000/signup &
    aletiq verify "Pricing shows plans" --url http://localhost:3000/pricing &
    aletiq verify "Login works" --url http://localhost:3000/login &
    aletiq verify "CTA navigates to signup" --url http://localhost:3000 &
    wait

Alle 5 Intents laufen gleichzeitig. Gesamtdauer: die Dauer des langsamsten Intents — typischerweise unter 8 Sekunden.

Was passiert bei FAIL in der Pipeline?

Der Pipeline-Step schlägt fehl, die PR wird blockiert und der Entwickler sieht das Verdict mit einer konkreten Begründung.

Beispiel-Output bei FAIL:

✗ FAIL: "The signup flow is completable"

Reason: The signup form is present and accepts email input, but clicking
the "Create Account" button navigates to /404 instead of completing the
registration. The submit action appears to reference a route that does
not exist.

Evidence: Screenshots attached (before click, after click showing 404 page)

Der Entwickler — oder AI-Agent — sieht sofort: Das Problem ist ein falscher Route-Link im Signup-Button. Kein kryptischer Selector-Error, kein „Expected true, received false". Sondern eine klare Beschreibung, was kaputt ist und warum.

Der Fix-Workflow:

  1. Entwickler liest Verdict in der PR
  2. Fixt das Problem (oder lässt den Agent fixen)
  3. Pusht den Fix
  4. Pipeline re-runs automatisch
  5. Verification-Gate: PASS → PR kann gemergt werden

Kein manuelles Re-Triggering, kein „Ignore failed check". Die Pipeline erzwingt, dass die kritischen Flows funktionieren, bevor Code in den Main-Branch geht.

Was mache ich mit UNCLEAR-Verdicts in CI?

UNCLEAR bedeutet: Die Multi-Model-Jury konnte sich nicht einstimmig auf PASS oder FAIL einigen. In einer CI-Pipeline musst du entscheiden, wie du damit umgehst.

Option 1: UNCLEAR = Block (konservativ)

Behandle UNCLEAR wie FAIL. Die PR wird blockiert, ein Mensch schaut drauf. Sicherer, aber kann bei ambivalenten Intents die Pipeline unnötig blocken.

Option 2: UNCLEAR = Pass (pragmatisch)

Nur FAIL blockiert den Merge. UNCLEAR wird als Warning geloggt, aber die Pipeline läuft durch. Pragmatischer, aber ein echter Bug könnte als UNCLEAR durchrutschen.

Empfehlung:

Starte mit UNCLEAR = Block und präzisiere deine Intents, bis UNCLEAR selten wird (unter 5 Prozent). Je spezifischer der Intent, desto seltener UNCLEAR. „The page should work" produziert häufig UNCLEAR. „The signup form should accept an email and show a success message on submit" produziert fast nie UNCLEAR.

Wenn dein UNCLEAR-Rate nach Intent-Optimierung unter 2 Prozent liegt, kannst du auf UNCLEAR = Pass wechseln — die verbleibenden UNCLEAR-Fälle sind dann Edge Cases, keine echten Risiken.

Mehr zu UNCLEAR-Handling und Intent-Optimierung: Wie teste ich Code, den mein AI-Agent geschrieben hat?

Kann der AI-Agent den Pipeline-Fix selbst übernehmen?

Ja — und das schließt den Automation-Kreis: Agent baut, Pipeline verifiziert, Agent fixt, Pipeline verifiziert erneut. Keine menschliche Intervention für funktionale Fixes.

Der Ablauf:

  1. Agent pusht Code → Pipeline startet → Verification-Gate: FAIL
  2. Agent liest das Verdict aus der Pipeline (über GitHub API oder CI-Notifications)
  3. Agent versteht das Problem: „Signup button navigates to /404 instead of completing registration"
  4. Agent fixt den Route-Link und pusht erneut
  5. Pipeline re-runs → Verification-Gate: PASS
  6. PR ist bereit zum Merge

Dieses Pattern funktioniert besonders gut mit Claude Code, das über MCP sowohl lokal verifizieren (im Dev-Loop) als auch Pipeline-Verdicts lesen und darauf reagieren kann. Der Agent lernt aus Pipeline-Failures und produziert beim nächsten Mal besseren Code.

Die lokale MCP-Integration reduziert Pipeline-Failures massiv: Wenn der Agent bereits im Dev-Loop verifiziert, fängt er die meisten Bugs bevor sie die Pipeline erreichen. Die Pipeline wird zum Sicherheitsnetz, nicht zum Haupt-Feedback-Kanal.

Wie der Self-Verification-Loop im Detail funktioniert — mit Code-Beispielen für Claude Code, Cursor und Copilot: MCP-Server für Testing und Claude Code vs. Cursor vs. Copilot.

Wie richte ich das Verification-Gate ein?

In 10 Minuten — drei Schritte:

Schritt 1: API-Key als CI-Secret speichern

GitHub: Settings → Secrets → Actions → New Secret → Name: ALETIQ_API_KEY

GitLab: Settings → CI/CD → Variables → Add Variable → Key: ALETIQ_API_KEY

Schritt 2: Pipeline-Config einfügen

Kopiere die GitHub Actions oder GitLab CI Config aus diesem Artikel in dein Repository. Passe die Intents an deine App an — ersetze die Beispiel-Intents durch deine kritischen Flows.

Schritt 3: Erste PR erstellen und verifizieren

Erstelle eine Test-PR, um den Pipeline-Step zu validieren. Du siehst: Pipeline läuft, Verification-Gate gibt Verdicts, PR wird freigegeben oder blockiert.

Optimierungs-Tipps:

  • Starte mit 3 bis 5 Intents — erweitere nach Bedarf
  • Parallelisiere Intents für minimalen Pipeline-Impact
  • Kombiniere mit MCP-Integration im Dev-Loop — die meisten Bugs werden lokal gefangen, Pipeline-FAILs werden selten

Wie du Intents formulierst, die selten UNCLEAR produzieren: Intent-Based Testing erklärt. Wie Aletiq sich von klassischen E2E-Tests in der Pipeline unterscheidet: Playwright vs. Aletiq. Der vollständige Tool-Vergleich: Diffblue, TestSprite oder Aletiq. Und warum du das Verification-Bottleneck lösen solltest: Mein AI-Agent baut schneller als ich reviewen kann.

Free Tier: 50 Verifications pro Monat — genug für circa 10 PRs mit 5 Intents pro PR.

Füge das Verification-Gate jetzt in deine Pipeline ein — in 10 Minuten ist kein AI-generierter Bug mehr einen Merge von Production entfernt.

Read more