Vollautomatische Softwarefabriken sollen dafür sorgen, dass Entwicklerteams nicht länger der Flaschenhals sind. Zwei Jahre Telemetriedaten aus 4.000 Teams zeigen das Gegenteil: Der Durchsatz steigt, die Störungen je Pull Request steigen dreimal so schnell. Ab dem 9. Dezember 2026 haftet dafür in Deutschland der Hersteller.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Die vollautomatische Softwarefabrik, in der KI-Agenten Code ohne menschliche Prüfung ausliefern, gilt vielen als nächster logischer Schritt. Dex Horthy, Gründer der Entwicklerplattform HumanLayer, hat aufgeschrieben, warum das Modell an genau einem Punkt scheitert, den kein besserer Prompt repariert.[1]

Das Wichtigste in Kürze

  • Das Verhältnis von Störungen zu Pull Requests ist um 242,7 Prozent gestiegen, die Zahl der Bugs je Entwickler um 54 Prozent.
  • 31,3 Prozent mehr Pull Requests landen ohne jede Review im Hauptzweig.
  • Die Ursache steckt im Training: Dort zählt allein der bestandene Test, nie eine wartbare Architektur.
  • Ab dem 9. Dezember 2026 gilt Software in Deutschland als Produkt im Sinne der Produkthaftung.

Was kostet das Tempo wirklich?

Wackliger Holzklötzchenturm mit orangefarbenen Steinen, einem Aufziehschlüssel und einem Zettel
Durchsatz steigt 66 Prozent, Störungen pro Pull Request 242,7 Prozent. Fehlersuche und Reviews werden zur Belastung

Der Durchsatz steigt um 66 Prozent, die Störungen je Pull Request um 242,7 Prozent. Das Tempo kommt nicht gratis: Arbeit verlagert sich aus der Produktion in die Fehlersuche und in ein Review, das die Menge nicht mehr bewältigt.

Das Analysehaus Faros AI hat dafür zwei Jahre Telemetriedaten von 22.000 Entwicklern ausgewertet.[2] Das Tempo ist real: 66 Prozent mehr abgeschlossene Epics je Entwickler.

Die Gegenrechnung fällt deutlicher aus: Die Störungen je Pull Request haben um 242,7 Prozent zugelegt, die Bugs je Entwickler um 54 Prozent, der kurzfristig wieder überschriebene Code um 861 Prozent. Das Prüfsystem ist überlastet, denn die mediane Zeit bis zur ersten Review ist um 156,6 Prozent gestiegen.

Googles DORA-Report 2025 kommt unabhängig zum selben Befund: Höhere KI-Nutzung verbessert fast jede Kennzahl, mit einer einzigen Ausnahme, der Stabilität der Auslieferung.[3] Auch Microsofts Zahlen zu Claude Code und Copilot CLI zeigen mit 24 Prozent mehr Pull Requests, dass sich die Arbeit von der Produktion zur Prüfung verlagert.

Warum lernen Modelle keine Wartbarkeit?

Benchmarks prüfen genau eine Frage: Läuft der Test durch? Eine erodierende Architektur kostet dagegen erst nach Monaten Geld. Diese Verzögerung lässt sich im Reinforcement Learning nicht auf die Entscheidung zurückrechnen, die sie verursacht hat.

Horthy formuliert das so: „Tests geben Rückmeldung in Sekunden, die Kosten schlechter Architektur bemessen sich in Wochen, Monaten, vielleicht Jahren.“[1] Ein Strafmaß fehlt, weil nachlassende Wartbarkeit in keinem Trainingsverfahren einen Preis hat. Wie leicht ein Benchmark selbst zum Ziel wird, hat der Streit um den Pelikan-Test gezeigt.

Dass die Wahrnehmung trügt, hat das Forschungsinstitut METR 2025 randomisiert belegt: 16 erfahrene Entwickler haben 246 echte Aufgaben gelöst, mit KI-Werkzeugen 19 Prozent länger gebraucht und sich trotzdem um 20 Prozent schneller eingeschätzt.[4] Selbstauskunft taugt nicht als Steuerungsgröße. Wartbarer Code wird damit von der Stilfrage zur Kostenfrage.

