Vibe Engineering

• „Vibe Engineering“ ist eine neue Bezeichnung für eine professionelle Entwicklungsweise mit AI-Coding-Tools. Anders als schnelles und verantwortungsloses „Vibe Coding“ bezeichnet es einen Ansatz, bei dem erfahrene Engineers LLMs nutzen und dabei Codequalität und Verantwortlichkeit aufrechterhalten
• Mit dem Aufkommen von Coding-Agenten wie Claude Code, OpenAI Codex CLI und Gemini CLI ist der Einsatz von LLMs in realen Projekten stark angestiegen. Einige Engineers führen sogar mehrere Agenten gleichzeitig aus, um parallel zu arbeiten
• Um LLMs effektiv zu nutzen, braucht es bereits etablierte Best Practices der Softwareentwicklung wie automatisierte Tests, Vorausplanung, umfassende Dokumentation, Versionsverwaltung und eine Kultur des Code-Reviews
• AI-Tools verstärken bestehende Expertise. Je mehr Fähigkeiten und Erfahrung ein Senior Engineer mitbringt, desto schneller und besser fallen die Ergebnisse mit LLMs aus
• Der Begriff grenzt sich bewusst von „Vibe Coding“ ab und betont eine schwierigere und ausgefeiltere Form des AI-Einsatzes für die Entwicklung von Produktionssoftware. Die widersprüchliche Kombination aus Engineering und Vibe macht den Ausdruck zugleich leichter merkbar (sie unterstreicht den Wandel von Entwicklungsprozessen durch AI-Tools und die Bedeutung von Professionalität)

---

Abgrenzung zwischen Vibe Coding und Vibe Engineering

• Vibe Coding ist eine schnelle, lockere und verantwortungslose Form der Softwareentwicklung mit AI, die vollständig promptgetrieben ist und kaum darauf achtet, wie der Code tatsächlich funktioniert
• Am anderen Ende des Spektrums gibt es eine Arbeitsweise, bei der erfahrene Fachleute ihre Arbeit mit LLMs beschleunigen und zugleich stolz und selbstbewusst Verantwortung für die von ihnen produzierte Software übernehmen. Diese wird als Vibe Engineering bezeichnet
• Mit LLMs in echten Projekten statt nur in Spielzeugprojekten produktiv als Software Engineer zu arbeiten, ist die weniger bekannte Wahrheit: Es ist schwierig. Es erfordert viel Tiefgang im Umgang mit den Tools, und es gibt viele Fallstricke, die man vermeiden muss

Das Aufkommen von Coding-Agenten und seine Auswirkungen

• Mit Coding-Agent-Tools wie Claude Code (veröffentlicht im Februar 2025), OpenAIs Codex CLI (April) und Gemini CLI (Juni) ist die Nützlichkeit von LLMs für reale Programmierprobleme dramatisch gestiegen
  • Diese Tools bearbeiten Code iterativ weiter und testen aktiv, bis sie das vorgegebene Ziel erreicht haben
• Erfahrene und verlässliche Software Engineers lassen mehrere Agenten gleichzeitig laufen, um mehrere Probleme parallel zu bearbeiten und den Umfang ihrer Arbeit zu erweitern
  • Der Autor war anfangs skeptisch, stellte nach dem eigenen Einsatz paralleler Coding-Agenten jedoch fest, dass dies mental anstrengend, aber überraschend effektiv ist
• Der Großteil der Sammlung auf tools.simonwillison.net wurde im klassischen Stil des Vibe Coding gebaut. Doch mit Coding-Agenten iterativ zu arbeiten und dabei wartbaren Code in Produktionsqualität zu erzeugen, fühlt sich wie ein völlig anderer Prozess an

Bestehende Software-Engineering-Praktiken, die durch LLMs verstärkt werden

• Automatisierte Tests: Mit einer starken, umfassenden und stabilen Test-Suite können Agent-Coding-Tools schnell arbeiten. Ohne Tests behaupten Agenten womöglich nur, dass etwas funktioniert, ohne es wirklich zu testen, oder neue Änderungen brechen nicht zusammenhängende Funktionen
  • Test-First-Entwicklung ist besonders wirksam für Agenten, die in einer Schleife iterieren können
