Mit AI besseren Code langsamer schreiben
(nolanlawson.com)- 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
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-meverwenden - 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
2 Kommentare
Hacker-News-Kommentare
Wenn man mit AI arbeitet, ist es inzwischen kein einfacher Einzelschritt mehr, sondern eine lange Review-Schleife mit vielen Rückkopplungen
Bei mittelgroßen Features, die mehrere Bereiche betreffen, entwerfe ich zuerst mit AI die Implementierung, prüfe dann die Details und lasse es anschließend von Claude 4.7 Max umsetzen, das langsam ist, aber gute Ergebnisse liefert.
Danach prüfe ich die Implementierung und lasse sie noch einmal von Codex GPT 5.5 xhigh fast reviewen; dabei werden fast immer Randfälle gefunden. Die Korrekturen lasse ich von Claude machen: Codex ist stark beim Finden von Bugs und beim Review, neigt aber zu Overengineering oder dazu, Abkürzungen einzubauen, während Claude meist intuitiveren und besser wartbaren Code schreibt.
Anschließend lasse ich die gestagten Änderungen noch einmal von einer neuen Claude-/Codex-Instanz prüfen, arbeite das Feedback ein und schreibe dann Tests dazu. Es ist immer noch schneller, als alles von Hand zu schreiben, aber die meiste Zeit geht für Reviews und das Behandeln von Randfällen drauf, und das Ergebnis fühlt sich an wie eine v1-Funktion, die schon mehrfach iteriert wurde — also eher wie eine Implementierung auf v3-Niveau
Das fühlt sich produktiv an, die AI-Ergebnisse werden gut, und am Ende verstehe ich den Code meistens noch selbst. Wenn ich den ganzen Tag mit einem Roboter über Design und Architektur diskutiere, habe ich das Gefühl, genau das ist der Punkt, an dem mich die AI-Revolution zu einem besseren Engineer gemacht hat
Mein Ansatz ist, fünf Runden aus Recherche/Planung/Testplanung zu machen, und bei jeder wichtigen Entscheidung bin ich selbst im Loop. Ich beginne mit der groben Form und gehe dann ins Detail; allein die Planung kann mich 2–3 Tage kosten, und der Implementierungsagent (Opus 4.7) braucht mehrere Stunden.
Die Implementierung ist in mehrere Schritte/Commits aufgeteilt, und in jedem Schritt gibt es eine Review-und-Korrektur-Schleife. Auch das abschließende tiefe Code-Review kann 1–2 Stunden dauern; wenn ich den PR öffne, reviewt Gemini ihn, ich lese das und behebe die Punkte.
Projekte dauern immer noch Tage oder Wochen, aber verglichen damit, alles allein zu machen, ist es 5x schneller
Zusatz: Der Skill liegt hier: https://github.com/scosman/vibe-crafting
In manchen Fällen habe ich das AI-Ergebnis verworfen und es einfach selbst gemacht. Ich denke, das ist eine Fähigkeit, die Leute lernen müssen. Irgendwann muss man wissen, wann man abbrechen sollte. Gerade bei einfachen Änderungen habe ich Kollegen gesehen, die endlos mit einem LLM diskutieren, um es zu irgendetwas zu bewegen
Man wird vielleicht ein bisschen schneller, indem man sich ständig um die AIs kümmert, aber verliert man dabei nicht Wissen und Kontrolle darüber, was die AI eigentlich getan hat?
Der Beitrag[1], in dem LLMs gegenseitig ihre Code-Reviews kritisieren, das Tool magpie[2] und Cloudflares jüngster Beitrag über ihren Code-Review-Stack[3] sind ziemlich überzeugend
Ich bin AI gegenüber eher skeptisch, aber der Grund ist für mich eher „Ist das gut für die Welt?“ als „Funktioniert das?“. Solche Review-Arbeiten wirken auf mich selten genug wie ein Fall, in dem Denken nicht ausgelagert oder die Fähigkeiten von Arbeitskräften nicht untergraben werden. Es löst bei mir nicht dieselben Alarmglocken aus, AI Code schreiben zu lassen oder von AI gefundene Probleme wieder von AI beheben zu lassen. Natürlich bleiben Umweltprobleme und andere ethische Bedenken weiterhin groß.
Von der jüngsten Qualität von AI-Code-Reviews war ich beeindruckt, aber die Erfahrung, in einem GitHub-PR separat mit drei AI-Reviewern zu interagieren, ist furchtbar. Ich hätte gern eher lokal ausgerichtete Review-Runden, die jj/rebase verstehen.
Kontext: recht großes PHP/Laravel-Backend und Vue-Frontend
[1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
[2]: https://github.com/liliu-z/magpie
[3]: https://blog.cloudflare.com/ai-code-review/
Die Zeit, die ich in LLM-Review-/Korrektur-Schleifen stecke, ist im Durchschnitt länger als Code direkt von Hand zu schreiben
Das liegt auch daran, dass ich, wenn ich im Flow bin, extrem schnell Code schreibe und manchmal schneller, als ich selbst gedacht hätte. Außerdem ist das, was ein LLM in den ersten paar Versuchen ausspuckt, meistens wirklich schlecht.
Trotzdem ist interessant, dass am Ende im Durchschnitt höhere Qualität herauskommt als bei Code, den ich in derselben Zeit selbst geschrieben hätte, wenn ich ihn direkt prüfe und mehrmals Reviews und Korrekturen anstoße. Wenn ich sehe, wie der Code eines anderen mehrfach iteriert wird, scheint mir das ein umfassenderes Verständnis meines Ziels zu geben als ein Ergebnis, das direkt aus einem Zustand tiefer Konzentration herausgeschossen kommt
Dieser Beitrag handelt nicht vom Schreiben von Code mit AI, sondern nur von Code-Review
Mein Problem mit agentischem Coden ist, dass ich beim Programmieren unzählige mikroarchitektonische Entscheidungen treffe. Fast nie liegt von Anfang an eine vollständige Spezifikation vor; ich entwickle die Spezifikation erst beim Schreiben.
Wenn ich Claude Code oder Codex nutze, verschwindet dieser Prozess. Claude Code ist so stark darauf fixiert, das Ziel zu erreichen, dass sich das gemeinsame Coden wie ein fiebriger Traum anfühlt. Am Ende bin ich mir weniger sicher bei Randfällen oder dabei, wie gut das Ergebnis zu den Architektur-/Designzielen des Projekts passt.
Außerdem mache ich Programmierung, Reverse Engineering usw. gern. Ein LLM kann zwar Probleme lösen oder Features liefern, aber es fühlt sich an, als würde es mir diesen Spaß nehmen. Ich versuche, einen Ablauf zu finden, den ich mit Überzeugung nutzen kann, aber ich fürchte, am Ende läuft es darauf hinaus, dass es nur für Chat, Suche und als Rubber Duck für meine Gedanken dient
Umgekehrt drängen manche Unternehmen darauf, dass Engineers eine robuste Self-Evaluation-Agent-Pipeline mit menschlichem Feedback im Loop aufbauen, damit Agenten den Großteil des Production-Codes schreiben
Der CEO von Creao sagte, er habe im Januar dieses Jahres das komplette Production-System in nur zwei Wochen neu architekturiert. Er behauptete auch, die Agenten hätten zu viele Features zu schnell implementiert, sodass man darauf warten musste, dass die Business-Development-Seite aufholt
Ich frage mich, wie man die Option bewerten soll, mit AI den Output um das Hundertfache zu steigern, gegenüber der Option, mit AI die eigenen Fähigkeiten weiterzuentwickeln
Gleichzeitig ist der Produktivitätsgewinn durch AI real. Zum Beispiel hat eine Engineering-Organisation bei Snowflake zum ersten Mal in der Firmengeschichte alle OKRs in einem Quartal vorzeitig erreicht. Normalerweise galt es schon als Erfolg, 70 % der geplanten OKRs zu schaffen, daher kann ich mir den Stress vorstellen, den Engineers bei solchen Ergebnissen empfinden
Der Titel dieses Beitrags ließ mehr Tiefe erwarten, und ich hatte echte Codebeispiele erwartet
Stattdessen ist es ähnlich wie andere Meinungsbeiträge. Es läuft darauf hinaus, Prompts vorzuschlagen, die für den Autor funktionieren, also AI anzuweisen, nach Bugs zu suchen, und dann allen zu empfehlen, das genauso zu machen
Ich nutze solche Tools sowohl bei der Arbeit als auch bei privaten Side-Projects und hatte gehofft, etwas Konkretes zu sehen und zu lernen, aber meinungsstarke Beiträge ohne Beispiele gibt es inzwischen einfach zu viele
Der Autor könnte sich dafür natürlich ein Code-Harness bauen oder schnell etwas zusammenstecken, aber diese Art von Tooling liegt im Moment eher in deinem Bereich als Praktiker. Wenn du das automatisieren und damit experimentieren willst, ist es vermutlich ehrlich gesagt schneller, selbst zu spezifizieren, was du möchtest, als dich mit seinem Code herumzuschlagen
Während ich das hier lese, arbeite ich gerade an einem recht umfangreichen Feature und musste dabei ziemlich viel iterieren
Das Endergebnis ist deutlich weniger Code als der Stand ungefähr zur Hälfte. Deshalb habe ich mich gefragt, ob AI tatsächlich geholfen hat. Für die Zeit, die in die Iterationen geflossen ist, hätte ich den Code vielleicht auch direkt selbst schreiben können
Mit AI konnte ich allerdings schnell vier Feature-Varianten grob bauen und sie genauso schnell wieder verwerfen, ohne dass sich das belastend anfühlte
Früher musste ich sehr viel über die Planung nachdenken, bevor ich mit der Implementierung eines neuen Features begonnen habe, und Unstimmigkeiten mit dem bestehenden Code fielen oft erst auf, nachdem schon einiges an Implementierung geschrieben war. Jetzt kann ich AI nach einem detaillierten Implementierungsplan fragen und solche kleinen Detailprobleme in ein paar Stunden oder sogar noch schneller finden
Interessant war für mich in den letzten Jahren, die Grenzen meiner Faulheit beim Coden nachzuverfolgen
Als Coder hasse ich Boilerplate-Code. Ich will ihn weder schreiben noch warten. Deshalb habe ich Design und Architektur oft rund um diese Vorliebe aufgebaut, manchmal klug, manchmal nicht. So oder so war es meine Präferenz, und ich habe Dinge vermieden, die für mich mühsam waren
Als LLMs vor ein paar Jahren anfingen, beim Coden einigermaßen nützlich zu werden, wurde mir klar, dass sie bei Boilerplate praktisch hervorragend sind und ungefähr 2023 fast nur darin gut waren. Das brachte mich dazu, darüber nachzudenken, wie sehr wir bei Design und Systemarchitektur stillschweigend Rücksicht auf die Stärken und Schwächen der Menschen nehmen, mit denen wir zusammenarbeiten
Aktuelle Modelle haben im Vergleich zu Menschen sehr andere Stärken und Schwächen, und sie einzusetzen ist eine interessante Übung, die andere Arten von Architektur- und Engineering-Skills erfordert. Mir macht das Spaß, und ich hoffe, das bleibt so
Es ist viel besser, mit
django-admin startproject,npm init,meteor createdeterministischen Output zu bekommen, als einen Prompt an ein LLM zu werfen und nicht zu wissen, was herauskommtIn einem ausgereiften Web-Ökosystem ist Boilerplate minimiert. Jetzt, wo diese Arbeit an LLMs abgegeben wird, mache ich mir Sorgen, dass weniger Entwicklungsaufwand in
startproject-artige CLIs und gute Defaults fließtGefällt mir. Ich nutze auch einen ähnlichen ralph-loop-Ansatz
Ich beginne mit einem freigegebenen Plan und übergebe ihn an einen Koordinator; vereinfacht läuft es über zwei Sessions, Build und Review, wobei an jede Session ein separates Modell gekoppelt ist
Für mich ist die Hürde beim Einsatz von Coding-Agenten, dass man sich auf kostenpflichtige externe Dienste verlassen muss
Gibt es ein brauchbares lokales Modell fürs Coding?
Das könnte ebenfalls hilfreich sein: https://hnup.date/hn-sota
Qwen-Modelle sind diese Woche meine täglichen Standardmodelle
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
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
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
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
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