Es ist erstaunlich, wie Nicht-Entwickler in letzter Zeit in die Lage versetzt wurden, eigene Apps zu erstellen, mit denen sich sogar Einnahmen erzielen lassen. Wir haben in jüngster Zeit Fortschritte im gesamten Bereich der KI-Entwicklung beobachtet, angefangen bei Erfolgen der KI bei „Greenfield-Code“ (von Grund auf neu entwickelte Apps) bis hin zu „Brownfield-Code“ (bestehende Anwendungen in größerem Umfang). Die neueren Modelle sind bei der Nutzung von Tools deutlich besser geworden und haben enorme Erfolge bei der Implementierung von Funktionen in größeren Anwendungen erzielt – und zwar in einem solchen Maße, dass Entwickler kaum noch innehalten, um den Code zu überprüfen. Stattdessen konzentrieren sie ihre Zeit mehr auf die Festlegung von Anforderungen und Funktionstests, was es ihnen ermöglicht, mehr Produkte auf den Markt zu bringen.
Gleichzeitig birgt die schnelle Entwicklung neuer Funktionen die Gefahr, dass die technische Verschuldung so weit ansteigt, dass weitere Fortschritte praktisch unmöglich werden. Ohne entsprechende Kontrolle können Teams am Ende mit Unmengen an Spaghetti-Code dastehen; daher sollten Standards für die Codequalität oberste Priorität haben, bevor das Problem außer Kontrolle gerät.
Hohe Qualitätsstandards beim Code einzuhalten, ist leichter gesagt als getan. Die manuelle Überprüfung kann da nicht mithalten, und Claude oder Cursor zu bitten, den Code zu überprüfen, ist so, als würde man jemanden bitten, eine Dissertation zu begutachten, ohne jeglichen Kontext hinsichtlich des Fachgebiets oder der zu beachtenden Standards zu haben.
Was tun Teams, wenn sich KI-Code anhäuft?
Die Kosten für das Überspringen von Überprüfungen, insbesondere bei architektonischen Änderungen, zeigen sich erst später, meist nach einigen Monaten. Von der KI generierte Änderungen bauen auf anderen von der KI generierten Änderungen auf, und jede Ebene geht davon aus, dass die darunterliegende Ebene fehlerfrei ist. Ist dies nicht der Fall, hat das Modell eine schwache Grundlage, auf der es aufbauen kann – ebenso wie die Entwickler, die ihm Befehle geben. Fehler tauchen an unerwarteten Stellen auf, und selbst kleine Änderungen führen zu Nebenwirkungen, deren Behebung einige Zeit in Anspruch nimmt.
Irgendwann kehrt sich die im ersten Monat noch hohe Geschwindigkeit um. Das Team liefert langsamer, da jeder PR nun die Last all dessen spürt, was zuvor gekommen ist.
Wenn Teams dann versuchen, diese Daten zu bereinigen, ist das eine gewaltige Aufgabe. Unternehmen versuchen sogar, das Problem mit Spezialisten für die Bereinigung von Vibe-Coding zu lösen. Auf LinkedIn findet man bereits jetzt Personen, die diese Rolle ausüben.
Es erscheint widersprüchlich, von KI zu profitieren, aber dann mehr Personal zu benötigen, um die Probleme zu beheben, die durch die KI erst möglich geworden sind. Daher sollten Teams Maßnahmen ergreifen, um den Code frühzeitig und effizient zu überprüfen.
So halten Sie die Code-Schulden gering
Die besten Möglichkeiten, die bisher gefunden wurden, um die Code-Schulden zu verringern, lassen sich im Allgemeinen einer der beiden folgenden Kategorien zuordnen:
- Ein Tool zur Überprüfung der Codequalität bei Pull-Anfragen, um Code-Schulden frühzeitig zu erkennen
- Ein Tool zur Überprüfung der Codequalität in Repositories
Teams nutzen sie, um:
- Aus Sicht des Managements sollten Sie prüfen, welche Teams mehr erfahrene Entwickler benötigen oder bei welchen Teams die Anforderungen an die Codequalität erhöht werden müssen.
- Verfolgen Sie einzelne Befunde nach. Selbst wenn Sie beispielsweise ein älteres Repository haben, das Sie nicht anfassen, weil es „einfach funktioniert“, ist es dennoch interessant, die Befunde zu Logikfehlern durchzugehen, um zu verstehen, ob es möglicherweise unerwartete Nebenwirkungen mit versteckten Auswirkungen gibt.
Beide Anwendungsfälle funktionieren nur, wenn die zugrunde liegenden Prüfungen korrekt sind, und die Genauigkeit hängt davon ab, wie eng der Umfang der einzelnen Prüfungen definiert ist. Wenn man ein LLM auffordert, ein gesamtes Repository in einem Durchgang zu überprüfen, stößt man auf dasselbe Problem wie bei einer zu vagen Eingabeaufforderung an Cursor: Es gibt zu viele Informationen, sodass das Modell sich nicht auf etwas Bestimmtes festlegen kann.
Aus diesem Grund löst die Funktion „Code Quality“Aikido LLM-Aufrufe regelbasiert aus. Dies hilft dem LLM erheblich dabei, sich jeweils auf eine bestimmte Frage zu konzentrieren. Darüber hinaus ist es möglich, diese Regeln durch zusätzlichen Kontext zu verfeinern, um sicherzustellen, dass die Ergebnisse dem Codestil entsprechen. Falls es keine Regel gibt, die auf eine bestimmte Anforderung abzielt, können auch benutzerdefinierte Regeln hinzugefügt werden. Diese Steuerungsebene trägt dazu bei, den gesamten Prozess im gesamten Team zu optimieren.
Zudem gilt diese Kontrollebene gleichzeitig sowohl für die PR-Prüfung als auch für das Repository-Scanning, um sicherzustellen, dass die statistischen Zahlen zum Repository-Scanning mit dem Feedback zu Pull-Anfragen übereinstimmen.
Benchmark-Prompts zur Codequalität
Ein weiterer Vorteil der Verwendung eines speziellen Systems zur Codequalität besteht darin, dass die LLMs fein abgestimmte Prompts erhalten, die einem Benchmark-Test unterzogen wurden (was wir auch bei AutoTriage tun). Der Vorgang ist einfach: Wir sammeln Code-Beispiele für eine bestimmte Regel und kennzeichnen manuell, ob sie mit einem Konfidenzwert markiert werden sollen oder nicht.
Manche Regeln zur Codequalität befinden sich in einer Grauzone, sodass unklar ist, ob sie gemeldet werden sollten oder nicht. So haben wir beispielsweise große Unterschiede festgestellt, wie streng Teams die Regel „keine offensichtlichen Duplikate“ handhaben. Der Code-Stil Aikidosieht vor, diese Regel nicht allzu streng anzuwenden. Lesbarkeit wird oft gegenüber dem Vorteil der Wartbarkeit durch Duplikatsbeseitigung bevorzugt. Neue Mitarbeiter wünschen sich manchmal mehr„DRY“und scheuen keine Mühen, um dies durch Abstraktionen zu erreichen. Hier gibt es kein Richtig oder Falsch, es handelt sich lediglich um eine andere Graustufe. In solchen Fällen definiert eine Konfidenzkennzeichnung, wie viele Personen unserer Erwartung nach etwas melden würden oder nicht.
Allerdings müssen wir bei der Kennzeichnung von Elementen in einem PR eine klare Entscheidung treffen. Wie gehen wir also mit der Grauzone um, wenn wir Konfidenz-Labels vergeben? Zunächst versuchen wir einfach, Beispiele aus der Grauzone nicht zu kennzeichnen – denn es ist wahrscheinlicher, dass wir Entwickler mit zu vielen Befunden frustrieren, als dass wir sie mit punktgenauen Befunden beeindrucken. Wir integrieren dies auch in unser Prompt-Engineering-System. Nach der Kennzeichnung der Beispiele optimieren wir die Prompts so, dass die Kundenzufriedenheit maximiert wird.
Leider sind LLMs nicht perfekt und es kommt immer wieder zu Fehlern, daher müssen wir uns unsere Kämpfe gut aussuchen. Beispiele aus der Grauzone helfen uns dabei, die richtigen Kämpfe auszuwählen. Wenn wir bei einem Beispiel aus der Grauzone eine falsche Entscheidung treffen, wird dies weniger stark bestraft als eine falsche Entscheidung bei einem eindeutigen Beispiel. Das Ergebnis ist, dass die Ergebnisse ziemlich nah an der Wahrheit liegen – deutlich näher als bei einer einfachen Prompt-Vergabe.
Der Schwerpunkt liegt auf der Codequalität und nicht auf der Fehlersuche
Eine interessante Quelle für Verwechslungen zwischen einem Code-Qualitätssystem und anderen PR-Prüfsystemen ist, dass sich die meisten Systeme in der Regel auf das Aufspüren von Fehlern konzentrieren. Das ist natürlich ein wichtiger Aspekt, dient aber einem anderen Zweck. Der bequemste Weg, um Fortschritte zu erzielen, besteht darin, den Codestil zügig zu überarbeiten, und diese Systeme sollten schnell arbeiten. Das Code-Qualitätssystem Aikidoist in der Regel innerhalb von weniger als einer Minute nach dem Push des Commits fertig, wodurch die Feedbackschleife kurz gehalten wird. Dies umfasst sowohl Code-Qualitäts- als auch Sicherheitsprüfungen.
In naher Zukunft wird es auch möglich sein, eine gründliche Überprüfung eines Commits anzufordern. Diese Überprüfung würde dann Logikfehler und Autorisierungsprobleme noch eingehender aufdecken. Sie erfolgt agentenbasiert und ist daher langsamer und aufwendiger, stellt jedoch eine ideale abschließende Überprüfung eines PR vor der Bereitstellung dar.
Fazit
Eine allgemeine Eingabeaufforderung an Claude oder Cursor überprüft den Code anhand dessen, was das Modell gerade an diesem Tag priorisiert, und nicht anhand der spezifischen Programmierkultur in einer Codebasis. Ein dediziertes System zur Codequalität behebt dieses Problem, da es dieselben optimierten Regeln sowohl auf Pull-Anfragen als auch auf vollständige Repositorys anwendet, sodass ein Team eine einheitliche Antwort erhält, anstatt zwei unterschiedlicher Antworten, je nachdem, wo die Überprüfung stattfindet. Der nächste Schritt vertieft diese Antwort noch weiter: eine agentische Prüfung, die darauf ausgelegt ist, Logikfehler und Autorisierungsprobleme aufzuspüren und die stabil und sicher genug ist, um direkt vor der Bereitstellung statt bei jedem Commit ausgeführt zu werden.