• Vorausplanung: Wenn man mit einem übergeordneten Plan startet, läuft das gemeinsame Hacken an etwas deutlich besser, und bei der Arbeit mit Agenten wird das noch wichtiger
  • Man kann zuerst den Plan iterieren und ihn dann dem Agenten übergeben, damit dieser den Code schreibt
• Umfassende Dokumentation: Wie menschliche Programmierer können auch LLMs jeweils nur Teile einer Codebasis im Kontext behalten. Gibt man ihnen relevante Dokumentation, können sie APIs aus anderen Bereichen nutzen, ohne zuerst den Code lesen zu müssen
  • Wenn man zuerst gute Dokumentation schreibt, kann das Modell allein auf Basis dieser Eingabe eine passende Implementierung erstellen
• Gute Gewohnheiten in der Versionsverwaltung: Wenn ein Coding-Agent Änderungen vorgenommen haben könnte, wird es noch wichtiger, Fehler rückgängig machen und nachvollziehen zu können, wann und wie etwas verändert wurde
  • LLMs sind sehr gut in Git und können die Historie selbst durchforsten, um den Ursprung eines Bugs nachzuverfolgen; git bisect beherrschen sie oft besser als die meisten Entwickler
• Effektive Automatisierung: Continuous Integration, automatisiertes Formatting und Linting sowie Continuous Deployment in Preview-Umgebungen helfen auch Agent-Coding-Tools
  • LLMs erleichtern das Schreiben schneller Automatisierungsskripte, damit Aufgaben beim nächsten Mal korrekt und konsistent wiederholt werden können
• Eine Kultur des Code-Reviews: Wer in Code-Reviews schnell und produktiv ist, wird auch bei der Arbeit mit LLMs deutlich bessere Erfahrungen machen
  • Wenn man lieber selbst Code schreibt, statt etwas Gleichwertiges zu prüfen, das jemand anderes (oder etwas anderes) geschrieben hat, wird es schwierig
• Eine sehr seltsame Form von Managementtechnik: Gute Ergebnisse von Coding-Agenten zu bekommen, ist auf unangenehme Weise ähnlich dazu, gute Ergebnisse von menschlichen Mitarbeitenden zu erhalten
  • Man muss klare Anweisungen geben, den nötigen Kontext sicherstellen und umsetzbares Feedback zu den Ergebnissen liefern
  • Dass es viel einfacher ist als die Arbeit mit echten Menschen, liegt daran, dass man sich keine Sorgen machen muss, sie zu beleidigen oder zu demotivieren. Bestehende Managementerfahrung ist dennoch überraschend nützlich
• Wirklich gutes manuelles QA (Qualitätssicherung): Neben automatisierten Tests muss man sehr gut darin sein, Software manuell zu testen, einschließlich des Antizipierens und Durchdringens von Edge Cases
• Starke Recherchefähigkeiten: Für ein gegebenes Coding-Problem gibt es Dutzende möglicher Lösungen. Die beste Option zu identifizieren und den Ansatz zu validieren war schon immer wichtig und bleibt auch dann ein Hindernis, wenn man Agenten echten Code schreiben lässt
• Die Fähigkeit, in Preview-Umgebungen zu deployen: Wenn ein Agent ein Feature baut, wird das Review viel produktiver und das Risiko, kaputte Software auszuliefern, deutlich kleiner, wenn es eine Möglichkeit gibt, diese Funktion sicher vorab anzusehen, statt direkt in Produktion zu deployen
• Ein Gespür dafür, was an AI ausgelagert werden kann und was man manuell erledigen sollte: Mit wirksameren Modellen und Tools entwickelt sich das laufend weiter
  • Ein großer Teil effektiver Arbeit mit LLMs besteht darin, eine starke Intuition dafür zu behalten, wann sie am besten eingesetzt werden können
• Ein aktualisiertes Schätzungsvermögen: Abzuschätzen, wie lange ein Projekt dauern wird, war schon immer einer der schwierigsten, aber wichtigsten Teile der Rolle eines Senior Engineers, besonders in Organisationen, in denen Budget- und Strategieentscheidungen auf solchen Schätzungen beruhen
  • AI-unterstütztes Coding macht das noch schwieriger: Dinge, die früher lange dauerten, gehen nun viel schneller, aber Schätzungen hängen jetzt von neuen Faktoren ab, die wir alle noch zu verstehen versuchen

