Entwicklungs­prozess mit KI-Agenten

01Die Herausforderung und die Antwort

KI-Agenten können guten Code schreiben, arbeiten aber unter schlechten Bedingungen: ohne Gedächtnis, ohne Nachweis, ohne unabhängige Abnahme. Der Prozess ändert die Bedingungen, nicht die Agenten.

Das Wesentliche in fünf Sätzen

1. Die Regeln prüft ein Programm, niemand muss sie im Kopf behalten. Fünfzehn automatische Prüfungen („Gates“) laufen vor jedem Merge; was nicht besteht, wird nicht gemergt.
2. Das Risiko bestimmt den Aufwand. Vier Risikostufen – Tier 0 bis 3 – legen fest, ob eine Änderung direkt gemergt werden darf oder Plan, unabhängige Prüfung und bei Tier 3 zusätzlich eine Widerlegungsprüfung (gezielte Fehlersuche) braucht.
3. Die Prüfung ist immer unabhängig. Wer baut, nimmt nicht selbst ab; ab Tier 2 prüft eine unbeteiligte Instanz (eine eigene Agentensitzung), und ihr Urteil gilt nur für genau den geprüften Code.
4. Alles Wissen steht in Dateien. Pläne, Entscheidungen und Journale liegen im Repository und werden jedem Agenten automatisch erneut vorgelegt, sobald sein Gedächtnis gekürzt wurde.
5. Der Mensch entscheidet, die Agenten arbeiten. Ein Koordinator-Agent verteilt die Arbeit an Arbeiter-Agenten; der Mensch priorisiert, entscheidet, gibt Designs frei und prüft wöchentlich eine Stichprobe.

02Wie der Prozess aufgebaut ist

Fünf Ebenen, jede mit einer klaren Zuständigkeit. Menschen urteilen, Agenten arbeiten, Programme prüfen, Dateien bewahren das Wissen.

Der Prozess wird als Vorlage (dev-process) ausgeliefert. Aus ihr entsteht ein fertig eingerichtetes Repository: Startdatei und Phasenbefehle für die gewählte Harness (GitHub Copilot, Claude Code oder eine neutrale AGENTS.md), die Gates sowie GitHub Actions-Workflows für Gates, Owner-Digest und Kennzahlen. Spätere Versionen der Vorlage holt sich ein Repository mit einem Befehl; projekteigene Dateien bleiben unberührt.

03Regeln und Risikostufen

Neun Regeln gelten immer; wie viel Verfahren eine Änderung braucht, entscheidet ihr Risiko, nicht ihre Größe.

Die neun Regeln stehen in jeder Startdatei und werden von einem Gate zeichengenau gegen das Original geprüft:

Die vier Tiers. Maßgeblich ist das Risiko, nicht der Umfang: Eine Zehn-Zeilen-Änderung, von der andere Komponenten abhängen, ist Tier 2, eine Formatierung Tier 0. Das eingestufte Tier darf nur nach oben korrigiert werden. Es steigt auf mindestens Tier 2, sobald eine dieser Fragen mit Ja beantwortet wird: Werden Daten dauerhaft gespeichert? Verlässt eine Benutzereingabe den Prozess? Geht es um Zugriffsschutz? Hängt anderer Code von der Schnittstelle ab? Ist mehr als eine Oberfläche betroffen? Ist Datenverlust möglich? Wird dieselbe Stelle wiederholt geändert? Tier 3 gilt, wenn die Änderung Zugriffsschutz, Datenhaltung und Migrationen, eine Sicherheitsgrenze oder einen Vertrag über mehrere Repositories berührt.

Widerlegungsprüfung heißt: Bei Tier 3 prüft zusätzlich eine Instanz, deren einziger Auftrag es ist, Fehler zu finden. Zweites Modell heißt: ein Modell eines anderen Herstellers, wo eines verfügbar ist; ist keines verfügbar, sagt das Attest das ausdrücklich. Das Gate verlangt das zweite Modell nicht, aber es verlangt, dass sein Fehlen offen angegeben wird.

04Prüfung, Gedächtnis, Ziele und Messung

Ein Prüfurteil zählt nur, wenn es unabhängig entstanden und an genau den geprüften Code gebunden ist. Was Agenten wissen müssen – Entscheidungen, Ziele, Kennzahlen – steht in Dateien und wird ihnen nach jeder Kürzung erneut vorgelegt.

Prüfung. Ab Tier 2 erhält eine unbeteiligte Instanz ein schreibgeschütztes Bundle – Änderungen, Plan, Tests, Bilder – und nicht das Gespräch, in dem die Arbeit entstand. Ihr Attest im Journal nennt Vorgang, Tier, Prüfer, Modell, Unabhängigkeitsmerkmale, Verdikt, Runde und die Prüfsummen des Codes. Das Gate prüft, ob ein Attest vorliegt, ob seine Merkmale zum Tier passen und ob es zum gemergten Code gehört. Was es nicht prüfen kann: ob der Prüfer wirklich eine andere Instanz war. Das beruht auf der Angabe des Prüfers – deshalb die wöchentliche Stichprobe durch den Menschen.

