Was Vibe-Coding ist

Softwareentwicklung hat einen neuen Namen bekommen, und er stammt aus einem einzigen Beitrag im Netz. Was seither darunter verstanden wird, hat sich davon ziemlich weit entfernt.

Woher das Wort kommt

Am 2. Februar 2025 schrieb Andrej Karpathy, Mitgründer von OpenAI, einen kurzen Beitrag über eine Arbeitsweise, die er bei sich selbst beobachtet hatte. Er beschreibt darin ein Vorgehen, bei dem man dem Modell sagt, was man möchte, das Ergebnis übernimmt und den Code gar nicht mehr liest. Er gab dem Ganzen einen Namen, und der Name blieb.

Zwei Stellen des Beitrags werden in der späteren Verwendung selten mitzitiert. Erstens: Karpathy beschreibt es als Verfahren für Wegwerfprojekte am Wochenende. Zweitens: Das Nichtlesen des Codes ist bei ihm der Kern der Sache. Wer den Code liest, macht etwas anderes.

Der Beitrag steht unter Karpathys Beschreibung vom Februar 2025 (externe Seite, x.com). Er ist drei Absätze lang.

Das Wort bekam eine Grenze, und zwar von ihm selbst

Fünfzehn Monate später, am 30. April 2026, hat Karpathy die Sache eingeordnet. Er stellt dem Begriff einen zweiten zur Seite und trennt beide an einem Bild:

Vibe coding raises the floor. It lets almost anyone create software by describing what they want. (externe Seite, karpathy.bearblog.dev)

Vibe-Coding hebt also den Boden. Es bringt Leute zu einem Ergebnis, die sonst gar keines bekommen hätten. Daneben stellt er das andere:

Agentic engineering raises the ceiling. It is the professional discipline of coordinating fallible agents while preserving correctness, security, taste, and maintainability. (externe Seite, karpathy.bearblog.dev)

Agentic Engineering heißt das im Deutschen bisher gar nicht, ein eingeführtes Wort dafür gibt es nicht. Gemeint ist die berufliche Fassung: mehrere fehlbare Agenten führen, ohne Richtigkeit, Sicherheit und Wartbarkeit aufzugeben.

seitlich verschiebbar

eigene Darstellung nach Karpathy, Stand 03.08.2026

Warum das kein Wortstreit ist

An der Grenze hängt, wer für das Ergebnis geradesteht.

Karpathys erste Fassung ist für kleine, ersetzbare Sachen gedacht. Ein Skript für einen Nachmittag, ein Prototyp, der nach der Vorführung gelöscht wird. Fünfzehn Monate später zieht er die Grenze selbst, und er zieht sie weiter als das Wochenende:

Vibe coding is fine for prototypes and personal tools. (externe Seite, karpathy.bearblog.dev)

Ein persönliches Werkzeug wird benutzt, oft jahrelang. Damit hängt die Frage an zwei Dingen, und das erste ist der Zugriff. Was ein Programm anrichten kann, ergibt sich aus dem, was es erreicht: Dateien, die es löschen darf, Zugangsdaten, die herumliegen, Dienste, die Geld kosten. Das entscheidet sich beim Einrichten, und wie, steht in Kapitel 02.

Das zweite kommt dazu, sobald etwas in Betrieb geht. Dann ist der Code, den niemand gelesen hat, genau der Code, den niemand reparieren kann. Und weil ein Modell flüssig formuliert, sieht ein falsches Ergebnis dabei aus wie ein richtiges. Das ist derselbe Mechanismus wie in Grundkurs, Kapitel 07, nur trifft er hier ein laufendes System statt eines einzelnen Satzes.

Wie weit das schon ist

Bleibt die Frage, ob das eine Randerscheinung ist. Die Antwort steht in Geschäftsberichten und Entwicklerblogs, und sie fällt deutlicher aus, als man erwartet.

Wer	Anteil	Wann
Anthropic (externe Seite, anthropic.com)	über 80 % der übernommenen Zeilen	Mai 2026
Spotify (externe Seite, newsroom.spotify.com)	über 73 % der Beiträge unterstützt	Mai 2026
Alphabet (externe Seite, s206.q4cdn.com)	rund 50 %, von Agenten geschrieben und von den eigenen Leuten geprüft	Februar 2026

