Jake war die beste Einstellung, die ich bei der Firma in zwei Jahren gesehen hatte. Kam als Mid-Level, hat sich schnell eingearbeitet, sauberen Code geliefert. Im dritten Monat hat er Tickets schneller geschlossen als jeder andere im Team. Im vierten Monat hat mich seine Teamleitung zur Seite genommen und gesagt, dass etwas nicht stimmt.

Die CI-Rechnung hatte sich verdoppelt. Nicht allmählich. In einem Monat.

Ich habe sie gebeten, mir zu zeigen, was sich geändert hat. Sie hat die PR-Liste geöffnet und gescrollt. Und gescrollt. Jake hatte in den letzten zwei Wochen 47 Pull Requests eingereicht. Die meisten waren klein, unter 50 Zeilen. Mehr als die Hälfte hatte rote Badges. Er war schon beim nächsten Task, bevor der erste fertig gebaut war.

Sie hat es Vibecoding genannt. Jake hatte angefangen, Cursor Vollzeit zu nutzen, den Agent den Großteil seines Codes schreiben zu lassen, PRs zu pushen, sobald der Agent fertig generiert hatte. Seine Velocity-Zahlen sahen in den Standup-Metriken unglaublich aus. Seine tatsächliche Merge-Rate lag bei 31%.

Ich sehe mittlerweile ungefähr einmal im Monat eine Variante dieser Geschichte.

Die Daten hinter dem Muster

Ich habe an einer Studie mitgearbeitet, die 24.560 Pull Requests über 447 GitHub-Repositories analysiert hat. Wir haben jeden PR auf acht Kovariaten gematcht (Repo-Alter, Star-Count, PR-Größe, Sprache, Timing, ein paar andere) und verfolgt, was passiert, wenn er auf CI trifft.

KI-geschriebene PRs scheitern nach Adjustierung auf Störfaktoren 19,4 % häufiger als menschliche. Die Zahl allein sagt wenig. Wo genau die Failures sich häufen, das ist der interessante Teil.

Kleine PRs, unter 55 Zeilen, sind der Punkt, an dem alles auseinanderfällt. KI-generierte Änderungen in dieser Größe scheitern doppelt so häufig wie vergleichbare menschliche (OR = 2,12, z = 8,23). Über 400 Zeilen verschwindet der Unterschied komplett. Die allergrößten KI-PRs schneiden sogar leicht besser ab als menschliche.

Jakes PRs hatten im Schnitt 23 Zeilen. Er hat jedes einzelne Mal den schlimmsten Punkt der Kurve getroffen.

Warum die kleinen kaputtgehen

Ein 12-Zeilen-PR von einem KI-Agent ist ein fundamental anderes Artefakt als ein 600-Zeilen-Feature-Branch vom selben Tool. Der kleine ist ein Einzelschuss. Agent sieht einen Task, generiert einen Fix, öffnet einen PR. Keine Iteration, kein Review, kein Bewusstsein für projektspezifische Konventionen. Er weiß nicht, dass dein Team letzten März auf Double-Quotes umgestellt hat, oder dass eure Import-Reihenfolge einem Custom-ESLint-Plugin folgt, das drei Leute im Team überhaupt kennen.

Große KI-PRs sehen anders aus, weil ein Mensch beteiligt war. Jemand hat dem Agent einen detaillierten Prompt gegeben, den Diff vor dem Push reviewt, oder die Änderung hat genug Dateien berührt, dass der Agent mehr von der Codebasis aufnehmen musste. Menschliche Präsenz wirkt als Qualitätsfilter.

Der Fehlermodus ist überraschend spezifisch. Test-Failures zwischen KI- und Human-PRs zeigen nach Kontrolle für Within-Repo-Clustering keinen statistisch signifikanten Unterschied. Tests bestehen ungefähr gleich häufig, egal wer den Code geschrieben hat.

Was kleine KI-PRs umbringt, ist Linting. 76 % mehr Lint-Violations als bei menschlichen PRs. Der Agent schreibt Code, der kompiliert, läuft, jeden Test besteht und dann abgelehnt wird, weil er Tabs statt Spaces benutzt hat. Lint-Regeln stehen in Config-Dateien, die der Agent nie gesehen hat.

Der Teil, der wirklich Geld kostet

Jakes Teamleitung dachte, der Fix liegt auf der Hand. Jake sagen, er soll seine PRs vor dem Push reviewen. Er hat das dann auch gemacht. Irgendwie. Er hat auf den Diff geschaut, gesehen, dass es vernünftig aussieht, und gepusht. Die Linting-Probleme sind weitergegangen, weil Jake den Linter lokal auch nicht laufen ließ. Er hat dem Output des Agents vertraut und darauf gesetzt, dass CI alles Falsche auffängt.

CI hat es aufgefangen. Jedes einzelne Mal. Bei $0,008 pro Minute.

Fünfzehn fehlgeschlagene Pipeline-Runs pro Tag, jeder zwischen 12 und 18 Minuten. Grob 4 Stunden verschwendeter Compute täglich. Über einen Monat sind das 120 Stunden Runner-Zeit, die nichts produzieren.

Aber die Compute-Kosten waren ehrlich gesagt das kleinere Problem.

