AI Coding braucht Quality Gates, nicht Bauchgefühl

KI-Coding-Tools bewegen sich vom Experiment zum Betriebsmodell.

Damit ändert sich die Managementfrage.

Die wichtige Frage ist nicht mehr, ob ein KI-Tool einen brauchbaren Diff erzeugen kann. Das kann es. Die bessere Frage ist, ob ein Team nachweisen kann, dass dieser Diff in das System gehört.

Diskussionen auf X haben diesen Wandel zuletzt gut sichtbar gemacht. DoorDash-CTO Andy Fang beschrieb, wie interne Benchmarks wie DashBench genutzt werden, um Open-Weight-Modelle sicher in KI-Code-Reviews einzubinden, ohne Review-Qualität zu verlieren. Andere Entwickler fragten, ob KI beim Refactoring genauso stark ist wie bei Greenfield-Arbeit, ob Architektur wichtiger oder unwichtiger wird, wenn KI Code schreibt, und wie Erklärbarkeit bei mehrstufigen Agenten zur Architekturanforderung wird.

Diese Punkte führen zur gleichen Schlussfolgerung:

AI Coding braucht Quality Gates, nicht Bauchgefühl.

Für CTOs, Gründer und Product Owner ist das kein Detail der Tool-Auswahl. Es ist eine Frage der Delivery-Steuerung. Wenn KI schneller Code erzeugt, als ein Team ihn verantwortlich prüfen kann, wird Qualitätssicherung zur Managementaufgabe.

Geschwindigkeit ohne Kriterien erzeugt Review-Schulden

KI-Coding-Assistenten sind nützlich, weil sie Implementierung beschleunigen. Sie können Tests entwerfen, Module refactoren, unbekannte Dateien erklären, Migrationen erzeugen und aus einem groben Task-Brief eine erste lauffähige Version machen.

Das ist wertvoll.

Schnellere Code-Erzeugung kann aber leise Review-Schulden aufbauen. Eine generierte Änderung kann kompilieren und trotzdem falsch für das Produkt sein. Sie kann eine enge Testsuite bestehen und gleichzeitig eine Architekturgrenze schwächen. Sie kann die lokale Aufgabe lösen und dabei ein zweites Pattern einführen, das zukünftige Maintainer verstehen müssen.

Hier wird blinde Adoption teuer.

Wenn ein Team KI-generierte Arbeit akzeptiert, weil sie plausibel aussieht, wird Review zur Vertrauensübung. Wenn ein Team sie akzeptiert, weil sie klare Quality Gates besteht, wird KI zum kontrollierten Delivery-Beschleuniger.

Der Unterschied ist entscheidend.

Benchmarks werden Teil der Engineering-Infrastruktur

Das DoorDash-Beispiel ist relevant, weil es KI-Modellauswahl als Engineering-Problem behandelt, nicht als Markenfrage.

Ein Team, das Code-Review-Qualität benchmarken kann, stellt bessere Fragen:

• Welche Modelle finden die Regressionen, die in unserem Code wirklich wichtig sind?
• Welche Modelle übersehen Architekturprobleme?
• Welche Modelle erzeugen laute oder irreführende Review-Kommentare?
• Können wir Modelle kombinieren, ohne Review-Qualität zu verlieren?
• Verbessert KI-Review akzeptierte Änderungen oder nur die Aktivität?

Allgemeine Modellrankings reichen dafür nicht aus. Ein Produktteam braucht Benchmarks, die die eigene Architektur, Risikolage, Sprachen, Frameworks, Datenmodelle und Betriebsrealität abbilden.

Das bedeutet nicht, dass jedes Unternehmen sofort eine große interne Benchmark-Plattform braucht. Es bedeutet aber, dass Führungsteams KI-Coding-Performance nicht als Geschmacksfrage behandeln sollten.

Nützliche Benchmarks können klein anfangen:

• bekannte Bugfix-Aufgaben aus der Repository-Historie;
• Refactoring-Aufgaben mit klaren Akzeptanzkriterien;
• sicherheitssensitive Code-Review-Beispiele;
• Migrationen mit Rollback-Erwartungen;
• Testaufgaben, bei denen die Qualität der Abdeckung bewertet wird;
• Architekturgrenzen mit typischen Fehlermustern.

Das Ziel ist keine akademische Reinheit. Das Ziel ist zu wissen, wo das Tool hilft, wo es scheitert und wo Menschen klar die Kontrolle behalten müssen.

Architektur ist das Quality Gate, das KI nicht ersetzt

Eine der nützlichsten Fragen aus der Diskussion war, ob Clean Code und Architektur in einer KI-gestützten Welt mehr oder weniger wichtig werden.

Sie werden wichtiger.

KI-Tools funktionieren am besten, wenn das System klare Struktur vorgibt. Konsistente Grenzen, Namen, Testmuster, Abhängigkeitsregeln und Dokumentation machen die richtige Änderung leichter zu erzeugen und leichter zu prüfen.

Unklare Systeme erzeugen unklare Prompts. Wenn ein Repository drei Wege für Datenzugriff, zwei Berechtigungsmodelle, unklare Modulverantwortung und uneinheitliche Tests hat, wird ein KI-Tool diese Uneinheitlichkeit oft kopieren. Es erkennt die gewünschte Architektur nicht zuverlässig durch Intuition.

Damit wird Architektur zur praktischen Steuerungsfläche.

Für KI-gestützte Delivery sollte Architektur Fragen beantworten wie:

• Wo gehört dieses Verhalten hin?
• Welche Abhängigkeiten sind erlaubt?
• Was muss auf Unit-, Integrations- und End-to-End-Ebene getestet werden?
• Welche Datenänderungen brauchen einen Migrationsplan?
• Welche Aktionen brauchen Audit-Trails oder menschliche Freigabe?
• Welche Bereiche sind für autonome Änderungen tabu?

