LLMs sind fast perfekt darin geworden, Code zu generieren, aber das ist nicht das Ende der Geschichte. Nur weil der Code formal korrekt ist, heißt das nicht, dass er keine unnötigen Abstraktionen einführt, Duplikate erstellt oder insgesamt schlechte Entscheidungen trifft. Dies ist keine bahnbrechende Beobachtung; die meisten Menschen, die ein Projekt vibe-codiert haben, haben festgestellt, dass jedes zusätzliche Feature manchmal zu einer Explosion von Codezeilen (LOC) führen kann. Dies führt zu einem Verlust menschlicher Handlungsfähigkeit, denn in Projekten, die Millionen von LOC pro Monat hinzufügen, ist es für Menschen schwer, mitzuhalten. Manche mögen sagen, dass das überhaupt kein Problem ist, weil sie darauf vertrauen, dass ihre Agenten damit umgehen. Ich habe schlechte Nachrichten für Sie: Agenten können den Schlamp auch nicht wirklich bewältigen.

Aus einem Physikhintergrund kommend, hatte ich immer einen experimentellen/quantitativen Ansatz zur Problemlösung. Als ich bei Earendil anfing, mit der Aufgabe herauszufinden, wie man Code-Schlampigkeit messen kann, war mein natürlicher Instinkt, zuerst tief in die Literatur einzutauchen und dann zu prüfen, was andere Unternehmen tun. Um ehrlich zu sein, abgesehen von einigen aufschlussreichen Forschungsarbeiten war ich enttäuscht, wie „vibes-basiert“ die Branche derzeit zu sein scheint. In meiner Forschung und auf X wurde ich ständig mit Botschaften wie „End-to-End-Coding-Agenten“, „KI, die Code nicht nur vorschlägt – sie liefert ihn aus“ oder „Bewertung auf menschlichem Niveau ohne Kosten auf menschlichem Niveau“ bombardiert. Die, wie alle guten Geschichten, ein Körnchen Wahrheit enthalten. LLMs sind in der Lage, fast perfekt korrekten Code zu schreiben. Dies liegt an der Skalierbarkeit und Verifizierbarkeit von Code. Es ist ziemlich einfach, LLMs Code generieren zu lassen und diesen Code dann durch versteckte Tests überprüfen zu lassen, was zu einem klaren Belohnungssignal führt. Im krassen Gegensatz dazu erfordert die Überprüfung der „Schlampigkeit“ dieses Codes oft menschliche Intuition und Geschmack und ist im Allgemeinen eine äußerst schwierige Aufgabe.

Ich denke, der beste Weg zu veranschaulichen, warum das so ist, ist, mögliche Wege zur Messung von Schlamp durchzugehen. KI als Richter: Dies ist wahrscheinlich die häufigste Methode zur Bewertung der Codequalität in der Branche, und nach meinen Beobachtungen funktioniert sie selten. Die naivste Art, dies zu tun, nämlich die Modelle zu fragen, wie gut der Code auf einer Skala von 1-10 ist, entspricht im Grunde einem Zufallszahlengenerator. Der ausgefeiltere Ansatz, nämlich zu versuchen, dem Richtermodell zwei Lösungen A und B zu geben und es dann entscheiden zu lassen, welche es bevorzugt, hat den Nachteil, dass das Modell seine Präferenz ändert, wenn Sie die Lösungen umbenennen. Ich bin hier etwas spöttisch, und der Effekt ist bei größeren Modellen nicht so ausgeprägt, aber der Hauptpunkt bleibt bestehen. LLMs zu bitten, den Code zu beurteilen, den sie schreiben, ist kein Ersatz für eine ordnungsgemäße Bewertung. Obwohl es einige interessante Ansätze mit Rubriken oder LLMs, die Tests schreiben, gibt, sind sie noch weit davon entfernt, den Schlamp tatsächlich loszuwerden.

Menschen beurteilen die KI: Wenn wir die Tatsache ignorieren, dass es eine große Vielfalt in der Qualität von Software-Ingenieuren gibt, wäre dies die beste Lösung, um sicherzustellen, dass der Code für Menschen lesbar bleibt. Mit dem Nachteil, dass dies nicht skalierbar ist, um KI zu trainieren oder große Benchmarks mit mehreren Modellanbietern und Harnessen zu haben. Die einfachste Methode: In meiner Forschung und meinen Tests war die bloße Messung der Änderung der Anzahl von LOCs eine überraschend effektive Metrik für Schlampigkeit, mit dem ironischen Vorbehalt, dass sie aufhören würde, ein sinnvolles Maß zu sein, wenn wir anfangen würden, darauf zu optimieren. Die nächsten beiden Maße wurden mir durch das Paper Slop Code Bench vorgestellt und schienen vielversprechend, weil sie Legacy-Codebasen recht gut von LLM-Schlamp trennen konnten. Weitschweifigkeit: Versucht, die Menge an duplizierten und unnötig weitschweifigen Zeilen zu messen. Erosion: Versucht zu messen, wie viel der Masse einer Codebasis in einigen wenigen großen und komplexen Funktionen konzentriert ist.

Schlüsselentitäten: Unternehmen: Earendil