Es ist erstaunlich, wie Nicht-Entwickelnde in letzter Zeit befähigt wurden, eigene Apps zu erstellen, die sogar Einnahmen generieren können. Wir haben in jüngster Zeit Fortschritte im Bereich der KI-Entwicklung gesehen, von der erfolgreichen Anwendung von KI in „Greenfield-Code“ (von Grund auf neu entwickelte Apps) hin zu „Brownfield-Code“ (größere bestehende Anwendungen). Die neueren Modelle sind im Umgang mit Tools wesentlich besser geworden und haben enorme Erfolge bei der Implementierung von Features in größeren Anwendungen erzielt, bis zu dem Punkt, dass Entwickelnde den Code kaum noch überprüfen. Stattdessen konzentrieren sie ihre Zeit mehr auf das Prompting von Anforderungen und das funktionale Testen, was sie befähigt, mehr zu liefern.
Gleichzeitig birgt die schnelle Entwicklung neuer Features das Risiko, die technische Schuld so weit zu erhöhen, dass Fortschritte praktisch unmöglich werden. Ohne Aufsicht können Teams in einem Haufen Spaghetti-Code enden, daher sollten Code-Qualitätsstandards im Vordergrund stehen, bevor das Problem außer Kontrolle gerät.
Hohe Code-Qualitätsstandards aufrechtzuerhalten ist leichter gesagt als getan. Menschliche Überprüfungen können nicht mithalten, und Claude oder Cursor zu bitten, den Code zu überprüfen, ist, als würde man jemanden bitten, eine Dissertation zu begutachten, ohne jeglichen Kontext der Disziplin oder der einzuhaltenden Standards.
Was tun Teams, wenn sich KI-Code ansammelt?
Die Kosten für das Überspringen von Reviews, insbesondere bei architektonischen Änderungen, zeigen sich später, meist nach einigen Monaten. KI-generierte Änderungen stapeln sich auf anderen KI-generierten Änderungen, und jede Schicht geht davon aus, dass die darunterliegende solide ist. Wenn dies nicht der Fall ist, hat das Modell eine schwache Grundlage, auf der es aufbauen kann, und ebenso die Entwickelnde, die es prompten. Bugs tauchen an seltsamen Stellen auf, und selbst kleine Änderungen beginnen, Nebenwirkungen zu erzeugen, deren Debugging eine Weile dauert.
Irgendwann kehrt sich die im ersten Monat hohe Geschwindigkeit um. Das Team liefert langsamer, weil jeder PR nun das Gewicht all dessen spürt, was zuvor kam.
Wenn Teams dann versuchen, aufzuräumen, ist das eine große Aufgabe. Organisationen versuchen sogar, das Problem mit „Vibe Coding Cleanup Specialists“ zu lösen. Personen mit dieser Rolle sind derzeit auf LinkedIn zu finden.
Es scheint widersprüchlich, von KI zu profitieren, aber dann mehr Personen zu benötigen, um die Probleme zu beheben, die die KI ermöglicht hat. Daher sollten Teams Schritte unternehmen, um den Code frühzeitig und effizient zu überprüfen.
Wie man Code-Schulden niedrig hält
Die besten Optionen, die bisher zur Reduzierung von Code-Schulden gefunden wurden, fallen im Allgemeinen in eine von zwei Kategorien:
- Ein Tool zur Überprüfung der Code-Qualität bei Pull Requests, um Code-Schulden frühzeitig zu erkennen
- Ein Tool zur Überprüfung der Code-Qualität in Repositories
Teams nutzen sie, um:
- Aus Managementsicht prüfen, welche Teams mehr Senior-Entwickelnde gebrauchen könnten, oder um zu sehen, bei welchen Teams die Messlatte für die Code-Qualität erhöht werden muss.
- Einzelne Findings verfolgen. Z.B. selbst wenn Sie ein Legacy-Repository haben, das Sie nicht anfassen, weil es „einfach funktioniert“, ist das Durchsehen der Logic-Bug-Findings immer noch interessant, um zu verstehen, ob es unerwartete Nebenwirkungen mit verborgener Auswirkung geben könnte.
Beide Anwendungsfälle funktionieren nur, wenn die darunter liegenden Prüfungen präzise sind, und die Präzision hängt davon ab, wie eng jede Prüfung gefasst ist. Ein LLM zu bitten, ein ganzes Repository in einem Durchlauf zu überprüfen, führt zu den gleichen Problemen wie ein zu lockerer Prompt an Cursor, mit zu vielen Informationen, um etwas Spezifisches zu finden.
Deshalb startet die Code Quality-Funktion von Aikido LLM-Aufrufe regelbasiert. Dies hilft dem LLM erheblich, sich jeweils auf eine spezifische Frage zu konzentrieren. Zusätzlich ist es möglich, diese Regeln mit zusätzlichem Kontext zu verfeinern, um sicherzustellen, dass die Findings dem Code-Stil entsprechen. Wenn es keine Regel gibt, die eine spezifische Anforderung abdeckt, können auch benutzerdefinierte Regeln hinzugefügt werden. Diese Kontrollschicht hilft, den gesamten Prozess im Team zu optimieren.
Darüber hinaus gilt diese Kontrollschicht gleichzeitig für PR-Prüfungen und Repository-Scans, um sicherzustellen, dass die statistischen Zahlen der Repository-Scans mit dem Feedback zu Pull Requests übereinstimmen.
Benchmarkte Prompts für Code-Qualität
Ein zweiter Vorteil bei der Verwendung eines dedizierten Code-Qualitätssystems ist, dass die LLMs feinabgestimmte Prompts erhalten, die gebenchmarkt wurden (was wir auch mit AutoTriage tun). Der Prozess ist einfach. Wir sammeln Code-Beispiele für eine bestimmte Regel und kennzeichnen manuell, ob sie mit einem Konfidenzwert markiert werden sollen oder nicht.
Einige Code-Qualitätsregeln bewegen sich in einer Grauzone, was unklar macht, ob sie markiert werden sollen oder nicht. Zum Beispiel haben wir große Unterschiede festgestellt, wie streng Teams die Regel „keine offensichtliche Duplizierung“ behandeln. Aikidos eigener Code-Stil ist es, diese Regel nicht sehr streng anzuwenden. Lesbarkeit wird oft dem Wartbarkeitsvorteil der Deduplizierung vorgezogen. Neue Mitarbeitende würden es manchmal „DRY“er haben wollen und viel Aufwand betreiben, um Abstraktionen hinzuzufügen, damit dies geschieht. Hier gibt es kein Richtig oder Falsch, es ist nur ein anderer Grauton. In solchen Fällen definiert ein Konfidenz-Label, wie viele Personen wir erwarten, etwas zu markieren oder nicht.
Allerdings müssen wir eine Schwarz-Weiß-Entscheidung treffen, wenn wir etwas in einem PR markieren. Wie navigieren wir also in der Grauzone, wenn wir Konfidenz-Labels anwenden? Zunächst versuchen wir einfach, Grauzonen-Samples nicht zu markieren – wir frustrieren Entwickelnde eher mit zu vielen Findings, als sie mit punktgenauen Findings zu begeistern. Wir integrieren dies auch in unser Prompt-Engineering-System. Nach dem Labeln der Samples optimieren wir die Prompts so, dass die Kundenzufriedenheit maximiert wird.
Leider sind LLMs nicht perfekt und Fehler passieren immer wieder, daher müssen wir unsere Kämpfe auswählen. Grauzonen-Samples helfen uns, die richtigen Kämpfe auszuwählen. Wenn wir bei einem Grauzonen-Sample eine falsche Entscheidung treffen, wird dies weniger stark bestraft als eine falsche Entscheidung bei einem offensichtlichen Sample. Das Ergebnis ist, dass die Findings der Wahrheit sehr nahekommen, deutlich näher als das, was man mit Vanilla Prompting erhält.
Fokus auf Code-Qualität statt auf Fehlerfindung
Eine interessante Quelle der Verwirrung zwischen einem Code-Qualitätssystem und anderen PR-Review-Systemen ist, dass die meisten Systeme dazu neigen, sich auf die Fehlerfindung zu konzentrieren. Das ist natürlich ein wichtiger Aspekt, dient aber einem anderen Zweck. Der bequemste Weg, Fortschritte zu erzielen, ist, schnell über den Code-Stil zu iterieren, und diese Systeme sollten schnell arbeiten. Aikidos Code-Qualitätssystem ist typischerweise in weniger als 1 Minute nach dem Pushen des Commits abgeschlossen, wodurch der Feedback-Loop kurz gehalten wird. Das umfasst sowohl Code-Qualitäts- als auch Sicherheitsprüfungen.
In naher Zukunft wird es auch möglich sein, eine rigorose Prüfung für einen Commit anzufordern. Diese Prüfung würde dann Logikfehler und Autorisierungsprobleme eingehender verfolgen. Sie verhält sich agentisch und ist daher langsamer und teurer, aber eine ideale abschließende Prüfung eines PR vor der Bereitstellung.
Fazit
Ein generischer Prompt an Claude oder Cursor prüft Code gegen das, was das Modell an diesem Tag zufällig priorisiert, nicht gegen die spezifische Coding-Kultur in einer Codebasis. Ein dediziertes Code-Qualitätssystem behebt dies, da es dieselben abgestimmten Regeln für Pull Requests und vollständige Repositories ausführt, sodass ein Team eine konsistente Antwort erhält, anstatt zwei verschiedene, je nachdem, wo die Prüfung läuft. Der nächste Schritt vertieft diese Antwort: eine agentische Prüfung, die entwickelt wurde, um Logikfehler und Autorisierungsprobleme zu verfolgen, stabil und sicher genug, um direkt vor der Bereitstellung statt bei jedem Commit ausgeführt zu werden.
