Vibe Coding 2026: Was die ETH-Studie wirklich über die Zukunft der Software-Entwicklung sagt

Am Vormittag des 4. Mai stellte die ETH Zürich eine Studie vor, die in der ersten Lektüre wie eine Trivialität wirkt: 100 Studierende lösten drei Programmieraufgaben — alle ausschließlich per Konversation mit einem LLM, ohne den generierten Code im Detail zu lesen. Die Forschenden um Sverrir Thorgeirsson, Theo Weidmann und Zhendong Su korrelierten die Ergebnisse mit allgemeinen kognitiven Fähigkeiten, Informatik-Vorwissen und Schreibkompetenz. Der Befund hat es in sich. Klassisches Informatik-Wissen ist der mit Abstand stärkste Prädiktor für erfolgreiches „Vibe Coding“, auch nach Kontrolle für allgemeine Intelligenz. Wer LLMs im Alltag häufig nutzt, schreibt schlechtere Essays und baut schlechtere Apps.

Die ETH-Studie ist nicht überraschend, weil sie etwas Neues entdeckt — sondern weil sie in einer Reihe empirischer Befunde steht, die das dominante Narrativ vom „Ende der Software-Entwicklung“ gerade systematisch unterspülen. Wer Strategie, Hiring und Org-Design für 2026 plant, sollte die Datenlage genau lesen.

Karpathys Tweet, der Karriere machte

Der Begriff „Vibe Coding“ stammt aus einem Tweet von Andrej Karpathy vom 2. Februar 2025. Sein Originalwortlaut: „There's a new kind of coding I call ‚vibe coding‘, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] I ‚Accept All‘ always, I don't read the diffs anymore. I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.“ Was oft unterschlagen wird, ist Karpathys Einschränkung: „It's not too bad for throwaway weekend projects.“ Der Mann selbst rahmte das Ganze ein Jahr später als „shower of thoughts throwaway tweet“.

Die Branche hat den Tweet trotzdem zur Doktrin erhoben. „Vibe Coding“ ist 2026 das Marketing-Versprechen einer ganzen Tool-Generation: Cursor 3 „Glass“, Claude Code, OpenAI Codex, GitHub Copilot, Hermes Agent, Claw Code. Das Versprechen: Programmieren wird vom Spezialwissen entkoppelt. Jeder kann mit der richtigen Prompt-Strategie funktionierende Software bauen. Die ETH-Studie ist die erste größere wissenschaftliche Untersuchung, die diese These empirisch testet — und sie liefert ein nuanciertes Gegenbild.

Was die Daten wirklich sagen

Die Datenlage der letzten 18 Monate ist erstaunlich konsistent. Die METR-Studie vom Juli 2025 — ein randomisierter kontrollierter Versuch mit 16 erfahrenen Open-Source-Entwicklern in großen Repositories — fand keinen Produktivitätsgewinn durch KI-Tools, sondern einen Verlust: minus 19 Prozent gegenüber der Kontrollgruppe ohne KI. Die Devs selbst glaubten nach dem Versuch, sie seien um 20 Prozent schneller gewesen. Die Wahrnehmung war exakt das Spiegelbild der Realität. METR aktualisierte die Studie im Februar 2026 mit 57 Devs und 800 Tasks; das Ergebnis: minus 4 Prozent Slowdown bei großem Konfidenzintervall (–15 % bis +9 %). Der Effekt ist also in der zweiten Generation der Tools kleiner geworden — aber kein klarer Produktivitätsgewinn.

GitClear hat über 153 Millionen Zeilen Code aus seinem Analytics-Backend ausgewertet. Code-Churn — also der Anteil Code, der innerhalb von zwei Wochen wieder gelöscht oder umgeschrieben wird — hat sich seit 2022 verdoppelt. Code-Reuse ist rückläufig, „Copy/Paste“ und „Added Code“ steigen, „Updated“, „Deleted“ und „Moved“ sinken. KI-Tools schreiben tendenziell neuen Code statt bestehende Bausteine wiederzuverwenden. Die DORA-Forschung 2024 von Google Cloud kommt zu einem ähnlichen Bild: 75 Prozent der Devs berichten subjektive Produktivitätsgewinne, aber objektiv sinken Delivery-Throughput um 1,5 Prozent und Stability um 7,2 Prozent.

Der jüngste Befund kommt vom Telemetrie-Anbieter Lightrun. Der „2026 State of AI-Powered Engineering Report“ vom April: 43 Prozent aller KI-generierten Code-Changes brauchen Production-Debugging, obwohl sie QA und Staging passieren. 88 Prozent der Teams brauchen zwei bis drei Redeploy-Zyklen, um einen KI-Fix zu verifizieren. 91 Prozent der KI-gebauten Apps haben kein brauchbares Security-Logging.

Und auf der kognitiven Seite: Die MIT-Media-Lab-Studie „Your Brain on ChatGPT“ (2025) zeigte über vier Monate, dass intensive LLM-Nutzer schwächere neuronale Konnektivität und geringere „Ownership“ ihrer Texte aufweisen. Die Forschenden tauften das Phänomen cognitive debt. Die ETH-Studie reiht sich exakt in dieses Muster ein.

Die Marktrealität: Layoffs, Junior-Krise, Tooling-Konsolidierung