Das sind keine abstrakten Engineering-Vorlieben. Sie entscheiden, ob KI-generierte Arbeit sicher reviewed, gemerged, deployed und gewartet werden kann.

Testarchitektur ist wichtiger als Testanzahl

KI kann schnell viele Tests erzeugen. Das macht ein System nicht automatisch sicherer.

Generierte Tests spiegeln häufig die Implementierung zu eng. Sie bestätigen, dass aktuelles Verhalten existiert, ohne zu beweisen, dass dieses Verhalten richtig ist. Sie können Coverage-Zahlen erhöhen und trotzdem das eigentliche Risiko verfehlen.

Für Teams, die KI-Coding-Tools nutzen, wird Testarchitektur zur Führungsfrage, weil sie entscheidet, ob Automatisierung Evidenz erzeugt oder nur Theater.

Gute Quality Gates fragen:

• Beweist der Test die Business-Regel oder nur ein Implementierungsdetail?
• Würde dieser Test bei der Regression fehlschlagen, die uns wirklich interessiert?
• Sind Integrationsgrenzen dort abgedeckt, wo Systeme aufeinandertreffen?
• Sind Berechtigungen, Datenintegrität und Fehlerpfade getestet?
• Gibt es einen zuverlässigen Weg, die relevanten Checks vor dem Merge auszuführen?

KI kann helfen, diese Evidenz zu erzeugen. Aber sie sollte den Standard nicht selbst definieren. Der Standard muss vom Team kommen.

Sicherheitschecks gehören in den Workflow

KI-Coding-Tools erleichtern Änderungen über mehr Teile des Stacks hinweg. Dazu gehören Authentifizierung, Autorisierung, Datenzugriff, Konfiguration, Logging und Deployment-Skripte.

Genau dort sind Fehler teuer.

Sicherheit darf nicht am Ende als finale Inspektion stattfinden. Sie muss Teil des KI-Workflows sein:

• Repository-Instruktionen, die sensible Bereiche markieren;
• automatisierte Checks für Secrets, Abhängigkeitsrisiken und unsichere Patterns;
• menschliche Freigabe für Berechtigungen, Authentifizierung, Zahlungen und Produktionsdaten;
• Review-Prompts, die gezielt nach Missbrauchsfällen fragen;
• Rollback- und Audit-Erwartungen für produktionsnahe Arbeit.

Das ist für deutsche und europäische Teams besonders relevant. Der EU AI Act und angrenzende Compliance-Erwartungen machen Nachvollziehbarkeit, Verantwortlichkeit und Erklärbarkeit zu mehr als guter Dokumentation. Teams müssen zeigen können, warum ein System geändert wurde, wer die Änderung freigegeben hat, welche Evidenz geprüft wurde und welche Risiken betrachtet wurden.

Das lässt sich im Nachhinein schwer rekonstruieren. Es ist deutlich einfacher, es direkt in den Delivery-Prozess einzubauen.

Nachvollziehbarkeit macht aus Output Evidenz

Die nächste reife Phase KI-gestützter Softwareentwicklung wird weniger von Prompts handeln und mehr von Nachvollziehbarkeit.

Ein guter KI-Coding-Workflow sollte Evidenz hinterlassen:

• den Task-Brief;
• die geänderten Dateien;
• die ausgeführten Tests und Checks;
• die genutzten Review-Kriterien;
• die getroffenen Architekturannahmen;
• die erforderlichen menschlichen Freigaben;
• Release- und Rollback-Notizen;
• das Produktziel, das die Änderung unterstützen sollte.

Diese Evidenz hilft Führungsteams, die einzige wirklich wichtige Frage zu beantworten:

Hat KI geholfen, bessere Software zu liefern, oder nur mehr Output, der wie Software aussieht?

Ohne Nachvollziehbarkeit bleibt die Antwort anekdotisch. Mit Nachvollziehbarkeit lernen Teams, welche Aufgaben KI übernehmen sollte, welche Aufgaben engere Aufsicht brauchen und welche Teile des Systems stärkere Architektur benötigen, bevor Automatisierung ausgeweitet wird.

Die Management-Lehre

KI-Coding-Adoption sollte nicht mit der Frage beginnen: “Welches Tool kaufen wir?”

Sie sollte mit der Frage beginnen: “Welchen Qualitätsstandard muss jede Änderung erfüllen?”

Daraus wird das Betriebsmodell klarer:

• Architekturregeln definieren, denen das Tool folgen muss;
• Benchmarks auf Basis echter Repository-Arbeit aufbauen;
• kleine, reviewbare Diffs verlangen;
• Testevidenz sinnvoll machen, nicht nur zahlreich;
• Sicherheitschecks in den Workflow einbauen;
• Nachvollziehbarkeit für regulierte und risikoreiche Änderungen sichern;
• akzeptierte, wartbare Produktverbesserungen messen statt generiertes Codevolumen.

So wird AI Coding für ernsthafte Produkte nützlich.

Gewinnen werden nicht die Teams, die den meisten Code generieren. Gewinnen werden die Teams, die KI-Geschwindigkeit aufnehmen können, ohne Produkturteil, Architekturkontrolle, Sicherheitsdisziplin oder Wartbarkeit zu verlieren.

Das ist der praktische Weg für KI-gestützte Softwareentwicklung: schnellere Implementierung, stärkere Gates, klarere Evidenz und Architektur, die das System langfristig änderbar hält.

Genau daran arbeitet McDougall Digital. Wir helfen Teams, KI so einzusetzen, dass Software Review, Deployment, Regulierung und die nächste Produktänderung übersteht.