Auf dem Weg zu verständlicher Software

• Programmierung ist schwer zu lesen, zu testen und zu warten, und das Verständnis eines Projekts konzentriert sich oft auf wenige Personen. Statt das Schreiben von Code mit LLMs zu automatisieren, braucht es daher Abstraktionen, die den Bereich reduzieren, in dem Code überhaupt nötig ist.
• LLMs haben sich bei Entwicklerinnen und Entwicklern ebenso wie bei Nicht-Entwicklern verbreitet, doch Probleme wie Umweltschädlichkeit, die Grundlage aus gestohlenem Code, inkonsistente Ergebnisse und das Erzeugen von Abhängigkeit bleiben weiterhin groß.
• Der Ausgangspunkt ist, die übliche Praxis umzukehren, erst Code zu schreiben und dann Dokumentation hinzuzufügen: hin zu literarischer Programmierung, bei der Dokumentation zuerst entsteht und der Code danach folgt.
• GUI-basierte visuelle Programmierung und deterministische natürlichsprachliche Programmierung können dafür sorgen, dass Code nur eine von mehreren Darstellungsformen wird. Für visuelle Umgebungen ist jedoch barrierefreies Design wie Screenreader-Integration unverzichtbar.
• Frühere Ansätze wie Eve und Inform sowie Tools wie Entangled und ReTangled zeigen, dass Software auf eine Weise erstellt werden kann, die sowohl für Einsteiger als auch für Fachleute verständlich ist.

---

LLMs sind nicht das Zielmodell

• LLMs sind zu einem wichtigen Werkzeug in der industriellen Softwareentwicklung geworden, und auch erfahrene Fachleute nutzen LLM-Agenten für Tests, Debugging und das Schreiben von Code.
• Auch Nicht-Entwickler erstellen mit LLMs alles von persönlichen Skripten bis hin zu Werkzeugen zur Verarbeitung wissenschaftlicher Daten.
  • Programmierung hat keinen klaren Einstiegspunkt und ist für Menschen wenig zugänglich, die nicht die Syntax einer bestimmten Sprache und die Details ihrer Bibliotheken lernen wollen.
• Die Verbreitung von LLMs ist weniger ein Zeichen dafür, dass LLMs besonders gut programmieren, sondern eher ein Hinweis darauf, dass Programmierung selbst eine komplexe und unangenehme Aufgabe ist.
  • Es gibt kollidierende Software-Stacks, endlosen Boilerplate-Code und schwierige Bibliotheken.
  • Die Arbeit durchschnittlicher Softwareentwickler reduziert sich darauf, Bibliotheken zusammenzustecken, statt interessanten Code zu entwickeln.
• Bei LLMs bleiben weiterhin große Probleme bestehen.
  • Sie sind umweltschädlich.
  • Sie basieren grundlegend auf gestohlenem Code.
  • Sie erzeugen inkonsistenten Code.
  • Sie erzeugen Abhängigkeit.
• Das heutige Programmierparadigma ist ebenfalls unzureichend, doch auch LLMs brauchen eine bessere Alternative.

Abstrahieren statt automatisieren

• Auf LLMs zu verzichten bedeutet nicht, auch auf Automatisierung, Abstraktionen auf hohem Niveau oder menschenfreundliche Interfaces verzichten zu müssen.
• Das Ziel sollte nicht dabei stehen bleiben, das Schreiben von Code einfacher zu machen, sondern den Software-Stack unter dem Code anzugehen und die Notwendigkeit des Codeschreibens selbst zu verringern.
• Wenn man immer wieder eine bestimmte Abstraktionsschicht automatisieren möchte, ist es angemessener, diese Schicht nicht zu automatisieren, sondern sie wegzuabstrahieren.
• Die breite Nutzung von LLMs für Programmierung zeigt den Wunsch, den Prozess des Codeschreibens zu automatisieren, und ist ein Signal dafür, dass die Notwendigkeit des Codeschreibens selbst abstrahiert werden sollte.
• Statt Menschen dazu zu bringen, wie Computer zu denken, braucht es neue Abstraktionsschichten, die näher daran liegen, wie Menschen auf natürliche Weise denken.

Programmierung, bei der die Dokumentation zuerst kommt

• Der erste Schritt zu verständlicher Software ist Dokumentation.
  • Wenn andere Menschen eine Software verstehen sollen, muss man sie erklären.
