Ein Turm voller Mängel, Vibe-Übelkeit und der Vibe-Bob

• Während sich eine Entwicklungsweise verbreitet, bei der Menschen von LLMs erzeugten Code nicht verstehen und dessen Auslegung wieder dem LLM überlassen, verschwimmt die einst klare Grenze zwischen Agentic Engineering und Vibe Coding schnell
• Vibe-Bob bezeichnet einen vorgezeichneten Pfad von Autovervollständigung über Codegenerierung bis zum Verzicht auf Review und schließlich auf Prompts; je mehr man die Generierungsgeschwindigkeit nutzt, desto weiter entfernt man sich von Theoriebildung und Review, den Kernaufgaben von Programmierern
• Im Pvote-Experiment fanden Sicherheitsexperten trotz Kenntnis der Fundstelle nach rund 20 Stunden Review von 100 Zeilen Code den schwierigen von drei Bugs nicht, was zeigt, dass die Annahme unrealistisch ist, Menschen könnten große Mengen an LLM-Ausgabe vollständig prüfen
• Vibe-Übelkeit, bei der unverstandener Code und andere generierte Artefakte in Restaurantpostern, Kundensupport-Chatbots, Altersverifikationscode sowie Open-Source-Issues und PRs eindringen, breitet sich aus; selbst Menschen, die die Tools nicht nutzen, sind betroffen, weil sie die Artefakte anderer prüfen müssen
• Generative KI kann beim Entdecken von Problemen nützlich sein, ist aber besonders schwach bei der Erzeugung; selbst wenn unverständliche Systeme die Welt ersetzen, dürfen Menschen nicht auch noch die Fähigkeit aufgeben, selbst eine bessere Umgebung zu schaffen

---

Der Turm aus unverständlichem Code

• The Tower Keeps Rising beobachtet einen Zustand, in dem man mithilfe von Agenten weiter vorankommt, selbst in Situationen, die früher nur durch Gespräche im Team lösbar gewesen wären
  • Armin bewertet das weder als gut noch als schlecht und verteidigt es auch nicht als nachhaltigen Zustand
  • Er befindet sich jedoch in der Position, diesen Trend voranzutreiben, da er ein Vibe-Coding-Unternehmen betreibt
• Vibe-Coding-Systeme schichten immer weiter Code und Abstraktionen übereinander, bis sie schließlich einen Zustand erreichen können, in dem kein Mensch mehr die Codebasis versteht
  • Selbst Teile, die Menschen nicht verstehen, können wieder von LLMs interpretiert werden, wodurch eine neue Betriebsweise entsteht, in der die Entwicklung weitergehen kann
• Selbst Befürworter erkennen inzwischen diesen Endpunkt an, an dem Menschen das System nicht mehr verstehen, und akzeptieren ihn als künftige Form der Entwicklung

Der Zusammenbruch der Grenze zwischen Agentic Engineering und Vibe Coding

• Simon Willison trennte Agentic Engineering anfangs klar von Vibe Coding
  • In einem Beitrag vom März 2025 formulierte er das Prinzip, dass man bei KI-unterstützter Programmierung in Produktionsqualität jeden Code, der ins Repository committet wird, lesen und einer anderen Person präzise erklären können müsse
  • Selbst wenn der Code von einem LLM geschrieben wurde, sei es nicht Vibe Coding, sondern Softwareentwicklung, solange ein Mensch ihn prüft, gründlich testet und seine Funktionsweise erklären kann
• Etwa ein Jahr später schrieb er in Vibe coding and agentic engineering are getting closer than I’d like, dass mit steigender Zuverlässigkeit von Coding-Agenten sogar Produktionscode nicht mehr Zeile für Zeile geprüft werde
  • Er vertraut darauf, dass Claude Code einen API-Endpunkt korrekt erstellt, der SQL-Abfragen ausführt und JSON zurückgibt, und außerdem Tests und Dokumentation ergänzt
  • Zugleich empfindet er Schuldgefühle und Zweifel, ob es verantwortungsvoll ist, ungeprüften Code in Produktion zu verwenden