Das Wesen und die Bedeutung von Vibe Engineering

• Um die Fähigkeiten dieser neuen Tools wirklich auszuschöpfen, muss man auf höchstem Niveau arbeiten, und das umfasst:
  • nicht nur Verantwortung für das Schreiben von Code, sondern auch für
  • die Recherche von Ansätzen,
  • Architekturentscheidungen auf hoher Ebene,
  • das Schreiben von Spezifikationen,
  • die Definition von Erfolgskriterien,
  • das Design von Agenten-Schleifen,
  • QA-Planung,
  • das Management einer ständig wachsenden Truppe seltsamer digitaler Praktikanten, die bei Gelegenheit versuchen zu schummeln,
  • und viel Zeit für Code-Reviews
• Fast all das sind ohnehin bereits Merkmale eines Senior Software Engineers
• AI-Tools verstärken bestehende Expertise: Je mehr Können und Erfahrung man als Software Engineer besitzt, desto schneller und besser werden die Ergebnisse bei der Arbeit mit LLMs und Coding-Agenten

„Vibe engineering“, wirklich? : Überlegungen zur Wortwahl

• Ist der Name „Vibe Engineering“ albern? Wahrscheinlich schon. Das Konzept des „Vibe“ in AI wirkt an diesem Punkt etwas abgenutzt, und „Vibe Coding“ selbst wird von vielen Entwicklern abwertend verwendet
  • Dennoch bin ich bereit, Vibe für etwas Konstruktiveres zurückzuerobern
• Ich mochte die künstliche Unterscheidung zwischen „Coder“ und „Engineer“ nie; sie wirkte immer etwas wie eine Eintrittsbarriere. Aber in diesem Fall ist genau so eine kleine Eintrittsbarriere notwendig
  • Vibe Engineering schafft eine klare Abgrenzung zu Vibe Coding und signalisiert, dass dies eine andere, schwierigere und ausgefeiltere Art ist, mit AI-Tools Produktionssoftware zu bauen
• Mir gefällt, dass das anmaßend und potenziell kontrovers ist; dieser ganze Bereich ist noch immer auf viele Arten absurd
  • Während wir herausfinden, wie wir diese neuen Tools am produktivsten einsetzen, sollten wir uns selbst nicht zu ernst nehmen
• In der Vergangenheit habe ich versucht, Begriffe wie AI-unterstützte Programmierung zu etablieren, hatte damit aber fast keinen Erfolg. Diesmal ist es vielleicht keine schlechte Idee, ein wenig Vibe hineinzureiben und zu sehen, was passiert
• Mir gefällt die klare Dissonanz zwischen „Vibe“ und „Engineering“ sehr; sie macht den zusammengesetzten Begriff spielerisch und (hoffentlich) einprägsam selbstwidersprüchlich

[m00nlygreat]

Soweit ich weiß, ist es erst vor Kurzem schon einmal gescheitert, etwas mit dem Namen „Was für Coding?“ zu etablieren; ich denke, „AI Pair Programming“ ist dafür der passendste Ausdruck.

Eine Namensgebung, nur um behaupten zu können: Diesen Namen habe ich erfunden.

[m00nlygreat]

Jemand hatte das einmal als augmentiertes Codieren (Augmented Coding) bezeichnet, aber der Begriff war schnell wieder verschwunden.

[GN⁺]

Hacker-News-Kommentare