Gedächtnis. Plan mit Entscheidungsliste, Journal und Aufgabenliste liegen im Repository. Ein Kommando liefert daraus, was in Arbeit ist, was als Nächstes kommt, welche Entscheidungen gelten und welche Frage offen ist. Nach jeder Kürzung einer Sitzung spielt ein Programm die neun Regeln im Wortlaut und die letzten zwölf Entscheidungen automatisch neu ein. Der Anlass war eine Beobachtung aus dem Betrieb: Die bloße Anweisung, nach einer Kürzung die Regeln neu zu lesen, wurde selbst mit weggekürzt.

Ziele. Ein Vorgang startet erst, wenn sein Typ feststeht und seine Akzeptanzkriterien als prüfbare Sätze vorliegen („Wenn <Auslöser>, dann soll das System <Reaktion>“, inklusive Negativ-, Rand- und Berechtigungsfällen). Abgenommen wird erst, wenn jedes Kriterium einen bestandenen Test hat, alle Gates grün sind und die Dokumentation nachgezogen ist. Beide Bedingungen stehen als Listen im Repository (Start- und Abnahmeliste) und werden fortgeschrieben: Sagt ein Mensch „am Ende muss X gelten“, wird X aufgenommen.

Messung. Ein Cockpit (Auswertungsskript im Repository) liest Journal, Git-Historie und Meldungen; jede Zahl nennt ihre Aussagekraft. Vier Kennzahlen sind maßgeblich:

• Prüfrunden bis zur Freigabe. Ziel: höchstens zwei bei 90 % der Vorgänge. Wird in Runde 3 noch abgelehnt, wird eine Regel festgehalten oder der Vorgang geteilt.
• Korrekturquote. Anteil der Features, die binnen sieben Tagen korrigiert werden mussten; nur der Trend zählt.
• Korrektur-Häufungen. Stellen, die immer wieder korrigiert werden – Regel 6 in Zahlen.
• Prüfrunden je Modell. Zeigt, welches Modell sich in welcher Phase bewährt.

05Architekturvorgaben: hart und weich

Vorgaben halten nicht, weil jemand sie kennt, sondern weil ein Gate sie prüft („hart“). Wo nur ein Prüfer urteilt („weich“), ist das in der Tabelle ausdrücklich ausgewiesen.

Lebenszyklus einer Vorgabe: Eine neue Vorgabe beginnt mit einem Entscheidungsdokument. Was sich maschinell prüfen lässt, wird zur verbotenen Abhängigkeit im Architektur-Linter oder zu einem Test mit allen bekannten Fällen; der Rest wird Frage in der Review-Checkliste. Bestehende Verstöße kommen in eine Baseline, die nur kleiner werden darf. Ein neuer Verstoß lässt das Gate scheitern; eine Ausnahme gibt es nur als Entscheidungsdokument mit Ablaufdatum. Neue nichtfunktionale Ziele nehmen denselben Weg und bekommen zusätzlich einen Punkt in der Abnahmeliste.

06Die Rolle des Menschen

Der Mensch schreibt keinen Code und liest nicht jede Änderung. Was ihm bleibt, ist das Urteil – an fünf Stellen, die kein Agent übernehmen darf.

Fünf Aufgaben des Owners

• Priorisieren. Er legt fest, was als Nächstes freigegeben wird. Legt ein Agent Dutzende Vorgänge an, beginnt die Arbeit erst, wenn der Owner sie sortiert hat.
• Entscheiden. Jede Produkt-, Architektur- oder Risikofrage kommt als Auswahl mit Optionen und Empfehlung; die Antwort wird zur Entscheidungszeile im Plan.
• Designs freigeben. Bei Tier 3 wird nicht gebaut, bevor das Design freigegeben ist. Der Merge selbst braucht seine Zustimmung nicht; dafür sorgen Gates und Attest.
• Stichprobe prüfen. Einmal pro Woche einen bereits gemergten Vorgang gründlich lesen; welcher es ist, bestimmt die Kalenderwoche. Kein Agent weiß vorher, welcher gezogen wird.
• Regeln fortschreiben. Start- und Abnahmeliste werden laufend ergänzt: Eine Vorgabe des Owners wird dauerhaft Teil des Prozesses, nicht nur Einzelfall.

Der Owner arbeitet über die Oberfläche seiner Harness: auf GitHub etwa über Issues, Pull Requests und den Owner-Digest, den ein Workflow erzeugt; im Referenzprojekt über eine Chat-App, auch mobil. Was er nicht mehr tut: an Regeln erinnern, Fortschritt erfragen, mergen, Sitzungen starten (im Referenzprojekt; auf GitHub offen), aufräumen.

07Ein Vorgang von Anfang bis Ende

Jede Phase läuft in einer eigenen Sitzung mit dem Modell, das die Modellpolitik (eine Konfigurationsdatei) für Tier und Phase festlegt. Die Phasen folgen ohne Wartezeit aufeinander; gewartet wird nur auf Entscheidungen des Menschen.

