Der Turm wächst immer weiter

• Die Art, wie „vibe-coded“ Software sich zufällig und unerwartet verändert, erinnert an den Turm von Babel, dessen Bau zum Stillstand kam, weil die gemeinsame Sprache verloren ging; im KI-Zeitalter besteht der Unterschied jedoch darin, dass der Bau auch nach dem Zusammenbruch des Verständnisses weitergeht
• Die Grenzen großer Software liegen nicht nur in der Geschwindigkeit, mit der Einzelne Code produzieren, sondern auch darin, wie gut sie ein gemeinsames Verständnis von Konzepten, Grenzen, Invarianten, Ownership und den Gründen für Designentscheidungen koordinieren
• Die Reibung, die beim Erkunden von Code, bei Fragen, Reviews und Abstimmungen zwischen Teams entstand, war zwar Verschwendung, aber zugleich ein Prozess, der das gegenseitige Verständnis synchronisierte und den Konsens über das System überprüfte
• Agenten erledigen Aufgaben wie OAuth hinzufügen, Caching einbauen oder eine Datenbank neu aufbauen parallel und ohne Gespräche; selbst wenn jede Änderung sinnvoll ist und Tests besteht, kann das gemeinsame Modell der Menschen schwächer werden
• Beim KI-gestützten Engineering interpretieren und ändern Agenten einzelne Bereiche und setzen den Bau ohne unmittelbares Scheitern fort. Dadurch ist schwer zu bemerken, dass die Architektursprache verloren geht, mit der Menschen das System gemeinsam durchdacht haben

---

Die Stärke des Turms von Babel lag eher in Koordination als in Technik

• Manche vibe-coded Software, die sich auf eher zufällige und unerwartete Weise verändert, lässt an Bruegels The Tower of Babel denken
• Die Geschichte vom Turm von Babel wird häufig als Erzählung über Hochmut und Ehrgeiz sowie als Erklärung dafür gelesen, warum Menschen unterschiedliche Sprachen sprechen; zugleich zeigt sie aber die Einigkeit, die technischen Fortschritt ermöglicht
• In Genesis 11, 3–6 (KJV) erzielen die Menschen technische Verbesserungen, indem sie gebrannte Ziegel statt Steine und Bitumen statt Mörtel verwenden, und wollen eine Stadt und einen Turm bauen, der bis in den Himmel reicht
• Was Gott als Problem sah, waren nicht die Ziegel oder das Herstellungswissen, sondern dass die Menschen ein Volk waren und eine Sprache teilten, sodass ihnen nichts verwehrt bleiben würde
• Wenn Menschen ihre Arbeit durch eine gemeinsame Sprache verbinden, können sie etwas bauen, das niemand allein schaffen könnte
• Nicht die Ziegel oder das Herstellungsverfahren gingen verloren, sondern die Fähigkeit, einander zu verstehen; dadurch wurde Koordination unmöglich, und der Bau kam zum Stillstand

Der Turm wächst weiter, auch nachdem KI-Agenten die Reibung beseitigt haben

• KI-gestützte Programmierung gibt Einzelnen mächtigere Werkzeuge, und Entwickler, die Agenten nutzen, können eine Codebase in deutlich größerem Umfang verändern
• Die Grenzen großer Projekte hängen jedoch nicht nur davon ab, wie schnell Einzelne Code produzieren, sondern auch davon, wie gut Menschen ihr Verständnis des zu ändernden Systems koordinieren
• Die gemeinsame Sprache eines Softwareprojekts ist nicht Englisch oder Python selbst, sondern ein gemeinsames Verständnis der folgenden Punkte:
  • was die einzelnen Konzepte bedeuten
  • wo die Systemgrenzen liegen
  • welche Invarianten wichtig sind
  • wer wofür verantwortlich ist
  • warum das System seine aktuelle Struktur hat
