David Heinemeier Hansson hat 25 Jahre lang Code behandelt wie ein Bildhauer seinen Marmor. Heute lässt der Erfinder von Ruby on Rails komplette Software von KI schreiben – teilweise ohne eine Zeile der Implementierung anzusehen. Und das Verrückte daran: Noch vor gut einem Jahr hielt er genau diese Vorstellung selbst für ziemlich fragwürdig.

Ich übrigens auch. Meine Annahme war simpel: KI kann schnell Code produzieren. Aber eben diesen typischen KI-Code. Viel davon. Funktioniert irgendwie. Technische Schulden inklusive. Gut für Prototypen, schlecht für ernsthafte Systeme.

Nach inzwischen sechs Wochen ziemlich intensivem Programmieren mit aktuellen Coding Agents sehe ich das anders. Das Problem ist nicht mehr primär eine „dumme KI“. Das Problem sind zunehmend Tokens, Kontext, Geschwindigkeit und die Frage, wie gut ich mehrere intelligente Systeme organisiere. Und genau deshalb führt uns der Begriff „Vibe Coding“ inzwischen ziemlich in die Irre.

Vom Code-Chiseler zum Agenten-Dirigenten

Kaum jemand eignet sich besser für diese Geschichte als David Heinemeier Hansson, kurz DHH. 5h Podcast mit ihm hier: https://lexfridman.com/dhh-2/

Er hat Ruby on Rails erfunden. Er ist seit Jahrzehnten besessen von elegantem, reduziertem und lesbarem Code. Im ersten großen Gespräch mit Lex Fridman 2025 erklärte er ausführlich, warum Code für ihn nicht einfach Mittel zum Zweck ist, sondern ein Handwerk mit Ästhetik. Damals verwendete er KI bereits intensiv – zum Lernen, Nachschlagen und teilweise auch zum Programmieren. Aber wenn er sie selbst Code schreiben ließ, war seine Begeisterung begrenzt. Bei Ruby beschrieb er die KI sinngemäß eher als Juniorentwickler, den man nach einigen Versuchen freundlich auffordern müsste, sich etwas mehr anzustrengen. Und bei der Vorstellung, einem Agenten einfach ein ganzes Projekt zu geben, sagte er ausdrücklich: So weit seien wir noch nicht.

Das war Mitte 2025.

Im neuen Gespräch mit Lex Fridman klingt DHH wie jemand aus einer anderen Zeitlinie. Lex fragt, ob KI inzwischen 80 Prozent des Codes schreibe. DHH antwortet nur: „Or 100.“ Seinen persönlichen Wendepunkt datiert er erstaunlich präzise auf den 24. November 2025, als Anthropic Opus 4.5 veröffentlichte. Plötzlich lag die Qualität für ihn nicht mehr irgendwo im Bereich eines hilfreichen Assistenten, sondern erstaunlich nah an dem, was er selbst geschrieben hätte. Noch wichtiger war aber etwas anderes: Nicht nur die Modelle waren besser geworden. Die Systeme drumherum waren besser geworden. Willkommen beim nächsten Buzzword.

Bitte anschnallen: Jetzt kommt der „Harness“

„Harness“ klingt ein bisschen so, als müsste man Claude vor der Arbeit erst ein Pferdegeschirr anlegen. Ganz falsch ist das Bild nicht. Das Sprachmodell allein ist nur ein Teil des Systems. Der Harness verbindet das Modell mit seiner Arbeitswelt: Terminal, Dateien, Git, Tests, Dokumentation, Tools, Subagents und Feedbackschleifen. DHH sagt rückblickend, dass ihm genau diese Entwicklung zunächst entgangen war. Die ersten Agenten seien zwar interessant gewesen, aber Intelligenz und Harness hätten noch nicht ausgereicht. Andere hätten bereits gesehen, wohin es geht. Er nicht. Das ist wichtig. Denn viele Diskussionen über KI-Programmierung basieren immer noch auf Erfahrungen mit einer Generation von Tools, die vielleicht neun oder zwölf Monate alt ist.

• Autocomplete.
• Prompt.
• Codeblock.
• Copy.
• Paste.
• Fehler.
• Noch ein Prompt.

