Einleitung — der Irrtum der englischen Spezifikation
- Inspiriert von dem Text „Eine hinreichend detaillierte Spezifikation ist Code“. Englische Spezifikationen wirken intuitiv präzise, aber sobald man versucht, sie tatsächlich umzusetzen, zeigt sich ihre Mehrdeutigkeit
- „Alles ist vage, bevor man versucht, es präzise zu machen.“ — Bertrand Russell
- Programmieren ist wie Schreiben eine iterative Tätigkeit, bei der man etwas im Tun immer weiter zuspitzt und verfeinert (auch dieser Essay ist durch zahllose Entwürfe gegangen)
Vibe Coding — warum es funktioniert und warum es gefährlich ist
- Weil AI die Umwandlung von Englisch → ausführbaren Code immer schneller und besser beherrscht, kann man Code inzwischen auf dem Niveau eines englischen „Gefühls“ (
vibe) erzeugen
- Indem man auf die von AI erzeugten Ergebnisse reagiert — „Verschieb den Button dahin, mach ihn blauer“ — wird der Prozess Schritt für Schritt präziser
- Der Ausdruck „Vibe Coding“ ist deshalb perfekt: Man hält das Denken auf dem Vibe-Niveau des Englischen und schärft es mithilfe der AI-Ergebnisse nach
- Das Kernproblem: Der Vibe erzeugt die Illusion einer präzisen Abstraktion. Wenn Funktionen zunehmen oder die Skalierung wächst, bricht die Abstraktion als
leaky abstraction auf, und unerwartete Bugs ruinieren plötzlich einen ganzen Tag
Ein reales Beispiel — Dan Shippers Vibe-Coding-App
- Eine von Dan Shipper per Vibe Coding gebaute Texteditor-App ging viral → Serverausfall
- Ursache: „Live Collaboration“ wirkt intuitiv einfach, ist in Wirklichkeit aber eine Komplexität auf Albtraum-Niveau
- Weil wir alle schon Google Docs und Notion benutzt haben, fühlt sich „Live Collaboration“ so an, als wäre es bereits präzise spezifiziert. Warum das nicht so ist, lässt sich im Vorfeld nur extrem schwer erkennen
- Auch der Autor selbst hat vor 10 Jahren beim Bau eines kollaborativen Editors einen Albtraum unerwarteter Komplexität erlebt. Was genau war schwierig? Er erinnert sich nicht einmal mehr! Das ist Teil des Problems — Komplexität ist langweilig, man will nicht darüber nachdenken, und Details sowie Edge Cases lassen sich nur schwer im Gedächtnis behalten
- Beispiel: das klassische Flussdiagramm dazu, wie Slack entscheidet, ob eine Benachrichtigung gesendet wird — hinter einer simplen Formulierung wie „Benachrichtigung senden“ steckt Komplexität in genau dieser Größenordnung
Abstraktion — das einzige Werkzeug zum Umgang mit Komplexität
- Grundlegende Grenze des menschlichen Gehirns: Es kann gleichzeitig nur 7±2 Dinge verarbeiten
- Der einzige Weg, mehr als 7 Dinge zu handhaben: mehrere Dinge zu einem komprimieren (
compress). Das lässt sich rekursiv unendlich oft wiederholen, weshalb Menschen mit unendlicher Komplexität umgehen können. Dieser Kompressionsschritt ist genau die Abstraktion (abstraction)
- „Der Zweck der Abstraktion ist nicht, vage zu sein, sondern eine neue Bedeutungsebene zu schaffen, auf der man absolut präzise sein kann.“ — Dijkstra
- Ein Beispiel dafür ist, wie Sophie Alpert das berüchtigte Slack-Benachrichtigungs-Flussdiagramm mit einer cleveren Abstraktion in eine viel einfachere Struktur refaktoriert hat
- Der beste Teil des Programmierens: immer bessere Abstraktionen zu schaffen und so Komplexität zu bezwingen — so wie ReactJS oder TailwindCSS es jeweils in ihrem Bereich getan haben
- Dass kollaborative Texteditoren grundsätzlich komplex sind, bedeutet nur, dass man weiter nach besseren Abstraktionen suchen muss
AGI — guter Code verschwindet trotzdem nicht
- Wenn man sich 1, 2, 5, 10 oder 100 Jahre in die Zukunft vorstellt: AI wird immer besser/schneller/billiger, und irgendwann kommt der Punkt, an dem maschinelle Intelligenz von menschlicher nicht mehr zu unterscheiden ist (AGI)
- Eine AGI-Welt könnte wie eine Vibe-Welt aussehen. Wenn man 100 Genies vom Kaliber eines Kapasi für 1000 $ pro Monat einsetzen könnte, warum sollte man sich dann noch um lästige Details kümmern?
- „Das ist wirklich lächerliches Gerede.“ Solche Gedanken sind nur möglich, solange die Technologie noch nicht da ist und man nur abstrakt darüber spricht
- Wenn wir Zugang zu einer solchen Intelligenz hätten, würden 0 % der Menschen sie dafür einsetzen, noch mehr Slop zu produzieren. Natürlich nicht
- Der Grund für diese Verwechslung: Wir denken (fälschlich), Code diene nur der Produktion von Software. Doch Code selbst ist ebenfalls ein zentrales Ergebnis. Wenn er gut gemacht ist, ist er Poesie
- „Niemand redet von ‚Vibe Writing‘, oder?“ — Beim Schreiben glaubt auch niemand, dass ChatGPT großartige Romanautoren oder Journalisten ersetzt. Bei Code ist es genauso, nur dass die „Magie“ von ausführbarem Code diese Täuschung hervorruft
- AI erzeugt (wenn auch zunehmend weniger) schlechten Code. Das wissen wir alle. Wir nutzen AI trotz des schlechten Codes, nicht wegen ihm
- Zitat von Simon Willison: „AI sollte dabei helfen, besseren Code zu schreiben“
- Wenn AGI kommt, wird sie als Erstes die schwierigsten Abstraktionsprobleme lösen — bessere Abstraktionen schaffen, um Komplexität besser zu verstehen und zu bezwingen
- Je intelligenter AI wird, desto überflüssiger wird guter Code? Das ist so, als würde man sagen, man wolle mit ChatGPT einfach nur noch mehr Slop produzieren
- Ein reales Beispiel: Opus 4.6 löste bei der Entwicklung von Val Towns Full-Stack-React-Framework (
vtrr) ein ungelöstes Problem auf Anhieb. Das Ergebnis war eine Demo einer 50-zeiligen Single-File-Full-Stack-App
Fazit — Code fängt gerade erst an
- Es wirkt, als hätten 99 % der Gesellschaft der Aussage „Code ist tot“ bereits zugestimmt. Erst gestern hörte der Autor, wie der Podcaster Sam Harris selbstsicher sagte: „Alle sind sich einig, dass Coding tot ist; niemand muss mehr programmieren lernen“
- „Das ist traurig. Das ist, als hätte man bei der Erfindung der Druckerpresse gesagt: ‚Storytelling ist tot.‘ Ihr Narren, Code fängt gerade erst an. AI wird ein gewaltiger Segen für das Programmieren sein.“
- Abschließende Zitate:
- „Die Pflicht, formale Symbole zu verwenden, sollte man nicht als Belastung sehen, sondern als Privileg. Dadurch können Studierende Dinge tun, die früher nur Genies konnten.“ — Dijkstra
- „Die eigene Muttersprache ‚natürlich‘ verwenden zu können, bedeutet nur, dass man leicht Sätze bilden kann, deren Unsinn nicht offensichtlich ist.“ — Dijkstra, „On the foolishness of natural language programming“
- „Es gibt zwei Wege beim Softwaredesign: Der eine ist, es so einfach zu machen, dass es offensichtlich keine Mängel hat, und der andere, es so kompliziert zu machen, dass es offensichtlich keine Mängel hat.“ — Tony Hoare
- „Die Menge an Bedeutung, die in algebraischer Notation auf engem Raum komprimiert wird, erleichtert die Schlussfolgerungen, die wir mit ihr anstellen.“ — Charles Babbage
7 Kommentare
Noch bevor man überhaupt über kollaboratives Editieren spricht, ist schon die saubere Umsetzung eines einzelnen Editors für die eigene Nutzung voller unerwarteter Komplexität – von Cursor-Verarbeitung über Undo/Redo-Stacks bis hin zu IME-Eingaben. Wie im Artikel angemerkt, gibt es kaum Software, bei der die Falle einer „Spezifikation, die sich intuitiv präzise anfühlt“ so deutlich zutage tritt wie bei Editoren. Was am Ende einfach aussieht, ist also nicht wirklich einfach, sondern verbirgt die Komplexität nur hinter einer guten Abstraktion.
Tatsächlich war der Grund, warum Anthropic als Demo einen C-Compiler gebaut hat, wohl ebenfalls, dass Compiler Spezifikationen mit hoher Präzision haben und auch die Testfälle gut vorbereitet sind. Gleichzeitig wirken sie aber auch enorm schwierig.
Ich habe schon einige Compiler gebaut und arbeite auch gerade an einem; aus der Perspektive des Vibe Coding habe ich auch versucht, einen Editor zu bauen, aber ein Compiler fühlte sich einfacher an. Wie Sie geschrieben haben, wirkt die Spezifikation weniger präzise, und ich habe das Gefühl, dass es durch die Nutzer mehr Variablen gibt. Auch das Testen ist schwieriger.
Spezifikationen werden zwar wichtiger, aber ich denke schon lange, dass es unmöglich ist, von Anfang an jede Spezifikation detailliert auszuschreiben und alle Situationen abzudecken. Ich halte es nach wie vor für besser, auch die Spezifikation wie Code während der Arbeit schrittweise zu verfeinern, wobei ich mich frage, ob man das nicht mehrere Agenten untereinander erledigen lassen könnte. Letztlich wird es ohne menschliches Eingreifen aber wohl kaum möglich sein, über die erlernten Situationen und das vorhandene Wissen hinauszugehen; deshalb dürften völlig neue Situationen und Funktionen schwierig sein.
Es erinnert mich an das Gefühl, das ich hatte, als die ersten Saugroboter aufkamen und man hörte, dass man für den Roboter erst einmal eine "einfache Reinigung" machen müsse, also Dinge vom Boden wegräumen. Auch detaillierte Spezifikationen für KI zu schreiben ist ein erheblicher Aufwand, sodass es sich anfühlt, als würde man für die KI arbeiten.
IDE und PR sind schon alle tot, aber der Code ist wiederauferstanden?
Code ist in einfachen Systemen logisch die präziseste Spezifikation.
Aber der Haken ist, dass die reale Welt ein komplexes System ist … Am Ende sind Daten noch die vergleichsweise präziseste Spezifikation.
Ich denke, man sollte prüfen, ob sich das durch andere Verifizierungsmethoden ersetzen lässt. Je näher man am Frontend ist, desto eher lässt sich wohl schon allein mit E2E über das Verhalten im Browser verifizieren, dass es korrekt funktioniert. Aber je näher der Code am Backend oder an der Infrastruktur ist, desto unverzichtbarer scheint ein Code-Review zu sein. Andernfalls wäre es schwierig, Side Effects zu verifizieren, die man nicht direkt sieht, etwa dass Transaktionen geöffnet und geschlossen werden oder API-Calls ausgelöst werden.
Im Browser gibt es jede Menge Probleme, die sich selbst mit E2E nicht erfassen lassen.