• Dieses Verständnis ist nirgends vollständig dokumentiert; es sammelt sich nicht nur in Dokumentation und Code, sondern auch in Code Reviews, Gesprächen, Debatten und der Erfahrung, anderen eine Änderung zu erklären
• Vor Agenten musste man, wenn man die Storage-Schicht einer anderen Person ändern wollte, oft Code lesen, Fragen stellen und sich mit anderen Teams abstimmen, die abhängige Services betreiben
  • In diesem Prozess steckte auch Verschwendung, aber er sorgte zugleich dafür, dass das Verständnis einer Person auf andere übertragen wurde und beide Seiten prüften, ob sie sich noch darüber einig waren, wie das System funktioniert
  • Diese Reibung synchronisierte das Verständnis der Menschen
• Agenten reduzieren diese Reibung stark und ermöglichen es mehreren Personen, unterschiedliche Änderungen anzustoßen, ohne miteinander zu sprechen
  • Eine Person fügt OAuth hinzu, eine andere baut Caching ein, eine weitere baut die Datenbank von Grund auf neu und macht die UI rosa
  • Jede einzelne Änderung kann für sich genommen sinnvoll sein; der Code kompiliert, die Tests bestehen, und bei Bedarf kann sogar eine Erklärung erzeugt werden
  • Niemand muss mit anderen sprechen oder einen Teil des gemeinsamen Modells erwerben, den man früher im Verlauf der Änderung gelernt hätte
• Agenten empfinden keinen Schmerz, nur Menschen tun das; und sie ermöglichen Änderungen an Systembereichen und Codebases, für die früher die Hilfe anderer nötig gewesen wäre
• Größer gewordene Vibe-Coding-Projekte werden nicht deshalb zu Codebases wie der Turm von Babel, weil Kommunikation unmöglich ist, sondern weil Kommunikation nicht mehr nötig ist
  • Jeder Entwickler hat einen unermüdlichen Übersetzer, der einen bestimmten Bereich des Turms erklärt und die gewünschten lokalen Änderungen ausführt
  • Änderungen werden weiter integriert, doch die Architektursprache, mit der Menschen das System gemeinsam durchdenken konnten, kann verschwinden
• Beim biblischen Turm von Babel brachte der Verlust der gemeinsamen Sprache den Bau zum Stillstand; beim KI-gestützten Engineering kann der Bau auch nach dem Zusammenbruch des gemeinsamen Verständnisses weitergehen
• Weil der Turm nicht einstürzt und kein unmittelbares Scheitern eintritt, ist schwer zu erkennen, was verloren ging, und der Turm wächst immer weiter

[GN⁺]

Hacker-News-Kommentare

