Agentic Software Engineering: Qualität nur mit Erfahrung

Kurzfassung. Review-Kompetenz entscheidet über die Qualität von KI-generiertem Code, nicht die KI selbst: Laufende Systeme verbergen Lücken in Sicherheit, Architektur und Wartbarkeit. Deshalb ist Review-Kompetenz eine Zulassungsbedingung, kein optionales Qualitätsmerkmal. KI erhöht Tempo und Volumen — und macht menschliches Urteil dadurch wichtiger, nicht überflüssig.

Dass KI Software generieren kann, wissen mittlerweile viele — Vibe Coding gehört für manche schon zum Alltag. Ein Satz, und eine hübsche Oberfläche steht. Sichere, nachhaltig wartbare und langfristig nutzbare Software für hunderte Anwender ist aber ein anderes Level.

Meine Erfahrung aus mehreren Projekten: Auch das ist möglich, in guter Qualität — mit der richtigen Methodik. Unabhängige Bewertungen mit externen Gutachtern, jeweils mit über 15 Jahren Seniorität und einer strukturierten Evaluierung in mehreren Kategorien, bestätigen im ersten Durchlauf 7 von 10 Punkten. Prozessverbesserungen und deterministische Werkzeuge — Linter, SAST und ähnliche — können das langfristig noch verbessern. Das erfahrene Urteil bleibt trotzdem ein knappes Gut. Das verändert Softwareentwicklung fundamental.

Wer KI-generierten Code in die Codebasis übernimmt, muss ihn deshalb vollständig fachlich bewerten können. Review-Kompetenz ist eine Zulassungsbedingung, kein optionales Qualitätsmerkmal. Und weil KI Geschwindigkeit und Volumen erhöht, wird das menschliche Gate wichtiger, nicht überflüssig.

Was ein laufendes System nicht verrät

Funktionale Korrektheit ist die eine Eigenschaft, die auch jemand ohne Entwicklungserfahrung prüfen kann: Läuft es, ja oder nein. Sie ist zugleich die Eigenschaft, die am wenigsten über Robustheit und Wartbarkeit aussagt. Genau daraus entsteht der Irrtum. Wer den Vergleichsmaßstab nicht hat, sieht ein laufendes System und schließt auf Qualität — während die Lücken in Sicherheit, Architekturkonformität und Wartbarkeit sich beim Ausführen gar nicht zeigen können. Das ist kein individuelles Versagen, sondern ein strukturelles Risiko: Es trifft zuverlässig jeden, dem die Erfahrung fehlt, unabhängig von Sorgfalt und gutem Willen.

Was mehrere Projekte gezeigt haben und durch weitere Quellen bestätigt wird

Ein Doppel-Review durch erfahrene Entwickler, unabhängig voneinander, deckte Fehleinschätzungen auf — vor allem in den Sicherheitskategorien, und Inkonsistenzen durch unklare Vorgabe von Standards. Vieles davon kann durch Verbesserung in der Methodik wiederholbar noch verbessert werden. Das heißt, in Zukunft erhalten wir eventuell Ergebnisse auf dem Niveau eines Senior-Entwicklers.

Es hatte aber einen Preis, den ich unterschätzt hatte. In der Abschlussbewertung eines Piloten steht er als eigener Punkt: Der Aufwand für Reviews von fremdem oder KI-erzeugtem Code steigt, und bei denen, die diesen Code künftig verantworten sollen, sinken Motivation und Zugehörigkeitsgefühl. Wer eine KI-gebaute Codebasis übernimmt, fühlt sich, als übernehme er fremden Code. Eingeordnet wurde das dort als kritischer Befund und als Adoptionsrisiko — nicht als Stimmungsproblem.

Weniger erfahrene Entwickler nehmen funktional korrekten Output leichter für bare Münze. Und — das gehört zur Ehrlichkeit dazu — der geprüfte KI-Code war nicht grundsätzlich schlechter als von Menschen geschriebener Code.

Der Vergleichsmaßstab verschiebt sich dabei. In einem anderen Projekt wurde ein vergleichbarer Aufwand bei einem Junior-Entwickler beobachtet, der zusätzlich in einer regulierten, gut ausgestatteten automatisierten Umgebung arbeitete, die systematisch nach Lücken sucht. Ein Projektteam, das einen Junior-Entwickler einbindet, hätte demnach einen ähnlichen Aufwand wie bei KI-generiertem Code — nicht mehr, aber auch nicht weniger.

Unabhängig davon beobachteten Xu und Kollegen 2025 dasselbe Muster in Open-Source-Projekten: Nach Einführung eines KI-Assistenten reviewten die Kernentwickler 6,5 Prozent mehr Code, bei einem Rückgang von 19 Prozent an eigener Codeproduktion.¹ Der Produktivitätsgewinn kam überwiegend von den weniger erfahrenen Beitragenden. Die Studie beobachtet und kontrolliert nicht — die Kausalität ist schwächer belegt, als ihr Titel nahelegt. Die Richtung deckt sich trotzdem mit dem, was wir im eigenen Piloten gesehen hatten: Die Reviewlast wandert zu den Erfahrenen.