• Üblicherweise schreibt man zuerst Code und fügt später Doc-Comments oder Nutzungsbeispiele hinzu.
• Der vorgeschlagene Ansatz kehrt diese Reihenfolge um: zuerst Dokumentation schreiben, danach den Code hinzufügen.
  • Man erklärt Menschen, was ein Programm tut, und sagt danach dem Computer, was er tun soll.
  • Dieses Konzept ist als literarische Programmierung bekannt.
• Bei diesem Ansatz liest man nicht sofort den Code anderer und versucht, die Absicht abzuleiten, sondern liest zuerst die Dokumentation, versteht die Absicht und prüft anschließend den Code.
• Entangled ist eine gute Umsetzung dieses Ansatzes.
  • Es ist ein bidirektionaler Tangler, der Code aus der Dokumentation extrahiert und in passende Quellcodedateien platziert.
  • Codeblöcke in der Dokumentation können bearbeitet werden, und Änderungen in normalen Codedateien werden ebenfalls in die Codeblöcke der Dokumentation übertragen.
  • Bestehende Werkzeuge für Tests, Refactoring und Codeformatierung können weiter genutzt werden, ohne spezielle Unterstützung für literarische Programmierung zu benötigen.
  • Der Tangler fügt dem Build-System nur geringen Overhead hinzu, insbesondere im Vergleich zu einem Compiler.
• Dieser Ansatz beseitigt die Komplexität des Codes selbst nicht, kann LLMs aber in dem Bereich ersetzen, in dem es darum geht, den Code anderer Menschen zu verstehen.

Code abschaffen: GUI und mehrere Darstellungen

• Code ist ein Konzept aus einer älteren Ära und eine Methode, die genutzt wurde, weil man über Terminals mit Computern interagieren musste.
• Auch wenn sich Computing in den vergangenen 40 Jahren verändert hat, gibt es keinen Grund, darauf zu bestehen, dass wir mit Computern nur über eindimensionale Zeichenketten aus obskuren Symbolen und Keywords kommunizieren müssen.
• GUIs machen komplexe Konzepte oft leichter handhabbar als textbasierte Interfaces und sind für neue Nutzer häufig zugänglicher.
• Eine IDE kann mehr sein als ein Ort, an dem man bequem Code bearbeitet: Sie kann zu einer neuen Art werden, mit Softwareentwicklung zu interagieren.
  • Einige IDEs bieten solche Funktionen bereits.
  • Darüber hinaus könnte visuelle Programmierung so allgemein und einfach werden, dass alle ohne Codekenntnisse erstellen können, was sie möchten.
• Code selbst muss nicht vollständig aufgegeben werden.
  • Eine GUI-Darstellung kann eine von mehreren für Menschen bearbeitbaren Darstellungen sein.
  • So wie manche Menschen textbasierte Betriebssystem-Interfaces bevorzugen, können auch weiterhin manche Menschen codebasierte Softwarebearbeitung bevorzugen.
  • Code muss jedoch weder der Standard noch die einzige Option sein.
• Visuelle Programmierung kann so gestaltet werden, dass sie zugänglicher ist, doch eine visuell ausgerichtete Umgebung kann zum Ausschluss blinder Menschen führen.
  • Eine starke Screenreader-Integration ist notwendig.
  • Ebenso braucht es alternative Darstellungen, die sich auditiv oder taktil reichhaltig verstehen lassen.

Natürliche Sprache zu einer deterministischen Abstraktion machen

• Entgegen der Aussage, LLMs würden eine Abstraktionsschicht nach oben rücken, sind LLMs eher eine Automatisierungsschicht als eine Abstraktion.
• Eine Abstraktionsschicht muss vorhersehbar und zuverlässig sein, und eine Absicht auf hohem Niveau muss auf niedriger Ebene exakt und konsistent ausgedrückt werden.
• LLMs interpretieren Prompts probabilistisch und sagen Absichten voraus, daher verhalten sie sich unvorhersehbar.
  • Sie automatisieren einen Prozess, der Arbeitsergebnisse zufällig annähert.
  • Wenn es eine Abstraktion ist, dann eine mit sehr hohen Verlusten.
