Skip to main content
AI Tool Radar
Deep Dives

Vibe Coding ist eine Lüge. Wofür Senior Engineers Claude Code wirklich benutzen

Der 'Vibe Coding' Pitch lässt es aussehen, als würdest du ein Gefühl beschreiben und eine App erscheint. Karpathys ursprüngliche Formulierung war halb im Scherz. Die Produktivitätsdaten, die seitdem kamen, sind ernüchternder als Befürworter wie Skeptiker erwarteten.

7 min read2026-04-19Von Roland Hentschel
claude codevibe codingki codingengineeringworkflow

Woher der Begriff wirklich kommt#

"Vibe Coding" wurde von Andrej Karpathy in einem Tweet am 2. Februar 2025 geprägt. Der volle Post ist lesenswert, weil er sich stark von dem unterscheidet, wie der Begriff in den zwölf Monaten danach genutzt wurde:

"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. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper..."

Quelle: Andrej Karpathy auf X, 2. Feb 2025.

Karpathy beschrieb spielerisch seine persönliche Erfahrung bei Wochenendprojekten. Innerhalb von Wochen wurde der Begriff von einer Welle aus Tutorials, YouTube-Kanälen und TikToks aufgesogen, die auf einem stärkeren Claim aufbauten: dass du den Code nicht mehr verstehen musst, die KI erledigt alles, du beschreibst, was die App fühlen soll, und shippst.

Dieser stärkere Claim ist der, den ich hier zerlegen will, weil die Evidenz, die seit Karpathys Tweet kam, auf interessante Weise dagegen läuft.

Die Produktivitätsdaten, die alle überraschten#

Im Juli 2025 veröffentlichte METR (das Model Evaluation and Threat Research Non-Profit) die erste gut designte randomisierte kontrollierte Studie zu KI-Coding-Tools und erfahrenen Entwicklern. Die Studie ließ 16 erfahrene Open-Source-Entwickler 246 echte Aufgaben in reifen Projekten abarbeiten, an denen sie im Schnitt seit fünf Jahren arbeiteten. Eingesetzte Tools: Cursor Pro mit Claude 3.5/3.7 Sonnet.

Das Ergebnis: Entwickler waren mit KI-Tools 19% langsamer als ohne. Sie hatten vor der Studie vorhergesagt, 24% schneller zu sein, und schätzten danach, dass sie 20% schneller waren. Die Realität war das Gegenteil. Paper: arXiv 2507.09089; Studien-Aufbereitung: metr.org.

Dieses Ergebnis ist nicht die ganze Geschichte. Frühere Feldexperimente zu GitHub Copilot (GitHub/MIT/Microsoft/Accenture) fanden, dass Junior-Entwickler sich um rund 35-39% beschleunigen, Senior-Entwickler um 8-16%. Paper: MIT Copilot-Studie.

Zusammengenommen zeichnet sich ab:

  • Junior-Entwickler profitieren am meisten von KI-Coding-Tools.
  • Senior-Entwickler profitieren bei allgemeinen Aufgaben weniger, und in reifen Codebases, die sie schon gut kennen, können sie tatsächlich langsamer werden.
  • Selbstwahrnehmung der Produktivität ist konstant höher als gemessene Produktivität. Entwickler fühlen sich schneller, auch wenn sie es nicht sind.

Das ist nicht, was der Vibe-Coding-Pitch vorhersagte. Der Pitch war, dass KI-Coding-Tools den Unterschied zwischen Junior und Senior einebnen oder umkehren würden. Die Daten sagen das Gegenteil: Für Leute, die wissen, was sie tun, in einer Codebase, die sie kennen, sind die Tools bestenfalls eine moderate Hilfe und schlimmstenfalls eine aktive Bremse bei bestimmten Aufgaben.

Wofür Senior Engineers diese Tools wirklich nutzen#

Gegeben diese Daten wird die Frage: Wo zahlen sich Claude Code, Cursor und ähnliche Tools für erfahrene Engineers aus?

Ich nutze Claude Code seit einem Jahr als Teil meiner eigenen Arbeit, und basierend auf Gesprächen mit anderen Senior Engineers zeichnet sich ein Muster ab, das weniger glamourös als das Marketing, aber ehrlicher ist.

Die größten Gewinne liegen im langweiligen Mittel-Layer:

  • Scaffolding neuer Module oder Test-Harness aus einer Spec.
  • Mechanische Refactors über viele Dateien, wo das Muster klar, aber mühsam ist: Umbenennungen, Signatur-Änderungen, Null-Handling-Ergänzungen.
  • Tests aus existierendem Code schreiben.
  • Übersetzung zwischen ähnlichen Frameworks oder Sprachen.
  • Eine unbekannte Codebase explorieren, um spezifische Fragen zu beantworten.

Das sind die Aufgaben, bei denen meine eigene Erfahrung mit der Richtung der GitHub-Feldstudie übereinstimmt: echte Beschleunigung, begrenztes Risiko, dass das Modell die falsche Art Sache produziert. Es sind auch die Aufgaben, die früher unverhältnismäßig viel Zeit in einer Woche fraßen.