Fragen. Kann nur der Owner entscheiden, trägt der Arbeiter die Frage mit Optionen und Empfehlung in den Plan ein und meldet „blockiert“. Der Koordinator legt sie dem Owner als Auswahl vor, die Antwort wird als Entscheidung im Plan vermerkt, und der Arbeiter macht weiter.

Merge. Freigegebene Branches werden in einer Merge Queue gesammelt, einmal gemeinsam durch Gates und Testsuite geführt und der Reihe nach gemergt. Scheitert der gemeinsame Lauf, wird der verursachende Branch ermittelt, aus der Queue genommen und an seinen Arbeiter zurückgemeldet.

Ausfall des Koordinators. Nichts geht verloren: Der Zustand liegt in Git; Arbeiter halten an, wenn sie eine Entscheidung brauchen; ein neuer Koordinator hat den Stand in einer Minute eingelesen.

Beispiel aus dem Referenzprojekt: ein Vorgang in Tier 2 – Plan um 21:18, zwei Fragen an den Owner während der Umsetzung, Review in drei Runden (Runde 1 Block), Merge um 04:24. Sieben Stunden, zwei menschliche Entscheidungen, kein weiterer manueller Schritt.

08Eine Möglichkeit: GitHub mit Copilot

Regeln, Gates, Journal und Kennzahlen sind Dateien und Skripte auf Git-Basis. Deshalb lässt sich der Prozess auf eine Plattform wie GitHub übertragen: Sie könnte die Gates ausführen, die Vorgänge als Issues führen und Merges in der Merge Queue sammeln; Copilot würde die Regeln lesen wie jede andere Harness.

Die folgende Tabelle zeigt, wie sich die Bausteine abbilden ließen und was davon heute schon in der Vorlage steckt. Sie ist ein Weg, keine Festlegung.

Was sich dadurch ändern würde: Im Referenzprojekt laufen die Gates auf einem einzelnen Server, auf GitHub liefen sie in der Organisation; mit Branch Protection könnte nur noch ein Administrator die Gates umgehen; und für das zweite Modell bei Tier 3 müsste niemand mehr die Harness wechseln. Ob das in der Praxis trägt, soll ein Pilot zeigen.

09Skalierung auf eine Organisation

Die Einheit des Prozesses ist das Repository. Maschinen skalieren mit; die Grenze ist die Zahl der Entscheidungen, die ein Owner treffen kann.

Was mitwächst: Jedes Repository erhält die Vorlage mit seinen eigenen Gates, seiner Modellpolitik und seiner Lagetabelle. Die Vorlage wird zentral versioniert und enthält organisationsweite Regeln wie Schichtenregeln oder die erlaubten Lizenzen; ein Update kommt als Pull Request in jedes Repository. Gates laufen zentral, etwa in GitHub Actions, und wachsen mit der Organisation. Arbeiter sind Sitzungen der Harness, zum Beispiel eine je Issue, und die Modellpolitik legt neben den Modellen auch fest, wie viele davon gleichzeitig laufen.

Was nicht von selbst mitwächst: Jedes Repository braucht einen Owner, und jeder Vorgang braucht im Mittel ein bis zwei seiner Entscheidungen. Wie viele parallele Vorgänge ein Owner trägt, ist die eigentliche Kapazitätsgrenze – und heute nicht gemessen. Ebenso offen ist, wo der Koordinator in einer größeren Umgebung läuft und ob ein Koordinator mehrere Repositories führen kann.

Was sich für Entwickler ändert: Sie übernehmen die Owner-Rolle eines Repositorys, prüfen Stichproben und schreiben Akzeptanzkriterien, Verträge und Entscheidungen. Rollenbild, Qualifizierung und Vertretung sind noch zu beschreiben (Kapitel 11).

10Risiken und Stand

Ein Prozess, der jede Aussage belegen will, nennt seine Grenzen selbst. Die Zahlen sind eine Baseline, kein Urteil.

Der Kern – Gates, Prüfung, Regelkern, Journal, Design-Verträge – ist stabil; was im Referenzprojekt nicht trug, ist gestrichen. Die Koordinationsschicht ist die jüngste. Aus ihren acht schnellen Überarbeitungen folgt ein Vorsatz, noch keine Regel: eine Betriebswoche vor jeder Erweiterung, und Änderungen an der Koordinationsschicht durchlaufen dieselben Tiers wie Produktcode.

11Offene Fragen und Ausblick

Was heute nicht beantwortet ist, steht hier als Frage mit dem nächsten Schritt.

Was dieses Dokument nicht behauptet: dass der Prozess fertig ist. Was es behauptet: dass jede Regel entweder von einem Programm geprüft wird oder ausdrücklich als Urteil ausgewiesen ist, dass jede Zahl ihre Aussagekraft nennt und dass die offenen Fragen bekannt sind. Das ist der Stand, von dem aus ein Pilot starten kann.

Die Prozessvorlage ist öffentlich und kann eingesehen werden: github.com/Crashman1983/dev-process