Agenten gut, alles gut?

Agenten machen lange liegengebliebene Refactorings plötzlich erschwinglich.
Mehr Parallelität durch Agenten erhöht mentale Last und Komplexität.
Nutze Agenten, um Code zu reduzieren und Entscheidungen zu challengen.
Generiere nicht gleichzeitig Features und neue Test-/Framework-Schichten.
Frameworks bleiben Leitplanken; Boilerplate-Explosion macht niemanden produktiv.

Die ewige Wunschliste

Lass uns doch Consumer-Driven-Contract-Tests mit Pact integrieren, denn wir haben da diese 23 Microservices geerbt, die wir mit 3 Personen maintainen sollen. Eine BDD-Testsuite mit Cucumber würde uns total helfen, ultrakomplexe Fachlichkeit transparent sicherzustellen, aber wir haben echt keine Zeit, alle 2 Wochen 3 Tage lang das Selenium-Setup zu debuggen, weil es wieder 5 Browser-Updates gab, die 70 % der Tests haben rot werden lassen. Dieses eine Refactoring schieben wir schon ewig vor uns her, aber das würde sich durch die gesamte Codebase ziehen. Mindestens 3 Tage Fleißarbeit würde das bestimmt bedeuten. Aber das liefert ja keinen spürbaren Impact für User. (Spürbar wird es erst in 2–3 Jahren werden, wenn die Liefergeschwindigkeit immer weiter sinkt. There is no glory in prevention.)

Hilfreiche Projektinfrastruktur, die aber entweder hohen initialen Zeitinvest oder langfristige Wartung bedeutet, wird und wurde häufig nicht umgesetzt. Entweder sind Teams personell nicht entsprechend aufgestellt oder es fehlt entsprechendes Backing durch die Organisation. So oder so, Ressourcen werden „aus Gründen“ nicht bereitgestellt für eigentlich notwendige Maßnahmen. Sollten wir jetzt mit Agenten alles umsetzen, und würde dadurch alles besser?

Jetzt wird alles besser

Mein initialer Reflex war „JA“, und ich habe einige Refactorings sehr effizient umsetzen können, während ich parallel weiter an Features arbeiten konnte. Das hat sich unglaublich gut angefühlt. Phasenweise fühlte ich mich regelrecht entfesselt. Es gab immer was zu tun, und ich konnte mich (endlich) mehr auf das Lösen fachlicher Probleme fokussieren. Die Technik stand mir nicht im Weg, sondern ermächtigte mich. Wenn ich über komische Bugs stolperte oder mit Frameworks kämpfte, habe ich erst gar nicht mehr versucht, auf Bugsuche zu gehen: Stacktrace Copy & Paste -> Info an den Agenten -> „Fix das“ -> Ab zum anderen Task -> Push-Notification macht „Pling“ -> Test grün -> Repeat. Ich hatte endlich wieder ein Gefühl von „Flow“. Kein stundenlanges Step-Debugging und Recherche in API-Dokus und Stackoverflow (RIP). Ende gut, alles gut?

Im nächsten Schritt wollte ich ganz neue Testklassen einführen. Es gab da noch diese vernachlässigte BDD-Testsuite, die immer ein schlechtes Gewissen erzeugte. Als ich loslegen wollte, hatte ich einen Moment der Klarheit und hielt inne. Wollte ich wirklich ein Tool nutzen, was mir evtl. wieder weggenommen werden kann, wenn die VC-Kohle verbrannt ist, um meine Projektkomplexität zu erhöhen? Sind nicht gerade Ressourcen-Constraints etwas, was uns auf das wirklich Wichtige fokussieren lässt? Ich merkte, dass dieser Arbeitsmodus mental ermüdend ist und zukünftig wieder in genau die gleiche Situation führen kann. Nur hat man dann noch viel mehr Komplexität zu jonglieren.

Mehr ist mehr. Oder?

Vielleicht konnte sich in der alten Welt mein Gehirn während „stumpfer“ Refactorings wieder mit Problemlösungsenergie aufladen? Ich bin einen Schritt zurückgetreten und habe den Modus radikal geändert. Zusammen mit den Agenten habe ich in wesentlich mehr Iterationen daran gearbeitet, den generierten Code immer weiter zu reduzieren und die Ausdrucksstärke zu erhöhen. Ich habe Agenten meine Architekturentscheidungen challengen lassen und konnte mit durchdachteren Konzepten in die Diskussion mit meinem Team gehen. Ich habe Agenten benutzt, um weniger, aber besseren Code zu erzeugen als vorher. Schließlich muss noch ich den Code noch lesen können, reviewen lassen und die Verantwortung übernehmen. Die Ergebnisse sind besser, und auch die Produktivität ist höher, aber nicht um Größenordnungen.

Mehrere fachliche Features parallel zu bauen hat zu höherer mentaler Belastung geführt, und die Ergebnisse wurden nicht besser. Also habe ich mir eher mehr Zeit zum Denken verschafft, indem ich mir nervige Blockaden durch Bug-Suchen erspart habe.

Divide and Conquer: Der richtige Einsatz von Agenten

Deshalb dieser Aufruf: Generiert guten fachlichen Code und baut gute, sichere Frameworks mit Agenten, aber nicht beides gleichzeitig. Divide and Conquer! Lauft nicht in die Falle, unendlich viel Boilerplate zu generieren. Dafür sind Frameworks da! Frameworks sind nicht obsolet, sondern werden noch wichtiger als Leitplanke für Agenten. Nicht jeder muss sein eigenes ORM oder seinen Auth-Code viben. Please don’t!

Guter Softwareentwickler vs. guter Programmierer

Ich glaube, KI macht mich zu einem schlechteren Programmierer, da ich weniger Konzepte parat haben muss. Ich muss sie nur noch bei Bedarf verstehen. Aber will ich ein guter Programmierer sein? Das Produzieren von (viel) Code hat noch nie Probleme gelöst (häufig eher viele erzeugt). Bei Softwareentwicklung ging es noch nie darum, viel Code zu schreiben. Code ist ein Werkzeug, um fachliche Probleme zu lösen. Also nutze ich die Agenten auch lieber dafür ein guter Softwareentwickler und -architekt zu sein. Es wird weiterhin Personen brauchen, die dem Agenten die richtigen Fragen stellen und die Rückfragen korrekt beantworten. Da bin ich dann bei Marx: Maschinen erhöhen die Produktivität, aber es braucht immer die menschliche Arbeit, um letztendlich Wert zu schaffen. Das kann die Maschine nie allein[1]. Aber sehen das wirklich alle so? Es gibt immer noch Personen, die Entwicklerproduktivität in LOC messen wollen. Ein positiver Ausblick wäre, dass die jetzt durch Unmengen von Code-Slop endlich verstehen könnten, dass das keine gute Idee ist und auch nie eine war.

„Gleich jedem andren Bestandteil des konstanten Kapitals schafft die Maschinerie keinen Wert, gibt aber ihren eignen Wert an das Produkt ab, zu dessen Erzeugung sie dient.” https://www.textlog.de/kapital-wertabgabe-produkt.html ↩︎

Blog-Post