• Fortschritte in der Verarbeitung natürlicher Sprache (NLP) eröffnen die Möglichkeit, eine vorhersehbare Pipeline von natürlicher Sprache zu Maschinensprache zu schaffen.
• Ziel ist es, Programme zu schreiben, die sich wie LLM-Prompts eingeben lassen, aber jedes Mal vorhersehbar und robust sind.
  • Sie sollen nicht die Arbeit anderer Menschen wie einen Durchschnitt gestohlenen Codes destillieren, sondern direkt über Definitionen aufgebaut werden.
• Dieser Ansatz kann Dokumentation und Code stärker miteinander verbinden.
  • Wenn man in der literarischen Programmierung den Codeanteil durch natürliche Sprache ersetzt, könnte nur noch Dokumentation übrig bleiben.
  • Ein Text, der Menschen erklärt, wie ein Programm funktioniert, kann zugleich ein Text sein, der mit der Maschine kommuniziert.
• Diese natürlichsprachliche Programmierung muss deterministisch sein.
  • NLP kann genutzt werden, um Bedeutung aus Grammatik zu parsen, ohne die generativen Fähigkeiten von Transformer-Modellen zu verwenden.
  • Die geparste Grammatik kann direkt in eine Zwischenrepräsentation übersetzt werden, die wie andere Programmiersprachen entsprechend den Plattformanforderungen kompiliert wird.
• Angedacht ist etwas Ähnliches wie Inform, jedoch mit stärkerer Syntaxerkennung und Anbindung an ein breiteres Netz von Definitionen.
• Durch die deterministische Qualität werden Prompts zuverlässig und konsistent zu Code. Das ist eine echte Abstraktionsschicht, die sich grundlegend von LLMs unterscheidet.

Frühere Versuche: Eve und Inform

• Diese Ideen sind nicht neu; es gab bereits frühere Versuche, sie umzusetzen.
• Eve ist eine Programmiersprache und IDE, die Programmierung für Menschen zugänglicher machen wollte.
  • Sie verwendet einen Ansatz literarischer Programmierung.
  • Eine domänenspezifische, datenorientierte Programmiersprache wird in Dokumentation eingebettet, die das Verhalten der Software beschreibt.
  • Der Code ist der Dokumentation untergeordnet, und die gesamte Programmierumgebung spiegelt das wider.
• Eve versuchte außerdem, diese Idee weiter auszubauen und die eigene Sprache durch NLP-Abfragen zu ersetzen.
  • Das Projekt war nicht bereit, die Komplexität der Verarbeitung natürlicher Sprache zu bewältigen.
  • 2016 war weiterentwickeltes NLP für Unternehmen, die nicht auf Machine Learning ausgerichtet waren, nicht leicht zugänglich.
  • Auch ein GUI-orientierter Ansatz wurde erprobt.
• Ein ehemaliger Eve-Mitwirkender behandelt ebenfalls ähnliche Bedenken zur Komplexität des Projekts und zu den Grenzen von LLMs.
• Eve endete, weil es ein ambitioniertes, VC-finanziertes Projekt war, dem die Monetarisierung misslang, und es gab keine Gelegenheit zu sehen, wie die Ideen Früchte tragen.
• Inform ist eine deklarative Sprache zum Erstellen interaktiver Fiktion und zeigt, dass sich solche Konzepte breiter anwenden lassen.
• Natürliche Sprache könnte eine grundsätzlich leaky Abstraction sein, doch ihr Potenzial, durchschnittlichen Menschen direkte Kontrolle über ihre Computer zu geben, verdient mehr Aufmerksamkeit.

Nächste Schritte und vorgeschlagene Arbeit

• Als Projekt für verständliche Software wird ReTangled entwickelt.
  • Es ist ein in Rust geschriebener, mit Entangled kompatibler bidirektionaler Tangler.
  • Ziel ist es, literarische Programmierung so weit wie möglich auszubauen und sie in sinnvollem Maß eng in bestehende Toolchains zu integrieren.
  • Derzeit befindet es sich in einer frühen Entwicklungsphase, und Beiträge sind willkommen.
• Es ist geplant, ausführlichere Texte zu visueller Programmierung, literarischer Programmierung und natürlichsprachlicher Programmierung zu schreiben.
• Auf Community-Ebene wird vorgeschlagen, in die Fußstapfen von Eve zu treten, dabei aber einen etwas anderen Ansatz zu verfolgen.
• Ziel ist es, eine gut dokumentierte und zugängliche visuelle oder natürlichsprachliche Programmierumgebung zu schaffen, die für Einsteiger ebenso nützlich ist wie für Fachleute.
• Der Ausgangspunkt ist, Software besser zu dokumentieren; das endgültige Ziel ist, das Konzept der Programmierung selbst auf den Kopf zu stellen.