• Wenn ich in letzter Zeit solche Themen lese, werde ich irgendwie niedergeschlagen. Früher hatte ich Programmierfähigkeiten, die schwer zu bekommen, gefragt und gut bezahlt waren, und selbst wenn sich Sprachen oder Frameworks schnell änderten, hatte ich das Gefühl, klug genug zu sein, um mitzuhalten. Aber wenn Leute wie Simon Willison sagen, dass diese neue agentenbasierte Art des Codings und parallele Arbeitsabläufe die Zukunft seien, fühlt sich das nach einem enormen Aufwand an und macht mir zu schaffen. Ich habe Coding-Agenten ausprobiert, aber am Ende warte ich eher mehr, und mehrere Aufgaben gleichzeitig zu verwalten macht es schwer, in einen Flow zu kommen, sodass es weniger Spaß macht. Deshalb denke ich inzwischen sogar darüber nach, in ein ganz anderes Feld wie Vertrieb zu wechseln.
  • Ich kann dieses Gefühl wirklich gut nachvollziehen. Tatsächlich war eines meiner Ziele, der Vorstellung zu widersprechen, dass „Programmierfähigkeiten wertlos werden und jeder mit einem LLM Code schreiben kann“. Ich glaube vielmehr, dass Menschen mit bestehender Entwicklungserfahrung in Kombination mit Coding-Agenten oder LLMs deutlich wertvoller werden. Man kann das, was man bisher gelernt hat, mit neuen Werkzeugen einsetzen und damit größere Wirkung erzielen. Wie im Post erwähnt, verstärken AI-Tools die Fähigkeiten bestehender Experten. Anfänger können mit ChatGPT vielleicht eine schicke UI bauen, aber Architekturdesign, automatisierte Tests oder CI/CD, Kubernetes-Deployments oder den parallelen Betrieb mehrerer Agenten schaffen sie nicht. Die Rolle erfahrener Ingenieure wird also noch wichtiger.
  • Auch ich empfinde „mehrere große parallelisierte Agenten zu verwalten“ als belastend. Von außen wirkt es sehr mächtig, deshalb interessieren sich wahrscheinlich viele Entwickler dafür, aber in Wirklichkeit fühlt es sich nach enormem Stress und Verwaltungsarbeit an. Als ich mich anfangs für Entwicklung begeisterte, machte das Codieren selbst Spaß, und ich lernte viel, indem ich den ganzen Tag programmierte. Jetzt, nach mehr als zehn Jahren Berufserfahrung, hat sich meine Perspektive eher in ein geschäftliches Denken verwandelt: „Warum sollte man das überhaupt programmieren?“ Wenn in Meetings andere Abteilungen nur fragen: „Können wir das machen?“, lautet die Antwort technisch fast immer „JA“. Fast alles ist machbar. Aber die wirklich wichtigen Fragen sind: „Wie schwierig ist es?“ oder „Warum sollten wir das tun?“ Ich denke weiterhin, dass es nicht entscheidend ist, viel zu iterieren und viele verschiedene Dinge auszuliefern, sondern auf das Wesentliche zu schauen.
  • Das spricht mir wirklich aus der Seele. Ich mag es ebenfalls überhaupt nicht, AI zu beaufsichtigen und zu verwalten. Außerdem ist es beängstigend, dass sich mit diesem AI-basierten Coding eine Realität normalisiert, in der man ohne ungeprüfte, dubiose Accounts bei Großkonzernen gar nicht mehr arbeiten kann.
  • Kein Grund zur Sorge. Ich betreue gerade einen Junior Engineer in unserem Team. Für ihn ist es sehr schwer, Code zu verbessern, weil er zufrieden ist, sobald es irgendwie funktioniert. Die Struktur ist schlecht, und überall lauern kleine Probleme oder Sicherheitslücken. Das passiert schon bei nur drei Python-Dateien. Wir haben zehn Entwickler im Team, und wenn alle LLMs einsetzen, wird der Qualitätsunterschied im Code je nach Erfahrung eher noch größer. In den sechs Monaten, bevor wir LLMs offiziell einsetzen durften, hatte ich bereits den Eindruck, dass die Kluft zwischen Junioren und Senioren bzw. erfahrenen Leuten in der Praxis größer wird. Das ähnelt Simons Sichtweise.
  • Im Kern gilt einfach: Wer Wissen hat, wird durch Werkzeuge noch stärker, nicht umgekehrt.