Das war der Anfang. Es ist ungefähr so sinnvoll, damit den heutigen Stand zu beurteilen, wie das Smartphone anhand eines Nokia Communicators zu bewerten. Ein modernes System plant selbstständig, untersucht den bestehenden Code, benutzt Tools, startet Tests, analysiert deren Ergebnisse, korrigiert sich, delegiert Teilprobleme an weitere Agents und überprüft anschließend seine eigene Arbeit. DHH erzählt sogar, dass der System-Prompt von Claude Code mit den neueren Modellen offenbar drastisch verkleinert werden konnte. Seine Interpretation: Die Agenten benötigen nicht nur weniger kleinteilige Anweisungen – zu viele menschliche Vorgaben können sie inzwischen sogar schlechter machen. Vielleicht ist Prompt Engineering also tatsächlich irgendwann das neue „SEO für AltaVista“: kurz enorm wichtig und wenig später etwas, über das man nostalgisch lächelt.

Ein Linux-Entwickler, der kein Rust können muss

Das schönste Beispiel im Gespräch ist nicht einmal Omarchy selbst, DHHs inzwischen erstaunlich populäre Linux-Distribution. Es ist eine kleine Python-Library. DHH wollte eine Bibliothek, die Terminaleffekte erzeugt, komplett in Rust neu schreiben lassen: keine Dependencies, ein einzelnes Executable, pixelgenau dasselbe Ergebnis. Sein Prompt war im Grunde: Hier ist der bestehende Python-Code. Mach daraus Rust. Analysiere alles. Hör nicht auf, bevor es funktioniert. Nach weniger als 45 Minuten war der Agent fertig. Die Startzeit sank laut DHH von 86 auf 2 Millisekunden, die Ausführung wurde ungefähr 9,6-mal schneller und das Ergebnis war ein rund drei Megabyte großes Executable. Und jetzt kommt der entscheidende Satz: DHH hatte selbst keine entsprechende Rust-Kompetenz aufgebaut und erledigte den Job „without looking at the Rust code at all“. Danach ließ er die KI das Repository erstellen, Packaging einrichten, den Pull Request für Omarchy vorbereiten und das Ergebnis veröffentlichen. Das ist nicht mehr Autocomplete. Das ist Delegation von Implementierung. Und DHH machte danach etwas, das noch interessanter ist: Er gab dieselbe Aufgabe unterschiedlichen Modellen.

Plötzlich wird Programmieren zu einer Einkaufsentscheidung

Das Experiment zeigt ziemlich schön, wo wir mittlerweile angekommen sind. Nicht jedes Modell schaffte die Aufgabe. Aber mehrere Modelle produzierten nach DHHs Darstellung ein funktional vergleichbares Ergebnis – zu drastisch unterschiedlichen Preisen.

Modell	Ergebnis	Zeit	geschätzte Token-Kosten
Fable / Opus	erfolgreich, beste Planung	ca. 45 Min.	ca. 550 $ bei API-Abrechnung
Sol	erfolgreich	ca. 1,5 Std.	ca. 46 $
Grok 4.6	erfolgreich	–	ca. 55 $
DeepSeek V4 Pro	erfolgreich	ca. 2 Std. 45 Min.	ca. 23 $
GPT Luna	Aufgabe nicht erfolgreich gelöst	–	–
DeepSeek Flash	Aufgabe nicht erfolgreich gelöst	–	–

DHHs Fazit: Fable war am stärksten und schnellsten, aber andere Frontier-Modelle kamen zu einem ähnlichen Ergebnis für ungefähr ein Zehntel der Kosten; DeepSeek noch günstiger, dafür langsamer. Das verändert die Fragestellung komplett.

Früher lautete sie: Kann die KI das überhaupt?
Heute lautet sie zunehmend: Welches Modell lasse ich welchen Teil der Aufgabe erledigen, wie viel Zeit darf es dafür verbrauchen und wie viele Tokens will ich investieren?

DHH formuliert den aktuellen Engpass entsprechend klar:

„At this moment in time, we are all token limited.“

Das deckt sich ziemlich genau mit meiner Erfahrung der vergangenen Wochen. Ich renne inzwischen erstaunlich selten gegen die Grenze „Die KI versteht das nicht“. Ich renne wesentlich häufiger gegen Limits bei Kontext, Token-Budget, Laufzeit oder Parallelisierung. Das ist ein fundamentaler Unterschied.

https://www.youtube.com/watch?v=NYFGCESmikA

DHHs aktueller AI-Programming-Stack

Interessant ist deshalb weniger das eine „beste Modell“ als das Gesamtsystem. DHH arbeitet mittlerweile bewusst mit unterschiedlichen Modellen für unterschiedliche Aufgaben.

