Mit AI besseren Code langsamer schreiben

• AI-Coding kann nicht nur dazu genutzt werden, große Mengen minderwertigen Codes schnell zu erzeugen, sondern auch, PRs gründlich zu prüfen und langsam hochwertigen Code zu erstellen
• LLM-Agenten sind stark bei der Fehlererkennung in Codebasen, doch die eigentliche Schwierigkeit liegt in der Priorisierung und Verifizierung der gefundenen Punkte
• Ein Claude-Skill, der mehrere Modelle gemeinsam nutzt, prüft PRs mit Claude sub-agent, Codex und Cursor Bugbot und erstellt einen finalen Bericht mit reduzierten False Positives
• Der Ablauf besteht darin, critical/high-Probleme wiederholt zu beheben, Punkte mit geringem Nutzen im Verhältnis zu den Kosten zu überspringen und den PR aufzugeben, wenn es zu viele kritische Probleme gibt
• Dieser Ansatz stellt die Gesundheit der Codebasis über Geschwindigkeit und stärkt sorgfältiges Programmieren, das Fehlermodi und bestehende Bugs versteht

---

AI-Coding auf langsame Weise

• Die Sichtweise, AI-Coding nur als Mittel zur schnellen Massenproduktion von minderwertigem Code zu betrachten, unterschätzt die Flexibilität von LLMs
• LLMs lassen sich nicht nur für schnelle Codegenerierung einsetzen, sondern auch wirksam, um langsameren, hochwertigeren Code zu schreiben
• Im Gegensatz zu Ansätzen wie slop cannons, die ungeprüfte große PRs ausstoßen, ist auch ein Vorgehen möglich, bei dem PRs tiefer geprüft und potenzielle Fehler hartnäckig abgeklopft werden

Wichtiger als Fehlererkennung: Verifizierung und Priorisierung

• Mythos zeigt, dass LLM-Agenten sehr gut Bugs in Codebasen finden können
• Auch in anderen Fällen konnten Modelle, die nicht Mythos sind, in unüberprüften Codebasen viele Bugs finden
• Aktuelle öffentlich verfügbare Modelle von Anthropic und OpenAI unterscheiden sich zwar bei der Erkennung subtiler Bugs und beim Vermeiden von False Positives, können aber ausreichend viele Bugs finden
• Die eigentliche Herausforderung liegt weniger im Finden von Bugs selbst als in Priorisierung und Verifizierung

Ein Claude-Skill zur PR-Prüfung mit mehreren Modellen

• Ein AI-Code-Review-Ansatz, bei dem mehrere Modelle verglichen werden und diskutieren, fokussiert sich darauf, dass mehr unterschiedliche Modelle Halluzinationen oder fehlerhafte Bugmeldungen seltener machen
• Der verwendete Claude-Skill führt zur PR-Prüfung Claude sub-agent, Codex und Cursor Bugbot aus
• Jedes Tool bewertet Bugs im PR als critical/high/medium/low, danach werden die Ergebnisse zusammengeführt und ein finaler Bericht erstellt, aus dem False Positives entfernt wurden
• Der Umfang dessen, was als „Bug“ gilt, kann an die Standards des Projekts angepasst und erweitert werden
  • Verstöße gegen die Prinzipien KISS und DRY
  • Ob HTML/JSX barrierefrei geschrieben ist
  • Ob SQL-Abfragen geeignete Indizes verwenden
  • Sonstige projektspezifische Qualitätskriterien

Tatsächlicher Workflow und Entscheidungskriterien

• Mit diesem Ansatz lassen sich im PR viele Bugs finden, während die False-Positive-Rate fast auf 0 gesenkt werden kann
• Die gefundenen Probleme reichen von kritischen Bugs bei Sicherheit und Korrektheit über Performance-Probleme bis hin zu Problemen mit niedriger Schwere wie „dieser Kommentar ist irreführend“

• Typischer Ablauf

  • Probleme mit critical- und high-Einstufung werden vom Agenten beheben lassen, wobei ein Mensch die passende Lösung vorgibt
  • Dies wird wiederholt, bis keine critical/high-Probleme mehr übrig sind
  • High-/medium-Probleme mit schlechtem Kosten-Nutzen-Verhältnis werden übersprungen
  • Ein typisches Beispiel ist, wenn 100 Zeilen Code nötig wären, um einen engen Edge Case zu beheben
  • Wenn es zu viele critical-Probleme gibt und der gesamte Ansatz als falsch eingeschätzt wird, wird der PR aufgegeben

Fokus auf die Gesundheit der Codebasis statt auf Produktivität