• Rund um die Veröffentlichung von GPT-4, Anfang 2023, gab es in der Übersetzungsbranche eine ähnliche Veränderung. Bei Englisch-Japanisch-Übersetzungen — meinem Arbeitsfeld — kam maschinelle Übersetzung erstmals an menschliches Niveau heran. Damals hatte ich viele Diskussionen mit professionellen Übersetzern, und wie hier äußerten viele Enttäuschung, weil sie fürchteten, dass ihre schwer erarbeiteten Übersetzungsfähigkeiten bedeutungslos würden. Viele reagierten auch so, dass selbst der anspruchsvolle Spaß am Prozess verloren gehe, wenn man LLMs als Helfer einsetze. Die Übersetzer, die ich kannte, arbeiteten meist freiberuflich und übersetzten Satz für Satz sehr sorgfältig. Projektmanager für große Übersetzungsprojekte zu werden, reizte sie eher nicht, und auch wenn sie hochentwickelte kulturelle und situative Kommunikationsfähigkeiten einsetzen konnten, war die Motivation gering. Ich übersetze heute nicht mehr viel, verfolge die AI-Entwicklung aber kontinuierlich und teste Modelle gelegentlich anhand von Übersetzungsaufgaben gegeneinander. In letzter Zeit experimentiere ich mit einem Multi-LLM-basierten Übersetzungssystem, bei dem mehrere LLMs kombiniert werden — sie prüfen und verbessern gegenseitig ihre Übersetzungen. Bei manchen Dokumenten kommen Ergebnisse heraus, die wirklich fast auf dem Niveau exzellenter menschlicher Übersetzungen liegen. Die API-Kosten waren nicht billig, aber für wichtige Übersetzungen absolut vertretbar. Beim Entwurf eines solchen „vibe translation“-Systems hat mir meine Erfahrung als Übersetzer eindeutig geholfen. Das ähnelt dem, was Simon mit vibe engineering meint. In meinem Alter (68) ist das für mich okay, aber wenn LLMs und Ähnliches in den ersten fünf bis zehn Jahren meiner Laufbahn aufgetaucht wären, hätte ich die Übersetzerei vielleicht aufgegeben.
  • Das Übersetzungsthema ist wirklich ein sehr gutes Beispiel für LLM-Diskussionen, danke fürs Teilen deiner Erfahrungen. Andererseits messen die meisten Menschen Übersetzern keinen tiefen Wert bei. Zum Beispiel erinnert sich kaum jemand daran, wer ein Buch übersetzt hat. Vielleicht auch, weil die Leute heute nicht mehr so viel lesen wie früher. Und aus diesem Grund wurde Übersetzung traditionell oft nach Wort- oder Zeilenzahl beauftragt und bezahlt. Ähnlich wie Software-Sicherheit wird sie als letzter Prüfschritt behandelt. Die Übersetzungsbereiche mit echter Zukunftsfähigkeit sind wohl eher Recht — weil dort Menschen verklagt werden oder haften — oder Simultan- bzw. Vor-Ort-Dolmetschen, weil dafür direkte Begegnung und echte Präsenz nötig sind.
