QA & Release-Gates
KI-Agenten QA-Checkliste: So prüfst du Claude, Codex & Co. vor dem Merge
Gute AI-Agenten-Arbeit endet nicht beim Code. Sie endet erst, wenn Scope, Schutzbereiche, Tests, Diff und Live-Risiken geprüft sind.
Ein Coding-Agent kann in Minuten erledigen, was früher einen Nachmittag blockiert hat. Genau deshalb braucht der letzte Schritt mehr Disziplin, nicht weniger. Vor dem Merge zählt nicht, ob die Antwort überzeugend klingt, sondern ob der Stand nachprüfbar zum Auftrag passt. Wenn du die Aufgabe noch sauberer zuschneiden willst, passt dazu die AI-Agenten-Briefing Vorlage. Wenn du direkt das System dahinter sehen willst: AI Orchestrator ansehen.
Warum AI-Agenten-QA zählt
AI-Agenten scheitern selten spektakulär. Die gefährlichen Fehler sehen im Abschlussbericht harmlos aus: eine Datei zu viel, eine versteckte Änderung in der Konfiguration, ein erfolgreicher Test ohne Browserblick oder eine SEO-Seite, die plötzlich nicht mehr sauber indexierbar ist.
- Unrelated files: Der Agent verändert Nachbarbereiche, weil sie ähnlich aussehen.
- Keine Schutzbereich-Awareness: Kaufstrecke, Env oder Tracking werden wie normale Dateien behandelt.
- Versteckte Risikoflächen: Kleine Änderungen an Payment, Login oder E-Mail haben große Folgen.
- Tests ohne Sichtprüfung: Der Build läuft, aber mobile Layout, Header oder CTA sind beschädigt.
- SEO-Regressions: Canonical, Robots, Sitemap oder interne Links passen nicht mehr zusammen.
- Unklare Akzeptanz: Es sieht fertig aus, aber die ursprünglichen Kriterien fehlen im Bericht.
Die QA-Checkliste vor Merge oder Live-Gang
Die folgende Tabelle ist der Kern. Sie ist bewusst praktischer als theoretisch: Was prüfen, warum es zählt und wann der Punkt grün ist.
Tabelle horizontal scrollen, um alle Spalten zu sehen.
| Bereich | Was prüfen? | Warum? | Grün wenn |
|---|---|---|---|
| Scope check | Passt der Diff zur beauftragten Aufgabe und bleiben Nicht-Ziele unangetastet? | Agenten optimieren sonst gern den umliegenden Code gleich mit. | Nur vereinbarte Bereiche sind geändert; keine fremden Oberflächen tauchen im Diff auf. |
| Diff check | Dateien, Zeilen und neue Abhängigkeiten bewusst lesen, nicht nur die Zusammenfassung. | Der Abschlussbericht kann plausibel klingen, obwohl der Diff etwas anderes tut. | Jede Änderung ist erklärbar und hängt direkt an einem Akzeptanzkriterium. |
| Schutzbereiche | Kaufstrecke, Stripe, Env, Auth, DB, E-Mail, Recht, Tracking und Security gesondert prüfen. | Kleine unbeabsichtigte Änderungen in diesen Bereichen haben große Folgen. | Keine Schutzbereiche geändert oder explizit beauftragt und strenger geprüft. |
| Test commands | Die im Projekt gültigen Checks ausführen, nicht erfundene Befehle melden. | Ein grüner erfundener Test ist schlimmer als ein ehrlich fehlender Test. | Befehle, Exit Codes und relevante Hinweise sind im Bericht genannt. |
| Browser smoke | Die betroffenen Seiten sichtbar öffnen: Desktop, mobile, Konsole, Klickpfade. | Lokale Tests finden nicht jedes Layout-, Routing- oder Hydration-Problem. | Keine Console Errors, kein horizontaler Overflow, zentrale CTAs funktionieren. |
| Indexability & Sitemap | Canonical, Robots, Sitemap, interne Links und noindex-Regeln vergleichen. | SEO-Seiten können korrekt aussehen und trotzdem nicht indexierbar sein. | Öffentliche Seiten sind index/follow und in der Sitemap; versteckte Tools bleiben draußen. |
| Accessibility & Mobile | Eine Tastatur- und Mobile-Prüfung für neue Controls, Tabellen und Accordions machen. | AI-Ausgaben erzeugen gern schöne, aber schlecht bedienbare Oberflächen. | Controls sind erreichbar, lesbar und ohne rohe Browser-Defaults gestaltet. |
| Release gate | Vor Merge oder Live-Gang prüfen, ob alle Gates grün und Risiken dokumentiert sind. | Ein Merge ist eine Produktentscheidung, nicht nur ein Git-Befehl. | QA grün, Schutzbereiche sauber, Diff verständlich, Release-Pfad klar. |
| Report quality | Der Bericht nennt Dateien, Tests, Browser-Check, Risiken und offene Punkte konkret. | Ohne prüfbaren Bericht kann niemand entscheiden, ob der Stand tragfähig ist. | Eine andere Person kann den Stand anhand des Berichts nachvollziehen. |
Das Ziel ist nicht maximale Bürokratie, sondern ein klares Ja oder Nein: Kann dieser Stand übernommen werden?
QA nach Risikostufe strukturieren
Nicht jede Aufgabe braucht dieselbe Härte. Ein Textlink auf einer Guide-Seite ist anders zu behandeln als eine Änderung an Kaufstrecke oder Auth. Teile Agenten-Aufgaben deshalb vor der Umsetzung in drei Stufen ein. Für die Tool-Entscheidung nach Aufgabe und Risiko ergänzt der Vergleich Claude Code vs. Codex diese Checkliste.
Low Risk
Typisch: Copy, interne Links, kleine visuelle Politur ohne Logikänderung
Gate: Diff lesen, relevante Seite öffnen, Fokus-Test oder Build ausführen, Bericht prüfen.
Medium Risk
Typisch: Öffentliche Seiten, SEO/Indexability, shared Header, generierte Reports
Gate: Build, SEO-Checks, Browser-Smoke auf Desktop und Mobile, Link- und Sitemap-Prüfung.
High Risk
Typisch: Kaufstrecke, Stripe, Env, DB, Auth, E-Mail, Recht/Steuer, Tracking, Security
Gate: Strenger Gate mit explizitem Scope, Review durch Menschen, keine stillen Nebenänderungen.
High-Risk-Arbeit braucht fast immer engere Grenzen und manchmal eine explizite Freigabe vor der Umsetzung. Wenn ein Agent in einem sensiblen Bereich landet, obwohl die Aufgabe dort nichts zu suchen hatte, ist das kein kleiner Stilbruch, sondern ein Stop-Signal.
Was einen Abbruch oder Rework auslösen sollte
Gute QA sagt nicht nur, wann etwas grün ist. Sie sagt auch, wann du stoppst. Diese Kriterien sollten nicht wegdiskutiert werden:
- Falsches Repository, falscher Branch oder unklarer Remote.
- Dirty Worktree mit fremden Änderungen im betroffenen Bereich.
- Schutzbereiche ändern sich, obwohl sie nicht beauftragt wurden.
- QA schlägt fehl oder ein Test wird übersprungen, ohne es klar zu melden.
- Sitemap, Robots oder Canonical regressieren.
- Noindex-Tools werden öffentlich verlinkt oder landen in der Sitemap.
- Kaufstrecke, Payment, Env oder Tracking werden unbeabsichtigt berührt.
- Browser-Smoke zeigt Console Errors, kaputte CTAs oder horizontalen Overflow.
Kompaktes Beispiel für ein QA-Gate
Das ist absichtlich nur ein kleines Beispiel, kein vollständiges Paket. Es zeigt die Haltung: Befehle ausführen, Grenzen prüfen, Browser-Smoke einfordern und einen konkreten Bericht verlangen.
Run:
npm run check
npm run build
npm run qa:seo
npm run buyer:check
git diff --check
Accept only if:
- QA exits 0
- no protected files changed
- browser smoke passes
- report lists exact changed filesWie AI Orchestrator daraus wiederverwendbare Workflows macht
Einzelne Checklisten helfen. Noch stärker wird es, wenn Scope, Schutzbereiche, QA-Gates, Release-Muster und Abschlussberichte als wiederverwendbare Workflows im Projekt liegen. AI Orchestrator bündelt genau diese Bausteine: klare Agenten-Aufgaben, geschützte Bereiche, Prüfpfade für öffentliche Seiten, SEO/Indexing-Watchdog und Founder-Workflow-Systeme, die nicht in jeder Session neu erklärt werden müssen.
Starte bei den KI-Guides, nutze die Briefing-Vorlage für die nächste Aufgabe oder sieh dir die Pakete an. Für Produktfragen steht außerdem die FAQ bereit.
Häufige Fragen
Warum brauche ich QA, wenn der AI-Agent Tests ausführt?
Weil Tests nur den Teil prüfen, den sie abdecken. Ein Agent kann Tests ausführen und trotzdem den falschen Scope ändern, eine Seite visuell beschädigen, Canonicals verschieben oder einen Schutzbereich anfassen. QA verbindet Tests mit Diff-Lesen, Browser-Smoke und Release-Urteil.
Was ist der Unterschied zwischen Low-Risk und High-Risk Tasks?
Low-Risk Tasks betreffen meist Text, interne Links oder begrenzte Oberflächen. High-Risk Tasks berühren Bereiche mit Folgekosten: Zahlung, Env, Auth, Datenbank, E-Mail, rechtliche Texte, Tracking oder Security. Je höher das Risiko, desto enger Scope, Review und Freigabe.
Muss ich jeden AI-Agenten-Output manuell prüfen?
Nicht jede Zeile braucht dieselbe Tiefe, aber jede Aufgabe braucht ein passendes Gate. Bei kleinen Textänderungen reicht oft Diff, Build und Seitenblick. Bei sensiblen Bereichen brauchst du menschliches Urteil, nachvollziehbare Tests und meist eine explizite Freigabe vor Merge oder Live-Gang.
Was gehört in einen guten Abschlussbericht?
Ein guter Bericht nennt Branch, Commit, geänderte Dateien, ausgeführte Checks mit Exit Codes, Browser-Smoke, sichtbare Risiken, nicht geprüfte Punkte und die genaue Empfehlung. Er sagt nicht nur, dass etwas fertig ist, sondern warum der Stand akzeptiert werden kann.
Kann ich die Checkliste für Claude und Codex nutzen?
Ja. Die Checkliste ist toolneutral. Claude, Codex, ChatGPT und andere Coding-Agenten unterscheiden sich in Bedienung und Kontextregeln, aber die Abnahme bleibt ähnlich: Scope, Diff, Schutzbereiche, Tests, Browser, Indexability und Release-Gate.
Ist die Checkliste ein Ersatz für Entwicklung?
Nein. Sie strukturiert die Prüfung von KI-Arbeit und macht Entscheidungen nachvollziehbarer. Fachliche Verantwortung, Produkturteil und technisches Review bleiben bei dir oder deinem Team.
Wie hilft AI Orchestrator dabei?
AI Orchestrator bündelt wiederverwendbare Aufgabenformate, Schutzbereich-Regeln, QA-Gates, Release-Muster und SEO/Indexing-Prüfungen als lokale Workflows. So muss der Ablauf nicht in jeder Agenten-Session neu erfunden werden.