Softwarequalität mit Coding-Agenten: erzeugen, verstehen, überprüfen.

Produktivität und Qualität stehen nicht automatisch in einem bestimmten Verhältnis.

Das 2026 veröffentlichte Experiment von Borg und Kollegen mit 151 Teilnehmenden findet keine signifikanten Unterschiede in der späteren Wartbarkeit von Code, der mit KI-Assistenten entstand. Die Aufgaben wurden Ende 2024 bearbeitet, vor den heutigen Coding-Agenten.

Liu und Kollegen analysieren dagegen rund 302.600 der KI zugeschriebene Commits in 6.299 Repositories. Sie erkennen Probleme durch statische Analyse; 22,7 % davon bestehen in der letzten beobachteten Revision fort. Dies belegt fortbestehende Probleme in der Stichprobe, misst aber weder alle Fehler noch den Vergleich mit jedem menschlichen Entwickler.

GitClear beobachtet während der Verbreitung von KI mehr Duplikation und weniger Refactoring. Diese Signale verdienen Aufmerksamkeit, belegen allein aber keine einzelne Ursache. Zusammen sprechen die Arbeiten dafür, die Auswirkungen im eigenen Prozess zu messen.

Wenn ein Agent mehr Code ändert, als ein Team verstehen und prüfen kann, wird der anfängliche Geschwindigkeitsgewinn möglicherweise zu Review- und Wartungsaufwand. Dieses Risiko halte ich für zentral.

Ich schlage vor, Erstellung und Validierung zu trennen: Abnahmekriterien und Referenzergebnisse sollten auch außerhalb des Prozesses geprüft werden, der die Änderung erzeugt hat. Ein zweiter Agent kann helfen, aber dieselben Fehler wie der erste machen.

• Verhaltens-, Integrations-, Vertrags- und Regressionstests entsprechend dem Risiko.
• Statische Analyse, Sicherheitsprüfungen und Prüfung der Abhängigkeiten.
• Reviews mit klaren Kriterien und Abgleich mit fachlichen Anforderungen und Vorgaben.
• Änderungen, die klein genug bleiben, um Fehler und Folgen erkennen zu können.

Nicht jede Zeile braucht dieselbe menschliche Prüfung. Eine Person muss jedoch für die Entscheidung verantwortlich sein; wo Fehler schwerere Folgen haben, sind stärkere Prüfungen erforderlich.

Eine Harness umfasst Kontext, Regeln, Werkzeuge und Verfahren. Ihre Verbesserung kann den Agenten wirksamer machen, aber auch eine falsche Interpretation schneller verbreiten.

Deshalb gehören für mich auch Aktionsgrenzen und Abbruchbedingungen dazu: fehlgeschlagene Tests, unklare Anforderungen, unerwartete Unterschiede oder fehlende Prüfungen. Entscheidend ist, eine falsche Änderung zu erkennen, bevor sie ins Produkt gelangt.

Meine Methode: Spezifikationen und Projekt-Harness →

Mit „Verständnisschulden“ oder „Cognitive Debt“ beschreibe ich ein Risiko: Die Software funktioniert weiterhin, doch immer weniger Menschen verstehen, warum sie so aufgebaut wurde. Das ist ein hilfreiches Konzept, keine etablierte Standardmetrik.

Dokumentierte Entscheidungen, Gespräche über die Fachdomäne und gemeinsame Prüfungen erhalten dieses Wissen. Zur Entwicklerrolle gehören Anforderungen, Architektur, Kontext und die Beurteilung von Änderungen; auch bei delegierter Umsetzung bleiben diese Fähigkeiten erforderlich.

Im September 2026 beschreibt Shopify den Wechsel von React Native zu Swift und Kotlin. Das Framework wird nicht als gescheitert dargestellt: Coding-Agenten haben die Kosten für zwei native Implementierungen verändert.

Die Shop-App wurde in etwa zwölf Wochen neu gebaut und veröffentlicht. Die Migration der Shopify-App mit über 300 Bildschirmansichten wird dagegen als laufend beschrieben. Dies ist eine konkrete Unternehmenserfahrung, keine auf andere Anwendungen übertragbare Zeitplanung.

Shopify nutzt dafür Helix: kleine Checkpoints mit Tests, visuellem Vergleich und zwei unabhängigen agentischen Reviews. Die Freigabe durch einen Ingenieur ist die Standardeinstellung; ein autonomer Modus ist ebenfalls vorgesehen.

Der Fall zeigt eine Möglichkeit: Geringere Umsetzungskosten können eine zuvor zu teure Architekturentscheidung praktikabel machen. Das Ergebnis hängt auch von Prozess, Tests und Änderungskontrollen ab.

