Was sind Quality Gates für KI Code?

Quality Gates sind automatisierte Prüfpunkte im Entwicklungsprozess, die KI generierten Code gegen definierte Standards testen, bevor er gemergt oder deployt wird. Jedes Gate hat ein klares Bestanden oder Durchgefallen Kriterium: Linting Regeln, Typprüfung, Testabdeckung, Security Scans oder Review durch einen separaten Agent.

Bei klassischer Entwicklung waren Quality Gates eine Absicherung gegen menschliche Flüchtigkeitsfehler. Bei KI generiertem Code werden sie zur tragenden Struktur, denn der Autor eines Vibe Coding Pull Requests versteht den Diff oft nicht Zeile für Zeile. Der Code liest sich flüssig, die Variablennamen passen zum Projekt, und genau diese Flüssigkeit täuscht Sorgfalt vor, die nie stattgefunden hat. Ein Gate prüft nicht den Eindruck, sondern das Verhalten.

Quality Gates sind das Gegenstück zur Rules Datei: Die CLAUDE.md oder AGENTS.md beschreibt, wie der Agent arbeiten soll, das Gate stellt sicher, dass er es auch getan hat.

Never Code Alone betreibt Quality Gates nicht als Theorie, sondern täglich im eigenen Stack: PHPStan und Psalm als statische Analyse für PHP Projekte, Ruff und mypy für Python, Cypress als E2E Gate und GitHub Actions als CI Backbone. Jeder Agent Run auf nevercodealone.de läuft gegen diese Prüfungen, bevor etwas live geht.

Aus dieser Praxis helfen wir Teams, ihren eigenen Gate Stack aufzubauen: von der sauberen Rules Datei über Review Workflows mit KI Agenten und abgesicherte Vibe Coding Security bis zur Begleitung im Vibe Coding Consulting, wenn ein Projekt vom Prototyp in Production soll. Auch festgefahrene Projekte ohne jedes Gate holen wir zurück auf Kurs.

Klassisches Code Review basiert auf einer Annahme: Der Autor hat stundenlang über die Änderung nachgedacht, der Reviewer ergänzt ein zweites Augenpaar. KI generierter Code bricht diese Annahme. Der Agent hat den Diff in Sekunden erzeugt, Edge Cases wurden nicht durchdacht, sondern aus einer Verteilung gesampelt. Eine Stanford Studie von Perry et al. zeigte bereits 2023, dass Entwickler mit KI Assistenten unsichereren Code schrieben und ihn gleichzeitig für sicherer hielten als die Kontrollgruppe.

Dazu kommt das Volumen: Ein Team mit KI Agenten produziert ein Vielfaches der täglichen Diff Menge. Manuelles Review skaliert damit nicht, es wird zum Flaschenhals oder zur Formalie. Die typischen Muster sind aus den Vibe Coding Risiken bekannt: hardcodierte Credentials, halluzinierte Pakete, fehlende Eingabevalidierung. All das sind Fehler, die ein Gate deterministisch fängt, ein müder Reviewer aber übersieht.

Die Konsequenz: Verifikation wird zur knappen Ressource, nicht Codegenerierung. Teams, die KI Coding skalieren, unterscheiden sich nicht durch schnellere Agents, sondern durch belastbare Prüfschichten.

Quality Gates bauen aufeinander auf, vom schnellen Syntax Check bis zur Verhaltensprüfung. Jedes Level fängt eine andere Fehlerklasse, und keines ersetzt das andere. Wer nur Level 1 betreibt, hat formatierten unsicheren Code. Wer Level 4 ohne die unteren Ebenen startet, verbrennt Review Kapazität mit Fehlern, die ein Linter in Millisekunden gefunden hätte. Die Reihenfolge ist bewusst: billige, schnelle Prüfungen zuerst, teure zuletzt.

Eine Rules Datei wie CLAUDE.md oder AGENTS.md ist der erste Schritt, aber sie ist eine Bitte an den Agent, keine Garantie. Agents übersehen Regeln, besonders in langen Sessions, wenn das Context Window voll läuft. Jede Regel, die sich automatisiert prüfen lässt, gehört deshalb doppelt abgesichert: als Regel in der Datei und als Gate in der Pipeline.

Das Muster aus der Praxis: Steht in der CLAUDE.md die Regel, dass alle Funktionen explizite Return Types brauchen, dann erzwingt ein tsc oder PHPStan Gate genau das. Steht dort eine Test Pflicht für jede neue Klasse, blockiert ein Coverage Gate den Merge ohne Tests. Der Agent bekommt die Fehlermeldung des Gates als Feedback und korrigiert selbst, ganz ohne menschliches Eingreifen. So entsteht der Loop, den auch Code Qualität mit KI Agenten beschreibt: Regel definieren, Verstoß erkennen, Regel schärfen.