Ein Agent, der in drei Tagen liefert, wofür ein Team drei Wochen braucht, ist kein Fortschritt, wenn die Rechnung zwei Quartale später als Störungsprotokoll auf dem Tisch liegt.

— Markus Seyfferth, Chefredakteur Dr. Web
Mehr Tempo, weniger Stabilität: zwei Jahre KI im Entwicklungsalltag

Telemetriedaten von 22.000 Entwicklern und mehr als 4.000 Teams, ausgewertet von Faros AI für den AI Engineering Report 2026.

+66 %

abgeschlossene Epics je Entwickler

+242,7 %

Störungen je Pull Request

+54 %

Bugs je Entwickler

+31,3 %

Pull Requests ohne jede Review

Wo die Rechnung auseinanderläuft

Sichtbar in Sekunden
  • Test bestanden oder nicht. Genau das messen die gängigen Coding-Benchmarks.
  • Pull Request ist offen. Der Durchsatz erscheint sofort im Dashboard.
  • Feature funktioniert. Die Demo läuft, das Ticket schließt.
Sichtbar in Monaten
  • Architektur erodiert. Kein Trainingsverfahren bestraft schwer änderbaren Code.
  • Review staut sich. Die mediane Zeit bis zur ersten Prüfung liegt 156,6 % höher.
  • Code wird neu geschrieben. Kurzfristig überschriebener Code hat um 861 % zugelegt.
  • Haftung greift. Ab dem 9. Dezember 2026 gilt Software als Produkt.

Stichtag 9. Dezember 2026: Mit dem modernisierten Produkthaftungsrecht gelten Software und KI-Systeme in Deutschland als Produkte. Dokumentieren Sie deshalb schon jetzt, welcher Code agentisch entstanden ist und wer ihn freigegeben hat.

Was ändert sich im Dezember für deutsche Anbieter?

Am 9. Dezember 2026 tritt das modernisierte Produkthaftungsrecht in Kraft. Software und KI-Systeme gelten dann als Produkte. Integriert ein Hersteller fremden Code, haftet er für dessen Fehler mit.

Die Richtlinie (EU) 2024/2853 erfasst erstmals Software, KI-Systeme, digitale Konstruktionsunterlagen und verbundene Dienste.[5] Die Beweislast verschiebt sich: Ein Fehler wird bereits vermutet, wenn ein Produkt bei vorhersehbarem Gebrauch offensichtlich versagt. Nicht-kommerzielle Open-Source-Entwicklung bleibt ausgenommen.

Für Softwarehäuser und Agenturen im DACH-Raum verschiebt das den Maßstab: Ein Merge ohne Review ist dann nicht mehr nur ein Qualitätsrisiko, sondern eine Lücke in der Dokumentation. Vier Schritte lohnen sich vor dem Stichtag:

  • Den agentisch entstandenen Codeanteil je Repository erfassen und protokollieren.
  • Merges ohne menschliche Freigabe technisch sperren, statt sie nur zu missbilligen.
  • Störungen je Pull Request als feste Kennzahl neben dem Durchsatz führen.
  • Architektur und Datenverträge vor dem Prompt festlegen, nicht im Review.

Horthy hält zwei- bis dreifach schnellere Entwicklung für erreichbar, sobald die menschliche Arbeit nach vorn wandert, in Produktentscheidung, Systemarchitektur, Programmentwurf und vertikal geschnittene Teillieferungen. Seine Faustregel lautet: „30 Minuten Planung sparen Stunden im Review.“[1] Die zehn- bis hundertfachen Sprünge tauchen in den Messdaten nicht auf.

Quellen

[1] HumanLayer, Dex Horthy: „Why Software Factories Fail“

[2] Faros AI: „AI Engineering Report 2026: The Acceleration Whiplash“ (PDF)

[3] DORA (Google): „State of AI-assisted Software Development 2025“

[4] METR: „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“

[5] Amtsblatt der EU: Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte

Mehr Newshunger?

4,4 20 Bewertungen

Wie hat Ihnen dieser Artikel gefallen?