Eine wahre Geschichte, wie man falsche Dinge beschleunigt

Der ursprüngliche 40-minütige Talk ist bei WeAreDevelopers verfügbar.

Ist der erste Versuch falsch, kostet der nächste kaum etwas. Das ist tatsächlich nützlich. Es legt aber auch etwas offen, das sich leichter übersehen ließ, solange das Schreiben von Code mehr Aufwand erforderte: Mit der Implementierung allein war die Entwicklungsarbeit noch nie erledigt.

Der schwierige Teil liegt zunehmend in den Entscheidungen rund um den Code. Eine Änderung muss ins System passen, eine Abstraktion ihren Platz verdienen. Eine vorhandene Implementierung kann hässlich und trotzdem ausreichend sein. Eine gewünschte Funktion kann einwandfrei laufen, ohne die damit verbundene Erweiterung des Systems zu rechtfertigen. Neu ist daran nichts. Nur fallen diese Entscheidungen im Verhältnis zur Umsetzung stärker ins Gewicht, sobald eine weitere Implementierung fast nichts mehr kostet.

Damit verändert sich auch, was als Produktivität erscheint. Generierter Code ist sichtbar und lässt sich zählen. Wer sich gegen eine Umsetzung entscheidet, hat nach außen hin weniger vorzuweisen, obwohl das die bessere technische Entscheidung sein kann. Dasselbe gilt, wenn jemand eine überflüssige Abstraktion verhindert, bevor sie im Repository landet. Je billiger die Produktion wird, desto weniger taugt die Menge als Maßstab für Fortschritt.

Wenn Code billig wird und Verständnis teuer bleibt, werden Systeme nicht einfacher. Es wird nur leichter, sie komplizierter zu machen. Die Fabrik arbeitet schneller. Die Landkarte ist nicht besser geworden.

Selbst die Unsicherheit kommt ordentlich sortiert daher. Bei herkömmlichen Softwarefehlern gibt es oft einen offensichtlichen Ansatzpunkt: Der Code lässt sich nicht kompilieren, ein Test schlägt fehl, eine Exception tritt auf oder das Verhalten ist sichtbar falsch. KI kann dagegen etwas liefern, das schlüssig genug wirkt, um Vertrauen zu erzeugen, bevor dieses Vertrauen begründet ist.

Plausible Unsicherheit ist eine gefährliche Benutzeroberfläche.

Das verändert, was ein Review leisten muss. Wer den Code prüft, muss herausfinden, welche Annahmen in die Implementierung eingeflossen sind, welche Randbedingungen das Modell kannte, ob eine Abstraktion ein tatsächlich vorhandenes Problem löst und ob eine in sich plausible Lösung zur Architektur des Systems passt. Nichts davon wird billiger, nur weil der erste Entwurf schnell fertig war.

In echten Projekten ist die Zeit für Reviews begrenzt, und die Abgabetermine verschwinden nicht, nur weil Code schneller entsteht. Eine Implementierung, die vernünftig aussieht und die naheliegenden Prüfungen bereits besteht, hat deshalb einen erheblichen Startvorteil gegenüber einer, die sichtbar unfertig ist. So landet „passt fürs Erste“ leicht im Repository, und Repositories sind ausgesprochen schlecht darin, sich zu merken, welche Teile eigentlich nur als Übergangslösung gedacht waren.

Tests, statische Codeanalyse, Build-Systeme, Deployment-Checks und Monitoring helfen uns dabei, Änderungen vorzunehmen, das Ergebnis zu beobachten und nachzusteuern. Entscheidend ist, was eine solche Schleife im Erfolgsfall tatsächlich belegt.

Eine grüne Testsuite zeigt, dass die Implementierung die darin hinterlegten Prüfungen bestanden hat. Das ist ein nützlicher Beleg, ersetzt aber keine Begründung für den Entwurf. Daraus erfahren wir nicht, ob die Lösung ins bestehende System passt, ob ihre Annahmen tragen, die zusätzliche Komplexität gerechtfertigt ist oder die Tests überhaupt den Teil des Problems abdecken, auf den es uns ankommt.

Ein Agent kann also mehrere gescheiterte Ansätze verwerfen und schließlich eine Variante liefern, die alle Tests besteht, ohne die endgültige Form der Lösung besonders gut erklären zu können. „Irgendwann waren die Tests grün“ ist nicht dasselbe wie „Wir wissen, warum das die richtige Lösung ist“.

