Können KI-Agenten produktionsreifes Laravel schreiben? Eine Code-Review-Richtlinie für KI-gestützte Teams

Kann KI produktionsreifen Code schreiben ist die falsche Frage — und genau die, die Vorstände immer wieder stellen. KI schreibt bereits Code in Ihrer Laravel-Codebasis, weil Ihre Entwickler sie einsetzen, und eine ablehnende Haltung führt nur dazu, dass es ohne Review-Disziplin geschieht.

Die nützliche Frage ist enger gefasst: Was macht sie in genau diesem Framework falsch, und was muss ein Reviewer deshalb prüfen? Laravel ist ein guter Fall, weil seine Konventionen stark sind, seine Dokumentation hervorragend ist und seine Präsenz in Trainingsdaten enorm — was ein charakteristisches Muster erzeugt: selbstbewusste, idiomatische, gelegentlich gefährliche Ausgaben.

Wo KI zuverlässig hilft

Genauigkeit zählt hier, denn eine pauschale Richtlinie ist in beide Richtungen falsch.

• Boilerplate mit klarer Konvention — Resource Controller, Form Requests, Factories, Seeder, API Resources. Laravels Konventionen sind so gut repräsentiert, dass die Ausgabe hier meist korrekt und stilistisch konsistent ist.
• Test-Scaffolding. Es erzeugt die Fälle, die Sie geschrieben hätten, sich aber vielleicht gespart hätten — besonders Randfälle rund um die Validierung.
• Mechanisches Refactoring über viele Dateien hinweg — umbenennen, extrahieren, einen veralteten Aufruf aktualisieren. Mühsam, wenig Ermessensspielraum, leicht zu prüfen.
• Unbekannten Code erklären. Wirklich wertvoll bei einer geerbten Codebasis — und ganz ohne Risiko für das, was in Produktion geht.
• Migrations und Schemadefinitionen aus einem beschriebenen Modell — durch Lesen überprüfbar, und wenn falsch, dann offensichtlich falsch.

Wo KI vorhersehbar scheitert

Das sind die Muster, die uns immer wieder begegnen — und genau darauf muss eine Review-Richtlinie zielen.

1. Abfragemuster, die funktionieren und nicht skalieren

N+1-Abfragen sind der typische Fehler. Generierter Code, der über eine Collection iteriert und innerhalb der Schleife auf eine Relation zugreift, ist korrekt, lesbar, besteht seine Tests gegen einen per Factory erzeugten Datenbestand von zehn Zeilen — und bricht bei Produktionsdaten zusammen. Das Modell kann nicht wissen, dass Ihre Tabelle orders neun Millionen Zeilen hat.

2. Autorisierung angenommen statt durchgesetzt

Generierte Controller lassen die Policy-Prüfung häufig weg oder platzieren sie dort, wo sie leicht zu umgehen ist. Das ist die riskanteste Kategorie überhaupt, denn für den Entwickler, der als Administrator testet, funktioniert der Code einwandfrei.

3. Alte Idiome aus alten Trainingsdaten

Trainingsdaten neigen zu dem, was am häufigsten geschrieben wurde — und das ist nicht dasselbe wie das, was aktuell ist. Bei einem Framework mit zehn Jahren Blogbeiträgen im Rücken heißt das: Ausgaben nach Konventionen mehrerer Major-Versionen zuvor — veraltete Helper, überholte Validierungssyntax, Muster, die längst durch hauseigene Funktionen ersetzt sind. Es wirkt plausibel, weil es einmal korrekt war.

4. Mass Assignment und Vertrauen in Eingaben

Generierter Code reicht Request-Eingaben häufiger direkt in die Modellerzeugung weiter, als er sollte. Laravels Schutzmechanismus macht das verkraftbar — aber nur, wenn das Modell tatsächlich konfiguriert ist, und generierte Modelle sind es oft nicht.

5. Mandantenfähige und eingegrenzte Kontexte

Wenn Ihre Anwendung Daten pro Mandant, pro Organisation oder pro Marke eingrenzt, weiß generierter Code das nicht — es sei denn, der umgebende Code macht es strukturell unmöglich, es zu vergessen. Das ist ein starkes Argument dafür, die Eingrenzung in der Datenbank oder im Basismodell zu erzwingen statt sie einer Konvention zu überlassen — ausführlich behandelt in mandantenfähige Laravel-Architektur.

6. Mit Überzeugung erfunden

Methodennamen auf Ihren eigenen Klassen, die es nicht gibt, Paket-APIs, die nie veröffentlicht wurden, Config-Schlüssel, die richtig klingen. Schnell zu entdecken — es scheitert sofort —, aber es kostet Review-Zeit und untergräbt die Aufmerksamkeit des Reviewers für die Fehler, die sich nicht von selbst melden.

Die Review-Richtlinie

Kurz genug, dass sie befolgt wird.