• Zwischen diesen beiden Positionen liegt kaum mehr als ein Jahr
• Obwohl sich weithin die Auffassung verbreitet hat, Agentic Engineering sei die wünschenswerte Nutzungsform, zeigt sich in der Praxis, dass Nutzer einschließlich Simon selbst eher in Richtung Vibe Coding gezogen werden

Vibe-Bob

• Bob ist ein Sport, bei dem man eine Eisbahn schnell hinunterfährt, aber faktisch nur eine Richtung hat
  • Die Athleten können ihre Fertigkeit messen und den Nervenkitzel genießen, aber die Fahrgäste haben kaum Spielraum, die Reise selbst zu wählen
• Beim Vibe-Bob ist das LLM das Fahrzeug und der Nutzer der Passagier
  • Die tatsächliche Kontrolle ist weit geringer, als es sich für den Nutzer anfühlt; es ist weniger ein rutschiger Hang als vielmehr eine im Voraus angelegte Reise
• Entwickler entfernen sich in den folgenden Schritten selbst aus dem Prozess der Codeerzeugung
  • Zunächst glauben sie, das System nur als fortgeschrittene Autovervollständigung zu nutzen
  • Danach starten sie einen Agenten zur Ideenfindung, wollen den Code aber noch selbst schreiben
  • Anschließend lässt man den Agenten Code erzeugen, nimmt sich jedoch vor, alle Ergebnisse zu prüfen
  • Bald prüft man den Code kaum noch und glaubt, der Agent könnte ein besserer Entwickler sein als man selbst
  • Am Ende kann man über „ich programmiere nicht mehr“ hinaus zu der Phase gelangen, in der man „nicht einmal mehr Prompts schreibt“
• Jeder Schritt ist ein Übergang zu vertrauensbasierter Codeerzeugung, bei der man davon ausgeht, dass das LLM die eigene Arbeit versteht und gut erledigt

Der Konflikt zwischen Generierungsgeschwindigkeit und Review

• Der langsame Teil beim Programmieren ist nicht die Erzeugung, sondern Theoriebildung und Review; plausibel wirkende, aber falsche Ergebnisse sind extrem schwer zu debuggen und zu verstehen
• Die stärkste Eigenschaft von LLMs ist ihre Generierungsgeschwindigkeit; wenn Menschen alle Ergebnisse prüfen, lässt sich diese Geschwindigkeit nur schwer voll ausnutzen
• Gleichzeitig sind Theoriebildung und Review die wichtigsten Aufgaben von Programmierern, sodass ein Konflikt entsteht: Je stärker man die Vorteile von LLMs maximiert, desto weiter entfernt man sich von der Kernrolle
• Ka-Ping Yees Arbeit Building Reliable Voting Machine Software nennt vier Faktoren, die Softwareverifikation erschweren
  • die Anzahl der Komponenten
  • komplexe Interaktionen
  • weitreichende Auswirkungen
  • Nichtlinearität
• Diese vier Probleme können durch die Art und Weise, wie LLMs Code erzeugen, noch verschärft werden

Das Pvote-Bug-Review-Experiment

• Ka-Ping Yee und David Wagner fügten dem Modellwahlgerät Pvote jeweils einen einfachen, einen mittleren und einen schwierigen Bug ein, die zur Manipulation von Wahlergebnissen ausgenutzt werden konnten
• Alle drei Bugs wurden in einem Bereich von 100 Zeilen platziert, nämlich in den Zeilen 11 bis 109 von Navigator.py
  • Das war eine Wahl, die sowohl den logisch interessanten Teil des Programms als auch die begrenzte Zeit der Reviewer berücksichtigte
  • Den Reviewern wurde gesagt, welchen Bereich sie untersuchen sollten, nicht aber, wie viele Bugs es gab
• Die Ergebnisse des dritten Tages waren wie folgt
  • Dan Sandler, der sehr erfahren mit Python war, fand den einfachen und den mittleren Bug in etwa 70 Minuten
  • Yoshi Kohno und Mark Miller fanden den einfachen Bug nach etwa 4 Stunden
  • Den schwierigen Bug fand niemand
