Agentische SoftwareentwicklungWenn KI mehr Code produziert, als Menschen prüfen können.

01 / Ergebnisse absichern

Der Paradigmenwechsel: Von der Codekontrolle zur Ergebnisabsicherung

In der klassischen Softwareentwicklung ist menschliches Code-Review ein wichtiger Bestandteil der Qualitätssicherung.

Bei agentischer Entwicklung verändert sich die Arbeitsteilung.

Ein Coding-Agent kann beispielsweise:

• Eine Anforderung analysieren und implementieren.
• Bestehende Funktionen auf potenzielle Auswirkungen untersuchen.
• Unit-, Integrations- und Regressionstests erstellen.
• Tests ausführen und Fehler selbstständig korrigieren.
• Seine Änderungen als Pull Request bereitstellen.

Ein zweiter, möglichst unabhängig arbeitender Agent kann anschließend Code, Tests und Anforderungen überprüfen, Fehler identifizieren und Korrekturen anfordern.

Dieser Review-Rework-Zyklus lässt sich für geeignete Aufgaben weitgehend automatisieren.

Entscheidend ist dabei eine Unterscheidung:

Ein bestandenes KI-Review ist kein Beweis für korrekte Software.

Deshalb müssen agentische Reviews durch unabhängig überprüfbare Nachweise ergänzt werden: automatisierte Tests, statische Analysen, Sicherheitsprüfungen und bei Bedarf Simulationen oder Hardwaretests.

Das Ziel ist nicht die Abschaffung menschlicher Verantwortung. Es ist die bessere Nutzung knapper menschlicher Expertise.

02 / Vier Risikoklassen

Vier Risikoklassen statt pauschalem Review-Zwang

Nicht jede Softwareänderung benötigt denselben Prüfaufwand.

Ein korrigierter Tippfehler in einer Benutzeroberfläche hat ein anderes Risikoprofil als eine Änderung an der Notabschaltung einer Industriemaschine.

Ich empfehle deshalb vier Risikoklassen als Ausgangspunkt:

Diese Einteilung ist eine vorgeschlagene interne Steuerungssystematik, keine gesetzliche Risikoklassifizierung.

Wichtig: Das potenzielle Schadensausmaß bestimmt die Risikoklasse, nicht die Anzahl geänderter Codezeilen.

Praxisbeispiel: Cloud-Anwendung

Ein Hersteller entwickelt ein Kundenportal für Ersatzteilbestellungen.

Ein Agent soll eine zusätzliche Sortierfunktion in einer bestehenden Übersicht implementieren.

Sind Darstellung und Sortierlogik isoliert, könnte die Änderung als R1 eingestuft werden.

Dazu gehören beispielsweise:

• Tests für unterschiedliche Sortierkriterien und leere Ergebnislisten.
• Prüfung, dass bestehende Filter weiterhin funktionieren.
• Automatisierte Regressionstests.
• Unabhängiges agentisches Review.

Ändert derselbe Agent hingegen die Mandantentrennung oder Zugriffskontrolle, wird eine höhere Risikoklasse erforderlich – selbst wenn nur wenige Zeilen betroffen sind.

Praxisbeispiel: Embedded Software

Ein Agent soll die Timeout-Behandlung eines Steuerungsmoduls verändern.

Dabei kann ein Fehler im ungünstigsten Fall physische Schäden verursachen.

Hier reichen Unit-Tests und KI-Code-Review nicht aus. Je nach System sind zusätzliche Verfahren nötig, beispielsweise Hardware-in-the-Loop-Tests, Timing-Analysen, Fehlersimulationen und sicherheitstechnische Freigaben.

Die Entwicklungsautomatisierung kann in beiden Fällen weitgehend identisch sein. Die notwendigen Nachweise und Freigaben sind unterschiedlich.

03 / Der Workflow

Der praktische Workflow: Entwickeln, prüfen, korrigieren, freigeben

Für die meisten mittelständischen Unternehmen genügt zunächst ein schlanker Workflow:

1Anforderungen und Risiko bestimmen

Ein Triage-Agent analysiert die Aufgabe, identifiziert betroffene Komponenten, schlägt Akzeptanzkriterien vor und empfiehlt eine Risikoklasse.

Bei unklaren oder kritischen Auswirkungen entscheidet ein Mensch.

2Implementieren

Der Coding-Agent entwickelt die Änderung einschließlich notwendiger Tests.

