Der Rahmen um alle drei Ebenen

Wie diese Arbeiten entstehen

Bausteine und Projekte sind das Ergebnis. Diese Seite zeigt den Rahmen, in dem sie entstehen: ein Softwareentwicklungsprojekt mit Anforderungen, Freigaben, Tests, Dokumentation und Betrieb – aufgebaut wie in einem Unternehmen, nur mit KI als Umsetzer.

Der Prozess – und seine Rückwege

Der Ablauf ist der übliche eines IT-Projekts: aus einer Idee wird eine Anforderung, daraus nach Abstimmung ein beauftragter Vorgang, daraus Umsetzung, Prüfung, Abnahme, Auslieferung und Betrieb. Neu ist daran nichts – bemerkenswert ist nur, wer ihn ausführt.

Der Ablauf – und wie weit er trägt

Wer ihn ausführt – und in welcher Rolle

Anforderung umgesetzt

KI + Mensch Anforderungsanalyst

Fachliches Refinement umgesetzt

wechselseitig Fachexperte

Beauftragung umgesetzt

Mensch Änderungsmanager

Architektur / Technisches Refinement in Planung

KI-Agent Softwarearchitekt

Umsetzung umgesetzt

KI-Agent Entwickler / Umsetzer

Verifikation eingerichtet mit bekannter Lücke

automatisch Testautomatisierer

Abnahme umgesetzt

Mensch Abnehmer

Auslieferung eingerichtet mit bekannter Lücke

automatisch Release- & Konfig.-Manager

Betrieb umgesetzt

automatisch Betriebs- verantwortlicher

Legende für die Besetzungsarten: Mensch (gefüllt: entscheidet allein) · Mensch und KI gemeinsam (nur umrandet: wirkt mit) · KI-Agent oder Code – läuft maschinell
Siehe auch: Drei Besetzungsarten, nicht zwei – dort ausführlich, in denselben Farben

Anforderung: Eine dauerhafte Zusicherung wird als eigener Vorgangstyp in Jira erfasst und an das Projekt-Epic gehängt. Sie gilt, bis sie widerrufen wird – anders als ein Arbeitsauftrag, der mit seiner Erledigung endet. Der KI-Agent legt vor, der Mensch entscheidet.
Fachliches Refinement: Zuschnitt und Akzeptanzkriterien werden geklärt: Was gehört dazu, was nicht, woran erkennt man die Fertigstellung. Wechselseitig – der KI-Agent schlägt vor, der Mensch schärft, bis beide dasselbe meinen. Erst danach ist der Vorgang beauftragbar.
Beauftragung: Das erste der beiden menschlichen Tore. Der Vorgang geht von „Zu erledigen“ nach „In Arbeit“ – entweder auf Nachfrage des Agenten oder indem der Mensch die Karte selbst zieht. Ohne dieses Tor beginnt keine Umsetzung.
Architektur / Technisches Refinement: Vor der Umsetzung wird entschieden, wie gebaut wird: welche Bausteine betroffen sind, wo die Nähte liegen, wie die Daten fließen. Das geschieht – aber nur im Arbeitsverlauf, ohne festgehaltenes Ergebnis. Damit ist die Entscheidung hinterher nicht nachweisbar und durchläuft kein Review.
Umsetzung: Der KI-Agent schreibt den Code, versioniert jede Änderung in Git und hält die Begründung in der Commit-Nachricht fest. Ein menschlicher Eingriff findet hier nicht statt.
Verifikation: Zwei Ebenen: Der Durchstich prüft die Naht über die echten Einstiegspunkte, die Regressionstests prüfen den Bestand – tut alles, was schon funktioniert hat, es immer noch? Ein roter Test kann heißen, dass der Code falsch ist – oder dass die Anforderung falsch war. Diese Unterscheidung trifft nicht der KI-Agent.
Abnahme: Das zweite menschliche Tor. Technisch fehlerfrei genügt nicht – hier wird beurteilt, ob das Ergebnis seinen Zweck erfüllt. Nur der Mensch zieht einen Vorgang auf „Fertig“, bei Unteraufgaben ebenso wie bei Aufgaben.
Auslieferung: Vor jedem Push fahren die Tests der betroffenen Projekte automatisch los und blocken bei Rot. Danach überträgt ein Skript den erzeugten Stand auf den Server. Was fehlt, ist ein definierter Rückfall auf die vorige Fassung.
Betrieb: Täglich laufen die Prüfungen still weiter und melden sich nur bei Rot. Was im Betrieb auffällt, wird nicht nur behoben, sondern als Dauertestfall aufgenommen – damit derselbe Fehler nicht zweimal unbemerkt bleibt.

Die vier Rückwege