Die fundamentale Änderung der Softwareentwicklung ist in vollem Gange und im Vergleich kaum noch beurteilbar

Es gibt Befunde, die dagegen sprechen. Molison und Kollegen fanden 2025, dass KI-generierter Code insgesamt weniger Fehler enthielt und weniger Aufwand zur Behebung brauchte als menschlicher Code;² bei besonders schweren Aufgaben entstanden allerdings Strukturprobleme, die menschlicher Code nicht hatte. Und METR maß 2025 etwas noch Unbequemeres: Erfahrene Entwickler waren mit KI-Werkzeugen 19 Prozent langsamer, schätzten sich hinterher aber 20 Prozent schneller ein.³ Sie konnten die eigene Verlangsamung aus der Erfahrung heraus nicht erkennen.

Bei METR gehört eine Einschränkung dazu, die METR selbst macht — und sie ist aufschlussreicher als die Zahl. Die Organisation versuchte die Messung zu wiederholen und meldete im Februar 2026, dass das Verfahren nicht mehr trägt:⁴ Zu viele Entwickler wollten nicht ohne KI arbeiten. Ein Teil lehnte die Teilnahme ab, zwischen 30 und 50 Prozent der Teilnehmer hielten einzelne Aufgaben zurück, um sie nicht ohne Werkzeug erledigen zu müssen. Die neuen Schätzwerte deuten auf Beschleunigung, METR nennt sie selbst einen schlechten Näherungswert. Ob die 19 Prozent heute noch gelten, ist damit offen — dass sich eine Vergleichsgruppe kaum noch bilden lässt, ist der belastbarere Befund.

Eine Studie, die das direkt prüft — ob Review-Kompetenz die Freigabe sicherer macht —, gibt es nicht. Der METR-Befund liest sich für mich aber sogar andersherum, und zwar unabhängig davon, ob die Zahl Bestand hat. Wenn erfahrene Entwickler die eigene Verlangsamung nicht bemerken, dann spricht das gegen das Bauchgefühl als Prüfinstanz — und damit für ein Verfahren, das unabhängige Urteile erzwingt und ihre Abweichung sichtbar macht. Also für das Doppel-Review, nicht für Vertrauen auf Erfahrung allein. Das war der Punkt, an dem ich meine eigene Begründung nachschärfen musste: Erfahrung qualifiziert zum Urteil, sie ersetzt das Verfahren nicht.

Für mich die klare Konsequenz mit vielen offenen Punkten

KI-generierte Software ist die Zukunft, kann aber nur durch optimierte Entwicklungsprozesse in Kombination aus deterministischen Sicherungen und agentischen Systemen eine ausreichende Qualität erreichen. Die Hype-Begriffe Agent Harness, Guardrails und ähnliche reichen dabei nicht aus, und es gibt bislang wenige Anbieter, die hier schon die nötige Reife erreicht haben. Von Standards kann man noch nicht sprechen, auch wenn Ansätze wie SpecKit oder BMAD sehr gute Ideen einbringen. Heute sehen wir, dass eine fachliche Qualifikation durch menschliche Experten unerlässlich ist. Gleichzeitig werden die Menge an produziertem Code und die Zahl der Applikationen durch nicht-technische Rollen zu einem Problem für die Qualitätssicherung. Review-Verfahren für KI-Output müssen ausdrücklich auf Robustheit und Wartbarkeit ausgelegt sein, nicht nur darauf, ob etwas läuft. Und ein Team ohne erfahrene Aufsicht sollte eine KI-Einführung nicht ohne Begleitung beginnen — sonst wandert die technische Schuld unbemerkt in die Codebasis, und zwar schneller als zuvor.

Misstrauen gegenüber KI ist das nicht. Es ist eine Governance-Frage: wer freigeben darf, und auf welcher Grundlage.

Wie dieser Text entstanden ist
─────────────────────────────────────────────────────────────
Modell            Claude Opus 5 und Claude Sonnet 5 (Anthropic),
                  Stand 2026-09
Arbeitsweise      Einstieg selbst geschrieben, Fortsetzung durch das
                  Modell, danach drei Redaktionsdurchgänge, Absatz für
                  Absatz
Eigenanteil       Einstieg, Piloterfahrung und ihre Bewertung, die These zu
                  Review-Kompetenz als Zulassungsbedingung, die Konsequenzen und die
                  Schlusspointe
Geprüft           Quellenprüfung inklusive Gegenbelegen · jeder Absatz auf
                  seinen Beitrag geprüft · Kennzeichnung jeder Zahl ·
                  Kurzfassung gegen den Text geprüft · Strukturprüfung
Quellen           5 belegt, davon 5 Primärquellen (siehe Fußnoten)
Verantwortlich    Michael Koch, 2026-09-25
Verfahren         innopractics.de/schreiben-mit-ki