3Automatisch verifizieren

Eine CI-Pipeline führt geeignete Prüfungen durch:

• Build, Linting, Typprüfung und Tests
• Statische Sicherheitsanalyse und Secret Scanning
• Prüfung von Abhängigkeiten und Lizenzen
• Projektspezifische Architektur- und Qualitätsregeln

4Unabhängig überprüfen

Ein separater Review-Agent sucht gezielt nach funktionalen Fehlern, Sicherheitsproblemen, Regressionen, unnötiger Komplexität und fehlenden Testfällen.

5Automatisch nacharbeiten

Bestätigte Findings werden an den Coding-Agenten zurückgegeben.

Nach jeder Korrektur werden die betroffenen Tests und Reviews erneut ausgeführt. Zwei erfolglose Review-Rework-Runden sind beispielsweise ein sinnvoller Eskalationspunkt, kein Grund für eine Endlosschleife.

6Risikobasiert freigeben

Risikoarme Änderungen können nach hinreichender Validierung automatisiert freigegeben werden. Kritische Änderungen gehen mit einer kompakten Übersicht der Nachweise und offenen Risiken an die verantwortliche Person.

7Aus Ergebnissen lernen

Später entdeckte Fehler, menschliche Korrekturen und tatsächliche Release-Probleme fließen in die Verbesserung des Verifikationsprozesses ein.

Für diesen Workflow sind nicht zwingend sieben verschiedene Agenten erforderlich. Zwei Agentenrollen, ein Coding-Agent und ein unabhängiger Reviewer, ergänzt um CI und eine einfache Triage, sind häufig der bessere Anfang.

04 / Vier Vorlagen

Vier direkt einsetzbare Vorlagen

Der größte Hebel liegt nicht in besonders langen Prompts, sondern in eindeutigen Arbeitsaufträgen, überprüfbaren Qualitätskriterien und verbindlichen technischen Grenzen.

05 / Weniger Komplexität

Ein unterschätztes Problem: KI erzeugt häufig zu viel

Coding-Agenten neigen teilweise dazu, Anforderungen überzuerfüllen.

Typische Beispiele sind:

Dokumentationsinflation: Für kleine Änderungen werden umfangreiche Markdown-Dateien, zusätzliche Architekturübersichten oder vollständige Change-Histories erzeugt.

Overengineering: Eine einfache Funktion wird in mehrere neue Klassen, Interfaces und Abstraktionsschichten zerlegt.

Testinflation: Zahlreiche Tests prüfen dieselbe Eigenschaft, während wichtige Grenzfälle fehlen.

Scope Creep: Der Agent refaktoriert angrenzende Komponenten, obwohl diese nicht Bestandteil des Auftrags waren.

Review-Theater: Agenten produzieren lange Review-Berichte mit vielen kosmetischen Feststellungen, aber wenig zusätzlicher Sicherheit.

Die Gegenmaßnahme ist eine explizite Optimierung auf Minimum Sufficient Engineering.

Jede zusätzliche Datei, Abstraktion, Dependency oder Dokumentation sollte einen nachvollziehbaren Nutzen besitzen.

Ein konkretes Beispiel: In einem Git-Repository gehört die normale Änderungshistorie in Git und die Pull Requests – nicht als neu generierte Historie in jede bearbeitete Quelldatei.

Architekturentscheidungen sollten dagegen dann dokumentiert werden, wenn sie späteren Entwicklern helfen, nicht offensichtliche Zusammenhänge oder bewusst akzeptierte Trade-offs zu verstehen.

Das spart nicht nur Tokens, sondern reduziert langfristige Wartungskosten.

06 / Vertrauen messen

Wie vertrauenswürdig ist ein KI-Review wirklich?

Ein Agent kann eine Änderung als korrekt bewerten und trotzdem einen Fehler übersehen.

Deshalb halte ich Prozentangaben wie „99 % Konfidenz“ für problematisch, wenn sie lediglich aus der Selbsteinschätzung eines Modells stammen.

Besser ist eine empirische Messung des gesamten Prüfprozesses.

Beispiel: Ein Unternehmen zieht eine Zufallsstichprobe von 300 automatisch akzeptierten Änderungen aus einer vergleichbaren, risikoarmen Aufgabenklasse. Qualifizierte Menschen prüfen sie zusätzlich. Dabei wird kein relevanter übersehener Fehler festgestellt.