• Am vierten Tag fand Ian Goldberg den einfachen Bug in etwa 2 Stunden, entdeckte aber keine weiteren Bugs
• Erfahrene Sicherheitsexperten kannten also sogar die Position und investierten insgesamt rund 20 Reviewer-Stunden, fanden aber dennoch nicht alle drei Bugs
• Mark S. Miller war später überrascht, dass nach der Bestätigung der Bugs alle zustimmten, es handle sich um offensichtliche Fehler, die sie hätten finden müssen
• Wenn selbst Spitzenprogrammierer Bugs übersehen, die garantiert in 100 Zeilen vorhanden sind, ist ein Ansatz, bei dem Menschen die gewaltige Ausgabe von LLMs prüfen sollen, kaum tragfähig
  • Letztlich geben Nutzer das Review auf und entfernen sich schrittweise selbst aus dem Prozess der Codeerzeugung

AI-Psychose und Vibe-Übelkeit

• „AI psychosis“ wird breit als Begriff für schlechtes Verhalten oder schlechte Ergebnisse durch generative KI verwendet, bezeichnete ursprünglich aber eher einen Zustand, in dem Nutzer durch übermäßig bestätigende Chatbots in echte Psychosen und wahnhafte Realitätsabkehr geraten
• Für das breite Unbehagen, das generative KI jenseits klinischer Psychosen auslöst, passt Vibe-Übelkeit (vibe sickness) besser
• In Glyphs PyCon US 2026 Rückblick treten folgende Situationen gleichzeitig auf
  • weit verbreitete Vibe-Übelkeit
  • eine groß angelegte Nachhaltigkeitskrise in Open Source
  • eine Flut minderwertiger Security-PRs
  • Hoffnung, Energie und Mühe für gegenseitiges Verständnis sowie Wertschätzung für die Arbeit

Generierte Artefakte im Alltag und in Open Source

• Menschen beklagen Slop, also minderwertige generierte Artefakte, aber Nutzer generativer KI nennen ihre eigenen Ergebnisse nicht Slop
• Plausibel wirkende, aber unverständliche Artefakte tauchen überall im Alltag auf
  • Poster lokaler Restaurants mit schwer verständlichem Design
  • Kundensupport-Chatbots, die Nutzer frustrieren
  • Altersverifikationscode
  • minderwertige Issues und PRs, die in Open-Source-Projekte eingereicht werden
• Solche Tools sind für manche Aufgaben nützlich und bei der Problemerkennung womöglich anders zu bewerten
• Doch gerade die Generierung, die schon der Name „genAI“ betont, ist ausgerechnet der Bereich, in dem die Tools am schlechtesten sind
  • Das Problem ist nicht nur die Qualität der Artefakte, sondern auch, dass niemand mehr versteht, wie die Systeme aufgebaut, strukturiert und gewartet werden

Eine Umgebung, der man mit generativer KI nicht entkommt

• Selbst wenn man generative KI nicht direkt nutzt, können Kollegen oder Open-Source-Beitragende „Beiträge“ einsenden, deren generierte Artefakte sie selbst nicht verstehen
  • Reviewer müssen sich fragen, ob es unhöflich wäre, nach einer LLM-Herkunft zu fragen
  • Während sie auf Issues oder PRs antworten, interagieren sie indirekt mit Agenten und geraten unbeabsichtigt in einen Vibe-Coding-Workflow
• Glyph vergleicht die Ablehnung aller Software mit LLMs mit dem Versuch, gegen verbleites Benzin im Auto zu protestieren, indem man die Luft anhält, bis alle anderen ebenfalls aufhören, es zu benutzen
  • Realistisch gesehen muss man es bis zu einem gewissen Grad hinnehmen; selbst wenn man persönliche ethische Grenzen zieht, bedeutet das noch keine Erwartung oder Begeisterung gegenüber einer generativen-KI-Umgebung
• Das Uncanny Valley besetzt die reale Welt, und Systeme, die niemand versteht, ersetzen die bestehende Welt
• Welche Kosten die Erholung aus diesem Zustand haben wird, ist noch nicht absehbar; Projekte, die sich bewusst gegen eine Beteiligung an der heutigen generativen KI entscheiden, verdienen Respekt