Bei Anthropic lag derselbe Wert Anfang 2025 noch im niedrigen einstelligen Bereich. Ein Team bei OpenAI (externe Seite, openai.com) hat fünf Monate lang ein Produkt gebaut, ohne eine einzige Zeile von Hand zu schreiben.

Drei Vorbehalte gehören in denselben Atemzug.

Die drei Zahlen messen Verschiedenes. Anthropic zählt Zeilen, die in die Produktion übernommen wurden. Spotify sagt „unterstützt“ und meint damit auch den Fall, in dem ein Mensch die Hauptarbeit gemacht hat. Alphabet spricht von Code, den Agenten schreiben und Menschen anschließend durchsehen. Nebeneinandergestellt sehen sie aus wie eine Reihe. Sie sind keine.

Alle vier Firmen verkaufen das Werkzeug, über das sie berichten. Das macht die Zahlen nicht falsch, es macht sie zu Angaben über die eigene Lage. Wie es in einem Betrieb aussieht, dessen Bestand zwanzig Jahre alt ist, misst niemand.

Für die Branche insgesamt gibt es keine solche Zahl. Die großen Erhebungen fragen nach der Nutzung, und die liegt hoch: 90 Prozent der Befragten arbeiten mit KI (externe Seite, cloud.google.com), bei Stack Overflow (externe Seite, survey.stackoverflow.co) sind es 84 Prozent, die es tun oder vorhaben. Wie viel von ihrem Code daher kommt, sagt die Frage nicht.

Was bleibt, ist die Richtung, und die ist eindeutig. Die Höhe der Zahlen hängt davon ab, was man zählt.

Warum dieser Kurs trotzdem so heißt

Er behandelt fast durchgehend das zweite, also die Decke. Der Name steht trotzdem darüber, weil danach gesucht wird und weil unter diesem Wort geführt wird, was in Wirklichkeit beides meint.

Wo es darauf ankommt, steht im Text, welche der beiden Fassungen gemeint ist. Sie werden feststellen: Es ist fast immer die zweite.

Was sich wirklich verschiebt

Die Arbeit verschwindet nicht, sie wandert. Vom Schreiben zum Beschreiben, und vom Suchen des Fehlers zum Erkennen des Fehlers.

Das Beschreiben ist dabei die kleinere Hälfte. Eine Aufgabe an einen Agenten liefert in Minuten ein Ergebnis, das plausibel aussieht. Die Zeit geht danach drauf: prüfen, ob es tut, was es soll; prüfen, ob es nebenbei etwas kaputt gemacht hat; entscheiden, ob der Weg dorthin tragfähig ist oder nur zufällig funktioniert.

Deshalb geht es in diesem Kurs nach dem Werkzeug sofort um das, was daneben steht: was der Agent zu Beginn vorfindet, was er zwischen zwei Sitzungen behält, und was ihn davon abhält, dieselbe Sache dreimal falsch zu machen.

Was es nicht ist

Es ist keine Frage der Programmiersprache und keine des Werkzeugs. Man kann mit demselben Agenten sorgfältig oder nachlässig arbeiten, und das entscheidet sich an der Arbeitsweise.

Es ist auch kein Ersatz für Verständnis. Ob eine Lösung taugt, lässt sich mit einem Agenten daneben genauso wenig beurteilen wie ohne. Ein Agent nimmt die Ausführung ab, und die reicht heute weit: nachschlagen, umbauen über viele Dateien, Tests laufen lassen, Fehlern nachgehen. Bei Ihnen bleibt die Frage, ob das Ergebnis richtig ist.

Boden und Decke sind zwei Zielrichtungen, und sie unterscheiden sich darin, was überhaupt als Erfolg gilt. Dazwischen liegen die meisten wirklichen Projekte, und eines wandert im Lauf seines Lebens von der einen Seite zur anderen: Das Werkzeug für den Eigenbedarf, das ein Kollege nützlich findet, steht am nächsten Tag unter dem zweiten Maßstab.