Die Chatoberfläche macht es erstaunlich leicht, diesen Unterschied zu übersehen. Jeder neue Versuch kann mit einer plausiblen Erklärung daherkommen; die Suche nach Alternativen wirkt dadurch möglicherweise durchdachter, als sie tatsächlich ist. Der eigentliche Nutzen liegt vielleicht schlicht darin, dass das System Möglichkeiten billig durchprobieren und schnell auf Rückmeldungen reagieren kann. Daran ist nichts auszusetzen, solange wir erfolgreiches Ausprobieren nicht mit Verständnis verwechseln.

KI-Agenten können aus Softwareentwicklung Brute Force mit Chatoberfläche machen. Das Gespräch macht den Ablauf leichter nachvollziehbar; eine technische Begründung für das Ergebnis entsteht dadurch noch nicht.

Künftige Änderungen müssen sie berücksichtigen, und irgendwann muss jemand genug von der neuen Struktur verstehen, um sie sicher ändern zu können. KI kann damit die Erzeugung von Komplexität verbilligen, ohne deren Folgekosten zu senken. Komplexität allein ist allerdings kein Beleg für schlechte Entwicklungsarbeit.

Sieben Abhängigkeiten können durchaus gerechtfertigt sein, und eine neue Abstraktion kann ein schwieriges Problem elegant lösen. Entscheidend ist, ob es für diese Komplexität einen Grund gibt, den jemand erklären kann. Ein bestandener Test kann das beobachtete Verhalten bestätigen, erklärt aber nicht, warum eine bestimmte Struktur nötig war, weshalb sich eine zusätzliche Abhängigkeit lohnte oder welche Randbedingung eine einfachere Lösung ausgeschlossen hat.

Je billiger die Generierung wird, desto wichtiger wird dieser Unterschied, denn Kosten können sich verschieben, statt zu verschwinden. Die Implementierung dauert vielleicht nur Minuten statt Stunden. Ihre Struktur bleibt jedoch Gegenstand von Reviews, Wartung und Fehlersuche und muss bei jedem späteren Versuch, diesen Teil des Systems zu verstehen, erneut berücksichtigt werden. Auch billiger Code kann einen Kontext schaffen, dessen Verständnis teuer ist.

Mailinglisten, Issue-Tracker, Forendiskussionen, Stack-Overflow-Antworten und alte Kommentare halten weit mehr fest als fertige Lösungen. Ihr Wert steckt oft gerade im Durcheinander: Jemand hat den naheliegenden Ansatz ausprobiert und herausgefunden, warum er scheitert. Ein anderer hat eine API falsch verstanden und wurde korrigiert. Ein Workaround wirkte clever, bis ein weiterer Entwickler erklärte, was er kaputtmacht.

Dieser überlieferte Lösungsweg ist Teil unseres technischen Wissens. Die akzeptierte Antwort allein ist oft weniger hilfreich als die Diskussion darum. KI-gestützte Arbeit findet zunehmend dort statt, wo solche Spuren leicht verloren gehen.

Ein IDE-Assistent schlägt einen Ansatz vor, ein Agent versucht einen anderen, ein Test legt eine unerwartete Randbedingung offen, die Implementierung wird erneut geändert, und irgendwann landet ein funktionierender Patch im Repository. Wie der Patch zustande kam, wird womöglich nirgends so festgehalten, dass das Team später danach suchen oder darauf zurückgreifen kann.

Mit den gescheiterten Ansätzen verschwinden auch die Annahmen, die sie widerlegt haben. Ein anderer Entwickler oder Agent kann morgen wieder in derselben Sackgasse landen, weil das System zwar die Antwort behalten hat, aber nicht die gewonnene Erkenntnis. Billige Iterationen verlieren damit einen Teil ihres Reizes: Die Organisation verbraucht womöglich immer wieder Rechenleistung und die Aufmerksamkeit ihrer Entwickler, um Dinge zu lernen, die sie bereits einmal gelernt hat.

Bleibt nur der fertige Patch übrig, hat der Workflow Aktivität erzeugt, aber nicht unbedingt Wissen. Ein System, das immer wieder bei null anfängt, kann sehr effizient darin werden, teuer erarbeitete Erkenntnisse wieder zu vergessen.