• Diese Technik beschleunigt die Entwicklung nicht zwingend
• Während des Reviews können bestehende Bugs entdeckt werden, die schon vor dem PR vorhanden waren, was zum Schreiben von Unit-Tests und zum Beheben subtiler Defekte führen kann
• Das ist fast das Gegenteil der oft mit „vibe coding“ verbundenen Entwicklung im Stil von „10x Produktivität“
• In komplexen Architekturen sind Fehlermodi oft interessanter als der Normalpfad, und das Verstehen und Beheben dieser Fehlerstellen kann ein Weg sein, die Codebasis kennenzulernen
• Das ist nützlich, um die Gesundheit der gesamten Codebasis zu verbessern und zugleich wenig bekannte Ecken des Systems zu verstehen

Praktische Methoden für langsames vibe coding

• Wer mit Agenten PRs über Hunderte Zeilen erzeugt, die man selbst nicht vollständig versteht, kann eine langsamere Methode ausprobieren
• Man kann den Agenten fragen, wie der PR funktioniert und an welchen Stellen er scheitern könnte
• Bei Bedarf kann man ihn Markdown-Dokumente mit Mermaid charts erstellen lassen
• Bis man den PR von Anfang bis Ende versteht, kann man den Skill Matt Pococks /grill-me verwenden
• Die gemessene „Produktivität“ in Codezeilen steigt dabei vielleicht nicht, und nach vielen verbrauchten Tokens kann man zu dem Schluss kommen, dass der ursprüngliche Plan falsch war
• Dieser Ansatz ist eher eine stärkere Form des sorgfältigen, systematischen und qualitätsbesessenen Programmierens, das schon vor LLMs angestrebt wurde

[GN⁺]

Lobste.rs-Kommentare

• An meinem Arbeitsplatz haben wir den Traum aufgegeben, mit AI schneller voranzukommen. In unserem Fall ist das Codieren nicht der Engpass
  Trotzdem sind Coding-Agenten großartig, weil sie mich so arbeiten lassen wie der Engineer, der ich immer sein wollte
  Zum Beispiel beim Aufbau eines ordentlichen Test-Harnesses, mit dem man den Code etwas mutiger vorantreiben kann, beim Hinzufügen eines CI-Schritts, der prüft, ob generierter Code mit dem Original übereinstimmt, oder beim sauberen Monitoring von Change-Deployments
  Früher wären das Dinge gewesen, die ich terminlich nicht hätte stemmen können, weil ich dafür das GitLab-CI-Handbuch hätte lesen, herausfinden müssen, wie man die Bedingungen richtig setzt, und außerdem den verworrenen firmeninternen Ansatz hätte verstehen müssen. Jetzt ist das möglich, und ich denke, das ist die Zukunft

• Ich war ziemlich erfolgreich damit, LLMs als Spike-Partner mit API-Kenntnissen oder als Werkzeug für mechanisches Refactoring zu nutzen, besonders in stark typisierten Sprachen. Sie eignen sich auch gut zum Schreiben von Tests, aber man braucht einen mehrschichtigen Prozess, um sicherzustellen, dass diese Tests tatsächlich einschränkend wirken
  Mutation Testing war ziemlich hilfreich, und wie im Original vorgeschlagen, sind auch mehrere Durchgänge der Überprüfung nötig
  Früher war ich LLMs gegenüber viel negativer eingestellt, rückblickend geradezu irrational, aber das lag vor allem an der minderwertigen Software, die LLMs damals massenhaft ausgespuckt haben
  Nachdem ich selbst tiefer eingestiegen bin, habe ich gemerkt, dass man sie eher als Prototyping-Werkzeug aus Pappe und als deutlich schnellere Schreibkraft behandeln sollte. Wenn ich zum Beispiel sage: „Finde in allen Theoremen dieses Lean-Projekts dieses Muster, ersetze es durch jenes, und markiere die Stellen, an denen es nicht sofort klappt, und gib mir die verbleibende Liste“, dann korrigiert es mir in Chunks über 100 Theoreme, in der Zeit, in der ich mit vim, sed, awk und Notlösungen erst ein oder zwei Versuche starten würde
  Bei Lean ist das besonders gut, weil aufgrund der Spracheigenschaften und der Art meiner Arbeit der Abstand zwischen „kompiliert“ und „funktioniert“ klein ist. In Rust fühlt es sich mit einer guten Test-Suite und Mutation Testing ähnlich an
  Der Long Tail dieser Werkzeuge ist meiner Ansicht nach nicht „Knopf drücken, Produkt kommt raus“, sondern dass gute Engineers sie annehmen, ihre Energie auf die wichtigen Dinge konzentrieren und einen erheblichen Teil der früheren Routinearbeit an die Maschine delegieren

  • Anfangs war ich LLMs gegenüber auch sehr negativ, aber inzwischen finde ich, dass sie sich bis zu einem Punkt verbessert haben, an dem sie eher helfen als stören
    Das Beispiel ist interessant: Als ich früher in einem JavaScript-Framework-Team gearbeitet habe, habe ich für Dinge wie Upgrades oder Migrationen selbst Codemods geschrieben. Das war mühsame AST-Bastelei
    Heute würde ich das wahrscheinlich einem LLM geben und erwarten, dass es auf etwa 90 % kommt