• Ich finde es etwas absurd, wie stark in Tech-Communities gerade die Behauptung gepusht wird, dass „Coding schneller wird und die Produktivität steigt“. Es herrscht eine Stimmung, in der nur schnelle Ergebnisse zählen. In meiner Erfahrung produzieren LLMs oft weitschweifigen, unordentlichen Code. Klar, sie können schneller sein als ich, aber oft habe ich das Gefühl, dass der von mir langsamer geschriebene Code deutlich besser ist. Diese heutige Atmosphäre, in der man alles schnell per Chat erledigen, schnell ein Ergebnis bekommen und schnell in Produktion gehen muss, war früher schon der Grund für die Flut an schlampigen Webprodukten. Statt mit modischen Begriffen wie vibe coding oder vibe engineering zu spielen, sollten wir ernsthaft darüber sprechen, warum überhaupt so viel Bedarf an niedriger Qualität bei hoher Geschwindigkeit besteht und warum sich die Automatisierung bzw. der Prozess selbst nicht stärker verbessern lässt. Man kann zum Beispiel Unit-Tests sehr schnell erstellen, aber man sollte sich zuerst fragen, warum überhaupt so viele Unit-Tests nötig sind. Sicher, sie sind notwendig, aber während sich die Abstraktionsebene weiterentwickelt, scheinen die unteren Werkzeuge, also die detaillierten Tools, langsamer voranzukommen.
  • Das eigentliche Problem in Debatten über Software Engineering ist, dass Werkzeuge und Sprachen zwar gleich aussehen, in der Realität aber enorme Unterschiede bei Fehlertoleranz, Sicherheit, Compliance und Wartbarkeitsstandards bestehen. Manche bauen schnell einen simplen Prototypen, andere arbeiten mit einem Zehnjahres-Roadmap-Horizont oder sensiblen Daten. Weil diese beiden Perspektiven vermischt werden, existieren gleichzeitig die Sicht, dass schnelles Produzieren Kompetenz sei, und die Sorge, dass so etwas katastrophale Folgen haben könne. Keine Seite liegt völlig falsch, aber der tatsächliche Arbeitskontext und das Risiko werden in solchen Diskussionen scheinbar jedes Mal ignoriert.
  • Realistisch betrachtet helfen LLMs enorm bei der Entwicklungsgeschwindigkeit. Ich programmiere seit der fünften Klasse, also seit über 20 Jahren, und mein Umfeld hat mein Tempo schon immer anerkannt, aber seit der Einführung von LLMs hat sich mein Maßstab gewaltig vergrößert. Das Spiel hat sich bereits verändert; jetzt geht es nur noch darum, ob man sich anpasst oder nicht. Ich bin selbst mit der Unsicherheit der Zukunft unzufrieden, aber als Ingenieur in ähnlicher Lage kann ich das gut nachvollziehen.
  • Ich versuche einmal darzulegen, warum Geschwindigkeit in der Softwareentwicklung so wichtig ist. Ich behaupte nicht, dass ich zwingend recht habe oder dafür harte Daten besitze, und vielleicht sind auch meine Begriffe nicht sauber definiert. Zunächst könnte man „triviale Software“ als Software verstehen, bei der jeder ihren Wert und die Lösung klar kennt, bei der automatische Verifikation möglich ist oder bei der es nur genau eine Art der Implementierung gibt. Die meiste reale Software ist jedoch nicht trivial. Dort treten immer Bugs, fehlende Anforderungen, undichte Abstraktionen, nutzlose Features, Integrationsprobleme, Performance-Probleme, Sicherheitsprobleme, Komplexität und Wartungsärger auf. Selbst wenn exzellente Entwickler den Code schreiben und selbst wenn der Code sehr gut ist, sind solche Probleme unvermeidlich. Diese Probleme werden nur durch wiederholtes Feedback, reale Nutzung, Wartung und viele Experimente sichtbar und nach und nach verbessert. Das heißt: Man kann Code nicht in einem Schritt perfekt machen; die Qualität steigt durch viele Iterationen. Die Gesamtqualität von Software wird durch die Menge dieser „Feedback-Loops“ bestimmt. Und die Zeit, die ein Loop dauert, begrenzt auch die Gesamtzahl der Iterationen. Letztlich ermöglicht höhere Produktionsgeschwindigkeit mehr Feedback-Loops, und dadurch entwickelt sich die Software zu etwas Besserem. Langsamer, aber hochwertiger Code hat seine Grenzen, wenn er nur eine einzige Iteration durchläuft; umgekehrt kann man selbst mit geringerer Qualität, aber unendlich vielen Iterationen, ein besseres Ergebnis erreichen.
  • In fünf Jahren dürfte sich das als eines der größten Beispiele für den Sunk-Cost-Fehlschluss der Welt herausstellen.