• Claude Code ist für ihn aktuell der stärkste Harness. Vor allem, weil mehrere Agents gleichzeitig laufen können und die Integration der Werkzeuge weit entwickelt ist.
• Fable nutzt er besonders für Planung und teilweise Review.
• Opus 5 übernimmt Implementierungsarbeit.
• Codex xHigh ist sein bevorzugter unabhängiger Reviewer. Das ist wichtig: Er lässt bewusst ein Modell die Arbeit eines Modells eines anderen Anbieters kontrollieren.
• Grok setzt er ebenfalls als zusätzlichen Prüfer ein und schätzt insbesondere dessen Geschwindigkeit.
• GitHub Copilot dient inzwischen als weitere Review-Stufe auf GitHub. Ironischerweise hatte DHH ältere Versionen dieser Funktion noch weitgehend abgeschrieben. Heute sagt er, dass Copilot tatsächlich reale Fehler finde.
• OpenCode nutzt er als Harness für Open-Weight-Modelle wie Kimi.
• Fireworks dient ihm dabei zur Inferenz dieser Modelle gegen Token-Abrechnung.
• Und dann wird es nerdig:
• Herdr organisiert mehrere parallel arbeitende Agents und meldet sich, sobald irgendwo eine Entscheidung des Menschen erforderlich ist.
• Tailscale verbindet seine Rechner.
• GL.iNet Comet KVMs geben ihm Remote-Zugriff auf weitere Maschinen.
• Neovim ist noch da – inzwischen teilweise weniger als Schreibwerkzeug und mehr als Browser für Struktur und Kontext.
• lazygit und Hunk helfen beim Betrachten von Änderungen.

Und das Ganze läuft natürlich unter Omarchy/Linux, weil Dateien, Konfigurationen und CLI-Tools für Agents hervorragend zugänglich sind. Zeitweise arbeitet DHH nach eigener Aussage mit etwa 16 parallelen Threads auf vier bis fünf Maschinen. Das ist vielleicht der eigentliche Paradigmenwechsel. Der Programmierer sitzt nicht mehr unbedingt vor einer Datei. Er betreibt eine kleine Softwarefabrik.

Spotify war sogar noch früher dran

Und DHH ist nicht allein. Spotify zeigt, wie diese Arbeitsweise innerhalb eines großen Unternehmens aussieht. Gustav Söderström – heute Co-CEO und zuvor Chief Product & Technology Officer – erklärte Anfang 2026 über die besten Entwickler des Unternehmens, sie „have not written a single line of code since December“. Sie haben natürlich nicht aufgehört, Software zu entwickeln. Spotify hat mit Honk einen eigenen Background-Coding-Agent aufgebaut, inzwischen auf Basis von Claude Code. Ein Entwickler kann beispielsweise morgens auf dem Weg zur Arbeit über Slack einen Bugfix oder ein neues Feature beauftragen. Der Agent arbeitet im Hintergrund und schickt anschließend eine neue Version der App zurück aufs Smartphone. Der Mensch testet, beurteilt, korrigiert und entscheidet über den Merge.

Das ist ein ziemlich anderes Bild als der „Vibe Coder“, der nachts um zwei einem Chatbot zum zwölften Mal schreibt: „Still doesn’t work. Please fix.“

Genau hier liegt das Missverständnis von Vibe Coding

DHH mag den Begriff selbst nicht. Für ihn erinnert Vibe Coding an die „Script Kiddies“ der frühen Internetzeit: Menschen, die irgendwelche PHP-Skripte herunterladen und benutzen, ohne zu verstehen, was sie eigentlich tun. Seine Definition ist entsprechend eng: Man sagt der KI, was sie bauen soll, und interessiert sich nicht für die Implementierung. Aber selbst diese Definition beginnt zu wackeln. Denn wenn die Implementierung immer zuverlässiger von Maschinen übernommen werden kann, stellt sich irgendwann die Frage:

Was ist eigentlich die wertvollere Kompetenz?

Eine for-Schleife besonders elegant schreiben? Oder erkennen, welches Problem überhaupt gelöst werden sollte? DHH bringt an dieser Stelle einen Punkt, den ich für viel wichtiger halte als die gesamte Diskussion über Prompt Engineering: Gute Softwareentwicklung war schon immer auch Produktmanagement.

Was soll das Produkt tun?
Für wen?
Was ist wichtig?
Was kann weg?
Was ist Version eins?
Welche Abhängigkeiten gibt es?
Wie erkenne ich, ob das Ergebnis wirklich gut ist?
Welche Risiken übersehe ich?
Welche Lösung ist unnötig kompliziert?

