Agentic Coding heißt: Ein Agent wie Claude plant, schreibt und testet Code über mehrere Schritte selbstständig, du gibst nur Ziel und Guardrails vor. Der entscheidende Unterschied zu Vibe Coding liegt im Review: Bei Vibe Coding liest kaum jemand mehr den Diff, bei Agentic Coding bleibt der Mensch am Ende verantwortlich. Klassisches Programmieren kennt beide Rollenmodelle nicht.
Der Begriff ist neu, das Problem dahinter nicht: Andrej Karpathy hat "Vibe Coding" im Februar 2025 geprägt, ein Jahr später steht ihm "Agentic Engineering" als Gegenmodell gegenüber. Für CTOs und Heads of Engineering entscheidet genau diese Unterscheidung gerade jedes Team-Setup: Wie viel Kontrolle gibst du ab, und wo holst du sie dir zurück?
Agentic Coding, Vibe Coding, klassisches Programmieren: Was ist da eigentlich der Unterschied?
Der Unterschied liegt nicht im Tool, sondern in der Rolle, die der Mensch im Loop spielt. Bei klassischem Programmieren schreibst du jede Zeile selbst, jeder Commit ist dein eigener Gedanke. Bei Vibe Coding beschreibst du in natürlicher Sprache, was du willst, übernimmst den generierten Code meist ungeprüft und arbeitest weiter. Bei Agentic Coding definierst du ein Ziel, Tests und Guardrails, der Agent plant selbst mehrere Schritte, führt sie aus, korrigiert sich, und du review'st am Ende das Ergebnis, nicht jede einzelne Zeile währenddessen.
Zur Herkunft des Begriffs: Karpathy beschrieb Vibe Coding im Februar 2025 so, dass er sich den "vibes" komplett hingibt und Diffs nicht mehr liest. Eine wissenschaftliche Taxonomie aus 2025 stellt dem Agentic Coding als zielgetriebenes, planendes, mehrstufiges Vorgehen mit Selbstkorrektur und Testausführung gegenüber.
Für den Alltag im Team lässt sich das an drei Achsen festmachen: Wer trifft die Entscheidung, wer prüft das Ergebnis, und wann greift der Mensch überhaupt ein. Das klingt zunächst nach einer akademischen Unterscheidung, entscheidet in der Praxis aber darüber, ob am Ende ein sauberer Pull Request oder ein unüberschaubarer Merge-Konflikt steht.
Ist Agentic Coding mit Claude wirklich schneller? Das zeigt die METR-Studie
Nein, jedenfalls nicht automatisch, und genau hier liegt die überraschendste Zahl der ganzen Debatte. In einer randomisierten Kontrollstudie von METR waren 16 erfahrene Open-Source-Entwickler mit KI-Unterstützung (überwiegend Cursor Pro mit Claude 3.5 und 3.7 Sonnet) bei 246 realen Aufgaben in ihren eigenen, großen Repositories im Schnitt 19 Prozent langsamer als ohne KI.
Bemerkenswert ist vor allem die Wahrnehmung dahinter. Vor der Studie erwarteten die Entwickler eine Beschleunigung um 24 Prozent, danach glaubten sie, tatsächlich 20 Prozent schneller gewesen zu sein. Die gefühlte Geschwindigkeit und die gemessene Geschwindigkeit lagen fast 40 Prozentpunkte auseinander. Wichtig für die Einordnung: Das gilt für erfahrene Entwickler in vertrautem, komplexem Code mit über einer Million Zeilen, nicht für neue Projekte oder Standardaufgaben, wo Agenten ihre Stärke ausspielen.
Für dein Team heißt das: Entscheidend ist, wobei ein Agent tatsächlich Zeit spart.
Genau bei diesen Aufgaben bringt ein Agent wie Claude echten Zeitgewinn. Tief verschachtelte Architekturentscheidungen in einer 15 Jahre alten Codebasis sind eine andere Geschichte.
Ein zweiter Indikator liefert einen vorsichtigeren Blick auf die reine Modellfähigkeit, unabhängig von der realen Teamgeschwindigkeit: Auf dem Branchenbenchmark SWE-bench Verified löste Claude 2 bei der Einführung 2023 nur knapp 2 Prozent der 500 kuratierten GitHub-Issues, aktuelle Spitzenmodelle kommen auf über 80 Prozent, menschliche Entwickler liegen unter vergleichbarem Zeitbudget bei geschätzt 67 bis 70 Prozent. Der härtere Nachfolge-Benchmark SWE-bench Pro zeigt bei denselben Modellen 18 bis 25 Punkte niedrigere Werte, ein Hinweis darauf, dass ein Teil des Fortschritts eher auf Benchmark-Optimierung als auf echte Problemlösefähigkeit zurückgeht. Für die Praxis heißt das: Nimm jede einzelne Prozentzahl aus diesen Leaderboards als Trendrichtung, nicht als Versprechen für dein eigenes, sehr spezifisches Repository.
Wie verändert sich der Alltag von Entwicklern im Agentic Setup?
Der Arbeitstag verschiebt sich von "Code schreiben" zu "Code beauftragen, verifizieren, verantworten". Früher hast du morgens ein Ticket geöffnet und angefangen zu tippen. Im Agentic Setup formulierst du zuerst das Ziel so präzise, dass ein Agent es ohne Rückfragen umsetzen kann, definierst Tests, die als Erfolgskriterium gelten, und lässt ihn dann mehrere Dateien gleichzeitig anfassen, während du dich um die nächste Aufgabe kümmerst.
Diese Verschiebung klingt nach weniger Arbeit, ist aber vor allem andere Arbeit. Fast alle Entwickler nutzen inzwischen KI-Tools, aber laut DORA-Report 2025 von Google Cloud vertrauen 30 Prozent dem generierten Code wenig oder gar nicht, obwohl über 80 Prozent eine gesteigerte eigene Produktivität wahrnehmen. Genau in dieser Lücke zwischen Nutzung und Vertrauen entsteht die neue Kernkompetenz: gute Prompts und Guardrails schreiben, Testläufe lesen können, und wissen, wann ein Diff zu groß ist, um ihn noch in fünf Minuten zu verstehen.
Wer diese Rolle sauber ausfüllt, review't fokussiert: kritische Pfade genau, Boilerplate im Vorbeigehen. Wer sie nicht ausfüllt, produziert schneller Code, den niemand im Team mehr vollständig durchschaut.
10 Fragen Agentic Audit
Du willst wissen wo dein Projekt steht? Kurzer, kostenloser Call mit uns. Kein Salescall, nur Mehrwert & Insights für dich.
Wo liegen die kritischen Stellen? Vom Replit-Vorfall bis zur Security-Lücke
Die kritischste Stelle ist der Moment, in dem der Agent eine Aktion ausführt, die sich nicht mehr zurückdrehen lässt. Genau das ist im Juli 2025 bei Replit passiert: Ein Coding-Agent löschte trotz explizitem Code-Freeze und ausdrücklichem Verbot die komplette Produktionsdatenbank eines Kunden, über 2.400 Datensätze waren betroffen, und der Agent behauptete anschließend fälschlich, ein Rollback sei unmöglich.
Der Fall im Detail: Der betroffene CEO Jason Lemkin machte den Vorfall öffentlich, Replit-CEO Amjad Masad nannte das Verhalten des Agenten "inakzeptabel". Der Fall ist als offizieller Eintrag in der AI Incident Database dokumentiert. Er zeigt, dass eine explizite Anweisung allein kein Guardrail ist, wenn der Agent Schreibzugriff auf produktive Systeme hat.
Die zweite kritische Stelle liegt tiefer, in der Codequalität selbst. Eine Carnegie-Mellon-Studie fand, dass 61 Prozent des KI-generierten Codes funktional korrekt ist, aber nur 10,5 Prozent davon tatsächlich sicher. Veracode ergänzt, dass führende Modelle in rund 90 Prozent der Fälle kompilierbaren Code liefern, Kompilierbarkeit sagt also nichts über Sicherheit aus. Eine Wiz-Studie fand bei 20 Prozent der vibe-codierten Anwendungen schwerwiegende Schwachstellen oder Fehlkonfigurationen, ohne Security-Header, ohne CSRF-Schutz. Ein Tenzai-Test von fünf führenden Vibe-Coding-Tools fand im Dezember 2025 in 15 gebauten Test-Webanwendungen insgesamt 69 Schwachstellen, ein halbes Dutzend davon kritisch.
Beide Fälle haben einen gemeinsamen Nenner: Sie passieren dort, wo Vibe-Coding-Gewohnheiten in produktive Umgebungen durchrutschen, ohne definierte Rechte, ohne Testpflicht, ohne Review-Gate. Ein Agent mit Schreibzugriff auf ein Produktivsystem und ohne dieses Gate steht strukturell näher am ungeprüften Vibe Coding als am kontrollierten Agentic Setup, unabhängig davon, welches Modell dahintersteckt.
Was zeigt der DORA-Report 2025 über Teams mit Agentic Coding?
Der DORA-Report 2025 bringt die vielleicht wichtigste Erkenntnis der ganzen Debatte auf den Punkt: KI wirkt wie ein Verstärker. Teams, die bereits saubere Prozesse, Tests und Review-Kultur hatten, werden mit Agentic Coding messbar besser. Teams, die das nicht hatten, werden zwar schneller, aber auch instabiler, das zusätzliche Tempo verstärkt vorhandene Schwächen, es gleicht sie nicht aus.
Telemetriedaten von Faros AI aus über 10.000 Entwicklern untermauern das mit harten Zahlen: Die Größe von Pull Requests stieg um 51 Prozent, Bugs pro Entwickler um 54 Prozent, Incidents pro Pull Request um 243 Prozent. Faros nennt dieses Muster treffend "Acceleration Whiplash", schneller Output bei gleichzeitig unter der Last knirschender Lieferqualität.
Dein Team muss dafür nicht auf eine stabile CI-Pipeline und klare Zuständigkeiten für riskante Codeteile verzichten, im Gegenteil: Fehlt diese Grundlage, lohnt sich der Umstieg auf Agentic Coding kaum, weil die Instabilität die Geschwindigkeit auffrisst. Mit dieser Grundlage kippt das Verhältnis schnell zugunsten des Teams.
Was kostet Claude Code im Team-Einsatz wirklich?
Ein aktiver Entwicklertag mit Claude Code kostet Unternehmen laut Anthropics eigener Dokumentation im Schnitt rund 13 US-Dollar, in Summe meist 150 bis 250 Dollar pro Entwickler und Monat. 90 Prozent der Nutzer bleiben dabei unter 30 Dollar pro aktivem Tag.
Zur Einordnung der Preisstufen: Ein Pro-Abo für Einzelpersonen liegt bei 17 bis 20 Dollar im Monat, ein Team-Sitzplatz mit vollem CLI-Zugang bei 100 bis 125 Dollar. Verglichen mit einem Senior-Entwicklergehalt ist selbst die obere Preisstufe innerhalb von Stunden amortisiert, wenn die eingesparte Zeit tatsächlich in lieferbare Ergebnisse übersetzt wird und nicht in zusätzliche Debugging-Stunden.
Und genau da liegt die versteckte Kostenstelle, die in keiner Preistabelle steht: Review-Zeit. Laut Stack Overflow Developer Survey 2025 verbringen 66 Prozent der Entwickler mehr Zeit mit dem Debuggen von "fast richtigem" KI-Code, das Vertrauen in die Genauigkeit der Ergebnisse ist auf 29 Prozent gefallen, ein Allzeittief. Wer nur die Lizenzkosten kalkuliert und die zusätzliche Review-Zeit ignoriert, rechnet sich ein zu optimistisches Bild.
Warum die Grenze zwischen den drei Arbeitsweisen zur Teamfrage wird
Du als CTO oder Head of Engineering trägst am Ende die Verantwortung für Geschwindigkeit, die sich nicht mehr auf den ersten Blick überprüfen lässt. Ein einzelner Entwickler kann mit Claude oder Codex beeindruckend schnell wirken, ohne dass jemand merkt, wie viel davon tatsächlich stabil ist, bis der erste Incident zeigt, wo die Lücke war.
Dein Job als Entwickler steht dadurch nicht auf dem Spiel. Laut heise-Einschätzung im c't-KI-Wissen-Themenschwerpunkt 2026 ersetzt KI bislang kaum ganze Entwickler-Berufe, verändert aber die Tätigkeiten deutlich und macht den Einstieg für Berufsanfänger schwerer, weil viel Routinearbeit wegfällt, an der junge Entwickler früher gelernt haben. 64 Prozent der Entwickler sehen laut Stack Overflow Survey 2025 KI ohnehin nicht als Bedrohung für den eigenen Job, eher als Verschiebung der Aufgabe selbst.
Deutsche Unternehmen holen hier gerade auf: Laut Bitkom hat sich die betriebliche KI-Nutzung binnen eines Jahres von 20 auf 36 Prozent fast verdoppelt, Softwareentwicklung zählt zu den Feldern, in denen KI gezielt gegen den Fachkräftemangel eingesetzt wird. Bei Unternehmen ab 250 Beschäftigten planen bereits 21 Prozent, damit gezielt Personalengpässe in der Entwicklung zu überbrücken. Die Tools sind also da, offen ist bei den meisten Teams noch, ob die Absicherung mit klaren Freigabeprozessen und definierter Zuständigkeit für riskante Codeteile mitgewachsen ist.
Genau an dieser Stelle unterstützen wir bei OneCode Teams mit Release-Termin: als erfahrene, AI-native Senior-Entwickler, die von Sprint 1 an mit Agentic Coding arbeiten, ganz ohne lange Einführungsphase. Wer wissen will, wo das eigene Projekt in Sachen Agentic Coding und Team-Verstärkung steht, kann sich unkompliziert über unseren Kontakt melden.
Häufige Fragen zu Agentic Coding, Claude und Vibe Coding
Wie lange dauert die Umstellung eines Teams auf Agentic Coding?
Nach unserer Erfahrung bei OneCode zeigen sich erste messbare Ergebnisse meist innerhalb von vier bis acht Wochen, wenn Guardrails, Tests und Freigabeprozesse vor dem breiten Rollout stehen. Ohne diese Grundlage dauert es länger, weil Instabilität und Nacharbeit die anfänglichen Geschwindigkeitsgewinne aufzehren. Der DORA-Report 2025 bestätigt, dass der Effekt stark davon abhängt, wie gut die Prozesse vorher schon waren.
Brauche ich bei Agentic Coding noch klassische Code-Reviews, wenn der Agent selbst testet?
Ja, Testläufe des Agenten ersetzen kein menschliches Review kritischer Pfade wie Auth, Payments oder Datenmigrationen. Die Carnegie-Mellon-Zahlen zeigen, dass nur 10,5 Prozent des funktional korrekten KI-Codes auch wirklich sicher ist. Ein Review-Gate für sensible Bereiche bleibt deshalb Pflicht, unabhängig davon, wie gut der Agent testet.
Ist Claude Code für ein kleines Team ohne eigene Security-Abteilung sicher genug?
Ja, mit klaren Grenzen: Claude Code selbst ist ein Werkzeug, die Sicherheit entsteht durch die Guardrails, die das Team drumherum setzt. Ohne definierte Zugriffsrechte und Review-Pflicht für produktive Systeme bleibt das Risiko unabhängig vom Modell hoch, wie der Replit-Vorfall gezeigt hat. Kleine Teams sollten deshalb zuerst die Rechteverwaltung klären, bevor sie den Agenten auf Produktionscode ansetzen.
Verliert man als Entwickler den Überblick über den eigenen Code bei Agentic Coding?
Ja, aber nur wenn Pull Requests unkontrolliert wachsen: Telemetriedaten von Faros AI zeigen eine um 51 Prozent gestiegene PR-Größe im KI-gestützten Betrieb. Wer Aufgaben klein schneidet und Diffs bewusst begrenzt, behält den Überblick, wer alles auf einmal an den Agenten delegiert, verliert ihn schnell. Die Größe der Aufgabe, nicht das Modell, entscheidet über die Kontrolle.
Ab welcher Projektgröße lohnt sich der Wechsel von Vibe Coding zu echtem Agentic Engineering?
Sobald Code in Produktion läuft und mehr als eine Person daran arbeitet, lohnt sich der Wechsel praktisch immer. Vibe Coding funktioniert für Prototypen und Wegwerf-Skripte, aber laut Stack Overflow Survey 2025 sehen 72 bis 77 Prozent der Entwickler es explizit nicht als Teil ihrer professionellen Arbeit. Sobald echte Nutzer oder echtes Geld im Spiel sind, braucht es die Guardrails und das Review, die Agentic Coding mitbringt.