Collins Dictionary kürte „Vibe Coding" zum Wort des Jahres 2025. Ein Großteil unseres eigenen Codes entsteht heute mit Claude an unserer Seite — wir arbeiten täglich mit diesen Tools und wissen, wie viel sie beschleunigen. Genau deshalb lohnt ein nüchterner Blick: Was funktioniert wirklich gut, und wo beginnt die eigentliche Arbeit erst?
Was Vibe Coding tatsächlich ermöglicht
Im Februar 2025 prägte KI-Pionier Andrej Karpathy den Begriff Vibe Coding: Man beschreibt in natürlicher Sprache, was man will, und die KI generiert den Code. Was wie ein Gimmick klang, hat sich als echte Verschiebung erwiesen.
Die Ergebnisse sind real — und sie beeindrucken uns selbst immer wieder. Gründer:innen validieren Geschäftsideen mit funktionierenden Prototypen in Stunden statt Monaten. Einzelpersonen bauen Anwendungen, für die früher ein ganzes Team nötig war. Interne Tools, die nie ein Budget bekommen hätten, existieren plötzlich. Auch in unserer eigenen Arbeit merken wir den Unterschied: Tests, Dokumentation, Refactorings, Boilerplate — vieles läuft heute Hand in Hand mit einem Modell. Die Einstiegshürde in die Softwareentwicklung ist so niedrig wie nie.
Das ist kein Hype. Das ist eine reale Demokratisierung von Technologie, und sie verändert, wer Software bauen kann und wie schnell.
Wo die Arbeit anfängt
Spannend wird es nach unserer Erfahrung nicht beim Prototyp, sondern danach: wenn er in Produktion soll, wenn Nutzer:innen kommen, wenn sich Anforderungen ändern, wenn Sicherheit relevant wird.
Die METR-Studie (Juli 2025) lieferte dazu ein überraschendes Ergebnis: 16 erfahrene Open-Source-Entwickler:innen lösten 246 Aufgaben in ihren eigenen, komplexen Repositories. Mit KI-Tools waren sie 19 % langsamer, schätzten sich aber als 20 % schneller ein. Das klingt paradox, ergibt aber Sinn: Bei einfachen, isolierten Aufgaben beschleunigt KI. In gewachsenen Codebasen mit tausenden Abhängigkeiten erzeugt sie Mehrarbeit durch Prüfen, Korrigieren und Kontextverlust.
Wichtig: Das heißt nicht, dass KI-Tools Entwickler:innen grundsätzlich langsamer machen. Es heißt, dass der Kontext entscheidet. Ein neues Projekt auf der grünen Wiese profitiert enorm. Ein Legacy-System mit 500.000 Zeilen Code braucht menschliches Verständnis, das kein Sprachmodell mitbringt.
Die Harvard Business Review beschreibt in einer Studie von Ranganathan & Ye (rund 200 Tech-Mitarbeitende, neun Monate Feldbeobachtung) einen weiteren Effekt: KI reduziert Arbeit nicht, sie intensiviert sie. Entwickler:innen arbeiten parallel an mehreren Streams, prüfen ständig KI-Outputs, wechseln den Kontext. Sie fühlen Momentum und Produktivität, akkumulieren aber kognitive Überlast. Nach ein bis zwei Stunden ist die mentale Energie aufgebraucht, obwohl die messbare Produktivität hoch aussieht.
Sicherheit — der blinde Fleck
Wo die Datenlage eindeutig ist: Sicherheit.
CodeRabbit analysierte 470 Pull Requests und fand 1,7-fach mehr Probleme in KI-generiertem Code gegenüber menschlichem; bei bestimmten Schwachstellenklassen — Cross-Site-Scripting etwa — steigt der Faktor auf 2,74. Auf der Plattform Lovable waren 10,3 % von 1.645 untersuchten Showcase-Apps von einer kritischen Row-Level-Security-Lücke betroffen (CVE-2025-48757). Das sind keine Argumente gegen KI-Tools. Es sind Argumente dafür, ihren Output nicht ungeprüft in Produktion zu bringen.
Denn das Problem ist nicht die Generierung. Das Problem ist die fehlende Prüfung. KI schreibt Code, der funktioniert. Aber „funktioniert" und „sicher" sind zwei verschiedene Dinge.
Die versteckten Kosten
Ähnlich verhält es sich mit Wartbarkeit. GitClear analysierte 211 Millionen Codezeilen und beobachtete 2024 eine achtfache Zunahme von Code-Blöcken mit fünf oder mehr duplizierten Zeilen. Gleichzeitig sank der Anteil von Refactoring von 25 % (2021) auf unter 10 % (2024).
Die Informatikerin Margaret-Anne Storey beschreibt dieses Phänomen auf ihrem Blog — entstanden aus einem Austausch mit Martin Fowler — als „Cognitive Debt": Schulden, die nicht im Code leben, sondern in den Köpfen der Entwickler:innen. Selbst sauberer, funktionierender Code erzeugt Cognitive Debt, wenn ein Team nicht mehr artikulieren kann, warum er so gebaut ist, wie er ist.
Storey beschreibt ein Studententeam, das mit KI-Tools in den ersten Wochen beeindruckend schnell lieferte. In Woche sieben und acht brach die Velocity ein. Die erste Annahme: schlechter Code. Die Realität: Niemand im Team konnte mehr erklären, warum bestimmte Designentscheidungen so gefallen waren.
Simon Willison, einer der bekanntesten Befürworter von KI-Coding-Tools, beschreibt den gleichen Effekt an sich selbst: Er verliert bei eigenen Projekten den Überblick, wenn er ganze Features promptet, ohne die Implementierung wirklich zu prüfen. Nicht weil die Tools schlecht sind. Sondern weil Verstehen Arbeit ist, die sich nicht delegieren lässt.
Unser Take: Wer den generierten Code versteht und pflegt, hat kein Problem. Wer ihn durchwinkt, baut auf Sand. Die Tools sind besser denn je — die Disziplin muss mitwachsen.
Was wir selbst beobachten
Weil wir täglich mit diesen Tools arbeiten, kennen wir die Muster aus erster Hand. Die ersten Tage in einem neuen Projekt sind eine Offenbarung: Ideen werden zu lauffähigem Code, bevor die nächste Kaffeepause vorbei ist. Nach einigen Wochen kippt die Dynamik. Zusammenhänge werden weniger offensichtlich, und der Code fühlt sich fremder an, als er sein sollte. Diesen Bruch aktiv zu managen — durch Reviews, durch Pair-Sessions, durch bewusstes Langsamwerden — ist für uns Teil der Arbeit geworden.
In Gesprächen mit anderen Teams begegnet uns das gleiche Bild. Jemand Neues übernimmt ein Feature, das die KI gebaut hat, und versteht es nicht — nicht, weil es schlechter Code wäre, sondern weil niemand ihn wirklich geschrieben hat. Die Geschwindigkeit von gestern wird zur Bremse von morgen, sobald sich etwas ändern soll.
In Organisationen ohne eigenes Entwicklungsteam sehen wir ein verwandtes Muster. Der erste Prototyp beeindruckt, oft innerhalb einer Woche. Taucht dann eine Datenschutzfrage auf oder muss die App angepasst werden, steht jemand mit einem System da, das niemand im Haus wirklich kennt. Der Prototyp war der einfache Teil.
Und die Frage, die wir am häufigsten hören: „Wir wollen KI-Tools einführen — aber wie?" Der Wille ist da, die Erwartungen sind hoch. Was fehlt, ist selten die Technologie. Es ist der Rahmen: Welches Tool passt zum eigenen Stack? Wer prüft den Output? Wer trägt die Verantwortung, wenn eine Schwachstelle durchrutscht?
Worum es eigentlich geht
Vibe Coding ist keine Modeerscheinung und wird nicht verschwinden. Im Gegenteil: Gartner prognostiziert, dass bis 2028 rund 90 % aller Enterprise-Entwickler:innen KI-Assistenten nutzen werden. Wir selbst gehören längst dazu. Die Frage war nie „KI ja oder nein". Die Frage ist: Wie setzt man diese Tools so ein, dass der Geschwindigkeitsgewinn nicht durch Sicherheitslücken, technische Schulden oder Wartungskosten aufgefressen wird?
Die Antwort ist nicht „mehr Vorsicht" oder „weniger KI". Die Antwort ist Kompetenz. Wer versteht, was die Tools generieren, nutzt sie als Multiplikator. Wer es nicht versteht, multipliziert Risiken. So halten wir es auch selbst: KI als Beschleuniger, menschliche Expertise als Steuerung.
Karpathy selbst brachte es Anfang 2026 auf den Punkt, als er Vibe Coding für überholt erklärte und stattdessen von „Agentic Engineering" sprach. Betonung auf Engineering.
„'Agentic', because the new default is that you are not writing the code directly 99 % of the time — you are orchestrating agents who do, and acting as oversight. 'Engineering', to emphasize that there is an art, a science, and expertise to it."
— Andrej Karpathy, Januar 2026
Quellen: METR-Studie (2025), GitClear AI Code Quality Research 2025, Veracode GenAI Code Security Report 2025, CodeRabbit: State of AI vs Human Code Generation, Storey: Cognitive Debt (2026), Fowler: Fragment zu Cognitive Debt, Simon Willison: Vibe Engineering, Ranganathan & Ye / HBR (2026), Gartner Software Engineering Trends (2025), CVE-2025-48757 / Lovable RLS, Karpathy: Vibe Coding (Feb 2025).