DHH geht sogar so weit zu argumentieren, dass ein hervorragender klassischer Programmierer in der neuen Welt schlechter abschneiden kann als jemand mit besseren Produkt- und Analysefähigkeiten. Das finde ich enorm spannend. Denn plötzlich werden Fähigkeiten wertvoller, die wir lange als „Soft Skills“ bezeichnet haben:

Der Code ist nicht verschwunden. Aber die Implementierung rutscht eine Ebene tiefer.

Nach sechs Wochen sehe ich meinen eigenen Irrtum

Ich bin selbst ziemlich skeptisch in diese Entwicklung hineingegangen. Meine Erwartung war: Ja, ich kann mit AI schneller Software bauen. Dafür bekomme ich aber wahrscheinlich mehr technischen Müll. Crappy Code in Rekordgeschwindigkeit. Nach sechs Wochen intensiver Arbeit sehe ich das anders. Natürlich produzieren Agents Fehler. Natürlich können schlechte Entscheidungen zu schlechter Architektur führen. Und natürlich sollte niemand daraus ableiten, dass technische Kompetenz plötzlich irrelevant ist. Aber der entscheidende Unterschied ist: Ich muss Fehler nicht mehr zwangsläufig selbst suchen. Ich kann ein zweites Modell prüfen lassen. Ein drittes Modell kann die Architektur kritisieren. Das erste kann daraufhin umbauen. Tests können automatisch laufen. Ein Agent kann Sicherheitsprobleme suchen. Ein anderer hinterfragt die Komplexität. Und sie können das wiederholen. Nicht einmal. Sondern zehnmal. Wenn ich bereit bin, die Tokens dafür auszugeben. Deshalb dreht sich meine eigene Kostenrechnung inzwischen um. Tokens sind nicht Kosten, die ich möglichst vermeiden muss. Tokens sind Arbeitskapazität, die ich möglichst intelligent einkaufe. Wenn ein Modell für 23 Dollar mehrere Stunden arbeitet und ein Problem löst, für das ein Mensch Tage oder Wochen benötigt hätte, dann ist die relevante Frage nicht mehr: „23 Dollar für Tokens? Ist das nicht teuer?“ Sondern: „Warum sollte ich hier Tokens sparen?“

Es geht nicht um dreimal mehr Code

Lines of Code waren schon immer eine miserable Kennzahl. Mit AI werden sie endgültig absurd. Das Ziel kann nicht sein, dreimal mehr Software zu produzieren. Das Ziel sollte sein: dreimal bessere Systeme zu bauen – in einem Bruchteil der bisherigen Zeit und für einen Bruchteil der bisherigen Implementierungskosten. Und genau deshalb halte ich „Vibe Coding“ für den falschen Begriff.

Ich vibe hier nicht.
Ich analysiere.
Ich beschreibe Probleme.
Ich zerlege Systeme.
Ich entscheide über Architektur.
Ich definiere Erwartungen.
Ich vergleiche Lösungen.
Ich lasse unterschiedliche Modelle gegeneinander reviewen.
Ich teste.
Ich verwerfe.
Ich vereinfache.

Und irgendwann sage ich: Genau so. Die eigentliche Implementierung wird dabei zunehmend zu einer Frage von Zeit, Compute und Tokens. Das bedeutet nicht, dass jeder morgen jedes Softwaresystem bauen kann. Aber es bedeutet, dass sich der Flaschenhals verschiebt.

Von der Fähigkeit, Code zu schreiben, zur Fähigkeit, klar zu denken und klar zu kommunizieren.

Für jemanden, der aus Strategie, Design, Produktentwicklung oder Kommunikation kommt, ist das eine ziemlich aufregende Verschiebung. Denn vielleicht war Programmieren nie das eigentliche Ziel. Vielleicht wollten wir schon immer nur Dinge erschaffen, die vorher nicht existiert haben. DHH formuliert seine eigene Rückkehr zu diesem Gedanken sehr schön: Er sei ursprünglich Programmierer geworden, weil er Programme wollte. Erst danach habe er sich in das Handwerk des Programmierens verliebt. Heute könne er wieder bei einer Idee anfangen und beinahe unmittelbar sehen, wie sie Realität wird. Genau das ist für mich der interessante Teil dieser Entwicklung. Nicht Vibe Coding. Sondern eine neue Form des Bauens. Und wer ein digitales Produkt, einen Prozess oder eine ziemlich verrückte Idee im Kopf hat und jemanden gebrauchen kann, der das Problem gemeinsam mit ihm analysiert, strukturiert und in ein funktionierendes System übersetzt:

Dafür kann man mich inzwischen ziemlich gut beauftragen. ;)