Die Entscheidung, ein besseres Terrain zu schaffen

• Aufgrund von Arbeit oder Umfeld ist es womöglich nicht möglich, die Mitwirkung an Problemen durch generative KI vollständig zu verweigern
• Auch wenn Autofahrer sich über Radfahrende auf der Straße ärgern, sind diese bei schlechter Fahrradinfrastruktur durch parkende Autotüren oder ungeduldige Fahrer gefährdet
• Wenn beim Fahren ein Fahrrad vor einem ist, kann man für dessen Anwesenheit dankbar sein und darüber nachdenken, wie sich Terrain und Infrastruktur so verändern lassen, dass Fahrräder sicherer teilnehmen können
  • Solche Veränderungen machen auch das Autofahren einfacher und je nach Situation auch die Entscheidung für das Fahrrad leichter
• Man sollte den Glauben nicht aufgeben, dass Menschen direkt an einer besseren Welt mitwirken können, statt sich dem von Technologie vorgegebenen Pfad zu überlassen

[GN⁺]

Kommentare auf Lobste.rs

• Einer der mit Abstand besten Texte über die Veränderungen in der Software-Engineering-Branche, die ich in letzter Zeit mit Sorge beobachte.

• Noch vor einem Jahr wirkte agentisches Engineering wie die wünschenswerte Richtung, aber die meisten tatsächlichen Tool-Nutzer scheinen sich, auch wenn sie es nur ungern zugeben, in Richtung Vibe Coding zu bewegen. Die Angst, dass LLMs meine Fähigkeiten und meine Leidenschaft entwerten könnten, ist stark zurückgegangen, seit ich mir zwei Grundsätze gesetzt habe.
  Erstens nutze ich in meiner Freizeit weder LLMs noch Coding Agents und lehne auch AI-Funktionen in Suchmaschinen ab. Nur wenn ich so dringend feststecke, dass ich es selbst nicht lösen kann, nehme ich das Risiko von Halluzinationen in Kauf und nutze sie. Die Welt löst ihre Probleme nicht dadurch, dass man die Technologie ignoriert, aber da ich weder einzelne Entwickler angreifen noch große Konzerne verändern kann, ist es eine realistisch mögliche Entscheidung, sie wenigstens nicht in meine Freizeit hineinzulassen.
  Zweitens nutze ich AI selbst an einem Arbeitsplatz, an dem ihr Einsatz stark empfohlen wird, nur für Code Reviews und Botengänge. Also höchstens, um Dinge zu erfragen, die ich zwar direkt in der Codebase finden könnte, die aber mühsam zu suchen sind; den Code schreibe ich komplett selbst. Nur so verstehe ich intuitiv, wie er funktioniert, und kann auf dem Niveau arbeiten, das ich selbst und meine Kollegen erwarten.
  Als Hilfsmittel, das musterbasierte Fehler findet, die deterministische Linter nicht entdecken, sind LLMs in Ordnung. Sie liefern zwar auch unsinnige Antworten, aber weil ich den Code selbst schreibe und verstehe, vertraue ich ihnen nicht blind. Wenn sie vor dem menschlichen Review offensichtliche Logikfehler und falsche Annahmen herausfiltern, können sich Kollegen auf die komplexeren Teile konzentrieren, und man vermeidet auch die Unhöflichkeit, in öffentlichen Kanälen Maschinen statt Menschen miteinander reden zu lassen.
  Kürzlich hat mein Unternehmen die Token-Nutzung streng begrenzt, aber da mein Workflow nur ein bis zwei Euro pro Tag kostet, mache ich mir keine Sorgen. Wer sich vollständig auf sein Bauchgefühl verlassen hat, ist vielleicht verunsichert, wieder menschliches Schlussfolgern einsetzen zu müssen, aber der Rest kann es direkt mit den Kollegen erledigen.

  • Die Kritik „Löst es denn etwas, den Kopf in den Sand zu stecken?“ richtet man dabei nicht wirklich an einen Dritten, sondern stellvertretend an einen eingebildeten Kritiker gegen sich selbst. Je mehr man seine Entscheidungen an solcher Kritik ausrichtet, desto schlechter wird das Leben; deshalb versuche ich selbst, darauf zu achten.
    Dahinter steckt auch eine selbstquälerische Erkenntnistheorie, nach der man der Wahrheit umso mehr ins Auge sehen müsse, je schmerzhafter sie ist. Es kann sich tugendlos anfühlen, belastende Informationen zu meiden, aber Aufmerksamkeit ist begrenzt; besser ist es, sie für Dinge einzusetzen, die einen glücklicher und erfüllter machen und einem die Kraft geben, morgen weiterzumachen.
  • Das ist weniger „den Kopf in den Sand stecken“ als vielmehr „Ich mag Büroarbeit nicht, also meide ich in meiner Freizeit Büros“. Wenn man unangenehme Dinge vermeiden kann, ist es vernünftig, sie zu vermeiden.
    Wer alles im Leben optimiert und wie Arbeit behandelt, in der man der Beste sein muss, schadet sich eher selbst. Wenn man gern programmiert, kann man es auch in der Freizeit tun; wenn nicht, kann es einfach der Beruf bleiben. In der Freizeit darf man manchmal ruhig ineffizient sein; sonst wird die freie Zeit zum zweiten Job, und man erholt sich überhaupt nicht.