[GN⁺]

Kommentare auf Lobste.rs

• Ich bin mir nicht sicher, ob es eine wirksame Lösung für das Zugänglichkeitsproblem des Programmierens ist, Code wegzuwerfen oder ihn natürlichsprachlicher Prosa unterzuordnen.
  Programmiersprachen sind eine Benutzerschnittstelle, die zwischen den Anforderungen von Computern und Menschen vermittelt. Eine gut gemachte, klare formale Notation kann ein Werkzeug des Denkens sein, das dem eigenen Verständnis und der Vermittlung von Ideen zwischen Mensch und Maschine hilft.
  Das Lernen von Sprachen aus der APL-Familie hat mich stark geprägt, und obwohl es Zeit gekostet hat, sie zu lernen, konnte ich danach größere Probleme im Kopf behalten und präziser darüber nachdenken. K erlaubt es, Probleme auch ohne komplexe IDE zu lösen – im Kopf, auf Papier und mit einer einfachen REPL.
  Gut dokumentierte Projekte und Literate Programming sind wertvoll, aber auch Dokumentation zu lesen, zu schreiben und zu ändern kostet Zeit. Wie bei Tests ist mehr Dokumentation nicht automatisch besser; ich bevorzuge knappe, strukturierte Erklärungen und knappe Programme, die sich leicht erklären lassen. Code kann Poesie sein, aber die meisten Gedichte sind keine Programme.

  • Ich mag formales Programmieren, glaube aber nicht, dass der durchschnittliche Nutzer zum Programmierer werden muss, um die Macht des Computers zu nutzen.
    Die meisten Menschen werden diese internen Funktionsweisen nicht lernen, daher möchte ich die Einstiegshürde senken, damit mehr Menschen mitmachen können.
    Deshalb halte ich LLMs für populär. Ich sehe oft, wie Nicht-Programmierer mit LLMs Code schreiben, um Aufgaben zu erledigen, aber wie im Artikel gesagt, haben LLMs große Mängel, die ich vermeiden möchte. Menschen sollten Spiele modifizieren, Skripte erstellen und Programme erweitern können – in natürlicher Sprache oder über eine bequeme Benutzeroberfläche.
    Die Formulierung „schaffen wir Code ab“ war vielleicht etwas übertrieben, aber viele Menschen wollen nicht über Code nachdenken, und sie sollten es auch nicht müssen.

• Programmierer haben Nicht-Programmierer gewissermaßen im Stich gelassen.
  Visual Basic ist tot, PHP ohne Framework scheint auch nicht mehr besonders lebendig zu sein, und Access ist praktisch tot. Übrig geblieben sind datenbankähnliche Tools wie Notion oder Airtable.
  Programmierer lieben das Schreiben von Code so sehr, dass viele sich von einfachen Lösungen für einfache Probleme entfernt haben.
  Python hat die Welt der Nicht-Programmierer einst erobert, weil es einfach wirkte und auch Tools wie Pandas leicht benutzbar schienen. Interessanterweise halten viele Programmierer Python oder Pandas nicht für besonders gut. Wenn man etwa Code sieht, der etwas mit Pandas erledigt, was mit der Standardbibliothek leicht möglich wäre, kann das ziemlich abschreckend sein.
  Früher konnten auch Nicht-Programmierer HTML-Seiten erstellen und Farben und Bilder einfügen. Wenn man heute einen Programmierer bittet, eine statische Website zu bauen, kommt absurde Komplexität mit dazu. Ein Teil davon ist nötig, aber das meiste überhaupt nicht. Würde man Nicht-Programmierern die Abläufe geben, die Programmierer heute zum Erstellen einfacher Websites verwenden, würden selbst die Leute, die vor 20 Jahren Spaß daran gehabt hätten, HTML zu bearbeiten, schreiend davonlaufen.
  Es ist zutiefst ironisch und beunruhigend, dass manche Dinge heute sogar deutlich schwieriger geworden sind.

  • Das ergibt überhaupt keinen Sinn. Auch heute kann jeder HTML schreiben, und es ist sogar einfacher geworden als früher.
    CSS ist mächtiger geworden, Browser sind weniger kaputt, und es gibt persönliche Coding-Assistenten, die bei allem helfen. Mit purem Python ist es genauso: Man kann es einfach benutzen. Programmieren ist einfacher denn je.
    Die Komplexität moderner Tech-Stacks hat meist ihre Gründe, aber man sollte sie erst nutzen, nachdem diese Gründe entstanden sind, und Anfänger müssen sie keineswegs verwenden.
    Wenn Menschen keine HTML-Websites oder einfachen Programme bauen, dann weil sie es nicht wollen. Ich dachte, in Zukunft würden alle grundlegendes Programmieren beherrschen, aber tatsächlich hat sich gezeigt, dass die Leute es einfach nicht wollen. Man könnte auch behaupten, jeder sollte grundlegende Wartung an Autos oder Fahrrädern können, aber die Leute lehnen das ab. Das bedeutet nicht, dass die Arbeit schwer oder unmöglich ist, sondern eher, dass der Wille dazu fehlt.
    Ich denke, die allgemeine Computerkompetenz der breiten Bevölkerung hat sich kaum weiterentwickelt, und das hat nichts mit der Komplexität des Programmierens zu tun. Aus dem Bildungsbereich hört man sogar, dass die Computerkompetenz eher zurückgeht, aber es ist schwer, das auf komplexe Frontend-Frameworks zurückzuführen.