Zwei Vorhaben, zwei Maßstäbe

Beim Boden lautet die Frage: Kommt jemand zu einem Ergebnis, der sonst keines bekommen hätte? Ein Verkäufer baut sich ein Werkzeug für seine Angebotsrechnung, eine Lehrerin eine Übungsseite. Gemessen wird daran, dass es das Ding gibt.

Bei der Decke lautet sie: Bleibt die Sache richtig, sicher und wartbar, während sie schneller entsteht? Gemessen wird an dem, woran Software immer gemessen wurde, und die Geschwindigkeit ist eine Zugabe, die diesen Maßstab nicht senken darf.

Karpathy sagt das in der Fassung von 2026 (externe Seite, karpathy.bearblog.dev) über die Fehlbarkeit der Agenten: Es geht um deren Führung unter Beibehaltung von Richtigkeit, Sicherheit, Geschmack und Wartbarkeit. Das Wort fallible steht dort mit Absicht. Ein Verfahren, das mit fehlerfreien Agenten rechnet, braucht keine Disziplin.

Praktisch heißt das: Wenn zwei Leute über die Sache sprechen und einer berichtet begeistert, wie schnell es geht, während der andere von Nachbesserungen erzählt, reden sie über verschiedene Vorhaben. Beide haben recht, und beide reden aneinander vorbei.

Die ursprüngliche Fassung von 2025 (externe Seite, x.com) ist dabei nicht verschwunden. Sie ist nur die eine Hälfte, und die kleinere von beiden für jeden, der Software beruflich baut.

Die Schleife

Technisch ist die Sache eine Wiederholung von vier Schritten. Es ist die Agentenschleife aus Grundkurs, Kapitel 09, angewendet auf ein Projektverzeichnis.

1. Absicht. Sie beschreiben, was entstehen oder sich ändern soll.
2. Erkundung. Der Agent sucht sich zusammen, was er dafür wissen muss. Er liest Dateien, sucht nach Namen, sieht sich an, wie es woanders gelöst ist.
3. Änderung. Er schreibt Dateien, führt Befehle aus, liest deren Ausgabe.
4. Rückmeldung. Ein Test schlägt fehl, ein Bau bricht ab, oder Sie sagen, dass es so nicht gemeint war. Damit fängt die Runde von vorn an.

Der Unterschied zu einem Chatfenster steckt in Schritt 2 und 3. Ein Modell, dem Sie Code hineinkopieren, sieht das, was Sie ihm zeigen. Ein Agent im Projektverzeichnis sieht, was er sich holt, und er entscheidet selbst, was das ist.

Warum die Prüfung die teure Hälfte ist

Erzeugen und Prüfen sind bei dieser Arbeitsweise nicht gleich aufwendig, und das Verhältnis ist ungewohnt herum.

Das Erzeugen ist billig geworden. Eine Änderung über zehn Dateien kostet ein paar Minuten Wartezeit. Das Prüfen ist gleich teuer geblieben: Jemand muss verstehen, was da steht, und beurteilen, ob es taugt.

Das ist inzwischen gemessen. Spotify hat seine Entwicklung weitgehend auf Agenten umgestellt und beziffert die Kehrseite in einem Satz:

The flip side: we now have 76% more PRs to review. (externe Seite, engineering.atspotify.com)

Der Beitrag heißt „Coding is no longer the bottleneck“, und im selben Abschnitt steht, wohin der Engpass gewandert ist:

As coding velocity increases, the constraints shift toward human decisions. (externe Seite, engineering.atspotify.com)

Die Jahreserhebung von DORA sieht dasselbe bei knapp 5.000 Befragten, und dort laufen zwei Größen auseinander. Mit KI wird mehr ausgeliefert, das war im Vorjahr noch anders. Mit der Stabilität der Auslieferung hängt es weiter andersherum zusammen:

AI adoption does continue to have a negative relationship with software delivery stability (externe Seite, cloud.google.com)

Das Wort relationship steht dort mit Bedacht: Eine Befragung misst, was zusammen auftritt. Was wovon kommt, sagt sie nicht.