Unter den unten genannten Annahmen ergibt sich eine einseitige 95%-Konfidenzobergrenze von rund 0,994 %, gerundet also 1 %. Gemeint ist der Anteil automatisch akzeptierter Änderungen, die trotzdem mindestens einen relevanten Fehler enthalten – nicht die Zahl der Fehler pro Codezeile.

Wann trägt diese Rechnung?

• Die Stichprobe ist repräsentativ für die betrachtete Aufgabenklasse; die Beobachtungen sind unabhängig und stammen aus einem Prozess mit gleichbleibender Fehlerwahrscheinlichkeit. Viele Varianten desselben Patches zählen nicht einfach als unabhängige Fälle.
• Stichprobengröße und Fehlerkriterien stehen vorher fest. Man prüft nicht beliebig weiter, bis zufällig ein günstiges Ergebnis erreicht ist.
• Die Nachprüfung erkennt die betrachteten Fehler zuverlässig. Die Rechnung nimmt vollständige Erkennung an: Bei unbekannten übersehenen Fehlern begrenzt sie nur die Entdeckungsrate, nicht belastbar den tatsächlichen Fehleranteil.

„95 % Konfidenz“ beschreibt die Verlässlichkeit des Verfahrens: Bei wiederholter gleichartiger Stichprobenziehung würden mindestens 95 % der so berechneten Obergrenzen den tatsächlichen Anteil abdecken. Es bedeutet weder „95 % Wahrscheinlichkeit, dass diese konkrete Grenze stimmt“, noch eine Garantie für einzelne Änderungen. Für neue Aufgabenklassen oder einen geänderten Prüfprozess muss die Aussage neu überprüft werden.

Methodische Quellen: Hanley & Lippman-Hand: Dreierregel und Herleitung (PDF); NIST: exakte binomiale Konfidenzgrenzen. Die Rechnung oben verwendet ausdrücklich eine einseitige Grenze; die obere Grenze eines zweiseitigen, zentralen 95%-Intervalls wäre mit etwa 1,22 % höher.

Meine Empfehlung: Autonomie auf Basis nachgewiesener Prozessqualität schrittweise erhöhen – und bei Qualitätsverschlechterungen wieder reduzieren.

Für sicherheitskritische Funktionen reichen solche allgemeinen Stichprobenkennzahlen allein nicht aus. Dort sind spezifische, risikogerechte Verifikationsnachweise erforderlich.

07 / Sicherheit & Compliance

Security, Datenschutz und Compliance: Von Anfang an integrieren

Wer Coding-Agenten produktiv einsetzt, muss nicht nur den erzeugten Code kontrollieren, sondern auch die Agenten selbst.

Ein Agent, der Shell-Befehle ausführen, Repositories lesen oder externe Dienste aufrufen kann, benötigt klar begrenzte Berechtigungen.

Deshalb empfehle ich fünf praktische Leitplanken:

1. Isolierte Ausführung: Agenten arbeiten standardmäßig in abgegrenzten Entwicklungsumgebungen mit möglichst wenigen Berechtigungen.
2. Kontrollierter Datenzugriff: Vertraulicher Quellcode, Zugangsdaten und personenbezogene Informationen dürfen nur über freigegebene Systeme verarbeitet werden. Anbieter, Verträge, Datenflüsse und Speicherbedingungen sind vorab zu prüfen.
3. Unabhängige Prüfungen: Sicherheitsregeln werden möglichst durch CI, Zugriffspolicies und spezialisierte Werkzeuge durchgesetzt, nicht allein durch Prompts.
4. Nachvollziehbare Änderungen: Pull Requests, Testergebnisse, Abhängigkeiten und relevante Freigabeentscheidungen bleiben nachvollziehbar.
5. Produktspezifische Anforderungen: Embedded-Steuerungen, Cloud-Dienste und Softwareprodukte können unterschiedliche Sicherheits-, Nachweis- und regulatorische Pflichten haben.

Hilfreiche technische Orientierungsrahmen sind beispielsweise das NIST Secure Software Development Framework sowie die OWASP-Empfehlungen zur Sicherheit agentischer KI-Systeme.

Rechtlich können je nach Anwendungsfall unter anderem DSGVO, Cyber Resilience Act, NIS2-Umsetzung, Vertrags- und Lizenzbedingungen sowie branchen- oder produktspezifische Regelwerke relevant sein.