• Vieles im Artikel unterschreibe ich. Zum Beispiel mag ich Literate Programming, denke aber nicht, dass Programmieren an sich schlecht ist.
  Manche Programmierung ist schlecht, und die Programmierung in BigTech-Unternehmen ist häufig eher schlecht. Aber Programme für mich selbst oder für Menschen, die ich liebe, zu schreiben, macht mir immer noch Freude.
  Entangled kannte ich nicht, aber es wirkt wie eine gute Idee und adressiert das größte Problem beim Literate Programming: LSPs und bestehende Tools nehmen es nicht wahr. Deshalb habe ich Literate Programming bisher vor allem für deklarative Sprachen wie NixOS-Konfigurationen verwendet.
  Bidirektionales Literate Programming könnte das Leben beim Einsatz nicht-deklarativer Sprachen erleichtern. Ich habe vor, ReTangled einmal auszuprobieren.

  • Programmieren ist nicht schlecht. Bis zu diesem Satz war ich mit dem Autor einverstanden, aber als „lasst uns GUIs annehmen“ kam, ließ mein Interesse nach.
    GUIs scheinen vor allem zu existieren, damit Führungskräfte und höhere Ebenen glauben können, dass die Mitarbeiter etwas tun, das sie selbst verstehen und tun könnten.
    Ich habe einen Kurs zu einem visuellen Drag-and-drop-ETL-Tool besucht, und am Ende blieb nur der Eindruck, dass es schwer wäre, etwas nahezu Gleiches wie das erste System noch einmal zu bauen, und dass es schwierig wäre, das Ganze unter Versionskontrolle zu stellen. Ähnlich war es 2010 mit dem visuellen Drag-and-drop-Ersatz für cron, den meine damalige Firma nutzte.
    Für Führungskräfte ist Ziehen und Ablegen einfach, aber für Praktiker werden Fehlersuche, Versionierung und Backups sowie Wiederverwendung schwieriger.
  • Wenn diese Funktion der Hauptzweck ist, würde ich empfehlen, Entangled zu verwenden, bis Stitching in ReTangled funktioniert.
  • Es gibt eine wirklich harte Phase, wenn man etwas, das im Moment Spaß macht, auf ein Niveau bringen will, auf dem Nutzer es mögen könnten.
    Um einen interessanten Prototypen produktionsreif zu machen, braucht es viel Fehlerbehandlung, Serialisierung, Deserialisierung, Typprojektionen und Ähnliches. Eine meiner Regeln ist, dass eine hervorragende User Experience fast immer eine schmutzige interne Struktur mit sich bringt.
    Persönlich macht mir das meiste davon keinen Spaß, und früher habe ich manchmal Abkürzungen genommen oder diese Arbeit ganz gelassen.

• Stimme ziemlich stark zu. Wenn man sich WYSIWYG-Editoren ansieht: Sie haben die Webentwicklung nicht vollständig ersetzt, aber sie haben eine erhebliche Nische für Leute geschlossen, die nur eine einfache Website oder einfachen Produktverkauf wollen.
  Es gibt immer noch große Bereiche von Software, die sich mit guten GUI-Oberflächen deutlich vereinfachen ließen.
  Wenn man derzeit nur Code zusammenklebt oder LLMs wahllos laufen lässt, könnte GUI-Programmierung tatsächlich die bessere Wahl sein. Auch Code, den ich häufig schreibe, ist oft ein REST-Server; es gibt keinen Grund, warum man dafür nicht etwas bauen könnte.