• Ich denke, statt „vibe coding“ wäre eine Bezeichnung wie „agentic coding“ oder „agentic software engineering“ passender. Mein Entwicklungsablauf beginnt mit einem Code-Plan von Claude, und im ersten Schritt erstelle ich immer eine klare Spezifikation. Ich nutze TDD und setze sogar selbst festgelegte versteckte Codequalitätsregeln mit Automatisierungstools durch. Wenn der Code zum Beispiel gegen das Design-System verstößt, lässt er sich nicht committen, und auch die Trennung der Schichten wird automatisch geprüft, damit HTTP-Handler zwingend über die Service-Layer laufen. Ich erinnere das Modell regelmäßig daran, TDD sauber einzuhalten; Claude 4.5 merkt sich das deutlich besser als 4.1. Dank des TDD-Ansatzes ist auch PR-Code-Review extrem einfach. Ich habe außerdem ein einfaches Tool gebaut, das PR und Spezifikation an Gemini übergibt, damit Diskrepanzen, Auslassungen und Fehler automatisch angemerkt werden. Ein gutes Backup-Tool. Aber letztlich entscheidend ist die Fähigkeit, selbst beurteilen zu können, welches Ergebnis man will und an welcher Stelle der Agent davon abweicht. Am Ende gilt: „Garbage in, garbage out“ beziehungsweise bei hochwertigem Input auch hochwertiger Output.
  • Du sagst, du erinnerst das Modell an TDD — mich würde interessieren, ob der Agent beim vibe coding tatsächlich wiederholt den TDD-Loop aus Red-Green-Refactor durchläuft oder ob er eher das Endergebnis in einem Rutsch ausspuckt.
  • Ich finde, statt vibe based wäre „slop-coding“ die passendere Bezeichnung.
• Ich bin unsicher, ob die Bezeichnung „vibe engineering“ wirklich passt. In der Praxis versieht man Agenten doch mit allen möglichen Einschränkungen: automatisierte Tests, Vorabplanung, detaillierte Dokumentation, Code-Formatierung/Linting, manuelles QA und so weiter. Ich habe nach dem Lesen von Karpathys Text ebenfalls mit vibe coding angefangen und zunächst diesen Ablauf erlebt, bei dem man dem Gesamtprozess vertraut und einfach mehrfach neu startet, wenn der Code hängen bleibt. Aber mit zunehmender Erfahrung wurde mir klar, dass man das Modell am Ende doch kontrollieren muss. Agentenbetrieb ähnelt Kart-Racing: Man braucht rund um die Strecke viele Begrenzungen wie Reifenstapel. Ein Constraint Harness ist der Kern, und der Code selbst lässt sich leicht generieren und regenerieren. Künftig wird es vor allem wichtig sein, gute Tests und gute Constraints für AI-Arbeitsergebnisse aufzubauen.
  • Der Begriff „vibe engineering“ wirkt zu leichtgewichtig und nicht besonders ernsthaft. Wäre ein neutralerer Begriff mit klarerer Funktion wie „LLM-assisted programming“ nicht besser? Weniger einprägsam vielleicht, aber treffender.
• „Vorabplanung“ könnte man auch spec-driven development nennen. Eigentlich basiert jede Entwicklung in gewissem Sinne auf einer Vorab-Spezifikation. Der eigentliche Kern ist aber eine „sehr seltsame Form des Managements“, also klare Anweisungen, ausreichend Kontext und umsetzbares Feedback. Als Text betrachtet wirkt das fast eher nach Waterfall als nach Agile.
• Inzwischen scheint sich der Begriff vibe-coding semantisch so verschoben zu haben, dass er AI-basiertes Coding insgesamt umfasst. Tatsächlich fühlt es sich für mich bei der Arbeit mit AI eher wie Pair Programming an, und ich denke oft: „Das ist wirklich vibing.“ Trotzdem wird das ursprüngliche vibe-coding im Sinne von „Take the wheel, LLama of God“, also dieses völlig unkritische Abgeben, wohl weiterhin häufig vorkommen, daher braucht es dafür vielleicht ein neues Wort. Ich würde „Yolo-Coding“ vorschlagen. Das passt auch gut zu no-code, low-code und yolo-code.
  • Ich finde es besser, wenn vibe coder ein negatives Image behält, ähnlich wie no-code. Der Ausdruck vibe engineer gefällt mir zwar auch nicht, aber ich glaube dennoch, dass die Bezeichnung Engineer/Entwickler künftig grundsätzlich den Einsatz von Agenten voraussetzen wird und „manuelle“ Entwickler eher die Ausnahme sein könnten.
  • Bei $enterprise suchten wir nach einer neuen Bezeichnung, um zwischen „responsible vibing“ und „YOLO vibe coding“ zu unterscheiden, und landeten schließlich bei dem Begriff „agent assisted coding“, schon allein weil wir unbedingt ein dreibuchstabiges Akronym brauchten.
  • Die ursprüngliche Bedeutung von „vibe coding“ war, wie Ilya Sutskever es auf Twitter gepostet hatte, einfach einen Prompt einzugeben und das Ergebnis ohne Review per Copy-and-Paste auszuführen — also ohne Analyse oder Verifikation.
  • AI-assisted coding bedeutet für mich persönlich eher Autocomplete oder Hilfe beim Lesen unfreundlicher Dokumentation. Vibe coding ist dagegen:
  • vom LLM geschriebener Code, den der Entwickler überhaupt nicht versteht
  • sofort entstehende technische Schulden ohne Code Review
  • rechtlich in EU/US wegen Copyright-Schutzproblemen völlig verwundbar Meiner Meinung nach ist der größte fatale Punkt beim vibe coding, dass von LLMs erzeugter Code im Kern nicht schutzfähig bzw. nicht urheberrechtlich registrierbar ist. Es gibt einige Ausnahmen wie Großbritannien, aber in den meisten Ländern sieht es schlecht aus.
  • Ich habe mir in Claude auch schon Slash-Befehle wie /yolo gebaut und sie einfach ohne große Anleitung ausgeführt.