Wichtig ist, die jeweils tatsächliche Anwendbarkeit zu prüfen. Der Einsatz eines Coding-Agenten führt nicht automatisch dazu, dass sämtliche KI-spezifischen Produktpflichten auf die entwickelte Software anwendbar werden.

Ein agentisches Review ersetzt weder eine erforderliche Konformitätsbewertung noch eine gesetzlich oder normativ vorgeschriebene menschliche Freigabe.

08 / Der Vier-Wochen-Pilot

Einführung im Mittelstand: Ein Pilot statt eines Großprojekts

Ein Unternehmen benötigt für den Einstieg weder eine eigene KI-Agentenplattform noch zehn spezialisierte Agenten.

Ich würde mit einem vorhandenen Repository und einem überschaubaren Pilot starten.

Woche 1Ausgangslage messen

Wie viel menschliche Zeit benötigt das Team für Implementierung, Review und Nacharbeit? Welche Fehler werden typischerweise erst spät gefunden? Welche Änderungen verursachen besondere Risiken?

Gleichzeitig werden Risikoklassen, Zugriffsgrenzen und vorhandene CI-Prüfungen festgelegt.

Woche 2Coding-Agent und unabhängiges Review einführen

Geeignete Aufgaben werden agentisch umgesetzt und durch die automatisierte Review-Rework-Schleife geführt.

Menschen überprüfen vorerst weiterhin die Ergebnisse.

Woche 3Qualität messen und Schwachstellen schließen

Das Team bewertet übersehene Fehler, falsche Review-Findings, Testqualität und tatsächliche Zeitersparnis.

Die wichtigsten Schwachstellen werden möglichst durch dauerhaft wirksame Prüfmechanismen behoben.

Woche 4Kontrollierte Autonomie erproben

Einzelne ausreichend abgesicherte, triviale Aufgaben können für automatische Freigaben vorgesehen werden.

Weitergehende Freigaben erfolgen erst nach ausreichender Validierung der jeweiligen Aufgabenklasse. Vier Wochen sind ein sinnvoller Startpunkt für den Pilot, aber kein Nachweis, dass R1-Automerge bereits sicher genug ist.

Welche Kennzahlen zählen?

Für eine seriöse Wirtschaftlichkeitsbetrachtung reichen Token-Kosten und generierte Codezeilen nicht aus.

Ich würde insbesondere messen:

• Menschliche Arbeitsstunden pro erfolgreich abgenommener Änderung
• Zeit vom Arbeitsauftrag bis zur produktiven Bereitstellung
• Nachträglich entdeckte Defekte und sicherheitsrelevante Findings
• Aufwand für Nacharbeit und Betriebsstörungen
• Direkte KI-, Infrastruktur- und Verifikationskosten

Diese Kennzahlen sollten nach Aufgabenklasse betrachtet werden. Andernfalls kann eine Verschiebung zu einfacheren Aufgaben fälschlich als Produktivitätssteigerung erscheinen.

Das Ziel lautet nicht „möglichst viele automatische Pull Requests“.

Es lautet: Mehr wirtschaftlich wertvolle, dauerhaft wartbare Software pro menschlicher Arbeitsstunde – innerhalb akzeptierter Risikogrenzen.

09 / Fazit

Fazit: Der Engpass verschiebt sich vom Schreiben zum Verifizieren

Agentische Softwareentwicklung verändert die Rolle von Entwicklern.

Die entscheidende Leistung besteht zunehmend darin, Ziele präzise zu definieren, geeignete Architekturgrenzen festzulegen, Ergebnisse unabhängig zu verifizieren und Risiken bewusst zu steuern.

Das gilt für ein mittelständisches Maschinenbauunternehmen mit Embedded-Software ebenso wie für einen Hersteller mit eigenen ERP-Erweiterungen oder Cloud-Services.

Der optimale Automatisierungsgrad wird unterschiedlich sein. Der zugrunde liegende Ansatz kann derselbe bleiben.

Mein Leitprinzip: So viel Autonomie wie wirtschaftlich sinnvoll – so viel unabhängige Verifikation und menschliche Kontrolle wie risikobedingt notwendig.

Wer diesen Ansatz konsequent umsetzt, kann die Produktivität agentischer Entwicklung nutzen, ohne Qualitätssicherung und Verantwortung aus dem Entwicklungsprozess zu entfernen.