Ein Prozess ohne Rückwege ist eine Wunschvorstellung. Entscheidend ist nicht, dass es zurückgeht, sondern wie weit – und diese Entscheidung trifft nicht der KI-Agent.

Test rot – Fehler im Code

Umsetzung Verifikation zurück von Verifikation nach Umsetzung

Der häufige Fall: Die Zusicherung stimmt, die Umsetzung nicht. Der KI-Agent korrigiert und lässt erneut prüfen. Der einzige Rückweg, den er allein gehen darf.

Test rot – die Anforderung war falsch

Anforderung Verifikation zurück von Verifikation nach Anforderung

Der wichtigste Rückweg. Ein roter Test heißt nicht automatisch „Code kaputt“. Er kann ebenso bedeuten, dass die Zusicherung von Anfang an falsch formuliert war. Wer das nicht trennt, repariert das Falsche – und schlimmer: Er passt am Ende den Test an, bis er wieder grün ist. Deshalb geht dieser Fall nie an den Agenten, sondern zur Abstimmung an den Menschen.

Abnahme verweigert

Umsetzung Abnahme zurück von Abnahme nach Umsetzung

Technisch fehlerfrei, inhaltlich nicht überzeugend. Der Vorgang geht zurück in Arbeit – mit einer Begründung am Vorgang, damit die nächste Fassung nicht dieselbe Lücke hat.

Störung oder Erkenntnis

Anforderung Betrieb zurück von Betrieb nach Anforderung

Was im Betrieb auffällt, wird nicht nur behoben, sondern als Dauertestfall aufgenommen und – wenn es eine dauerhafte Zusicherung berührt – als neue Anforderung erfasst. So schließt sich der Kreis zum Anfang.

Drei Besetzungsarten, nicht zwei

Rollen werden hier nicht nur von Menschen und Agenten besetzt, sondern auch von deterministischem Code. Der Push-Hook ist der Prozesshüter, das Schreib-Protokoll der Revisor, der Health-Check die Rufbereitschaft. Diese Rollen sind nicht besetzt – sie sind einkompiliert. Eine Leitplanke, die aus Code besteht, kann man nicht überreden.

Mensch

Behält die Entscheidungen: Priorisierung, Freigabe, Abnahme, und jeden Fall, in dem ein bestehender Test rot wird.

KI-Agent

Analysiert, setzt um, testet, dokumentiert, verifiziert – und legt vor, wo entschieden werden muss, statt selbst zu entscheiden.

Deterministischer Code

Hooks, Tore und Prüfläufe. Sie halten den Prozess ein, ohne dass jemand daran denken muss – und lassen sich nicht überzeugen.

Wer welche Rolle besetzt →

Die Regeln, nach denen gearbeitet wird

Sieben Kapitel, die zusammen den Rahmen bilden. Jedes ist aus einem konkreten Vorfall entstanden, nicht aus einem Lehrbuch.

Kapitel 1 · Vereinbarung

Das Rahmenkonstrukt

Eine versionierte Arbeitsvereinbarung zwischen Mensch und KI-Agent – im Repository, nicht im Kopf.

Gilt durchgehend

Details →

Kapitel 2 · Zuständigkeit

Rollen und Vorbehalte

Was der Mensch sich vorbehält, was der KI-Agent nie tut – und was passiert, wenn mehrere Sitzungen laufen.

Gilt bei: BeauftragungAbnahme

Details →

Kapitel 3 · Vorgänge

Anforderungen und Steuerung

Fünf Stufen, zwei menschliche Tore – und die Trennung zwischen „ist das fertig“ und „tut das System das noch“.

Gilt bei: AnforderungFachliches RefinementBeauftragung

Details →

Kapitel 4 · Prüfung

Qualitätssicherung

Zwei Ebenen: Der Durchstich prüft die Naht, die Regression den Bestand. Lücken werden gemeldet, nicht übersprungen.

Gilt bei: VerifikationAbnahme

Details →

Kapitel 5 · Laufzeit

Auslieferung und Betrieb

Ein Tor, das bei rotem Test deterministisch blockt – und ein Prüflauf, der täglich still nachsieht.

Gilt bei: AuslieferungBetrieb

Details →

Kapitel 6 · Herkunft

Nachvollziehbarkeit

Der KI-Agent arbeitet unter dem Konto eines Menschen. Ohne Gegenmaßnahme unterscheidet der Prüfpfad die beiden nicht.

Gilt durchgehend

Details →

Kapitel 7 · Gedächtnis

Wissen und Dokumentation

Ein KI-Agent vergisst zwischen zwei Sitzungen alles. Was bleiben soll, muss geschrieben werden.

Gilt durchgehend

Details →

Stand der Angaben auf dieser Seite: 5. August 2026.