Ich habe drei Monate lang zugesehen, wie eine Junior-Engineerin einen Staff-Level-Entwickler in der Produktion übertroffen hat. Nicht in Codezeilen. Nicht in PR-Anzahl. In gemergten, in Produktion laufenden, reviewten und abgenommenen Pull Requests.
Die Junior hat Cursor für alles benutzt. Der Staff-Engineer hat jede Zeile von Hand geschrieben. Am Ende von Q1 hatte die Junior 38 gemergte PRs. Der Staff-Engineer hatte 29. Beide haben an derselben Codebase gearbeitet, im selben Sprint-Rhythmus, mit demselben Review-Prozess.
Das soll eigentlich nicht passieren. Eine Junior mit vier Monaten Erfahrung soll nicht mehr ausliefern als jemand mit neun Jahren. Aber die Zahlen waren sauber, und die Codequalitäts-Metriken (Post-Merge-Defektrate, Revert-Rate, Review-Revisionsanzahl) waren vergleichbar. Der Code der Junior war nicht schlechter. Es gab einfach mehr davon, und er hat weiter bestanden.
Der Staff-Engineer war im Stillen wütend. Ich weiß es, weil er es mir gesagt hat.
Warum die meisten Vibecoding-Geschichten anders ausgehen
Das Narrativ, das ich normalerweise höre, ist das Gegenteil. Junior fängt mit Vibecoding an, CI-Rechnung explodiert, die meisten PRs scheitern, keiner fixt sie, das Team erstickt im Rauschen. Ich habe über dieses Muster geschrieben, weil es verbreitet ist und die Daten es belegen. KI-generierte PRs unter 55 Codezeilen scheitern doppelt so häufig wie menschliche PRs in derselben Größenordnung. Der mediane KI-generierte PR liegt genau in dieser Gefahrenzone.
Aber Größe ist ein Proxy. Was sie tatsächlich misst, ist, wie viel menschliche Beteiligung in die Änderung geflossen ist, bevor sie CI erreicht hat. Ein 12-Zeilen-PR, der in einem Schuss generiert und ohne Review gepusht wurde, spielt die schlechtesten Odds im Datensatz. Ein 200-Zeilen-PR, den jemand sorgfältig promptet, den Diff reviewt, lokal ausgeführt und mit Absicht gepusht hat, verhält sich nicht anders als ein menschlicher PR derselben Größe.
Die Studie, die wir über 24.560 PRs und 447 Repos durchgeführt haben, bestätigt das. Über 400 Zeilen haben KI-generierte PRs keinen statistisch signifikanten Unterschied zu menschlichen. Bei den allergrößten schneidet KI sogar leicht besser ab. Die Lücke existiert ausschließlich am kleinen, spekulativen, unreviewten Ende der Verteilung.
Die Junior hat keine kleinen spekulativen PRs generiert. Das war der ganze Unterschied.
Was sie tatsächlich anders gemacht hat
Ihr Name war Priya. Sie hatte bei einer größeren Firma ein Praktikum gemacht, wo jemand vor ihrem Einstieg einen ordentlichen KI-Entwicklungs-Workflow aufgesetzt hatte. Sie kam mit Gewohnheiten zum Startup, die die meisten Engineers noch herausfinden.
Sie hat den Linter vor jedem Push laufen lassen. Nicht manuell. Sie hatte einen Pre-Commit-Hook eingerichtet, der eslint --fix und prettier --write auf Staged Files ausführt. Dauert etwa vier Sekunden. Allein das hat den häufigsten KI-Fehlermodus in unserem Datensatz eliminiert: die 76-%-Lint-Lücke zwischen KI- und menschlichen PRs. Ihre Lint-Fehlerrate war im Grunde null, weil der Linter lokal gelaufen ist, bevor der Code jemals CI erreicht hat.
Ihre .cursorrules-Datei war detailliert. Nicht nur Formatierungsregeln. Sie hatte die Modulstruktur des Projekts aufgenommen, die Namenskonventionen, die das Team für React-Komponenten benutzt, die Import-Reihenfolge, das Testdatei-Benennungsmuster, welche Libraries gegenüber Alternativen bevorzugt werden (das Team nutzte date-fns und sie hatte geschrieben "never suggest moment.js"). Der Agent hatte genug Kontext, um Code zu generieren, der zum Projekt passt, nicht nur Code, der kompiliert.
Sie hat zusammengehörige Änderungen gebündelt. Statt einen Ein-Zeilen-Fix zu pushen, dann noch einen, dann einen dritten, hat sie den Agent alle drei generieren lassen, den kombinierten Diff reviewt und einen PR mit dreißig oder vierzig Zeilen gepusht. Das hat sie aus der fehleranfälligen Small-PR-Zone in den Bereich bewegt, wo KI-Code genauso gut abschneidet wie menschlicher.
Und sie hat jedes Mal den Diff gelesen. Kein flüchtiger Blick. Sie hat durchgescrollt, die Logik geprüft, manchmal Cursor gebeten, einen Abschnitt zu erklären, den sie nicht verstanden hat. Wenn etwas komisch aussah, hat sie den Agent vor dem Push zur Überarbeitung aufgefordert. Das hat vielleicht fünf Minuten pro PR gekostet. Dafür hat ihr Code, wenn er CI erreicht hat, bereits den Filter bestanden, den die meisten vibecoded PRs komplett überspringen.
Der Einwand des Staff-Engineers
Er hat ihn in einer Retro vorgebracht. Höflich, aber pointiert. Priya "schummle." Sie benutze ein Tool, das Code für sie schreibt. Natürlich hat sie mehr Output. Es sei wie jemanden zu vergleichen, der 120 Wörter pro Minute tippt, mit jemandem, der 40 tippt. Der Geschwindigkeitsunterschied sei nicht Können, sondern Tooling.
Die Tech-Leaderin hat widersprochen. Sie hat ihn gebeten, Priyas Post-Merge-Defektrate aufzurufen. Sie war 2,1 %. Seine war 1,8 %. Beide exzellent. Bei ihrer Stichprobengröße statistisch nicht unterscheidbar.
Dann hat sie nach der Revert-Rate gefragt. Priyas: null in drei Monaten. Seine: eine, eine Datenbank-Migration, die einen kurzen Staging-Ausfall verursacht hat. Kein bedeutsamer Unterschied, aber es hat das Argument untergraben, dass KI-Code inhärent unzuverlässiger sei.
Das Gespräch hat sich verschoben. Nicht von "sollen wir KI-Tools benutzen" zu "wie benutzen wir sie, ohne Verschwendung zu erzeugen." Der Staff-Engineer hat im nächsten Sprint angefangen, Cursor zu benutzen. Seine erste Woche war holprig. Fehlerrate um die 35 %, hauptsächlich Lint. In Woche drei, nachdem er Priyas .cursorrules-Datei und Pre-Commit-Hook übernommen hatte, lag er bei 22 %.
Das Setup, das es funktionieren lässt
Es gibt vier Dinge, die einen Vibecoder, der Verschwendung erzeugt, von einem unterscheiden, der wirklich schneller liefert.
Eine Kontextdatei, die der Agent liest. .cursorrules für Cursor, .github/copilot-instructions.md für Copilot, CLAUDE.md für Claude Code. Formatter-Config-Pfad, Namenskonventionen, Modulstruktur, Library-Präferenzen rein. Zehn Minuten Arbeit, und es eliminiert den häufigsten Fehlermodus.
Ein lokaler Pre-Commit-Hook, der Linter und Formatter auf Staged Files ausführt. Vier Sekunden pro Commit. Fängt alles auf, was die Kontextdatei nicht abdeckt. Kostenlos.
Kleine Änderungen in einzelne PRs bündeln. Die Daten sind hier eindeutig. KI-PRs unter 55 Zeilen scheitern doppelt so häufig. Über 200 Zeilen kein Unterschied zu menschlichem Code. Einen PR mit fünf zusammenhängenden Änderungen zu pushen ist strikt besser als fünf separate Ein-Zeilen-PRs.
Den Diff vor dem Push lesen. Fünf Minuten. Der Qualitätsfilter, der einen spekulativen Agent-Versuch in einen reviewten menschlichen Beitrag verwandelt. Jede Metrik in unserem Datensatz verbessert sich, wenn dieser Schritt vorhanden ist, weil der PR aufhört, "KI-generiert" in irgendeinem sinnvollen Sinn zu sein, und zu "KI-unterstützt, menschlich-reviewt" wird.
Priya hat alle vier gemacht. Der Staff-Engineer hat irgendwann alle vier gemacht. Der Unterschied zwischen ihren frühen Erfahrungen mit demselben Tool war nicht Talent, nicht Erfahrung, nicht Modellqualität. Es war Setup.
Basierend auf einer empirischen Studie von 24.560 PRs über 447 Open-Source-Repositories. Namen und Details wurden geändert. Ich helfe Startups und Teams beim Einrichten von CI/CD-Pipelines, DevOps-Infrastruktur und Entwicklungs-Workflows, die mit KI-Tools arbeiten statt gegen sie.
Ist deine CI/CD Pipeline bereit für AI-Agents?
Die meisten Pipelines sind nicht für AI-Coding-Tools ausgelegt. Ein kurzes Audit kann dir jede Woche Stunden an verschwendeter Rechenzeit sparen.