Die Erklärung dazu ist zugleich die Gliederung dieses Kursbereichs. Ohne belastbare Vorkehrungen, aufgezählt werden automatische Tests, gepflegte Versionierung und schnelle Rückmeldung, führt mehr Änderungsvolumen laut DORA zu Instabilität. Der Satz, der die ganze Erhebung zusammenfasst, lautet:

AI doesn’t fix a team; it amplifies what’s already there. (externe Seite, cloud.google.com)

Daraus folgt eine Sache, die den ganzen Rest dieses Kurses erklärt. Wenn das Prüfen der Engpass ist, dann lohnt sich jede Investition, die Prüfen billiger macht, sofort und mehrfach. Ein Test, der in zwei Sekunden sagt, ob etwas kaputt ist, ersetzt zehn Minuten Lesen. Eine Regel, die verhindert, dass ein Fehler ein zweites Mal entsteht, ersetzt jede spätere Suche danach.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Mitchell Hashimoto beschreibt genau diesen Umgang, als er dem Vorgehen einen Namen gibt:

It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again. (externe Seite, mitchellh.com)

Was um das Modell herum steht

Was ein Agent leistet, hängt weniger am Modell, als die Werbung der Anbieter vermuten lässt. Es hängt daran, was um das Modell herum gebaut ist: welche Tools es hat, was es zu Beginn zu lesen bekommt, was mit seinen Fehlern geschieht, wann jemand gefragt wird.

Für dieses Drumherum hat sich seit Anfang 2026 der Ausdruck Harness eingebürgert. Die Formel dazu ist kurz:

Agent = Model + Harness (externe Seite, blog.langchain.com)

Und die Abgrenzung ebenso:

A harness is every piece of code, configuration, and execution logic that isn’t the model itself. (externe Seite, blog.langchain.com)

Das ist die praktische Nachricht für jeden, der anfängt: Die Frage „welches Modell nehme ich“ ist an einem Nachmittag beantwortet und kommt danach selten wieder hoch. Die Frage „wie richte ich das ein“ begleitet einen dauerhaft. Dieser Kurs handelt überwiegend von der zweiten. Wie weit die Wahl bei einem Werkzeug überhaupt frei ist, steht in Kapitel 02, und was die Stufen eines Anbieters unterscheidet, in Grundkurs, Kapitel 10.

Spotify sagt in seinem Bericht selbst, woran die Umstellung dort gelegen hat, und es waren die Jahre davor: Die Vorarbeit an internen Plattformen und an einheitlichen Standards habe das Haus in eine gute Lage gebracht. Überliest man diesen Satz, sehen die Zahlen wie eine Aussage über das Modell aus.

Wo die Arbeitsweise taugt und wo nicht

Sie taugt gut, wo es viel gleichförmige Arbeit gibt und eine schnelle Antwort auf die Frage „funktioniert es noch“. Umbauten über viele Dateien, das Nachziehen einer Schnittstelle an dreißig Stellen, das Schreiben von Tests zu vorhandenem Code, Werkzeuge für den Eigenbedarf.

Für die umgekehrte Reihenfolge, den Test vor dem Code, gibt es eine eigene Arbeitsweise und eine Messung dazu, welchen Unterschied sie im Agentenbetrieb macht: Erst der rote Test.

Sie taugt schlecht, wo der Aufwand im Urteil steckt statt in der Ausführung. Bei einer Architekturentscheidung ist das Tippen nie das Problem gewesen. Ein Agent liefert dort schnell eine Lösung, und die Geschwindigkeit verdeckt, dass die eigentliche Frage nie gestellt wurde.

Sie taugt auch schlecht dort, wo niemand die Fehler bemerkt. Das ist der gefährlichere der beiden Fälle, weil er sich gut anfühlt.

Wie sich die Zeit verteilt

Was in Berichten über diese Arbeitsweise regelmäßig fehlt: Die Zeit, die man gewinnt, verteilt sich anders, als man erwartet. Es gibt Tage, an denen in zwei Stunden etwas fertig wird, wofür sonst eine Woche nötig gewesen wäre. Und es gibt Nachmittage, die damit vergehen, einem Agenten dreimal dieselbe Sache zu erklären, bis man sie schließlich selbst schreibt.