1. Die Urheberschaft wird offengelegt. Ein Pull Request gibt an, ob er im Wesentlichen KI-generiert ist. Nicht, um jemanden bloßzustellen — sondern um dem Reviewer zu sagen, wo er hinsehen muss.
2. Der Autor hat jede Zeile gelesen. Das ist die gesamte Richtlinie in einem Satz. Code einzureichen, den man nicht gelesen hat, ist der eigentliche Fehler; womit er erzeugt wurde, ist nebensächlich.
3. Vier Pflichtprüfungen bei generiertem Code: Abfrageverhalten bei Produktionsdatenmengen, Autorisierung, Eingabevalidierung und Mass Assignment sowie Mandanten- oder Scope-Kontext.
4. Statische Analyse ist nicht optional. PHPStan oder Psalm auf einem Level, das Ihre Codebasis tatsächlich hält, in der CI, blockierend. Maschinell erzeugter Code verdient maschinell durchgesetzte Standards.
5. Tests müssen von einem Menschen geschrieben oder geprüft werden. Ein Agent, der Code und Test zugleich schreibt, kann ein Paar erzeugen, das in sich stimmig ist und trotzdem an der Anforderung vorbeigeht.
6. Nichts Generiertes kommt der Sicherheitsgrenze nahe, ohne dass eine zweite Person es geprüft hat. Authentifizierung, Autorisierung, Zahlungsabwicklung, alles, was personenbezogene Daten berührt.
7. Migrations und destruktive Operationen schreibt ein Mensch. Eine generierte Migration, die eine Spalte löscht, wirkt genauso überzeugend wie eine, die eine hinzufügt.

Die Codebasis so bauen, dass Fehler schwerer werden

Der wirksamste Eingriff ist nicht, härter zu reviewen. Er besteht darin, das Falsche schwer schreibbar zu machen — was menschlichen Beitragenden genauso hilft.

• Erzwingen Sie Autorisierung strukturell, damit eine Controller-Aktion ohne Policy-Prüfung fehlschlägt, statt stillschweigend zu erlauben.
• Erzwingen Sie die Mandantentrennung im Basismodell oder in der Datenbank, damit eine ungefilterte Abfrage eine Exception wirft.
• Setzen Sie auf strikte Typen und ein hohes Level der statischen Analyse. Beides verengt den Raum für plausiblen, aber falschen Code drastisch.
• Pflegen Sie eine echte Dokumentation Ihrer Konventionen im Repository. Agenten lesen das Repository; eine Codebasis, die ihre eigenen Muster dokumentiert, bekommt bessere Ausgaben — und neue Teammitglieder kommen genauso schneller zurecht.
• Halten Sie die Codebasis idiomatisch. Konsistenz ist inzwischen auch eine Frage der Lesbarkeit für Maschinen, nicht nur für Menschen — ein ungewöhnliches Muster erzeugt ungewöhnliche Ausgaben.

Der letzte Punkt ist das wirklich neue Argument. Konventioneller Code und gute Dokumentation galten früher als angenehmes Extra, begründet mit schnellerem Onboarding. Sie sind heute eine direkte Eingangsgröße für die Qualität eines erheblichen Teils des geschriebenen Codes — und damit ein wirtschaftliches Argument, kein stilistisches.

Messen, ob es tatsächlich hilft

Anbieter verkaufen einen Produktivitätsfaktor. Messen Sie Ihren eigenen, denn die ehrliche Antwort schwankt enorm je nach Art der Aufgabe.

• Durchlaufzeit vom ersten Commit bis zum Merge, nicht die Zahl der Zeilen. Zeilen sind hier eine Kennzahl, die in die Irre führt.
• Review-Aufwand — aufgewendete Review-Zeit und Iterationen bis zur Freigabe. Steigt die Review-Zeit stärker, als die Schreibzeit sinkt, haben Sie Kosten verschoben, nicht gespart.
• Fehlerrate pro gemergter Änderung, getrennt erfasst für KI-gestützte und von Menschen geschriebene Arbeit.
• Nacharbeitsquote — wie oft gemergter Code innerhalb eines Monats wesentlich neu geschrieben wird.
• Wo sich die Gewinne konzentrieren. Nach unserer Erfahrung sind sie bei Boilerplate und Tests real und groß, bei Domänenlogik klein und gelegentlich negativ bei allem, was Wissen über Ihr konkretes System erfordert.

Verfolgen Sie das ein Quartal lang, bevor Sie Ihre Kapazitätsplanung darauf umstellen. Ein Team, das einen Produktivitätsfaktor annimmt und danach besetzt, hat teuer auf eine Zahl gewettet, die niemand gemessen hat.

Genau diese Governance-Arbeit bringt unser Laravel-Team in Codebasen von Kunden ein, und sie steht neben der größeren Frage, wo KI ihren Platz in der Umsetzung wirklich verdient — das Thema unserer Praxis für KI-Integration und unseres KI-Engineering-Teams. Bei älterem Code zeigt sich dasselbe Fehlermuster noch deutlicher: siehe warum KI-Coding-Agenten fließend PHP-7-Idiome sprechen.

Erst die Richtlinie einführen, dann messen

Wir helfen Ihnen, die Review-Richtlinie und die strukturellen Leitplanken einzuführen und die Messung aufzusetzen, die Ihnen zeigt, ob sich das alles auszahlt. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.