Shopify beschreibt zudem eine für Agenten zugängliche Architektur: von der Oberfläche getrennte Logik und schnelle Tests über die Kommandozeile.

Daraus leite ich einen allgemeineren Vorschlag ab: Klare Verantwortlichkeiten, ausdrückliche Verträge, schnelle Tests und verständliche Beobachtbarkeit erleichtern Menschen und Agenten die Arbeit am System. Dafür ist nicht derselbe Technologie-Stack erforderlich.

Ein Coding Agent kann selbstständiger arbeiten, wenn ihm ein Prüfzyklus zur Verfügung steht: Er ändert den Code, führt Prüfungen aus, liest Fehlermeldungen und korrigiert Fehler. Automatisierte Tests sind neben der Kompilierung und weiteren relevanten Prüfungen ein zentraler Bestandteil dieses Zyklus. Ein strikter TDD-Prozess ist dafür nicht zwingend erforderlich; entscheidend sind wiederholbare Rückmeldungen zum geforderten Verhalten.

Bei manchen Legacy-Anwendungen erfordert die Prüfung einer Änderung den Start des gesamten Systems, eine Datenbank mit geeigneten Daten, externe Dienste und schwer reproduzierbare Konfigurationen. Wenn die Logik eng mit diesen Abhängigkeiten verbunden ist und automatisierte Tests fehlen, verursacht die Einrichtung eines Prüfzyklus zusätzlichen Aufwand. Auch eine neuere Anwendung kann dieselben Einschränkungen aufweisen.

Eine Datenbank verhindert die Automatisierung nicht: Testumgebungen und zurücksetzbare Daten lassen sich vorbereiten. Dennoch kann es nötig sein, den Start zu dokumentieren, Tests für das bestehende Verhalten einzuführen und einzelne Abhängigkeiten schrittweise zu trennen. Dieser Aufwand gehört in die anfängliche Bewertung des Agenteneinsatzes. Wo Prüfungen überwiegend manuell bleiben, würde ich die Autonomie des Agenten begrenzen und kleine Änderungen mit ausdrücklichen menschlichen Kontrollen vorsehen.

Der Anteil KI-generierten Codes, Token, Prompts oder die Anzahl von Pull Requests reichen zur Nutzenmessung nicht aus. Ich vergleiche Bearbeitungs- und Reviewzeiten, Fehler, Regressionen, Nacharbeit und die Fähigkeit, das Produkt weiterzuentwickeln.

Das SPACE-Framework behandelt Produktivität als mehrdimensional. Entsprechend schlage ich vor, Ergebnisse, Zusammenarbeit und nachhaltige Arbeitsweisen gemeinsam zu bewerten, ohne aus einer einzelnen Messgröße eine Rangliste der Entwickler zu machen.

Mein Ziel wäre korrekte, nützliche und wartbare Software zu tragbaren Kosten.

Die Studien nutzen unterschiedliche Methoden und untersuchen verschiedene Kontexte. Die Vorschläge zur Validierung und zur Entwicklerrolle sind daraus abgeleitete Arbeitsgrundsätze, keine Zusage eines allgemeingültigen Ergebnisses.

• Borg et al. — Echoes of AI (öffnet in einem neuen Tab): Experiment zur späteren Wartung; Daten von Ende 2024.
• Liu et al. — Debt Behind the AI Boom, Version 2 (öffnet in einem neuen Tab): der KI zugeschriebene Commits und statisch erkannte Probleme.
• GitClear — Maintainability Gap (öffnet in einem neuen Tab): beobachtete Signale zu Duplikation, Wiederverwendung und Wartung.
• Shopify — Entscheidung für native Entwicklung (öffnet in einem neuen Tab): Gründe des Wechsels und für Agenten zugängliche Architektur.
• Shopify — Migration der Shop-App (öffnet in einem neuen Tab): Erfahrung und Zeitrahmen des konkreten Projekts.
• Shopify — Helix (öffnet in einem neuen Tab): Checkpoints und Prüfungen bei der Migration der Shopify-App.
• Forsgren et al. — SPACE (öffnet in einem neuen Tab): ergänzende Dimensionen der Entwicklerproduktivität.
• Claude Code — Best practices (öffnet in einem neuen Tab): Kriterien und Prüfungen, die der Agent ausführen kann.
• Martin Fowler — Legacy Seam (öffnet in einem neuen Tab): Trennung von Abhängigkeiten zur Prüfung bestehenden Codes.
• Microsoft — Choosing a testing strategy (öffnet in einem neuen Tab): Tests mit echten Datenbanken, Isolation und Grenzen von Test-Doubles in EF-Core-Projekten.