Während die Studien Skepsis nahelegen, läuft am Arbeitsmarkt eine entgegengesetzte Dynamik. Im ersten Quartal 2026 verloren in der Tech-Branche knapp 80.000 Menschen ihre Stelle, fast die Hälfte davon mit expliziter KI-Begründung. Amazon strich rund 16.000 Corporate-Stellen, obwohl AWS um 24 Prozent wuchs. Meta entlässt 8.000 Personen. Microsoft schickt 8.750 in Voluntary Retirement. Oracle strich bis zu 30.000 Stellen, vor allem Legacy-DBA und On-Prem-Support. Salesforce baut 4.000 Customer-Support-Stellen ab.

Der härteste Befund liegt bei Junior-Entwicklerinnen und -Entwicklern: Die Beschäftigung in der Altersgruppe 22 bis 25 ist gegenüber dem Peak von Ende 2022 um 20 Prozent gefallen. Firmen, die früher zehn Hochschulabsolventen pro Jahr einstellten, nehmen heute zwei. Der Pragmatic-Engineer-Survey (n ≈ 1.000, Februar 2026) zeigt parallel: 95 Prozent nutzen KI-Tools mindestens wöchentlich, 75 Prozent für mindestens die Hälfte ihrer Arbeit, 70 Prozent nutzen zwei bis vier Tools parallel.

In diesem Tooling-Markt hat sich Anthropics Claude Code in acht Monaten von Null zur Spitze entwickelt — laut Pragmatic Engineer das meistgenutzte Tool 2026, vor Cursor und GitHub Copilot. Stripe rollte es auf 1.370 Engineers aus; ein Team migrierte 10.000 Zeilen Scala nach Java in vier Tagen, geschätzt waren zehn Engineering-Wochen. Wiz konvertierte 50.000 Zeilen Python nach Go in rund 20 Stunden aktiver Arbeit. Bei Ramp sank die Incident-Investigation-Zeit um 80 Prozent. Bei Rakuten verkürzte sich die Feature-Delivery von 24 auf fünf Arbeitstage.

Die Wahrheit liegt also nicht zwischen den Polen — sie liegt jenseits. Es gibt belegbare, wiederholbare Produktivitätsgewinne in spezifischen Aufgabenmustern (große Migrationen, Boilerplate, Test-Generierung, Code-Refactoring). Und es gibt belegbare Qualitätsverluste und Slowdowns in anderen Aufgabenmustern (komplexe Architektur, Debugging legacy Codes, Code-Reviews ohne erfahrenes Korrektiv).

Die Amazon-Lehre und der Aufstieg von Spec-Driven Development

Im März 2026 lieferte Amazon einen Praxistest. Am 2. März kam es zu einem Outage, der 120.000 Bestellungen verlor und 1,6 Millionen Fehler erzeugte. Drei Tage später ein zweiter, sechs Stunden dauernd, mit 99 Prozent Drop bei US-Bestellungen und rund 6,3 Millionen verlorenen Orders. Beide Vorfälle wurden auf KI-assistierte Code-Changes ohne ordentliches Approval zurückgeführt. Amazon legte daraufhin einen 90-Tage-Code-Safety-Reset über 335 kritische Systeme auf; KI-Changes brauchen seither Senior-Engineer-Approval.

Das ist die Kontur des Enterprise-Patterns 2026: Spec-Driven Development. AWS' eigenes Kiro-IDE-Team hat damit eine 18-monatige Rearchitektur in 76 Tagen mit sechs Personen abgewickelt. Statt „Vibe“ kommt eine maschinenlesbare Spezifikation, der Agent erzeugt Code, ein Senior-Engineer reviewt — die Trias bleibt. Auch der EU AI Act, ab 2. August 2026 für High-Risk-Systeme verpflichtend, drängt in diese Richtung: Auditierbarkeit, nicht improvisierte Generierung.

Was das für CEOs, PMs und Tech-Leads heißt

Drei Konsequenzen, scharf gestellt.

Erstens: Die Pipeline nicht abreißen lassen. Wer 2026 Junior-Stellen streicht, hat 2028 keine Senior-Engineers mehr, die KI-Code reviewen können. Der GitClear-Code-Churn und die Lightrun-Production-Debug-Quote sind das ökonomische Argument für ein Hiring-Modell, das Junior-Talente aktiv durch eine KI-Pipeline begleitet, statt sie wegzuoptimieren. IBMs Gegenstrategie — Verdreifachung der Entry-Level-Hires 2026 — ist ein Signal.

Zweitens: Spec-Driven statt Vibe-Driven, sobald die Codebase produktiv läuft. Vibe Coding bleibt das richtige Werkzeug für Throwaway-Prototypen, interne Tools und Wochenendprojekte. Für Production-Code mit Compliance-Anforderungen, Customer-facing Logik oder Sicherheitsauswirkungen braucht es eine maschinenlesbare Spezifikation, klare Approval-Gates und KI-Code als Produktionsfaktor mit Default-Deny-Vertrauen. Mitchell Hashimoto formulierte das Prinzip im April: „This is not an anti-AI stance. This is an anti-idiot stance.“

Drittens: Schreibkompetenz wird messbar wichtiger. Die ETH-Studie zeigt es klar: Wer präzise Spezifikationen formulieren kann, baut bessere Software mit LLMs. Hiring-Loops sollten Prompt-Qualität, technische Klarheit und Spec-Schreiben explizit prüfen — nicht nur LeetCode. Und Onboarding-Programme für Junior-Devs sollten bewusste Phasen ohne KI-Unterstützung enthalten, damit Fundamente überhaupt entstehen können.

Vibe Coding ist nicht das Ende der Software-Entwicklung. Es ist eine neue Schicht über einer Kompetenz, die wichtiger wird, nicht weniger wichtig. Die ETH-Studie macht das, was die Branche eigentlich längst hätte ablesen können, einfach nur empirisch sichtbar.