• Es gibt ein Experiment, in dem Tauben mit einer Vorrichtung interagieren, die zufällig Futter ausgibt, und dann glauben, wegen ihres eigenen Verhaltens belohnt zu werden, woraufhin sie allerlei lustige Tänze und Bewegungen wiederholen.
  • Diese lustigen Tänze könnten möglicherweise genau so etwas wie „Tests schreiben“ oder „Pläne machen“ sein.
  • Gibt es dazu vielleicht eine Quelle oder ein Paper? Wenn man nach „tanzenden Tauben“ sucht, findet man fast nur Social-Media-Videos, daher ist das schwer zu finden.
• „Augmented Engineering“ (AE) klingt besser. Man kann seine Fähigkeiten mit der Kraft von AI erweitern und bessere Ergebnisse erzielen, also „Augmented Engineering“. AE ließe sich auch als „Advanced Engineering“ lesen. Da AI sofort Zugang zu aktuellem technischen Wissen verschafft, ist es natürlich auch fortgeschritteneres Engineering. Dagegen klingt vibe eher schlecht.
  • Man muss sich über Begriffe vielleicht gar nicht so viele Gedanken machen. Wenn man extra neue Namen vergibt, kann das sogar so wirken, als beträfe AI-Coding nur einen Teil der Entwickler. Künftig wird eher traditionelles Coding die Ausnahme sein, und der heutige Begriff vibe wird vermutlich sowieso verschwinden.
  • Dem letzten Satz würde ich widersprechen. AI kann nicht nur aktuelles Engineering-Wissen „sofort“ vermitteln, sondern ebenso die in den letzten ein bis zehn Jahren wiederholten Fehler, Irrtümer, Missverständnisse und Designmängel sofort mitübernehmen. Man darf den von AI gelieferten Informationen also niemals unkritisch vertrauen, muss Quellen immer prüfen und sogar kontrollieren, ob diese Quellen nicht wiederum von AI erzeugt wurden. Da Datensätze zunehmend kontaminiert werden, ist noch mehr Vorsicht geboten.
  • Ich würde fragen, ob „Augmented Engineering“ überhaupt einen eigenen Namen braucht. Eigentlich ist es einfach nur „Engineering“ — so wie man es auch nicht „book-assisted engineering“ nennt, nur weil man mit einem Nachschlagewerk arbeitet. Dasselbe gilt für vibe. Man könnte es genauso gut „Yolo engineering“ oder „Machine Outsourced Irresponsible LMAO Engineering“ nennen. Und auch „Advanced Engineering“ klingt eher nach Übertreibung.
• Simon trifft immer genau den Kern. Aber das eigentliche Problem ist weniger „coding“ als das Wort „vibe“. Selbst wenn man es zu vibe engineering erweitert, bleibt die Nuance, dass man einfach loslegt, ohne zu wissen, was man da tut. Ein Begriff wie „AI-assisted software engineering“, bei dem beide Enden klar voneinander abgegrenzt sind, wäre meiner Meinung nach deutlich besser.

[kimjoin2]

Sinnlose Bezeichnungen erfinden;