• Wir teilen dasselbe Ziel, und ich denke seit Jahren über einen Tech-Stack nach, der genau die Lösung bieten würde, die ich selbst nutzen möchte.
  Ich habe zwar ein Projekt namens Curv veröffentlicht, aber es ist nur ein kleiner Teil eines viel schöneren Systems, das bislang nur in meinem Kopf existiert.
  Tausende andere Menschen haben sich ebenfalls mit diesem Problem beschäftigt. Angesichts der Größe des Problems scheint Teamarbeit nötig zu sein, tatsächlich sind es aber meist kleine Ein-Personen-Projekte. Oft wollen gerade diejenigen mit der stärksten Vision ihre eigene Vision nicht zugunsten eines Teamziels kompromittieren. Ich weiß nicht, wie man das lösen soll.
  Inspirierende Projekte sind Alan Kays Dynabook-Vision, das daraus hervorgegangene Smalltalk, Alan Kays späteres Projekt STEPS Toward the Reinvention of Programming, die Arbeit von Bret Victor und insbesondere seine erstaunliche Leistung Dynamicland.
  Eine Community, die sich für dieses Thema interessiert, ist Feeling of Computing, früher Future of Coding genannt. Wenn es noch weitere gibt, würde ich mich über Hinweise freuen.

• Die Idee „Geben wir Anweisungen ein wie in einen LLM-Prompt, um vollständige Programme zu erstellen, aber so, dass sie jedes Mal vorhersehbar und robust funktionieren“ beruht auf der gewaltigen Annahme, dass sich aus natürlicher Sprache deterministische und konsistente Semantik parsen lässt.
  Ich glaube aber nicht, dass das überhaupt stimmt. Selbst abgesehen davon, dass es noch nie wirklich zum Funktionieren gebracht wurde, bezweifle ich, dass es möglich ist.
  Sprache enthält zu viel Kontext. Wenn man denselben Satz zwölfmal sagt, entstehen je nach Intonation, Publikum, physischem Ort, Medium der Äußerung und Tageszeit jedes Mal leicht andere Bedeutungen. Traditionelle Verfahren zur Verarbeitung natürlicher Sprache können diese Flexibilität grundsätzlich nicht bewältigen.
  Genau deshalb gibt es LLMs. Statt zu versuchen, strenge Kontextregeln festzulegen, die es vermutlich gar nicht gibt, trainiert man Modelle, die Kontexterkennung in Gewichten kodieren können. Es hat sich gezeigt, dass das erstaunlich gut funktioniert.
  Deshalb nutzen Menschen LLMs. Sie können Kontext viel besser berücksichtigen und die erwartete Antwort erzeugen als jede bisher gebaute natürliche Sprachschnittstelle. Aus dieser Perspektive funktionieren sie wirklich. Verarbeitung natürlicher Sprache außerhalb von LLMs hat keinen vergleichbaren Erfolg gezeigt.

• Wenn du dich für reichhaltige visuelle Programmierumgebungen interessierst, ist Glamorous Toolkit ein gutes Beispiel dafür, wohin die Reise gehen könnte: https://gtoolkit.com/
  Ich würde es noch nicht als vollendet ansehen, aber es ist ein Werkzeug, das das bereits Existierende deutlich weiter treibt. Im Zeitalter von LLM-generiertem Code lohnt es sich auch, über bildbasierte Umgebungen zu sprechen.

  • Ich habe die Website von Glamorous Toolkit überflogen, konnte aber überhaupt nicht erfassen, was es ist. Kannst du es in ein paar Sätzen zusammenfassen?

• Was fehlt, sind vorhersagbare Abstraktionen jenseits der primitiven Elemente, die Programmierer heute üblicherweise verwenden, also Codezeilen, organisiert in Funktionen und Modulen.
  Besonders wenn man Anforderungen, die nicht einfache Datentransformationen sind, sondern komplexe externe Systeme modellieren, nur auf solche Elemente abbildet, wird daraus selbst bei menschlichen Programmierern ein immer größerer Schlammball. LLMs ahmen genau dieses Bild nach.