Wer den zweiten Nachmittag oft erlebt, sieht sich am besten zuerst das Projekt an: ob es so eingerichtet ist, dass ein Agent darin arbeiten kann. Womit man das tut, steht in Kapitel 02, und wie man es einrichtet, in den Kapiteln danach.

Wer diese Arbeitsweise über Wochen betreibt, stößt auf ein Problem, das mit der Qualität des Modells nichts zu tun hat und sich auch nicht durch ein besseres wegkaufen lässt: Ein Agent kann nicht unterscheiden, ob er etwas geprüft oder ob er die Prüfung nur behauptet hat.

Die Selbstauskunft ist keine Messung

Fragt man einen Agenten, ob er den Test laufen ließ, antwortet er ja. Die Antwort kostet ihn dasselbe wie das Ausführen, und sie sieht hinterher genauso aus. Dasselbe gilt für „ich habe die Datei gelesen“, „die Adresse habe ich aufgerufen“ und „das steht so in der Dokumentation“.

Daraus folgt die Bauregel, an der sich in diesem Gebiet alles Weitere ausrichtet: Jede Bedingung, auf die es ankommt, wird außerhalb des Modells geprüft. Am besten als Code, der danebenläuft und ein Ergebnis hat, das entweder null oder ungleich null ist. Der Auftragstext taugt dafür nicht.

Zwei Einschränkungen gehören dazu, und beide bleiben den ganzen Kurs über gültig. So prüfbar ist, was sich entscheiden lässt: ob der Bau läuft, ob ein Zeichen im Text steht, ob eine Adresse antwortet. Ob eine Oberfläche verständlich ist oder eine Architekturentscheidung standhält, beurteilt weiterhin ein Mensch. Und ein grünes Ergebnis ist selbst eine Behauptung, solange niemand gezeigt hat, dass diese Prüfung überhaupt anschlagen kann. Woran man das erkennt, steht in Kapitel 07.

Eine Regel im Prompt ist eine Bitte. Sie wird meistens befolgt, und „meistens“ ist bei einer Bedingung, auf die man sich verlässt, dasselbe wie nein. Der Unterschied fällt genau dann auf, wenn er zählt: bei einer Aufgabe, die die Regel ausdrücklich verletzen möchte, und bei einem Modell, das hilfsbereit genug ist, sie zu verletzen.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Was daraus für den Aufbau folgt

Drei Dinge, die alle darauf hinauslaufen, Zusagen durch Eigenschaften zu ersetzen.

Der Zustand vor der Arbeit ist eine Eigenschaft, keine Prüfung. Ein Agent, der in einem eigenen Worktree auf einem definierten Stand läuft, kann fremde Arbeit nicht mitnehmen. Ein Agent, der im gemeinsamen Verzeichnis läuft und vorher prüft, ob dort nichts liegt, bricht entweder ständig ab oder nimmt irgendwann etwas mit. Eine Bedingung, die fast nie zutrifft, wirkt am Ende wie ein Ausschalter.

Das Ergebnis wird am Artefakt gemessen, nicht am Bericht. Ob der Bau läuft, sagt der Bau. Ob der Text stimmt, sagt der Vergleich mit der Quelle. Der Abschlussbericht eines Agenten ist eine Zusammenfassung dessen, was er zu tun glaubte.

Was einmal schiefging, wird zur Vorkehrung. Das ist der Kern von Hashimotos Beschreibung, und es ist der einzige Mechanismus, der einen Aufbau über die Zeit besser macht statt nur größer. Ein Fehler, der bloß korrigiert wird, hinterlässt nichts, was ihn beim nächsten Mal abfängt.

Der Begriff Harness, und woher er kommt

Für das Drumherum gibt es seit Februar 2026 einen eingeführten Ausdruck. Wie schnell er sich gesetzt hat, ist gut belegt, und das allein ist ein kleines Lehrstück.

Hashimoto benutzt den Namen am 5. Februar 2026 und sagt dazu ausdrücklich, dass er keinen etablierten kennt:

I don’t know if there is a broad industry-accepted term for this yet, but I’ve grown to calling this (externe Seite, mitchellh.com)

Einen Anspruch auf das Wort wehrt er im selben Absatz ab:

I don’t need to invent any new terms here; if another one exists, I’ll jump on the bandwagon. (externe Seite, mitchellh.com)

Beansprucht wird damit eine Bedeutung für ein vorhandenes Wort. Wer den Abschnitt liest, sieht einen Mann, der eine Praxis benennen will und dafür das nächstliegende Wort nimmt.

Sechs Tage danach steht es im Titel eines Beitrags von OpenAI, in dem ein Team beschreibt, wie es seinen Aufbau um den Agenten herum gestaltet (11. Februar 2026 (externe Seite, openai.com)). Ob dort jemand den anderen Beitrag gelesen hatte, steht nirgends und wird hier auch nicht behauptet. Belegt sind die beiden Daten.

Zwölf Tage nach Hashimoto greift Birgitta Böckeler den Ausdruck auf und beschreibt ihn als

as a word to describe the tooling and practices we can use to keep AI agents in check (externe Seite, martinfowler.com)

Sie stellt dieselbe Verbindung her wie der Absatz oben und markiert sie als Vermutung:

Maybe the term was an afterthought inspired by Mitchell Hashimoto (externe Seite, martinfowler.com)

Die Definition, die heute überall zitiert wird, zieht Vivek Trivedy im März 2026 (externe Seite, blog.langchain.com) nach, zusammen mit der Formel Agent = Model + Harness.

Fünf Wochen von Hashimotos Abschnitt bis zu der Formel, die heute jeder zitiert. Das ist die Geschwindigkeit, mit der sich in diesem Gebiet Begriffe setzen, und sie ist der Grund, warum ein Text darüber sein Datum nennen sollte.

Woran man eine wertlose Messung erkennt

In der Auseinandersetzung um diese Arbeitsweise sind Zahlen schnell zur Hand. Die meisten davon messen die eigene Erwartung.

Zeilen pro Tag. Ein Agent erzeugt mühelos das Zehnfache. Die Zahl steigt auch dann, wenn das Ergebnis schlechter wird, und sie steigt besonders stark, wenn niemand aufräumt.

Commits, Testdateien, angebundene Tools. Alles Mengenangaben über die Erzeugung, keine über das Ergebnis. Sie sagen, wie viel entstanden ist, nicht wie gut es ist.

Die Selbsteinschätzung des Modells. Ein Modell, das seinen eigenen Text benoten soll, benotet ihn gut. Bittet man es um Verbesserungsvorschläge, schlägt es den Stil vor, den es selbst schreibt.

Der Anteil, den alle zitieren

Die Prozentzahlen aus dem Überblick dieses Kapitels sind der Fall, an dem das praktisch wird, denn sie kommen in jeder Diskussion vor. Sie sind echt, die Firmen haben sie selbst veröffentlicht, und trotzdem reicht keine von ihnen so weit, wie sie beim Zitieren gedehnt wird.

Bei Google stehen zwei Zahlen im Umlauf, und beide lauten rund 50 Prozent. Die aus dem Überblick stammt aus der Bilanzvorlage vom Februar 2026 und spricht von Code, den Agenten schreiben und die eigenen Ingenieure durchsehen. Die ältere steht im Research-Blog und zählt etwas ganz anderes. Dort ist die Rechnung benannt, mit ihrer Reichweite gleich daneben:

it’s possible to use a rough measure of impact, e.g., the percentage of new characters written by AI (externe Seite, research.google)

Gemessen wird dort das Verhältnis von angenommenen Zeichen aus der Code-Completion zu allen neu geschriebenen, bei einer Annahmequote von 37 Prozent (externe Seite, research.google). Das beschreibt einen Vorgang, bei dem ein Mensch tippt und laufend entscheidet.

Zu einer Zeitreihe zusammengezogen ergeben die beiden ein Wachstum, das aus dem Wechsel der Definition kommt. Beide Zahlen stimmen, und sie zählen verschiedene Dinge in verschiedenen Jahren.

