Ihr Team liefert mehr Code als je zuvor. Und Sie trauen ihm weniger. Dahinter steckt keine technische Frage, sondern eine Budgetfrage: Was genau ändern Sie jetzt?
Kaufen Sie mehr Review-Kapazität auf Senior-Niveau ein. Keinen Bot, keinen schlankeren Prozess. Menschen, die Geschäftslogik, Sicherheitsmodell und Performance-Profil im Kopf behalten, während sie ein Diff lesen.
Das ist die teure Antwort. Und für jeden, der Software ausliefert, für die andere Leute bezahlen, ist sie die einzige, die trägt.
Was sich tatsächlich geändert hat
Faros AI hat Teams mit hoher KI-Nutzung mit dem Rest verglichen. Diese Teams mergen 98 % mehr Pull Requests. Bei denselben Teams ist die Zeit, die ein Pull Request im Review verbringt, um 91 % gestiegen. Es kommt mehr an, und es bleibt länger liegen.
Der CircleCI-Bericht 2026 zeigt dasselbe an einer anderen Stelle. Der Durchsatz auf Feature-Branches ist im Jahresvergleich um 59 % gestiegen. Der mediane Durchsatz auf dem Main-Branch ist gefallen. Der Code entsteht schneller, aber er kommt nicht schneller dort an, wo er zählt.
Der DORA-Report 2025 misst je nach Team einen Zuwachs beim Durchsatz von 2 bis 18 %. Im selben Datensatz korreliert KI-Nutzung mit höheren Change-Failure-Raten. Die Erklärung der Autoren wird oft falsch wiedergegeben, deshalb sauber: Es liegt nicht daran, dass KI schlechten Code schreibt. Die Erzeugung läuft der Review- und Deployment-Kapazität davon.
GitClear schaut sich seit Jahren an, was in den Commits selbst steht, und nicht nur, wie viele es sind. Die Duplikation ganzer Codeblöcke liegt 81 % über dem Wert von 2023 und damit auf dem höchsten je gemessenen Stand. Refaktorierter, also verschobener Code machte 2023 noch 13 % der geänderten Zeilen aus, 2026 sind es 3,8 %. Funktionsaufrufe über Dateigrenzen hinweg sind um 35 % zurückgegangen.
Das ist kein Stilproblem. Das ist die Beschreibung einer Codebasis, die kopiert, statt wiederzuverwenden, und deren Änderung dadurch jedes Jahr ein Stück teurer wird.
Und die Reviewer? Eine Untersuchung aus dem Jahr 2026 hat sich angesehen, wie Menschen auf Pull Requests reagieren, die rund doppelt so viel redundanten Code enthalten wie üblich. Diese Pull Requests bekamen weniger negative Reaktionen als erwartet, nicht mehr. Sauber formatierter Code, der plausibel aussieht, rutscht durch.
Vier Optionen liegen auf dem Tisch
In der Praxis sehe ich vier Reaktionen. Drei davon sind billiger als die vierte, und jede hat eine Stelle, an der sie bricht.
Aushalten
Gleiche Reviewer, gleiche Standards, mehr Volumen. Auf dem Papier kostet das nichts, und genau deshalb ist es die Standardreaktion: Sie verlangt keine Entscheidung. Das Risiko ist hoch, und es zeigt sich spät.
Diese Option scheitert leise. Reviews werden flacher, lange bevor das jemand ausspricht. Eine MSR-Studie von 2026 hat Pull Requests von Coding-Agenten ausgewertet: 77,5 % der gemergten Agenten-PRs wurden von derselben Identität gemergt, die sie eingereicht hatte. Bei menschlichen Autoren liegt dieser Wert bei 57,6 %. Bei 5,5 % der Merges war überhaupt keine sichtbare menschliche Interaktion mehr erkennbar. Das ist kein Vier-Augen-Prinzip mehr, das ist ein Durchlauf.
Ein KI-Reviewer vor der Warteschlange
Ein Bot macht den ersten Durchgang, ein Mensch liest, was übrig bleibt. Die Kosten liegen im zweistelligen Eurobereich pro Entwickler und Monat. Das Risiko ist mittel und wird meistens falsch eingeschätzt. Als Ergänzung passt das fast überall.
Der Bot ist gut in seiner Fehlerklasse und blind für die teure. Er meldet Ihnen den ungenutzten Import. Er kann nicht wissen, dass eine Service-Klasse gerade eine zweite Verantwortung dazubekommen hat. Er kann nicht wissen, dass der Erstattungsprozess ins Ledger schreiben muss, bevor der Zahlungsanbieter aufgerufen wird, weil das nirgendwo steht, wo er es lesen könnte.
Als Linter mit besseren Manieren ist so ein Tool in Ordnung. Als Gate haben Sie genau das Urteilsvermögen automatisiert, das Sie eigentlich schützen wollten.
Den Input drosseln
Pull Requests deckeln, kleinere Änderungen, engerer Zuschnitt. Kostet wenig Geld und echte Reibung. Das Risiko ist gering. Für Teams, die in Pull Requests mit 900 Zeilen ertrinken, ist das die schnellste Verbesserung, die zu haben ist.
Nur lässt sich ein Volumenproblem ab einem gewissen Punkt nicht mehr kleinschrumpfen. Zehn kleine Reviews kosten mehr Kontextwechsel als zwei große. Das hilft. Die Antwort ist es nicht.
Mehr Review-Kapazität auf Senior-Niveau einkaufen
Review wird zu erstklassiger Arbeit mit echten Stunden im Plan, besetzt mit Leuten, die erfahren genug sind, einen Fehler in der Geschäftslogik zu finden und nicht bloß einen Stilverstoß.
Mit deutlichem Abstand ist das die teuerste der vier Optionen. Das Risiko ist gering. Sie passt zu jedem, dessen Software echtes Geld oder echtes Vertrauen kostet, wenn sie in der Produktion ausfällt.
Was wir tun, und was uns das kostet
Wir lesen jede Zeile. Nicht überfliegen, lesen. Der Code, der aus unseren Abläufen kommt, hat in aller Regel gute Qualität, und an der Verantwortung ändert das nichts. Eine KI unterschreibt keinen Vertrag, sie haftet nicht, und um 23 Uhr kann man sie nicht anrufen.
Was wir zurückweisen, ist fast nie Syntax. Es ist Architektur. Ich lehne regelmäßig Pull Requests wegen SOLID-Verstößen ab, und das Muster wiederholt sich: Der Code funktioniert, die Tests laufen durch, und eine Klasse hat still eine zweite Verantwortung dazubekommen, weil das der kürzeste Weg zu einer funktionierenden Antwort war.
Eine KI optimiert auf die Änderung, die vor ihr liegt. Sie weiß nicht, dass die Klasse, die sie gerade erweitert hat, diejenige ist, an der drei Teams hängen. Sie weiß nicht, dass Sie dieses Interface absichtlich schmal gehalten haben. Im Diff steht davon nichts. Sie müssen die Codebasis vorher kennen, und deshalb muss der Reviewer senior sein.
So weit die Haltung. Jetzt der Preis, den sie uns kostet.
Erstens brauchen wir deutlich mehr Review-Zeit als noch vor einem Jahr. Eine genaue Zahl nenne ich nicht, weil wir keine saubere haben. Bei Festpreisprojekten kommt diese Zeit aus unserer Marge.
Zweitens werden die Leute müde. Reviewen ist geistig anstrengend, auf eine Art, wie Schreiben es nicht ist. Schreiben hat einen Rhythmus. Reviewen heißt, die Absicht eines anderen im Kopf zu halten und nach dem zu suchen, was fehlt. Man kann sechs Stunden damit verbringen und am Ende auf nichts zeigen.
Drittens sagt es das Team offen: zu viele Reviews, zu wenig Bauen. Eine saubere Lösung dafür habe ich nicht. Rotation hilft ein wenig, gedeckelte Review-Blöcke auch, geschützte Zeit zum Bauen ebenfalls. Die Spannung verschwindet nicht. Wenn Ihnen eine Agentur erzählt, sie habe das gelöst, verkauft sie Ihnen etwas.
Viertens sind Senior-Entwickler knapp, und sie werden knapper. Die Pipeline lief bisher über Junioren, die Code schreiben und dabei korrigiert werden. Wenn Junioren weniger schreiben, woher kommen dann die Reviewer von übermorgen? Ich weiß es nicht. Bisher weiß es niemand.
Die Entscheidung, nach Situation
Kurz und sortiert nach der Lage, in der Sie gerade stecken.
- Vor dem ersten Umsatz, Prototyp, Wegwerfcode: aushalten. Ausliefern, leicht reviewen. Der Prozess-Overhead bringt Sie hier schneller um als ein Bug.
- Kleines Produkt, echte Nutzer, aber kein Geldfluss: Bot als erster Durchgang, kleinere Pull Requests, Senior-Review auf Authentifizierung und Daten.
- Geld, personenbezogene Daten oder regulierte Workloads: Senior-Review auf allem, Bot als Ergänzung. Teuer und richtig.
- Altsystem, kleines Team, hohes Änderungsvolumen: Senior-Review plus harte Obergrenze für die Größe eines Pull Requests. Ihr Problem heißt Verständnis, nicht Durchsatz.
- Sie bekommen die Senior-Entwickler nicht: Holen Sie sich Review-Kapazität von außen, während Sie eigene aufbauen. Tun Sie nicht so, als wäre das Gate besetzt.
Wenn Ihr Code Geld bewegt, bezahlen Sie für das Gate
Wenn Ihr Code Geld bewegt, personenbezogene Daten hält oder Sie am Montagmorgen in Erklärungsnot bringen würde, dann besetzen Sie das Gate mit Senior-Entwicklern und bezahlen Sie dafür. Alles Billigere kauft Ihnen eine bestimmte Art von Blindheit.
Falsch ist dieser Rat in genau einem Fall: Sie haben noch keinen Umsatz und bauen, um überhaupt herauszufinden, ob jemand das Produkt will. Dann liefern Sie schnell aus, reviewen Sie leicht und nehmen Sie die Schulden bewusst auf.
Der Umschaltpunkt ist der Tag, an dem Ihnen jemand seine Kreditkarte gibt. Der häufigste Fehler, den ich sehe, sind Teams, die diesen Tag längst hinter sich haben und trotzdem weiterarbeiten wie davor. Man hat sich an das Tempo gewöhnt, bevor es etwas zu verlieren gab, und niemand hat entschieden, den Gang zu wechseln.
Wo wir ins Spiel kommen
Review-Kapazität auf Senior-Niveau ist eine unserer Leistungen, entweder eigenständig oder innerhalb eines Entwicklungsprojekts. Wir lesen gegen Ihre Geschäftslogik, Ihr Sicherheitsmodell und Ihr Performance-Profil, nicht gegen eine allgemeine Checkliste. Wir entwickeln mit Laravel, React und React Native und sind Laravel Community Partner.
Ein Punkt, der beim Review mehr zählt als fast alles andere: Wir sitzen in derselben Zeitzone wie Westeuropa. Ein Review, das acht Stunden wartet, ist kein Review, sondern eine Warteschlange.
Wenn Sie wissen wollen, wo Sie stehen, schreiben Sie uns an [email protected]. Wir sehen uns Ihren aktuellen Prozess an und sagen Ihnen ehrlich, ob Sie Leute brauchen, Tooling oder einfach kleinere Pull Requests.