Jeder fehlgeschlagene Run löst eine Benachrichtigung aus. Wenn das ganze Team für jeden CI-Failure einen Slack-Alert bekommt, und die meisten davon Jakes aufgegebene Bot-PRs sind, hören die Leute auf hinzuschauen. Ich habe es bei dieser Firma in Echtzeit beobachtet. Innerhalb von zwei Wochen, nachdem Jake voll auf Vibecoding umgestiegen war, stieg die mediane Reaktionszeit des Teams auf echte CI-Failures von etwa 12 Minuten auf über 3 Stunden. Das Rauschen hatte sie trainiert, nicht mehr hinzuschauen.

Niemand repariert die kaputten

Wenn ein KI-PR CI failt, werden 9,3 % irgendwann repariert und bestehen bei einem späteren Run. Bei menschlichen PRs liegt die Zahl bei 23,4 %. Einundneunzig Prozent der gescheiterten KI-Pull-Requests werden aufgegeben. Der Agent versucht es einmal, scheitert, zieht weiter.

Jakes Zahlen waren schlechter als der Datensatz-Durchschnitt. Er hatte 34 offene PRs mit roten Badges. Der älteste war fünf Wochen alt. Er hatte jeden einzelnen davon vergessen. Sie saßen in der Queue, belegten Dashboard-Platz und schickten Notification-Pings ins Leere. Jeder neue Engineer, der dem Projekt beitrat, verbrachte seinen ersten Nachmittag damit, tote PRs durchzuscrollen und herauszufinden, was echte Arbeit und was Rauschen war.

Was seine Teamleitung eingerichtet hat (ein Nachmittag)

Der Fix war nicht, Jake zu sagen, er soll aufhören, Cursor zu benutzen. Das wäre dumm gewesen. Seine guten PRs, die, die tatsächlich bestanden haben, waren wirklich gut. Schnell, sauber strukturiert, oft besser als was er von Hand geschrieben hätte. Das Problem war die Pipeline, nicht das Tool.

Erstes, was sie gemacht hat: ein schneller Precheck-Workflow. Nur Lint und Type-Check, kein Build, keine Integrationstests. Läuft in etwa 30 Sekunden. Wenn der Precheck fehlschlägt, wird die volle Pipeline gar nicht erst getriggert. Allein das hat ihre verschwendeten CI-Minuten um etwa 60 % reduziert. Eingerichtet als separater GitHub-Actions-Workflow auf pull_request, als required Status-Check konfiguriert. Hat vielleicht zwei Stunden gedauert, inklusive Testen.

Dann hat sie die ESLint-Config und die Prettier-Regeln des Teams in Jakes .cursorrules-Datei gepackt. Cursor liest diese Datei und nutzt sie als Kontext beim Generieren von Code. Die Lint-Fehlerrate bei seinen PRs ist in der ersten Woche um etwa ein Drittel gesunken. Zehn Minuten Arbeit.

Auto-Close kam als Nächstes. Eine tägliche Cron-Action, die jeden PR mit dem Label ai-generated findet, der fehlgeschlagene Checks und seit 48 Stunden keine Aktivität hat, und ihn dann mit einem Kommentar schließt. GitHubs Stale-Action erledigt das. Bei einer Aufgaberate von 91 % bei gescheiterten KI-PRs ist Schließen nach zwei Tagen Stille nicht aggressiv. Du räumst Arbeit auf, die bereits tot war.

Letztes Stück: Concurrency-Groups, gekeys auf den PR-Branch. Wenn Jakes Agent dreimal innerhalb von 20 Minuten auf denselben Branch gepusht hat, hat nur der letzte Commit einen vollen Pipeline-Run bekommen. Die früheren wurden automatisch abgebrochen. Hat ihn daran gehindert, die Runner zu monopolisieren, während andere Engineers auf ihre Branches gewartet haben.

Das Ganze hat einen Nachmittag gedauert. Ihre CI-Rechnung ist wieder auf 15 % über dem Niveau von vor Jakes Vibecoding-Phase gefallen. Jake hat weiter Cursor benutzt. Er hat immer noch mehr PRs eingereicht als jeder andere im Team. Die, die es durch das Precheck-Gate geschafft haben, wurden mit einer höheren Rate gemergt als der Team-Durchschnitt.

Das Gespräch, das keiner führen will

Seine Teamleitung hat mir später erzählt, dass der schwierigste Teil nicht das technische Setup war. Es war Jake zu sagen, dass seine Velocity-Zahlen gelogen haben.

Er hatte im Standup 47 PRs in zwei Wochen gemeldet. Sah auf dem Papier fantastisch aus. Aber zieh die ab, die CI gefailt haben und nie repariert wurden. Die, die als stale geschlossen wurden. Die, die Arbeit dupliziert haben, die jemand anders schon gemacht hatte, weil Jake nicht vorher nachgeschaut hat. Sein tatsächlicher ausgelieferter Beitrag waren 11 gemergte PRs. Immer noch respektabel. Aber nicht der 4x-Multiplikator, den er glaubte.

Das Vibecoding-Versprechen ist, dass du schneller arbeiten kannst. Und das stimmt. Aber nur wenn deine Pipeline für das Muster gebaut ist, das diese Tools produzieren: Dutzende kleine spekulative PRs pro Tag, von denen die meisten an Lint-Regeln scheitern, die der Agent nicht kennt, und von denen fast keiner repariert wird, wenn er bricht. Wenn deine CI für fünf bis zehn sorgfältig reviewte menschliche PRs pro Tag designed wurde, knickt sie ein.

Die Antwort sind vier Änderungen an deinem CI-Setup, die ungefähr fünf Stunden brauchen, und ein ehrlicher Blick darauf, was "Velocity" bedeutet, wenn ein Bot den Code schreibt.

Was für ein Projekt planst du?

Cookie-Einstellungen