• Ich mag diese Sichtweise. Es scheint offensichtlich, dass das Werkzeug flexibel ist und nicht zwangsläufig minderwertige Ergebnisse erzeugen muss, aber sowohl Befürworter als auch Ablehner ignorieren diese Perspektive oft
  Ich habe Code Review mit LLMs noch nicht ausprobiert, sollte es aber wohl auf meine To-do-Liste setzen. Bisher nutze ich sie eher für Ideenfindung und als Hilfe bei SQL oder VimScript und schreibe den Code selbst
  Ein Risiko ist, dass Code Review ebenfalls eine Fähigkeit ist. Wenn man sich zu sehr auf das Modell verlässt, könnte diese Fähigkeit verkümmern. Andererseits ist in kommerziellen Umgebungen selbst das beste Code Review normalerweise eher eine Kombination aus „angemessener Zeit“ und „vertraue ich dieser Person“ als etwas, das an mathematische Korrektheit heranreicht

  • Das stimmt, aber ich hatte sogar das Gefühl, dass dieser Workflow meine Code-Review-Fähigkeiten verbessert hat. Denn ich muss beurteilen, ob ein „Bug“ tatsächlich möglich ist oder nur theoretisch, ob es sich lohnt, ihn zu beheben, und ob er in den nächsten PR verschoben werden sollte
    Komplexe Bugs denke ich meist selbst vollständig durch, weil 1) sich immer noch Halluzinationen einschleichen und 2) es ohnehin wertvoll ist, das System End-to-End zu verstehen

• Eher meta, aber ich verstehe die Flags bei diesem Beitrag nicht. 1× off-topic, 3× spam ist seltsam
  Der Beitrag ganz oben auf der Startseite handelt auch von der Nutzung von LLMs, und da er sich um allgemeines Schreiben dreht, wirkt er sogar weniger thematisch passend als dieser hier, der auf Coding fokussiert ist, aber offenbar ohne Flags

  • Vermutlich wird es als Eigenwerbung angesehen und deshalb als Spam markiert

• Es ist erfrischend, diese Perspektive auf Lobsters zu sehen. Die pauschale Anti-AI-Stimmung wird allmählich ermüdend. Dass niemand minderwertige Ergebnisse mag, darauf können wir uns vermutlich alle einigen
  Aber Menschen, die AI vollständig boykottieren und eine dogmatische Haltung einnehmen, werden es schwerer haben, die Zukunft zu akzeptieren, als diejenigen mit einer pragmatischeren Haltung
  Ich sage schon von Anfang an, dass AI der Erfindung von Elektrowerkzeugen ähnelt. Wenn du einen Reifen mit einem Hand-Radschlüssel wechseln willst, ist das in Ordnung, aber als der Schlagschrauber aufkam, haben Mechaniker ihn auch nicht boykottiert. Im Kontext des Beitrags ist das nicht die perfekte Analogie, aber ich halte sie weiterhin für zutreffend
  Mit AI habe ich mehr gelernt als beim Lesen von Dokumentation, weil man der Doku keine Rückfragen stellen kann, wenn man mehr Kontext, Erklärungen oder Beispiele braucht. Man kann auch sagen: „Bau einfach etwas und mach keine Fehler“, aber ich bevorzuge den langsameren Ansatz, um tatsächlich zu lernen

  • Eine pauschale Anti-AI-Stimmung habe ich hier nicht gesehen. Kannst du Beispiele verlinken?
    Was ich gesehen habe, war Kritik an Veränderungen, bei denen mit LLMs Millionen Zeilen Code auf einmal geändert und dann ohne menschliches Review ausgerollt werden. Konkret zum Beispiel im Thread über das Portieren von Bun von Zig nach Rust
    Genau das kritisiert dieser Beitrag ebenfalls