• Ich denke schon lange, dass sich die Kombinierbarkeit von Software wie bei Tetris verhalten sollte: Reihen müssen verschwinden. Wer Agenten unausgereift einsetzt oder wenig Erfahrung als Engineer hat, übersieht solche Aufräumarbeiten und neigt dazu, den Turm einfach immer höher zu bauen.
  Man kann Agenten zwar dazu bringen, bestehende Elemente wiederholt in bessere Abstraktionen zu integrieren, aber selbst Fable oder 5.6 Sol liegen beim hochdimensionalen Architekturgespür, das die subtilen Entwicklungen von Software vorhersieht, noch weit hinter Menschen zurück. Die heutigen Systeme scheinen die hochwertigen, spärlichen und zoombaren Weltmodelle, mit denen Menschen arbeiten, noch nicht ausreichend aufrechtzuerhalten; hoffnungsvoll stimmt aber schon die Tatsache, dass sich der Abstand inzwischen bis auf diese feine Ebene verringert hat.

  • Beweisen kann ich es nicht, aber ich bin fest davon überzeugt, dass sich die Logik und Intuition, die für Abstraktionen unter Berücksichtigung künftiger Änderungen nötig sind, nicht allein durch eine Abfolge vorhergesagter Tokens umsetzen lassen. Es fehlt etwas, das wir nicht messen können.
  • Früher war die Leistungsfähigkeit des menschlichen Geistes die Obergrenze für Programmkomplexität, aber Vibe Coding kann diese Barriere durchbrechen. Nicht weil das Problem tatsächlich so komplex wäre, sondern weil der Entwicklungsprozess nicht zu knappen Abstraktionen konvergiert.
    Das ist die KI-Version des Skalierungsproblems, das Brooks in 《The Mythical Man-Month》 behandelt: Mit wachsender Größe verschlimmert sich die kombinatorische Explosion, und überall im Projekt entsteht doppelter Code, der faktisch dieselbe Funktionalität implementiert. Wir brauchen einen Weg, KI-gestütztes Coding auf Prägnanz auszurichten.
  • Das Kontextfenster eines Menschen könnte deutlich kleiner sein als das heutiger LLMs. Diese Beschränkung hat den Vorteil, dass sie uns dazu zwingt, Arbeit so zu modularisieren und zu abstrahieren, dass sie in den Kopf passt. LLMs, die viel mehr auf einmal aufnehmen können, haben denselben Anreiz nicht, weshalb Agenten unaufgeräumten Spaghetti-Code produzieren.
  • Am Ende ist es eine Frage der Zeit. gpt2 oder llama2 sind im Vergleich zu heutigen Modellen erschreckend schlecht und waren schon damals praktisch nutzlos, trotzdem waren wir beeindruckt.
    Auch GPT3.5 und gpt4, die einmal für Begeisterung sorgten, werden heute von qwen27b oder gemma31b klar übertroffen. Mit genug Zeit und geeignetem Reinforcement Learning (RL) werden auch Modelle im Kopf ein gutes Modell von Softwaresystemen aufbauen.
  • Könnte das nicht daran liegen, dass LLMs per Reinforcement Learning darauf trainiert wurden, Aufgaben mit kurzem Zeithorizont zu lösen? Anders als Aufgaben, bei denen Tests bestanden werden müssen, lassen sich jahrelange Arbeit, saubere Architektur und gutes Gespür nicht leicht als Benchmark maximieren.

• Die Kernthese dieses Textes erinnert an den Lisp Curse und den Bipolar Lisp Programmer. Die Argumentation war, dass Lisp es Einzelnen zu leicht macht, genau das zu bauen, was sie wollen; dadurch sinkt für Programmierer der Anreiz, gemeinsam generische, komplexe Ergebnisse zu schaffen, und das öffentliche Software-Ökosystem bleibt schwächer als bei Sprachen, die erheblichen Aufwand erfordern.
  Armin scheint beim Thema KI-Coding eine sehr ähnliche These zu vertreten: Lisp Curse, Bipolar Lisp Programmer

  • Assembly-Programmierer haben dieselbe Argumentation auch vorgebracht. Es ist eine wiederkehrende Binsenweisheit, sobald Software Engineering einen Paradigmenwechsel durchläuft, und manche Menschen tun sich mit solchen Übergängen schwerer als andere.
  • Ob es wirklich dieselbe Argumentation ist, bezweifle ich. Inzwischen gibt es genügend Leute, die glauben, man müsse sich nicht mehr zur Zusammenarbeit zusammentun, sondern könne einfach einen Schwarm von Agenten einsetzen, um jede erdenkliche komplexe Software zu bauen.
  • Im Gegenteil: Wenn TypeScript und Rust den Markt nicht so stark dominiert hätten, wäre jetzt eine gute Zeit, LLM-Dompteur für Lisp zu werden. Heutige Agenten können das meiste fast ohne Halluzinationen erklären; wenn man den Willen zum Verstehen mitbringt, verschwindet die Verständnisbarriere praktisch. Genau darum geht es auch im Kern des Textes.
  • Die Prämisse, dass andere Sprachen „deutlich mehr Aufwand“ erfordern, um dasselbe Ergebnis zu erzielen, ist nicht offensichtlich. Viele Nicht-Lisp-Entwickler legen großen Wert auf Syntax, Lisp-Entwickler nicht; und es gibt viele, die Lisp auch nach der Erfahrung, dass es ihr Denken erweitert, nicht bevorzugen.
    Zwischen den beiden Gruppen könnten unterschiedliche kognitive Verarbeitungsweisen liegen. Damit Lisp so produktiv ist wie andere Sprachen, muss man Homoikonizität aktiv nutzen; dadurch werden ernsthafte Lisp-Programme aber leicht zu Sammlungen von domänenspezifischen Sprachen (DSLs), die nur ein oder zwei Personen verstehen.