• Dass hier Fawlty falsch geschrieben ist, stört mich übermäßig.

  • Ich vermute, das ist Absicht, als Wortspiel mit einem „fehlerhaften“ Turmbau zu Babel.

• Der Text ist, wie immer, ausgezeichnet, aber ich glaube nicht, dass man sich Sorgen machen muss, ob es unhöflich wäre zu fragen, ob etwas von einem LLM erzeugt wurde. Unabhängig davon, ob im Entstehungsprozess ein LLM verwendet wurde, kann man sagen, dass ein miserables Ergebnis schlechte Qualität hat und einem nicht gefällt.

  • Bei einem unbekannten neuen Contributor ist es sinnvoll, die Qualitätsprobleme des PRs anzusprechen und die Verantwortung für die Korrektur zurückzugeben. Ich erinnere mich allerdings, dass das Zig-Projekt eine Anti-AI-Policy eingeführt hatte, weil es neue Contributor zu langfristigen Mitwirkenden entwickeln wollte, indem echte Menschen sie anleiten, nicht LLMs.
    Bei Kollegen oder Menschen, mit denen man online schon lange zu tun hat, möchte man dagegen vielleicht möglichst unhöflich wirkendes Verhalten vermeiden, um die Beziehung zu erhalten. Man muss wissen, wie der Beitrag entstanden ist, um darüber sprechen zu können, und das Ergebnis kann die Beziehung absichtlich stark beeinflussen. Ob man das Risiko eingeht, unhöflich zu wirken, oder ob man grundsätzlich Konflikte meidet und die Beziehung bewahrt, ist eine Frage der eigenen Neigung.
    Da ich selbst eher konfliktscheu bin, verstehe ich, woher dieser Satz kommt, und widerspreche der eigentlichen Aussage auch nicht wesentlich.

• Mir gefällt die Bobsleigh-Analogie. Ich stimme nicht zu, dass LLM-Nutzer zwangsläufig bis ganz nach unten fahren, aber sie beschreibt das Verhalten, das man in der Branche beobachten kann, besser als jede andere Analogie, die ich bisher gesehen habe.

• Die „Bobsleigh-Analogie“ ist besser bekannt als der logische Fehlschluss der schiefen Ebene. Vor einem Jahr lag der Anteil von Vibe Coding bei 0 %, und Simon Willison hat in mehreren Beiträgen öffentlich beschrieben, wie er Coding Agents vorsichtig einführt und ihnen nach und nach mehr Vertrauen schenkt.
  Daraus wird dann aber geschlossen: „Es gibt nur einen Weg, und der führt nach unten.“ Plausibler ist, Willison und anderen Nutzern ebenfalls Geschmack und Urteilsvermögen zuzugestehen.