Wenige Themen treiben Software-Teams derzeit so um wie KI-Agenten. Versprechen gibt es viele: Tempo, Autonomie, weniger Routine. Die Realität sieht häufig anders aus – nämlich genau dort, wo das Vertrauen aufhört und die Verantwortung beginnt. Die Frage ist nicht mehr, ob KI Code schreibt. Die Frage ist, ob wir kontrollieren können, was sie produziert – und ob wir das nachweisen können.

Dieser Beitrag stellt ein Konzept vor, das genau diese Lücke adressiert, ohne in die übliche Tool-Debatte abzurutschen.

Die Ausgangslage: Tempo, das auf Vertrauen baut

KI-Agenten können heute eigenständig Code entwerfen, Anforderungen aufnehmen, Tests formulieren und sogar Slice um Slice an Architektur und Schnittstellen arbeiten. Das klingt nach einem Traum für jedes Engineering-Team mit Lieferdruck.

Der Haken: Geschwindigkeit allein ist kein Qualitätsversprechen. Wer Software einfach „schneller“ produziert, verschiebt das eigentliche Problem nur um eine Ebene nach hinten – vom Code zum Prozess, der diesen Code erzeugt. Genau dort liegen die Knackpunkte:

• Halluzinationen und unzuverlässiger Output: Modelle erfinden nahtlos wirkende, aber falsche APIs, Schnittstellen oder Randfälle. Der Output ist statistisch plausibel, fachlich aber nicht verlässlich.
• Der menschliche Review wird zum Flaschenhals: Weil KI-Output so leicht „richtig aussieht“, darf er nicht ungeprüft durchruschen. Jede Änderung braucht Verifikation – und die leistet meist ein einzelner Senior, viel öfter, als das Team Kapazität hat.
• Wissen verschwindet in Köpfen: Fachliche Entscheidungen, Architektur-Begründungen und Kompromisse leben in Köpfen und Chatverläufen. Wenn sie nicht dokumentiert werden, stirbt der Kontext mit der Person oder dem nächsten Teamwechsel.
• Der Kontext geht verloren: Wurde eine Architektur unter bestimmten Randbedingungen gewählt, wissen spätere Änderungen davon nichts mehr. Jede neue Iteration beginnt bei Null – und produziert elegant aussehende Entscheidungen, die am echten System vorbeigehen.

All das ist kein Pech, sondern systemisch. Es ist die Folge davon, KI einfach als schnellen Coder in einen Erstellungsprozess einzufügen, der auf menschliche Sorgfalt ausgelegt war.

Was wäre, wenn Qualität nicht die Bremse, sondern der Motor wäre?

Der entscheidende gedankliche Sprung: Statt KI zu verlangsamen, damit der Mensch hinterherkommt, wird der Prozess so gebaut, dass Tempo und Kontrolle dieselbe Richtung haben. Das ist der Kern eines Konzepts, das unter dem Arbeitstitel Quality Engineering Framework läuft – ein schlankes, teilautomatisiertes Qualitäts-Management-System für die KI-gestützte Softwareentwicklung.

Das Konzept baut auf Ideen auf, die seit Jahrzehnten in regulierten Branchen erprobt sind: Risikomanagement, Rückverfolgbarkeit, klare Verantwortungsgrenzen und unabhängige Prüfung. Der Unterschied liegt darin, dass diese Prinzipien nicht als schwerfällige Bürokratie gedacht werden, sondern als schlanker, technisch prüfbarer Arbeitsrahmen, der teilautomatisch direkt in Git- und GitLab-Workflows lebt. Dabei erledigen KI-Agenten die Hauptlast der Arbeit – von der Analyse über das Schreiben von Code und Tests bis zur Zusammenstellung der Nachweise. Gleichzeitig sind ihnen die Prüfkriterien von vornherein fest vorgegeben, gesteuert durch den fachlichen Input menschlicher Experten. Die extern nachprüfbaren Nachweise darüber, dass diese Kriterien erfüllt sind, entstehen als natürlicher Nebeneffekt der eigentlichen Arbeit, statt als nachgelagerte Fleißaufgabe.

Zwei Leitideen tragen das Konzept.

1. Risiko bestimmt die Tiefe der Kontrolle

Nicht jede Änderung braucht denselben Aufwand. Ein unkritischer Schönheits-Refactor verdient einen leichten Prozess; eine Änderung an Zahlungslogik oder Datenintegrität verlangt deutlich mehr Prüfung. Das Konzept folgt deshalb dem Prinzip: Der Aufwand an Review, Test und Nachweis richtet sich nach der Risikobewertung – und nicht nach der Laune eines Tools oder der Verfügbarkeit eines Reviewers.

So bleibt Entwicklung schnell, befeuert durch KI-Agenten, wird aber gleichzeitig so gründlich und genau, wie es der fachliche Rahmen erfordert. Das ist genau der Punkt, an dem „schneller“ und „besser“ keine Gegensätze mehr sind.

