Der Kult um Vibe Coding ist verrückt
(bramcohen.com)- Der Vorfall um den Quellcode-Leak von Claude hat offengelegt, welchen Schaden blinder Glaube an „Vibe Coding“ der tatsächlichen Qualität von Projekten zufügen kann
- Vibe Coding erhebt es zum Prinzip, den Code überhaupt nicht anzusehen, doch das ist nichts als reiner Aberglaube; tatsächlich braucht es immer von Menschen entworfene Strukturen wie Planungsdateien, Skills und Regeln
- KI ist in Aufgaben wie dem Bereinigen von Codeduplikaten und Technical Debt tatsächlich sehr gut, aber um das zu nutzen, müssen Menschen den Code selbst prüfen, Probleme erkennen und sie der KI erklären
- Dass KI von sich aus erkennt „Hier gibt es Spaghetti-Code, das sollten wir aufräumen“, ist selten; hochwertige Ergebnisse entstehen, wenn Menschen zuerst Richtung und Kontext vorgeben
- Wie die Formulierung „Schlechte Software ist eine Entscheidung von Entwicklern“ sagt, ist Qualitätsverfall nicht das Werk der KI, sondern das Ergebnis von Entscheidungen
- Mit anderen Worten: Sinkende Softwarequalität ist nicht die Schuld der KI, sondern eine Entscheidung, die Entwickler selbst treffen
Der Claude-Quellcode-Leak und das Problem mit Vibe Coding
- Der Quellcode von Claude wurde geleakt und von vielen verspottet, weil die Codequalität schlecht sei
- Als Ursache dieses Problems wurde ein Übermaß an Dogfooding genannt, also eine Kultur, das eigene Produkt übermäßig blind einzusetzen
- Dogfooding an sich ist eine gute Idee, kann aber in eine kultartige Praxis umschlagen, die jede vernünftige Grenze überschreitet
Was Vibe Coding wirklich ist
- Vibe Coding ist ein Ansatz, der es zum Prinzip erhebt, überhaupt nichts zum Inneren des Codes beizutragen und nicht einmal hineinzusehen
- Doch reines Vibe Coding ist ein Mythos — in der Praxis gibt es immer von Menschen geschaffene Frameworks wie Planungsdateien (To-do-Listen), Skills und Regeln, und ohne diese Struktur liefert KI sehr schlechte Leistung
- Obwohl Code auf Englisch geschrieben ist und daher von jedem gelesen werden kann, weigern sich Entwickler, ihn selbst zu prüfen, mit der Logik, ein Blick ins Innere sei „Schummeln“
- Tatsächlich stellte sich heraus, nachdem ein Mensch den Code einmal angesehen hatte, dass es massive Duplikation zwischen Agenten und Tools gab — ein Problem, das jeder leicht hätte erkennen können, wenn nur jemand kurz hingeschaut hätte
KI und das Bereinigen von Technical Debt
- Softwareprojekte starten oft mit Technical Debt, und früher konnte allein deren Bereinigung bis zu einem Jahr dauern
- Mit KI lässt sich diese Aufräumarbeit in wenigen Wochen erledigen oder schrittweise abbauen, während parallel neue Funktionen entwickelt werden
- KI ist beim Aufräumen von Code sehr stark, erkennt Probleme aber nur unzureichend von selbst — gute Ergebnisse entstehen, wenn Menschen sagen „Hier gibt es Spaghetti-Code“ und dazu Anleitung geben
Der richtige Einsatz von KI — ein gesprächsbasierter Ansatz
- Als richtiger Weg zur Lösung von Duplikationsproblemen werden die folgenden Schritte vorgeschlagen:
- Eine Liste der Einträge erstellen, die sowohl zu Agenten als auch zu Tools gehören
- Beispiele prüfen und für jeden Eintrag entscheiden, ob er ein Agent oder ein Tool ist
- Die allgemeinen Kriterien besprechen und allgemeine Richtlinien festlegen
- Alle Einträge auditieren und falsch klassifizierte Einträge korrigieren
- Einträge, die auf beiden Seiten existieren, in beiden Versionen prüfen und zu einer zusammenführen
- Der Ask-Modus ist für genau diesen Prozess gedacht: Beispiele gemeinsam durchgehen und die KI korrigieren, wenn sie zu schnell allem zustimmen will, ist der Kern
- Nach ausreichend viel Dialog kann es sich anfühlen, als hätte die KI ein One-Shot-artiges Ergebnis geliefert, tatsächlich setzt es aber viele vorherige Interaktionen mit Menschen voraus
- Das Claude-Team wendet Dogfooding ohne diesen Prozess extrem an und verweigert selbst den minimalen Aufwand, kurz in den Code zu schauen und das Problem zu beschreiben
Praktische Beispiele aus dem Einsatz
- Beispiel für den eigenen Workflow: Zu Beginn eines Gesprächs sagen wie „Lass uns in dieser Codebasis unerreichbaren Code auditieren“ oder „Diese Funktion tut in den Augen weh“ und so die Unterhaltung starten
- Das Gespräch so lange fortsetzen, bis eine umsetzbare Richtung entsteht, dann erklären, was zu tun ist, und weiterdiskutieren, bis die KI aufhört, Unsinn zu reden
- Danach einen Plan aufstellen und den Build ausführen — das ist der übliche Ablauf
Softwarequalität ist eine Frage der Entscheidung
- Wer KI nutzt, muss Software von niedriger Qualität nicht einfach hinnehmen
- Auch Bibliotheken von überbezahlten Entwicklern ohne KI-Hilfe können schlechte Qualität haben
- Schlechte Software ist eine selbst getroffene Entscheidung; dafür muss man Verantwortung übernehmen und bessere Qualität anstreben
9 Kommentare
Während mit AI AGENT alles vollautomatisch gemacht wird und sogar Codegenerierung, Merge, Review und Validierung komplett autonom laufen sollen, sodass der Code quasi von selbst zusammengestellt wird und man sich überhaupt nicht mehr darum kümmern müsse und Entwickler nur noch gelegentlich eingreifen müssten, wenn sich die Agenten untereinander verheddern, wurde ständig eine Stimmung verbreitet, in der Entwickler, die das nicht so machen können, als abnorm hingestellt werden, weil sie dem Trend nicht folgen würden ... Wenn ich dann sehe, wie Leute, die sonst wohl nur endlos Boilerplate-Code und bloß fortlaufende einfache Muster schreiben und dafür ein hohes Gehalt kassieren, jetzt groß reden, dass man dank AI gar keinen Code mehr schreiben müsse, ist das einfach nur erbärmlich.
Man muss sogar die kleinsten Details micromanagen, um Code von halbwegs plausibler Qualität zu bekommen. Ich halte vollständige Autonomie für völlig unrealistisch, außer wenn es darum geht, echte Boilerplate-Code-Massenproduktion zu betreiben. Menschen, die von vollständiger Autonomie reden, sind meiner Meinung nach eines von zwei Dingen: Entweder sie verstehen nicht viel davon, oder sie sind Betrüger.
Halbfertige Projekte überschwemmen alles …
Und Leute, die nur die Hälfte vom Programmieren verstehen, geraten in Ekstase …
Es ist wohl besser,
dogfoodingnicht als Monopolisierung zu verstehen, sondern eher als „Dog Pudding“.dog食...
Titel und Inhalt sind unterschiedlich …?
Es wirkt eher wie eine Kritik nach dem Muster, bei dem man Vibe Coding kurzerhand mit „es wird ohnehin kein Code Review gemacht“ gleichsetzt und dann Gründe passend dazuerfindet.
Außerdem ergibt es keinen Sinn, dabei auch noch Claude Code heranzuziehen. Wenn man wirklich Engineering-Prinzipien auf dem Niveau von Linux-Maintenance anlegt, also bei Leuten, die auf genau diese Art von Qualität achten, geht man Fragen der Code-Qualität nicht so fragmentarisch an. Das ist größtenteils ein propagandistischer Ansatz, kein Ergebnis eigener Tests, sondern eher ein „man hört eben so etwas“.
Das ist ungefähr so, als würde man sagen, das Design von Samsung-Gebäuden sei nicht gut und deshalb sei Samsung noch weit davon entfernt, Sony einzuholen.
Als ich Claude Code zum ersten Mal ausprobiert habe, sagte ich zu ausländischen Freunden: "Ich habe zum ersten Mal Vibe Coding ausprobiert!" Nachdem sie sich angehört hatten, was ich gemacht hatte, meinten sie jedoch: "Nein, das ist kein Vibe Coding; Vibe Coding bedeutet doch gerade, dass man sich den eigentlichen Code überhaupt nicht anschaut." Das, was hierzulande oft als "Vibe Coding" bezeichnet wird, scheint also viel weiter gefasst zu sein als die Definition im Westen. Auf Hacker News wird Vibe Coding im Grunde tatsächlich als "kein Code-Review" definiert.
Hacker-News-Kommentare
Es ist seltsam, wenn Leute die Qualität des geleakten Source Codes von Claude Code als Beleg dafür anführen, dass „Vibe Coding“ gescheitert sei
Für mich ist eher das Gegenteil der Fall. Es ist ein Beweis dafür, dass man populäre und erfolgreiche Produkte bauen kann, selbst wenn man traditionelle Regeln für „guten Code“ bricht
Wegen Deadlines bleibt provisorisch zusammengebauter Code oft einfach in Production
Auch bei privaten Projekten sind die ersten Commits chaotisch, und erst später macht man einen Cleanup-Branch und räumt auf
In Unternehmen gibt es aber fast nie Zeit für einen zweiten oder dritten Entwurf, also wird am Ende der erste Entwurf ausgerollt
Ehrlich gesagt mache ich mir manchmal Sorgen, dass Code mit meinem Namen daran geleakt werden könnte. Aber das ist die Realität
Wenn sich bei einer Codeänderung etwas „irgendwie erzwungen“ anfühlt, spart es am Ende Zeit, es sofort zu beheben
Bei LLMs habe ich allerdings noch nicht genug Erfahrung, um mir da sicher zu sein
Claude Code ist im Kern ein einfaches Produkt, und der eigentliche Wert liegt im Modell selbst
Anders gesagt: Das ist ein risikoarmes Produkt, bei dem niedrige Codequalität kein großes Problem ist, deshalb war so ein Fall möglich
Es ist auch kein Verstoß gegen das Konzept „Vibe Coding“. Man gibt nur abstrakte Ideen auf hohem Niveau vor, und den eigentlichen Code schreibt die AI
Claude Code liegt bei AI Level 7 (Mensch macht die Spezifikation, Bot den Code), und der Autor meint, Level 6 sei besser
Das ideale Niveau ist von Person zu Person unterschiedlich. Manche sehen Level 5 oder weniger als Grenze, andere halten schon alles ab Level 2 für riskant
Je nach Komplexität und Neuartigkeit des Fachgebiets ist ein anderes Niveau angemessen
In einer App, die ich baue, wäre zum Beispiel der Algorithmus-Teil Level 0, das UI Level 7 und die Middleware irgendwo dazwischen
Die Kunst besteht darin, für jeden Codebereich das passende Niveau zu finden
In dynamischen Sprachen wäre mir mehr als das zu unsicher. Wenn ich auf Level 7 oder höher gehen würde, dann lieber mit einer vollständig statisch typisierten Sprache
Coding wird dann nur noch in Resten übrig bleiben, wie Schmiedekunst heute, und größtenteils automatisiert sein
Dafür kann eine einzelne Person dann die Arbeit erledigen, für die früher ein ganzes Team nötig war
Die Versuchung ist groß, Features zu übernehmen, ohne den genauen Mechanismus vollständig zu verstehen
Der Autor dieses Beitrags ist der Gründer von BitTorrent. Er ist nicht einfach nur irgendein Blogger
Mein Lieblingsanwendungsfall für Claude Code ist die Verbesserung der Codequalität
Dinge, die von Hand wie Zeitverschwendung wirken würden, erledigt AI fast kostenlos, daher lohnt es sich
Wiederkehrende Testmuster aufräumen, Konsistenz bei der JSON-Serialisierung sichern, duplizierten Code entfernen und so weiter
Dadurch wird die Codebasis kleiner und wartbarer. Es ist eine Art Linting im großen Stil
Die Ergebnisse der einzelnen Modelle prüfe ich gegeneinander, und am Ende erstellt Opus eine finale Liste und behebt sie
Es gibt zwar viele unnötige Änderungen, aber die gefundenen Probleme sind tatsächlich nützlich
Die Perspektive des „Dogfooding“ ist interessant
Der Punkt ist nicht Codequalität, sondern ob Nutzer AI-Ergebnisse kritisch bewerten können
Es ist ein riesiger Unterschied, ob erfahrene Engineers AI nutzen und dabei ihr Urteilsvermögen behalten, oder ob sie das Urteilen an die AI abgeben
Das Problem ist, dass die Tools diese beiden Fälle nicht unterscheiden, und das Marketing auf den zweiten Fall ausgerichtet ist
Befürworter von „Vibe Coding“ argumentieren, dass Codequalität unwichtig werde, weil LLMs Iteration viel schneller durchlaufen können als Menschen
Für Menschen sind die Kosten jedes Schritts (schreiben–prüfen–korrigieren) hoch, während LLMs schnell iterieren können und nur Token-Kosten anfallen
Ich bin bei diesem Ansatz aber skeptisch. Ich habe schon zu viele Fälle gesehen, in denen es in der Praxis kaputtging
Trotzdem könnten sie recht behalten, wenn LLMs noch besser werden
Beim Spektrum von „Vibe Coding“ gibt es zwei Gruppen
Die eine besteht aus Leuten ohne technischen Hintergrund, die es spannend finden, die andere aus AI-Hassern
Dazwischen gibt es eine stille, aber produktive Mitte. Diese Leute sind optimistisch und zugleich erfahren
Ich selbst habe in den letzten sechs Monaten etwa 2500 Dollar an Claude-Code-Credits verbraucht und dabei enormen Wert erhalten, obwohl das meiste nie wirklich ausgerollt wurde
Ich stimme der Behauptung nicht zu, dass „Claude Code nutzlos ist“
Die meisten Web-Apps sind einfache CRUD-Anwendungen. 99 % der Unternehmen haben nicht einmal 50.000 Nutzer
In einem Unternehmen, in dem ich gearbeitet habe, mussten Programme wegen ineffizientem Code 22 Stunden am Tag laufen
Dieses Phänomen erinnert mich an Clayton Christensens Innovationstheorie
Etablierte Unternehmen ignorieren neue, minderwertige Technologien, weil sie sich auf ihre aktuell profitablen Produkte verlassen, doch irgendwann reifen diese Technologien genug heran, um den Markt umzukrempeln
Claude Code ist schon jetzt „gut genug“, und wenn AI sich weiter verbessert, wird sie manuell geschriebenen Code am Ende übertreffen
Die Leute rund um „Vibe Coding“ lassen sich in einige Gruppen einteilen
① Menschen mit finanziellem Eigeninteresse, ② Entwickler, die vom Coding müde geworden sind, ③ Einsteiger, die zum ersten Mal etwas bauen
② will nichts Neues mehr lernen, und ③ erlebt aufrichtig die Freude am Erschaffen
AI Coding kann für diese Leute ein guter Einstiegspfad sein
Ich gehöre auch dazu. Seit 30 Jahren liebe ich das Coding, aber es hat immer zu lange gedauert, das umzusetzen, was ich mir vorgestellt habe
Jetzt verschwindet diese Lücke, und das fühlt sich befreiend an. Mein Ziel ist es, zu lernen, wie man bei gleichbleibender Qualität schneller wird
Man hat die Probleme großer Konzerne einfach nachgespielt, wodurch die Produktivität sank und nur die Erschöpfung zunahm
Dank AI kann man diese Komplexität jetzt ignorieren und direkt zu Ergebnissen kommen
Selbst wenn ein neues Framework oder ein neues Deployment-Verfahren auftaucht, muss man sich darum nicht kümmern. Die AI erledigt das
Bei jedem Generationswechsel in der Technologie wiederholt sich dieser Konflikt