Ok, die Zahlen zuerst: Mit KI-Agenten schreiben Entwickler 30 Prozent mehr Codezeilen und liefern 23 Prozent mehr Pull Requests. Und am Ergebnis ändert sich nichts. Das sagt eine Harvard-Studie über 700'000 Entwickler in 718 Firmen, und t3n hat sie diese Woche mit der Überschrift gebracht, KI mache Entwickler nicht wirklich produktiver. Ich habe den Artikel zweimal gelesen, und ich finde, die Überschrift stimmt nicht. Die Studie sagt etwas anderes, und das ist interessanter: Der Engpass ist gewandert. Vom Schreiben zum Verstehen. Genau dorthin, wo ich ihn seit einem Jahr vermute.
Die Zahlen
Fiona Chen und James Stratton von Harvard haben Daten der Engineering-Plattform Jellyfish ausgewertet: 300 Millionen Arbeitsergebnisse, Januar 2021 bis März 2026, über 700'000 Beschäftigte in 718 Unternehmen. Drei Kennzahlen: Codezeilen, Commits, Pull Requests.
Reaktive Assistenten, also die Autovervollständigung im Editor, bringen laut Studie 12 Prozent mehr Codezeilen, 9 Prozent mehr Commits, 5 Prozent mehr Pull Requests, und nur die Commits sind statistisch belastbar. Teilautonome Agenten, die ganze Aufgaben übernehmen, heben alle drei: 30 Prozent mehr Zeilen, 20 Prozent mehr Commits, 23 Prozent mehr Pull Requests.
Und dann der Teil, der die Überschrift gemacht hat: Kein messbarer Effekt auf den Output der Firmen, kein Effekt auf die Beschäftigung. Stattdessen steigt die durchschnittliche Zeit für die Prüfung eines Pull Requests um 49 Prozent. Der Anteil der Pull Requests, bei denen Änderungen verlangt werden, verdoppelt sich fast. Die Kommentare pro Pull Request steigen um 35 Prozent. Der Anteil der Leute, die Reviews machen, steigt um 14 Prozent. Und das bleibt so, auch wenn die Firma KI-Tools fürs Review einführt.
Dazu 21 Interviews. Ein leitender Entwickler sagt sinngemäss: Für Routine ist der Entwurf in zwei Sekunden da und in neun von zehn Fällen richtig. Bei anspruchsvollen Aufgaben spart es nicht viel, es macht Fehler, und man verbringt die Zeit mit Prüfen. Ein Junior: Die KI macht 95 Prozent, und die restlichen 5 Prozent bestehen darin, herauszufinden, was sie falsch gemacht hat.
Der Engpass ist gewandert
Jedes System hat einen Engpass, und wer einen beseitigt, bekommt den nächsten. Das ist keine KI-Erkenntnis, das ist Fliessband. Jahrzehntelang war der Engpass in der Softwareentwicklung das Schreiben: Ein Mensch tippt, denkt, tippt, und das dauert. Also haben wir alles darum herum optimiert, bessere Editoren, Frameworks, Bibliotheken, Autovervollständigung.
Jetzt ist das Schreiben praktisch gratis. Ich habe das in „Code wird billig" geschrieben, und die Studie liefert die Zahl dazu: 30 Prozent mehr, ohne dass jemand länger arbeitet. Aber der Code muss immer noch durch einen Menschen, bevor er in die Produktion darf. Und der Mensch liest nicht 30 Prozent schneller. Er liest eher langsamer, weil er dem Code weniger traut, und zu Recht: fast doppelt so viele Pull Requests kommen mit Änderungswünschen zurück.
Das ist der Entwickler aus „Nur noch Enter", nur mit Zahlen. Der Mann im Post hat beschrieben, wie er zwölf Stunden am Tag Ausgaben bestätigt. Die Studie sagt: Die Firmen schieben gerade ihre Leute genau dorthin, 14 Prozent mehr Reviewer. Sie machen aus Entwicklern Prüfer. Und Prüfen skaliert nicht, weil Verstehen nicht skaliert.
Wir messen seit Jahren das Falsche
Hier ist der Punkt, den ich an der Studie wichtiger finde als das Ergebnis: die drei Kennzahlen selber. Codezeilen, Commits, Pull Requests. Das sind die Zahlen, die auf jedem Dashboard stehen, und das sind die Zahlen, die KI am leichtesten nach oben treibt. Mehr Zeilen zu schreiben war nie das Ziel. Weniger Zeilen für dasselbe Ergebnis wäre eines. Ich habe das bei „Nur noch Enter" aufgeschrieben, was ich messen würde: wie viel Komplexität wir entfernt haben, wie gut das Team das System versteht, ob das Produkt besser geworden ist.
Und das ist das Fiese an den 30 Prozent: Sie sehen aus wie ein Erfolg. Ein CTO, der nur das Dashboard sieht, kauft noch mehr Agenten. Die Zeilen steigen weiter. Das Review wird noch länger. Und irgendwann sitzt das ganze Team im Review und niemand baut mehr.
Warum das Review länger dauert
Die Studie sagt, dass das Review länger dauert. Sie sagt nicht, warum. Ich sage, was ich in Projekten sehe, als Erfahrung, nicht als Messung.
Der Agent kennt das System nicht. Er kennt die Datei, vielleicht den Ordner. Er kennt nicht die Entscheidung von vor zwei Jahren, warum das Modul so gebaut ist, und nicht die Abhängigkeit, die niemand dokumentiert hat. Also baut er etwas, das lokal richtig ist und global falsch. Der Reviewer muss das Globale im Kopf haben. Das dauert.
Der Agent schreibt zu viel. Zweitausend Zeilen, wo zweihundert reichen. Duplikate, feste Verdrahtung, eigene Hilfsfunktionen statt der vorhandenen. Das habe ich beim Enterprise-Thema die Riesenklassen genannt. Jede dieser Zeilen muss jemand lesen.
Der Agent nimmt sich selber ab. Er meldet „fertig", und der Mensch fängt bei null an. Es gibt keinen Zwischenschritt, in dem jemand anderes, Mensch oder Agent, die Regeln geprüft hat, bevor der Reviewer draufschaut. Also prüft der Reviewer alles, Stil, Architektur, Logik, Sicherheit, in einem Durchgang.
Es gibt kein Gedächtnis. Der Reviewer hat gestern genau dasselbe Muster beanstandet. Der Agent weiss es heute nicht mehr. Jeder Pull Request ist der erste. Darum verdoppeln sich die Änderungswünsche: Es sind dieselben Änderungswünsche, jeden Tag.
Keiner dieser vier Punkte wird besser, wenn das Modell grösser wird. Sie werden besser, wenn das System um das Modell herum anders gebaut ist.
So würde ich es bauen
Nicht einen Entwickler beim Tippen beschleunigen. Das hat die Studie gerade gemessen, es bringt 30 Prozent mehr Zeilen und null mehr Ergebnis. Sondern den ganzen Prozess so bauen, dass der Code, der beim Reviewer ankommt, schon durch alles andere durch ist.
Das System vor dem Code. Der Agent bekommt nicht die Aufgabe, er bekommt die Aufgabe plus die Architekturregeln plus die Entscheidungen, die zu diesem Modul gehören. Das ist der Wissensaufbau, über den ich bei „Software ist ein Film" geschrieben habe: Was das Projekt über sich selber weiss, muss in den Kontext, bevor die erste Zeile entsteht. Sonst prüft der Mensch nachher, was der Agent vorher hätte wissen können.
Weniger Code als Ziel. Der Agent, der zweihundert Zeilen liefert, wo er zweitausend hätte liefern können, hat gewonnen. Das muss in der Aufgabe stehen und gemessen werden. Ein Sprint, in dem Code verschwindet, ist ein guter Sprint.
Vier Augen, bevor ein Mensch schaut. Wer schreibt, prüft nicht. Ein zweiter Agent prüft die Architekturregeln, ein dritter die Tests, einer die Sicherheit, jeder nur seins, und nie derselbe wie der, der geschrieben hat. Der Mensch bekommt dann einen Pull Request, bei dem Stil und Regeln schon durch sind, und prüft das, was nur er prüfen kann: ob es das Richtige ist.
Ein Gedächtnis für Reviews. Jeder Änderungswunsch eines Menschen ist ein Datenpunkt. Wenn derselbe Reviewer dasselbe Muster dreimal beanstandet, gehört das in die Regeln, automatisch. Die Änderungswünsche müssen sinken, nicht sich verdoppeln. Wenn sie es nicht tun, ist das System falsch gebaut, egal wie viele Zeilen es schreibt.
So machen wir es bei NeoCoder
Das ist nicht nur Theorie, das ist der Grund, warum NeoCoder so gebaut ist, wie es gebaut ist. Als wir angefangen haben, war die erste Entscheidung nicht, welches Modell wir nehmen. Die erste Entscheidung war: Der Agent darf keine Zeile schreiben, bevor er das System kennt. Das klingt banal. Es ist das Gegenteil von dem, was die meisten Werkzeuge tun, die bei der Datei anfangen, die gerade offen ist.
Konkret heisst das bei uns: Bevor ein Agent eine Aufgabe bekommt, baut NeoCoder das Wissen über das Projekt auf. Welche Module es gibt und wo ihre Grenzen sind. Welche Architekturregeln gelten, und zwar als Regeln, die geprüft werden, nicht als Dokument, das niemand liest. Welche Entscheidungen früher getroffen wurden und warum. Welche Abhängigkeiten zwischen Bereichen bestehen, auch die, die in keinem Diagramm stehen, sondern nur in der Git-Historie. Das ist die Kette, über die ich bei „Software ist ein Film" geschrieben habe: Zustand, Aktion, Ergebnis, Folgezustand, mitgeschrieben bei jedem Arbeitspaket.
Und was haben wir damit verbessert? Drei Dinge, die ich sehe, noch ohne die Zahlen, die ich im nächsten Abschnitt verlange.
Der Agent baut dort, wo es hingehört. Weil er die Grenzen kennt, legt er keine zweite Hilfsfunktion neben die bestehende und keinen Querzugriff zwischen Modulen, die nichts voneinander wissen sollen. Das war vorher der häufigste Änderungswunsch im Review. Er ist nicht weg, aber er ist selten geworden.
Kein Agent nimmt sich selber ab. Das haben wir von Anfang an so gebaut und es ist die Regel, die am meisten bringt. Wer schreibt, prüft nicht. Ein anderer Agent prüft die Regeln, einer die Tests, und erst dann kommt der Mensch. Der sieht einen Pull Request, der schon durch den langweiligen Teil durch ist.
Das Review fliesst zurück. Ein Änderungswunsch eines Menschen bleibt nicht im Pull Request liegen. Er wird zu einem Eintrag im Projektwissen, und beim nächsten Arbeitspaket weiss der Agent, dass es diese Regel gibt. Das ist der Teil, der am meisten Disziplin braucht, weil es verlockend ist, die Korrektur einfach zu machen und weiterzugehen.
Nichts davon ist Magie. Es ist Reihenfolge: erst das System, dann der Code. Und genau diese Reihenfolge ist es, die die Studie vermisst. Die 30 Prozent mehr Code entstehen bei Werkzeugen, die mit dem Code anfangen. Wir fangen mit dem System an und würden lieber 30 Prozent weniger Review haben. Ob das stimmt, kommt jetzt.
Was ich selber beweisen muss
Und jetzt die Stelle, an der ich mich selber in die Pflicht nehme, weil ich sonst genau das mache, was ich den anderen vorwerfe. Alles im letzten Abschnitt ist eine These. Die Studie belegt den Engpass. Sie belegt nicht, dass mein Ansatz ihn löst. Das kann nur eine Messung, und die habe ich noch nicht.
Was wir bei NeoCoder messen müssen, mit und ohne Wissensaufbau, auf denselben Aufgaben: die Zeit pro Review, der Anteil der Pull Requests mit Änderungswünschen, die Zahl der Kommentare, und die Fehlerrate nach dem Merge. Genau die Zahlen der Studie, nur bei uns. Wenn die Review-Zeit mit Wissensaufbau sinkt und die Änderungswünsche zurückgehen, ist die These bestätigt. Wenn nicht, schreibe ich das auch hier. So wie bei dem Modell, das gegen die Baseline unentschieden gespielt hat und liegen geblieben ist.
Was bleibt
Die Studie ist gut, weil sie ehrlich ist. 30 Prozent mehr Code, 49 Prozent längeres Review, null Effekt am Ende. Die Überschrift darüber ist falsch. KI macht Entwickler nicht unproduktiver, sie verschiebt die Arbeit an eine Stelle, an der wir sie noch nicht organisiert haben. Wer jetzt noch mehr Agenten kauft, kauft mehr Review. Wer das System um die Agenten herum baut, mit Wissen vorher, Prüfung dazwischen und Gedächtnis danach, bekommt vielleicht das, was alle versprochen haben. Vielleicht. Das ist der Teil, den jeder von uns selber messen muss.
Nicht die Geschwindigkeit, mit der Code entsteht, entscheidet über die nächsten Jahre. Sondern ob jemand das System versteht, das dabei herauskommt. Die Studie zeigt, dass wir den Engpass verschoben haben, nicht beseitigt. Die Antwort ist nicht weniger KI und nicht mehr Reviewer. Die Antwort ist ein Prozess, in dem der Code, der beim Menschen ankommt, schon klein, regelkonform und bekannt ist. Ob das funktioniert, muss man messen. Ich fange damit an.
Quelle: Noëlle Bölling, „Laut Harvard-Studie: Warum Software-Entwickler durch KI nicht wirklich produktiver sind", t3n, 9. Oktober 2026, über Fiona Chen und James Stratton, „Artificial Intelligence in the Enterprise: Bottlenecks in Software Production", Harvard, Daten von Jellyfish. Zahlen und Zitate sinngemäss. t3n.de
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.