• Die Grenze großer Softwareprojekte liegt nicht darin, wie schnell einzelne Personen Code produzieren, sondern darin, wie gut die Menschen, die das System verändern, ihr gemeinsames Verständnis dieses Systems koordinieren. Die Aussage, dass seit dem 30. November 2022 alles komplizierter geworden ist, trifft zu.

  • Software ist übermäßig komplex geworden, indem Schicht auf Schicht gestapelt wurde, und um damit umzugehen, verwenden wir Tools, die noch viel mehr Komplexität erzeugen. In den 1990ern und frühen 2000ern konnte man auch ohne formale Ausbildung mit Visual Basic oder PHP leistungsfähige Anwendungen bauen, aber heutige Web- oder Desktop-Entwicklung ist überwältigend komplex, und selbst React richtig zu nutzen erfordert viel zu viel Wissen.
    AI darauf anzuwenden, ist ziemlich nahe daran, auf bestehende Komplexität noch eine weitere Komplexitätsschicht zu setzen. Im besten Fall ist es enorme Hardware-Verschwendung, im schlimmsten Fall erzeugen Agenten so viele neue Bugs, wie sie beheben, es entsteht mehr anfällige Schrottsoftware, und zugleich lernen Menschen die Technik nicht mehr, sodass die Fähigkeiten der Menschheit insgesamt schwächer werden könnten. Software muss ihrem Wesen nach nicht so komplex sein; um das zu lösen, sollte man Handwerkskunst in den Mittelpunkt stellen.
  • Dass man ein System verstehen muss, bevor man es verändert, ist nicht neu. Peter Naurs Programming as Theory Building erschien bereits in den 1980ern, und selbst wer es nicht gelesen hatte, wusste unter erfahrenen Entwicklern gemeinhin, dass Systemverständnis unverzichtbar ist.
  • Nicht alles ist komplizierter geworden. Große Datenbanken enthalten inzwischen praktische High-Availability-Tools, Microservices sind auf dem Rückzug, und strukturierte Datenbanken kehren anstelle von NoSQL zurück.
    Auch HTML und Pre-Rendering sind zusammen mit HTMx und LiveView zurückgekehrt, und CSS hat sich von den grotesken Workarounds der Vergangenheit gelöst. Wenn man jüngeren Kollegen erklärt, wie man Webseiten in IE6 debuggt hat, spürt man den Abstand der Zeiten. Einiges ist komplexer geworden, anderes ist ausreichend gereift und dadurch einfacher geworden.
  • Man sollte nicht sagen „seit dem 30. November 2022“, sondern seit 2022 v. Chr. ist alles komplizierter geworden. Zunehmende Komplexität ist die Geschichte der menschlichen Zivilisation.
    Ein Mensch im Jahr 20.000 v. Chr. suchte Nahrung und mied Kälte und Raubtiere, während ein Mensch im Jahr 5.000 v. Chr. Landwirtschaft betrieb, sich um Regen und Krankheiten sorgte und Systeme zur Verwaltung von Gemeinschaften und Land schuf. Heute bauen die meisten ihre Nahrung nicht selbst an, sondern verwalten die Komplexität riesiger Gesellschaften. Für Entwickler der 1970er- und 1980er-Jahre wäre schon Software vor LLMs enorm komplex, und inzwischen programmiert fast niemand mehr ohne Abstraktionsschichten direkt auf Hardware. Auch bei Kryptografie verbergen Libraries die Komplexität und lehren uns: „Implementiere es nicht selbst.“ Die zentrale Frage ist jetzt, wie schnell LLMs ein Verständnis des zu ändernden Systems koordinieren können.