2. Trennung von Entwickeln und Prüfen – auch zwischen Agenten

Ein zentrales Muster: Der Agent, der etwas entwickelt, darf es nicht auch alleine freigeben. Das Konzept führt eine explizite Trennung zwischen Entwicklung und unabhängiger technischer Prüfung ein – idealerweise als zwei getrennte Agenten, die unterschiedliche Rollen verkörpern. Und beide haben ihre klar vorgegebenen Kriterien, nach denen sie arbeiten.

Das klingt zunächst kompliziert. In der Praxis bewirkt es das Gegenteil: Halluzinationen haben weniger Angriffsfläche, weil der Output von einer Instanz geprüft wird, die nicht denselben Kontext samt Fehlern teilt. Die Prüfung wird zur Zweitsicht, die nicht durch schöpferische Vorfreude getrübt ist. Die menschliche Verantwortung bleibt dabei bewusst erhalten: Fachliche Freigaben, Risikoakzeptanz und Release-Entscheidungen trifft weiterhin ein Mensch – gut informiert, aber entscheidend.

Ein kurzer Blick in den „Maschinenraum“

Was bedeutet das konkret? Wie entstehen die Qualitätskriterien einer Änderung – und wie wird ihre Erfüllung verifiziert? Ein kurzer Einblick, ohne in das letzte Detail zu gehen:

Jede kontrollierte Änderung wird nicht als isolierter Codewurf behandelt. Bevor ein Agent loslegt, ist festgelegt, welche Informationen die Arbeit tragen: der fachliche Anlass und sein erwarteter Nutzen, die betroffenen Anforderungen, die geplante Spezifikation, die Risikobewertung und die Tests, die das Ergebnis absichern. Diese Elemente liegen nicht als lose Notizen vor, sondern als strukturierte, maschinenlesbare Artefakte mit stabilen Referenzen. Daraus ergeben sich die Qualitätskriterien für die konkrete Änderung fast von selbst: Was muss dokumentiert sein, welcher Test gehört zu welcher Anforderung, welches Risiko ist akzeptabel, welche Freigabe trägt den Stand.

Die Agenten arbeiten innerhalb fester Grenzen – definierte Arbeitsaufträge, klare Regeln, welche Felder und Status sie bearbeiten dürfen. Ein Validator prüft die Artefakte gegen vorgegebene Schemata, bevor eine Pipeline sie weiterlässt; Lücken in Dokumentation, Referenzen oder Nachweisen stoppen die Kette, statt stillschweigend durchzugehen. Die Rückverfolgbarkeit von Anforderung über Risiko und Test bis zur Freigabe entsteht so als Beigabe der normalen Arbeit, nicht als nachträglicher Aufwand. Und weil Entwicklung und Prüfung getrennt sind, kommt zu dieser technischen Kontrolle noch die unabhängige Zweitsicht eines weiteren Agenten auf denselben Artefakt-Baum.

Freigaben und Risikoakzeptanz bleiben menschlich. Was der Rahmen also liefert, ist weniger Bürokratie als vielmehr eine zweite Sicherheit: dass die Grundlage jeder Entscheidung vollständig, aktuell und nachvollziehbar ist – und dass ein Agent nur so weit vorankommt, wie die Qualität des bisherigen Schritts es erlaubt.

Der rote Faden: Wissen statt Vertrauen

Am Ende ist der wichtigste Akzent dieses Konzepts vielleicht: Softwareentwicklung soll nicht auf blindem Vertrauen in ein Modell beruhen, sondern auf nachprüfbarem Wissen darüber, was warum entstanden ist. Ein Team, das KI nutzt und diese Nachweisbarkeit mitführt, gewinnt beides: das Tempo der Automatisierung und die Ruhe, Qualität und Verantwortung jederzeit erklären zu können.

Ein ehrlicher Stand

Ich arbeite mit diesem Rahmen selbst in realen Projekten und dokumentiere meine Erfahrungen offen. Das Konzept ist noch keine fertige, verkaufte Lösung, sondern ein laufend wachsendes Vorhaben. Gerade dieser transparente Weg – erst in eigenen Projekten erprobt, dann schrittweise weitergetragen – soll die Versprechen einlösen, die der Beitrag weckt.

Hinweis: Dieser Text stellt ein Konzept vor und verzichtet bewusst auf technische Detailtiefe. Wer die zugrundeliegenden Prinzipien vertiefen möchte, findet Anknüpfungspunkte in den Begriffen Qualitätsmanagement, Risikobewertung und Rückverfolgbarkeit – klassische Werkzeuge reifer Softwareorganisationen, hier neu auf die Zusammenarbeit von Mensch und KI-Agenten zugeschnitten.