Wichtig ist die Arbeitsteilung: Das Gate prüft, was deterministisch prüfbar ist. Die Rules Datei übernimmt, was sich nicht automatisieren lässt, also Architekturentscheidungen, Namenskonventionen mit Kontext und projektspezifische Ausnahmen. Wer versucht, alles in Gates zu gießen, produziert False Positives, die das Team ignorieren lernt. Wer alles der Rules Datei überlässt, hat keine Verbindlichkeit.

Lokale Prüfungen sind gut, aber umgehbar. Verbindlich wird ein Gate erst in der CI: GitHub Actions oder GitLab CI führen bei jedem Pull Request denselben Stack aus, und ein rotes Gate blockiert den Merge, egal wie überzeugend der Diff aussieht. Drei Prinzipien machen den Unterschied zwischen einem Gate, das trägt, und einem, das nervt:

• Schnelles Feedback zuerst: Linting und Typprüfung laufen in Sekunden und stehen am Anfang der Pipeline. Teure E2E Tests mit Cypress folgen erst, wenn die billigen Gates grün sind.
• Fehlermeldungen für Agents formulieren: Ein Gate, das nur Security Scan fehlgeschlagen meldet, hilft niemandem. Ein Gate, das Fund, Zeile und Korrekturvorschlag nennt, kann direkt an den Coding Agent zurückgespielt werden, der die meisten Funde selbst behebt.
• Risiko gestaffelt prüfen: Eine Textänderung auf einer Landing Page braucht keine Mutation Tests. Eine Änderung am Auth Flow braucht das volle Programm. Pfadbasierte Regeln skalieren die Gate Intensität mit dem Schadenspotenzial.

Für sicherheitskritische Prüfungen ergänzen Werkzeuge wie Claude Code Security die klassischen SAST Scanner um semantisches Verständnis von Datenflüssen. Und wer mit Claude Code arbeitet, kann Gates über Hooks schon lokal erzwingen, etwa Linting vor jedem Commit, bevor die CI überhaupt anspringt.

Der häufigste Fehler bei Quality Gates ist, sie als reine Hürdensammlung zu bauen: noch ein Check, noch eine Checkbox, noch ein Pflichtfeld. Das Ergebnis ist eine Pipeline, die alle nervt und niemanden schützt, weil das Team lernt, sie mechanisch abzunicken. Trainas Punkt: Der Wert eines Gates liegt nicht darin, dass es existiert, sondern dass es Aufmerksamkeit umlenkt. Die Maschine übernimmt die mechanischen Prüfungen wie Syntax, Typen und Coverage, und genau dadurch wird menschliche Aufmerksamkeit frei für das, was kein Tool bewerten kann: Passt die Architektur, stimmt die Business Logik, gehört diese Lösung in diese Codebase. Ein gutes Gate sagt dem Reviewer, wo er hinschauen soll, statt ihm nur mehr Kästchen zum Abhaken zu geben.

In Beratungsprojekten sehen wir zwei wiederkehrende Fehlbilder. Das erste: gar keine Gates. Der Prototyp lief lokal, das Team shippt per Bauchgefühl, und drei Monate später steht die Projekt Rettung an, weil niemand mehr weiß, welcher Agent Run welche Regression eingeführt hat. Das zweite Fehlbild: Gates als Alibi. Eine Pipeline mit zwanzig Checks, von denen die Hälfte auf Warn statt Fail steht und die andere Hälfte so viele False Positives wirft, dass jeder Merge per Admin Override durchgeht.

Was funktioniert, ist klein anfangen und konsequent bleiben: ein Linting Gate und ein Typprüfungs Gate in der ersten Woche, beide auf Fail. Danach Tests mit realistischer Coverage Schwelle, dann Review Agents nach dem Muster aus den Agentic Coding Patterns. Jede Regel, die ein Gate erzwingt, fliegt aus dem manuellen Review raus, so bleibt menschliche Aufmerksamkeit für Architektur und Business Logik übrig. Wie ein solcher Einstieg für dein Team aussieht, hängt vom Stack ab, den wir uns im Vibe Coding Consulting gemeinsam anschauen.

Antworten auf die Fragen, die uns in Beratungsprojekten und in der Community zu Quality Gates am häufigsten gestellt werden.