• Die gemeinsame Sprache eines Softwareprojekts ist weder Englisch noch Python, sondern ein gemeinsames Verständnis von Bedeutungen der Konzepte, Grenzen, Invarianten, Ownership und den Gründen, warum das System seine aktuelle Form angenommen hat. Christopher Alexanders Pattern Language behandelt genau dieses Problem, und seine Empfehlung, für jede Domäne eine passende Pattern Language zu schaffen, führte bekanntlich zu den GoF Design Patterns.
  Ich experimentiere mit einer Funktion, bei der AI für jedes Projekt drei Pattern Languages für Business-, Produkt- und Technikdomäne pflegt, und das funktioniert sehr gut. Wenn man sie bei der Planung heranzieht und während Implementierung und Review bereinigen lässt, werden selbst zu 100 % von AI gecodete Projekte strukturiert, gut zwischen den Domänen ausgerichtet und leichter handhabbar.

  • Ich wäre neugierig auf ein echtes Beispiel. Ich habe schon öfter gehört, dass der Reifeprozess von Code dem natürlichen Wachstum einer Stadt ähnelt, aber konkrete Ergebnisse habe ich noch nicht gesehen.
  • Ich würde gern wissen, ob es ein öffentliches GitHub-Beispiel gibt.

• Beim Turmbau zu Babel kam der Bau zum Stillstand, als die gemeinsame Sprache verloren ging; bei AI-gestützter Entwicklung hingegen geht der Bau weiter, auch nachdem das gemeinsame Verständnis zusammengebrochen ist. Der Autor sagt nicht ausdrücklich, ob das gut oder schlecht ist, aber ich sehe es eindeutig als etwas Schlechtes.
  Wenn zu wissen, dass eine Tomate eine Frucht ist, Intelligenz bedeutet, und sie nicht in einen Obstsalat zu tun, Weisheit, dann ist AI die ultimative Form von Intelligenz ganz ohne Weisheit und im Grunde eher eine Illusion von Intelligenz. Wenn niemand mehr versteht, was AI tut, sollten wir anhalten und anerkennen, dass uns die Weisheit fehlt, das zu kontrollieren, was wir erschaffen.

  • Mir gefällt, dass der Autor nicht predigt, sondern das Bild selbst die Bedeutung vermitteln lässt. In der Geschichte wiederholt sich nichts exakt, aber es reimt sich immer.
  • Kindische Klischees wie „zu wissen, dass eine Tomate eine Frucht ist, ist Intelligenz“ sollte man lieber vermeiden, sofern sie nicht absichtlich in die Irre führen sollen. Schon Klassifikation und das Verständnis von Abhängigkeiten sind hinreichend schwierige Probleme, und im Supermarkt oder nach den Steuerkriterien von Nix v. Hedden ist die Tomate ein Gemüse.

• Auch ich denke an Babel und Bruegels Gemälde, sehe es aber deutlich weniger optimistisch. Kurzsichtige kleine Agenten entwickeln jeweils ihren eigenen Bereich eines unüberschaubar großen Ganzen: Auf der einen Seite gibt es 50 Zinnen, auf der anderen einen merkwürdig herausragenden Turm, und ohne zu wissen warum setzt man über den Innenhof ein Adobe-Dach und daneben auf den Treppenabsatz einen Turm mit Strohdach.
  Auf der Ebene einzelner Entwürfe ist das plausibel, aber ohne die vielen Schichten von Richtlinien und Urteilsvermögen, die das Gesamtvorhaben integrieren, wird daraus ein riesiges Designmonster. Dass es Disziplin braucht, um in einer hinreichend großen Organisation eine gemeinsame Sprache zu schaffen und zu erhalten, zeigt sich auch an der eigentümlichen Terminologie erfolgreicher Unternehmen und Armeen. Die „Gastown Mayors“ und die darunter stehenden „polecats“ und noch darunter die Golems glauben, dieselbe Sprache zu sprechen, doch erst wenn alles fertig ist, werden sie vom Thron aus erkennen, dass das Verständnis, von dem man glaubte, es perfekt vermittelt zu haben, in Wirklichkeit nicht geteilt wurde.

