Dein Engineer hat 47 PRs in zwei Wochen gemeldet. Elf wurden gemergt.

Das Standup sah großartig aus. Lukas, vier Monate im Job, hatte mehr Pull Requests eingereicht als der Rest des Teams zusammen. Siebenundvierzig in vierzehn Tagen. Sein Manager hat das Sprint-Dashboard aufgemacht und die Balken waren höher als alles, was sie seit dem Produktlaunch gesehen hatten.

Dann hat jemand gefragt, wie viele davon tatsächlich in Produktion sind.

Lukas' Merge-Rate war 31%. Von 47 Pull Requests haben es 11 durch CI, Review und Merge geschafft. Der Rest lag verstreut über die PR-Queue in diversen Zuständen von Rot. Vierzehn waren an Lint-Checks gescheitert. Neun hatten fehlschlagende Tests bei Dependencies, die Lukas' Agent nicht berücksichtigt hatte. Dreizehn waren gepusht, ignoriert und irgendwann von einem Stale-Bot geschlossen worden, den jemand Monate vorher eingerichtet hatte. Die restlichen waren noch offen, unberührt, wurden langsam unsichtbar.

Lukas hat vibecoded. Cursor den ganzen Tag offen, Agent generiert Code, PRs werden gepusht, sobald der Output vernünftig aussieht. Er hat nichts direkt falsch gemacht. Er hat das getan, wofür das Tool gemacht ist. Schneller Code schreiben. Öfter ausliefern. Weiter zum Nächsten.

Das Problem ist, was "ausliefern" bedeutet, wenn du es auf PR-Ebene misst statt auf Merge-Ebene.

Die Lücke, die keiner trackt

Ich habe an einer Studie mitgearbeitet, die 24.560 Pull Requests über 447 GitHub-Repositories abdeckt. Eines der Dinge, die wir gemessen haben, ist, was passiert, nachdem ein KI-generierter PR CI failt. Kommt jemand zurück und fixt ihn?

Bei menschlichen PRs werden 23,4 % der Failures irgendwann repariert und bestehen bei einem späteren Run. Jemand schaut sich den Fehler an, passt den Code an, pusht nochmal. Bei KI-generierten PRs fällt die Zahl auf 9,3 %.

Einundneunzig Prozent der gescheiterten KI-Pull-Requests werden aufgegeben. Der Agent generiert, submittet und zieht weiter. Niemand kommt zurück.

Das erzeugt ein spezifisches Buchhaltungsproblem. Wenn dein Team Produktivität nach PR-Anzahl trackt, oder nach eingereichten Codezeilen, oder nach berührten Tickets, wird Vibecoding deine Zahlen unglaublich aussehen lassen. Das Dashboard füllt sich. Die Aktivitätscharts schießen nach oben. Im Standup, wo Leute berichten, woran sie gearbeitet haben, hat der Vibecoder immer die längste Liste.

Aber der tatsächliche Output, Code der kompiliert hat, CI bestanden hat, reviewt wurde und in Produktion gelandet ist, ist oft ein Bruchteil dessen, was die Zahlen suggerieren.

Wo sich die Verschwendung versteckt

Lukas' 36 ungemergte PRs waren nicht kostenlos. Jeder hat einen vollen CI-Pipeline-Run getriggert. Fünfzehn Minuten pro Run bei ihrem Setup. Das sind 9 Stunden Compute-Zeit für Code, der nie ausgeliefert wird. Bei GitHub-Actions-Preisen grob $4,30 in reinen Minuten. Nicht viel für einen Sprint. Aber Lukas' Tempo war konstant, und er war nicht der Einzige im Team, der mit KI-Tools experimentiert hat.

Über das ganze Team gerechnet haben sie etwa 120 Stunden Runner-Zeit pro Monat für Builds verbrannt, die nichts produziert haben. Ungefähr $58 an GitHub-Actions-Minuten für Code, den sich niemand je wieder anschauen würde.

Die Compute-Kosten waren real, aber ehrlich gesagt verkraftbar. Was nicht verkraftbar war, war die Verwirrung.