Anthropic zählt Zeilen und legt die Lücken offen. Im selben Absatz, der die über 80 Prozent nennt, steht, dass die Zuordnung Lücken hat (externe Seite, anthropic.com) und dass unter den nicht zugeordneten Zeilen auch maschinell erzeugte sind, die ebenfalls niemand getippt hat. Zur zweiten Zahl desselben Textes, der achtfachen Menge je Ingenieur, schreibt die Firma:

Lines of code is an imperfect measure, as it measures quantity over quality (externe Seite, anthropic.com)

Dieselbe Fußnote nennt daneben eine Schätzung der Führung von 90 Prozent, sobald man Skripte und Versuche mitzählt. Für ein Zitat aus diesem Text stehen also zwei Werte derselben Firma zum selben Zeitpunkt zur Wahl.

Bei OpenAI umfasst der Begriff alles. Der Bericht über das Team, das ohne handgeschriebene Zeile arbeitet, hat einen eigenen Abschnitt dazu, was „agent-generated“ dort heißt: Produktcode und Tests, die Bauleitung, interne Werkzeuge, Dokumentation, Bewertungsläufe, sogar die Definitionsdateien der Produktionsanzeigen (externe Seite, openai.com). Eine solche Zählweise ergibt zwangsläufig einen höheren Prozentsatz als eine, die nur Anwendungslogik betrachtet.

Warum die Gegenzahl auch nicht hilft

Gegen die Prozentzahlen wird meist dieselbe Arbeit angeführt: ein randomisierten Versuch von METR, der 2025 ergab, dass erfahrene Entwickler mit KI 19 Prozent länger brauchten, während sie sich für 20 Prozent schneller hielten. Die Arbeit ist sauber gemacht und wird bis heute zitiert.

Sie hat seit Februar 2026 einen Nachtrag, und der ist lehrreicher als das Ergebnis. METR hat ab August 2025 erneut gemessen, bekam ein umgekehrtes Vorzeichen und erklärte die eigenen Daten für unbrauchbar:

we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools (externe Seite, metr.org)

Der Grund dafür ist selbst ein Befund. Die Versuchsanordnung verlangt, dass ein Teil der Aufgaben ohne KI bearbeitet wird, und daran scheiterte sie:

we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI (externe Seite, metr.org)

Bei denen, die mitmachten, wählten 30 bis 50 Prozent einzelne Aufgaben ab (externe Seite, metr.org), weil sie sie ohne KI nicht angehen wollten. Übrig bleibt eine Stichprobe ohne die Fälle, auf die es ankommt.

Was METR daraus zieht, steht schon im Titel des Nachtrags. Der Aufbau wird geändert:

Due to the severity of these selection effects, we are working on changes to the design of our study. (externe Seite, metr.org)

Für die eigene Lage folgt daraus mehr als aus jeder der Zahlen. Wer heute messen will, ob eine Arbeitsweise etwas bringt, muss die Vergleichsbedingung selbst herstellen, und die Leute, die er dafür braucht, wollen sie nicht.

Was etwas sagt, ist unangenehmer zu erheben: Wie viele der erzeugten Änderungen mussten zurückgenommen werden. Wie oft ist derselbe Fehler ein zweites Mal aufgetreten. Wie lange dauert es vom Ergebnis bis zu dem Moment, in dem jemand es verantworten kann.

Was offen bleibt

Zwei Fragen, auf die es hier keine Antwort gibt.

Wie viel Verständnis nötig bleibt, wenn man den Code nicht mehr selbst schreibt, weiß niemand. Die Erfahrung sagt: mehr, als der erste Eindruck vermuten lässt, und anderes als früher. Man muss weniger auswendig können und mehr beurteilen.

Und wie sich das auf Leute auswirkt, die auf diesem Weg anfangen statt umsteigen, ist eine offene Frage. Wer zwanzig Jahre selbst geschrieben hat, erkennt ein schiefes Ergebnis in Sekunden. Woher diese Fähigkeit kommen soll, wenn die Zwischenschritte wegfallen, an denen man sie sonst erwirbt, ist ungeklärt.