Die kleineren, schwereren Gewinne liegen bei wirklich neuartiger Arbeit, wo das Modell weniger als Coder und mehr als interaktive Gummiente funktioniert: etwas, mit dem man argumentiert, während man die Architektur herausfindet. Das ist echter Wert, aber schwer zu messen.

Die Fälle, in denen die Tools unterperformen oder dich bremsen:

  • Tiefes Debugging eines subtilen Bugs in einem System, das du schon kennst. Das Modell generiert plausibel aussehende falsche Fixes schneller als richtige.
  • Arbeit, die viel impliziten Codebase-Kontext im Kopf voraussetzt. Das Modell teilt dein mentales Modell nicht, und genug davon zu erklären, um das Modell nützlich zu machen, kann mehr Zeit kosten, als die Arbeit selbst zu tun.
  • Hochriskante Berührungen von Auth-, Billing-, Datenschicht-Code, wo jede Zeile richtig und reviewt sein muss.

Das ist die Form des METR-Ergebnisses, in gelebte Erfahrung übersetzt. Das Modell ist ein Hebelwerkzeug, das deinen Input verstärkt. Wenn dein Input ein Junior-großes Verständnis ist, verstärkt es das in einen spürbaren Produktivitätsgewinn. Wenn dein Input ein Senior-großes Verständnis einer spezifischen Codebase ist, funktioniert die Verstärkung weniger gut, weil der Engpass nie das Tippen war.

Gewohnheiten, die wirklich zählen#

Ein paar Beobachtungen dazu, wie ich und andere Senior Engineers diese Tools effektiv nutzen, unterschieden vom Vibe-Coding-Framing.

Lies den Code. Ich lese jede Zeile, die das Modell schreibt und in mein Repo geht. Nicht aus Misstrauen. Nach einem Jahr Claude Code Nutzung weiß ich grob, wo es zuverlässig ist. Ich lese, weil ich wissen muss, was das System tut, aus demselben Grund, aus dem ich Pull Requests von Kollegen reviewe. Nicht zu lesen heißt, mein mentales Modell des Systems zu verlieren.

Scope ist immer noch eine Fähigkeit. Der größte Differenzierer zwischen Senior und Junior bei diesen Tools ist Scope-Management. Das Modell zu viel auf einmal tun zu lassen produziert Output, der schwerer zu reviewen als selbst zu schreiben wäre. Senior-Nutzer zerlegen Arbeit in Stücke, die das Modell gut handhabt.

Mehr Tests, nicht weniger. Günstige Test-Generierung ist eine der wertvollsten Fähigkeiten dieser Tools. Claude Code um Tests zu bitten ist billig, und die Tests sind, wie ich weiß, dass der generierte Code das tut, was ich beabsichtigte. Das ist einer der Orte, wo der Produktivitätsgewinn für mich real und messbar ist.

Ownership verschiebt sich nicht. Das Modell schreibt den Code. Ich shippe den Code. Was ins Repo geht, ist meine Verantwortung. Die "die KI hat's gemacht" Ausrede existiert in keiner Codebase, in der ich arbeiten will.

Was das für die Hype-Kurve bedeutet#

Cursor schloss eine Series D bei 29,3 Milliarden Dollar Bewertung im November 2025 (CNBC-Bericht), mit Berichten im April 2026 über weitere Finanzierungs-Verhandlungen bei höherer Bewertung. Anthropic launchte Claude Code als Preview im Februar 2025 und General Available im Mai 2025 mit Claude 4, mit Web-Version im Oktober 2025.

Das sind keine kleinen Produkte. Sie sind echte Geschäfte mit echten Nutzern, die echte Arbeit produzieren. Was sie nicht sind, ist ein Ersatz für Engineering-Urteil. Das METR-Ergebnis ist die erste rigorose Messung dessen, was passiert, wenn KI-Coding-Tools in den Workflow erfahrener Engineers in reifen Codebases kommen, und die Antwort ist: der Effekt ist gemischt und kontextabhängig. Das ist ein nützliches Ergebnis, und es argumentiert gegen beide Extreme der Debatte.

Das Vibe-Coding-Framing in seiner stärkeren Form lag bei Senior-Arbeit immer falsch. Die Daten holen jetzt ein, was Praktiker bemerkten. Die Tools sind nützlich, manchmal dramatisch so, für bestimmte Arten Arbeit. Sie sind kein universelles Lösungsmittel für Softwareentwicklung, und besonders kein Shortcut um das Verständnis, das Engineering überhaupt erst funktionieren lässt.

Weiterlesen#

Quellen#


Roland Hentschel

Roland Hentschel

AI & Web Technology Expert

Web developer and AI enthusiast helping businesses navigate the rapidly evolving landscape of AI tools. Testing and comparing tools so you don't have to.

Tools aus diesem Beitrag

Weitere Beiträge aus dem Blog