Neue Engineers, die dem Projekt beigetreten sind, haben die PR-Liste geöffnet und Dutzende offene Branches gefunden, die meisten fehlschlagend, manche wochenlang. Sie haben einen Nachmittag damit verbracht, sie durchzulesen, um zu verstehen, was in Arbeit ist und was tot ist. Die PR-Queue war zu Rauschen geworden. Echte laufende Arbeit war unter spekulativen Versuchen begraben, die zufällig dasselbe visuelle Gewicht in der GitHub-UI hatten.

Velocity ist eine nachgelagerte Metrik

Lukas' Manager hat sich irgendwann mit ihm hingesetzt und die Zahlen durchgegangen. Nicht um ihn zu bestrafen. Um neu zu kalibrieren.

Siebenundvierzig eingereichte PRs klingt nach 4x Produktivität. Elf gemergte liegen immer noch über dem Teamdurchschnitt, der bei ungefähr acht pro Zwei-Wochen-Sprint lag. Lukas war mit Cursor wirklich schneller. Das Tool hat funktioniert. Aber der Multiplikator, den er glaubte zu bekommen, der, den er beim Benutzen gefühlt hat, lag um den Faktor vier daneben.

Das Problem ist, dass Velocity sich sofort anfühlt. Du promptest den Agent, Code erscheint, du pushst. Die Feedback-Schleife dauert 90 Sekunden. Es fühlt sich an wie Ausliefern. Das Failure-Signal kommt später, asynchron, als CI-Notification, die in einem Slack-Channel landet, der voller anderer Failures ist, von denen die meisten ebenfalls Bot-PRs sind, die niemand fixen wird.

Nach ein paar Wochen in so einer Umgebung hörst du auf nachzuschauen. Der Channel wird Rauschen. Und wenn das einmal passiert ist, merkst du auch nicht mehr, wenn deine eigenen PRs scheitern.

Was sein Team geändert hat

Sie haben Cursor nicht eingeschränkt. Das wäre sinnlos gewesen. Was sie geändert haben, war wie sie gezählt haben.

Das Sprint-Dashboard hat eine neue Spalte bekommen: Merge-Rate. Nicht Gesamt-PRs geöffnet. Nicht eingereichte Zeilen. Gemergte Pull Requests als Prozentsatz der geöffneten. Lukas' Zahl war 23 %. Der Senior-Engineer, der alles von Hand schrieb und vier PRs pro Sprint eingereicht hat, lag bei 100 %.

Keine der Zahlen allein hat die ganze Geschichte erzählt. Aber zusammen haben sie etwas Nützliches gezeigt: Lukas hat mehr Versuche generiert, und der Senior hat weniger, aber zuverlässigere produziert. Das Ideal lag irgendwo dazwischen. Das Tool benutzen, aber vor dem Push reviewen. Den Linter lokal laufen lassen. Prüfen, ob jemand anderes schon einen Branch hat, der dieselben Dateien berührt.

Sie haben außerdem ein Precheck-Gate eingebaut (nur Lint und Type-Check, 30 Sekunden), das die volle Pipeline bei offensichtlichen Failures blockiert. Hat ihre verschwendeten CI-Minuten um etwa 60 % reduziert. Und sie haben Auto-Close für jeden KI-gelabelten PR mit fehlschlagenden Checks und ohne Aktivität seit 48 Stunden eingerichtet. Hat die Queue über Nacht aufgeräumt.

Lukas' Merge-Rate ging innerhalb eines Monats von 23 % auf 61 %. Sein PR-Volumen fiel von 47 pro Sprint auf etwa 20. Sein tatsächlicher gemergter Output ging von 11 auf 12. Fast identisch. Aber die Verschwendung drumherum ist dramatisch geschrumpft, und das Team ist nicht mehr in toten PRs ertrunken.

Die Zahl, die dein Standup enthalten sollte

Wenn dein Team KI-Coding-Tools einführt, ist die wichtigste Metrik nicht, wie viele PRs geöffnet werden. Es ist, wie viele gemergt werden. Und genauer gesagt: das Verhältnis zwischen den beiden.

Ein Vibecoder mit 25 % Merge-Rate erzeugt drei Einheiten Verschwendung für jede Einheit ausgelieferten Code. Ein Vibecoder mit 80 % Merge-Rate, nach Lint-Gates und Config-Dateien und lokalen Checks, übertrifft wirklich sein Pre-KI-Selbst.

Der Unterschied zwischen diesen beiden Engineers ist nicht Talent. Es sind vier Config-Dateien und ein Nachmittag CI-Setup.