Sechs Monate Code nur mit KI-Agenten: Ein Selbstversuch

> Der größere Kostenpunkt war das Tippen. Jedes Mal, wenn ich etwas bauen wollte, sah ich den Code in meinem Kopf. Ich konnte ihn nur nicht schnell genug tippen.

Fakt. Für mich gilt: Je größer die Kluft zwischen dem, was ich in meinem Kopf sah, und der Geschwindigkeit, mit der meine Finger es physisch realisieren konnten, desto mehr Stress fühlte ich, und manche Marathon-Coding-Sessions endeten mit einem völlig verspannten Rücken, nur wegen der Anspannung.

Und vor LLMs hätte er in der Mittagspause schnell ein zwanzigzeiliges Bash-Skript und einen Cron-Job zusammengeschustert und dann sechs Monate an etwas anderem gearbeitet.

Wie lesen Leute diese Art von Beiträgen mit diesem KI-Flair? Ich konnte nicht mehr als ein paar Sätze lesen.

Mehrere Kommentare hier sprechen das Kernproblem an: Agenten schreiben mehr Code, als wir reviewen können. Seniors hatten nie genug Zeit zum Reviewen, und die produktive Ausgabe von Coding-Agenten macht es schlimmer. Außerdem ist der Code fast immer gut. Du reviewst also eine Flut von ziemlich gutem Code, was zu Review-Müdigkeit führt und das Ganze zur reinen Farce wird.

Für mich bedeutet das, dass die Checks mehr sein müssen als nur "Ich habe es mir angesehen". Es gibt zwei Dinge, die passieren, bevor ich es überhaupt sehe: Erstens, wie andere erwähnt haben, lasse ich ein Modell aus einer anderen Familie es mit klar definierten Kriterien reviewen. Reviewer aus derselben Familie teilen sich Vorurteile, also muss es ein anderes sein. Zweitens habe ich eine Reihe von deterministischen Gates (wie Lint, aber auch Unit-Tests), die laufen müssen. In beiden Fällen gehen Fehlschläge zurück an den Coding-Agenten.

Und erst dann kümmere ich mich darum. Aber ich lese wirklich nicht alles. Wenn es Standard-CRUD-Operationen sind, sind die Agenten darin ziemlich gut, besonders wenn sie ausgereifte Pakete verwenden. Ich konzentriere mich auf kritische Dinge, wie die Durchsetzung von Berechtigungen.

Das funktioniert für mich gut, obwohl es ein großes Problem unberührt lässt: ob es sich lohnt, das zu bauen. Die Agenten neigen dazu, etwas übereifrig zu sein, also muss ich im Vorfeld viel Arbeit leisten, um sicherzustellen, dass die Ausgabe einen Mehrwert bietet. Die Gates können nur das Artefakt prüfen, nicht meine Absicht.

Code mit LLMs zu schreiben erfordert Disziplin und ist schwierig. Du musst lernen, wie man es macht und wie man das Beste daraus herausholt.

Softwareentwicklung ist tot, es lebe die Softwareentwicklung!

Ich fühle eine wirklich seltsame Dissonanz mit all diesen Berichten. Ich habe auf der Arbeit Zugang zu Top-Modellen über Cursor. Jedes Mal denke ich mir: Hier ist eine langweilige, aber klar definierte Aufgabe mit klaren Erfolgskriterien, bei der man mit beharrlichen Iterationen viel erreichen kann. Ich gebe sie Claude.

Zuerst brauche ich ewig, um die Aufgabe richtig zu beschreiben. All diese klaren Erfolgskriterien – nun, statt Code aus einer klaren Spezifikation in meinem Kopf zu schreiben, schreibe ich Unmengen von Prosa und versuche, sie eindeutig zu machen. Ich programmiere in English++.

Aber dann, einmal in fünf Fällen, produziert es etwas, das irgendwie funktioniert. Vielleicht nicht perfekt, aber gut genug. In zwei von fünf Fällen sieht es irgendwie ganz okay aus, ignoriert aber tatsächlich 80 % der Spezifikation oder zollt ihr nur minimal in den Kommentaren Tribut.

Und manchmal, vielleicht etwas seltener als 2/5, driftet es völlig in den totalen Müll ab. Es beginnt, Skripte zu schreiben, die das AST des Hauptskripts laden, einpicken und dann ohne guten Grund in Base64 serialisieren. Kodiert einige Dinge in Strings und prüft dann wiederholt ord(string[i]) für String-Vergleiche. Irgendwann geht ihm der Kontext aus und es entwickelt das LLM-Äquivalent von schwerer Demenz.

Ich kann meine Erfahrung wirklich nicht mit Leuten in Einklang bringen, die zu sagen scheinen: "Hey Computer, schreib das", und es ist eine gute Nutzung ihrer Zeit.

Schade, einen ansonsten guten Artikel mit KI-typischen Floskeln aufgebläht zu sehen ("Aber hier ist der Twist: Die Suche, die ich vorhin beschrieben habe, wurde nie an botd gesendet. Die gesamte Historie war in SQLite, also habe ich einen anderen Agenten darauf angesetzt und die Analyse trotzdem bekommen. Das Tool starb; die Daten nicht.", unter anderen Beispielen).

Maisem Ali schreibt darüber, wie sie trotz der Übergabe der Code-Produktion an KI nicht aufgehört haben zu entwickeln. Ich denke, das ist aus mehreren Gründen eine interessante Perspektive, aber vor allem bin ich mir nicht sicher, ob ich zustimme.

Erstens sehen wir ein Paradebeispiel dafür, wie das nach hinten losgehen kann. "botd ist diesen Monat gestorben. Es ist unter seinem eigenen Gewicht zerbrochen." Es ist schwer vorstellbar, wie ein Agenten-Harness (oder ist es ein Overlay auf anderen Harnesses?) allein durch technische Komplexität unter seinem eigenen Gewicht zerbrechen könnte. Was bringt ein solches Tool zum "Zerbrechen"? Wenn es richtig architekturiert ist, scheint jede äußere Änderung anpassbar zu sein. Fehlschlagende Tests könnten behoben werden.

Diese KI-Coding-Revolution hat uns die Fähigkeit gegeben, Prototypen zu erstellen, deren innere Funktionsweise wir nicht verstehen, aber ich glaube, für alles von Wert (und ich würde argumentieren, dass botd für Maisem Wert zu haben schien) sollten wir zumindest die Architektur und das Engineering dessen, was wir bauen, verstehen und beeinflussen. Wenn Maisem das für botd getan hätte, wäre es nicht und _hätte nicht_ "unter seinem eigenen Gewicht zerbrechen" können. Welcher äußere Einfluss auch immer Änderungen innerhalb von botd erforderte, wäre handhabbar gewesen.

Zweitens deutet die Auslagerung der Produktion dieses Artikels darauf hin, dass m […]