• Anakin: „Entwickler, die Agenten nutzen, werden ihre Fähigkeit, Codebases zu verändern, drastisch steigern.“
  Padmé: „In eine bessere Richtung, oder?“
  Anakin: Schweigen
  Padmé: „In eine bessere Richtung, oder?“

• Der Grund, warum Vibe Coding davon abrät, den generierten Code zu lesen, scheint zu sein, dass man den Horror, der in Python-Dateien lauert, nicht mehr vergessen kann, sobald man ihn einmal gesehen hat. Im weiten Sinne funktioniert es wie angefordert, aber bei jeder Entscheidung darüber, wie das Ziel erreicht werden soll, trifft es inkonsistente Entscheidungen.
  Es wendet nur auf manche Nutzereingaben seltsame Validierung an, sortiert oder lowercaset Daten ohne Grund in drei Schritten wiederholt und hardcodet sogar sämtliche Spaltennamen aus der ersten Zeile der Eingabe-CSV als Strings. Die eine Hälfte besteht aus globalen Funktionen, die Data Classes entgegennehmen, die andere ist als Klassen implementiert. Wenn man daran denkt, dass man das irgendwann selbst aktualisieren und warten muss, fällt es schwer, es nicht zu korrigieren; doch während man es so überarbeitet, verschwindet ein großer Teil der eingesparten Zeit.

• Agentenbasierte Programmierung ähnelt weit mehr Managementarbeit als eigentlichem Programmieren. Manager überblicken die Arbeit einzelner Contributors nur auf hoher Ebene; oft fehlt ihnen die Zeit, die kognitive Kapazität oder die Kompetenz, jedes Detail zu verstehen.
  Je mehr Software von Agenten geschrieben wird, desto stärker wird die Rolle von Software Engineers eher einer Management- als einer technischen Rolle ähneln.

  • Für Programmierer gilt dasselbe. Die meisten einzelnen Contributors wissen nicht, was unterhalb der Ebene passiert, auf der sie arbeiten, und kennen nicht die internen Implementierungen von Libraries, Frameworks, Remote-APIs oder System Calls.
    Da sie weder Zeit noch Kapazität haben, alles zu verstehen, erledigen sie lediglich die nötigen Aufgaben auf ihrer abstrahierten eigenen Ebene.
  • Es fühlt sich an, als würde man den ganzen Tag Code von Junior-Entwicklern reviewen; deshalb nutze ich es kaum und hauptsächlich nur, um Dinge zu finden, die ich übersehen habe.

• Früher brauchte man für große Refactorings gute Gründe, weil sie viel Aufwand bedeuteten. Heute kann ein Agent schon bei einem leicht unklaren Prompt und ohne gründliche Prüfung des Ergebnisses die Hälfte des Codes neu schreiben, sodass sich die Seele eines Programms jeden Tag stark verändern kann. Das ist großartig und zugleich überhaupt nicht.

  • Die größte Hürde bei großen Refactorings war ursprünglich nicht der Arbeitsaufwand, sondern die Minimierung des Bug-Risikos, die Bewahrung von Funktionalität und die Sicherstellung der Kompatibilität mit dem bestehenden Ökosystem. Im KI-Zeitalter ist es einfacher geworden, weil wir uns um solche Dinge offenbar nicht mehr kümmern.