Agentic Development: Umsetzung und Prüfung — Cheat Sheet

Der Spickzettel zum Seminar Spec-driven & Agentic Software Development, zweiter Teil: was passiert, sobald ein Agent schreibt — Build, Review, Tests, Subagents, Rechte, Governance und der eigene Prozess. Spezifikation und Projektkontext stehen auf dem ersten Blatt, Spec und Kontext. Werkzeugnamen und Konfigurationsschlüssel ändern sich schnell; maßgeblich bleibt die Dokumentation des jeweiligen Werkzeugs. Das Blatt fasst Entscheidungen zusammen — es bringt die Arbeitsweise nicht bei.

Was eine Build-Session hinterlässt

Artefakt	Inhalt
geänderte Dateien	die eigentliche Umsetzung
Testlauf	Beleg, dass die Kriterien greifen
Commit	eine Nachricht nach Konvention
Implementation Record	was in dieser Sitzung geschah
Liste zurückgestellter Arbeit	was bewusst offen blieb

Die letzte Zeile ist die interessanteste — dort steht, was der Agent nicht getan hat. Eine Planfreigabe vorab lohnt, wenn der Intent Lücken hat, die Änderung nicht umkehrbar ist (Migration, Löschung, Veröffentlichung) oder der Fußabdruck mehrere Bereiche berührt; sonst kostet sie nur Zeit.

Modul: Agentische Implementierung mit bmad-build

Aufträge formulieren

Statt	Besser
Füge in Zeile 42 ein Feld ein	Eintragen soll dauerhaft gespeichert sein
Mach die Tests grün	Kriterium X muss geprüft sein
Räum das mal auf	Diese Funktion bleibt, ihr Aufrufer wandert

Wer das Wie diktiert, übernimmt die Verantwortung für das Wie.

Modul: Agentische Implementierung mit bmad-build

Review mit mehreren Linsen

Linse	Frage an den Diff
blind-hunter	Was hat bisher niemand angesehen?
edge-case-hunter	Was passiert am Rand des Wertebereichs?
verification-gap	Was wird behauptet, aber nicht belegt?
acceptance-auditor	Erfüllt es die Akzeptanzkriterien?

Prüfbar sind Pull Requests, Commits, Branches, einzelne Dateien oder der Arbeitsstand. Entscheidend ist die Unabhängigkeit: Wer die anderen Befunde nicht kennt, wiederholt sie nicht nur — und die Spezifikation liefert den äußeren Maßstab, gegen den überhaupt geprüft werden kann.

Warum Selbstevaluation nicht genügt, zeigt der Unterschied zwischen Abdeckung und Aussagekraft:

Abdeckung sagt	Aussagekraft braucht
Zeile wurde ausgeführt	eine Zusicherung dazu
Pfad wurde betreten	einen Grenzfall daneben
Test ist grün	ein Kriterium aus der Spec

Modul: Reviews, Tests und unabhängige Prüfung

Befunde einordnen

Weg	Wann	Ergebnis
Patch	echter Defekt im Diff	Korrektur in dieser Runde
Defer	bestand schon vorher	Eintrag im Backlog
Entscheidung	Anforderung unklar	Frage an einen Menschen

Wer alles patcht, zieht fremde Baustellen in den eigenen Pull Request. Eine Befundliste ist keine Aufgabenliste, sondern wird triagiert — Fehlalarme gehören heraus, sonst entwerten sie die echten Funde.

Modul: Reviews, Tests und unabhängige Prüfung

Teststrategie: Ebene und Zuständigkeit

Ebene	Erzeugt	Von Hand
Unit	einfache Fälle	Randfälle, Invarianten
Integration	Standardpfade	Transaktionen, Nebenläufigkeit
API	Status und Format	Autorisierung
End-to-End	Hauptfluss	Sonderfälle der Bedienung

Sicherheitskritische Tests schreibt ein Mensch — Authentifizierung, Rechte, Eingaben, Krypto. Teständerungen werden besonders geprüft: Ein gelöschter Test macht die Suite grün, ohne etwas zu beweisen, und abgeschwächte Zusicherungen sind im Diff leicht zu übersehen.

Modul: Reviews, Tests und unabhängige Prüfung

Subagents: wofür ja, wofür nicht

Gut geeignet	Heikel
Codeanalyse und Abhängigkeiten	paralleles Schreiben
Sicherheits- und Testlückenprüfung	geteilte Migrationen
Zusammenfassen großer Ausgaben	konkurrierende Umbauten
unabhängige Lösungsvarianten vergleichen	gemeinsame Konfigdateien

Faustregel: lesen gern parallel, schreiben lieber nacheinander. Die Beschreibung entscheidet, wann der Hauptagent den Subagenten überhaupt wählt; ohne Rückgabeformat kommt Prosa zurück statt eines Ergebnisses.

name = "abhaengigkeiten"
description = "Sucht Abhängigkeiten vor einem Umbau"
developer_instructions = """
Lies nur. Ändere keine Datei.
Nenne Datei und Zeile zu jeder Aussage.
Gib höchstens zehn Punkte zurück.
"""
sandbox_mode = "read-only"

Modul: Subagents und autonome Abläufe

Ausführung und Orchestrierung

Ausführung	Orchestrierung
eine Story je Aufruf	wählt die nächste Story
meldet einen Endstatus	wertet den Status aus
ändert Dateien, testet, committet	koordiniert Reihenfolge
kennt nur ihren Auftrag	kennt den Bestand

Ohne Orchestrator übernimmt ein Mensch die Auswahl — das ist ein gültiger Aufbau. Läuft eine Schleife unbeaufsichtigt, gehören die Abbruchgründe vorher fest:

Abbruchgrund	Bedeutung
unklarer Intent	Auftrag lässt zu viel offen
Intent-Lücke im Review	Umsetzung weicht von der Absicht ab
keine Subagents	Voraussetzung fehlt
Verifikation fehlgeschlagen	Ergebnis nicht belegbar
Reparaturschleife zu lang	keine Annäherung nach fünf Runden

Dazu die selbst gesetzten Grenzen: Laufzeit und Kosten je Lauf begrenzen, nur lokal committen, Freigabepunkte an den riskanten Stories, Rückweg und Protokoll klären, bevor der erste Lauf startet.

Modul: Subagents und autonome Abläufe

Rechte und Risiko

Ursache	Beispiel	Gegenmittel
zu viele Funktionen	Shell ohne Not	Werkzeuge begrenzen
zu viele Rechte	Schreibrecht auf Produktion	Rechte trennen
zu viel Autonomie	Push ohne Rückfrage	Bestätigung erzwingen

Die Ursachen addieren sich: Wer alle drei offen lässt, hat keine Grenze mehr. Die Rechtestufe gehört zur Aufgabe, nicht zur Person und nicht zur Gewohnheit:

Stufe	Erlaubt	Typischer Einsatz
lesend	ansehen, zusammenfassen	Analyse, Review
Arbeitsbereich	Dateien im Projekt ändern	Umsetzung einer Story
erweitert	Netz, Installation, Push	nur mit Freigabe

Nie in den Kontext:  .env, *.pem, *.key, secrets/
Netz:                nur die interne Registry
Ohne Rückfrage nie:  Migration, Löschung, Push
Trennung:            wer baut, merged nicht

Nicht vergessen, woher die Eingaben stammen, denen niemand traut: Issues, Pull Requests und Kommentare schreiben Beteiligte von außen, Dokumentation und Webseiten landen über Werkzeuge im Kontext.

Modul: Sicherheit, Berechtigungen und Governance

Governance im SDLC

Gruppe	Für KI-erzeugte Änderungen
Organisation	erlaubte Anwendungsfälle und Werkzeuge festlegen
Software schützen	Herkunft und Abhängigkeiten prüfen
Sicher entwickeln	Pull Request, Review, Scans verpflichtend
Reagieren	Rückweg und Nachweis je Änderung

Nachweis heißt: Welches Werkzeug, welcher Auftrag, wer hat freigegeben. Die üblichen Prüfungen gelten unverändert weiter — geschützte Branches, statische Analyse, Abhängigkeits- und Geheimnis-Scans, menschliches Review als Voraussetzung für den Merge.

Modul: Sicherheit, Berechtigungen und Governance

BMad, Spec Kit und OpenSpec

Merkmal	BMad	Spec Kit	OpenSpec
Schwerpunkt	Rollen und Skills	Prozess	Änderungen
Ablauf	Spec, Stories, Build	Spec, Plan, Tasks	Proposal, Specs
Umfang	flexibel, breit	gründlich	bewusst knapp
Rollenmodell	ausgeprägt	kaum	kaum
Bestandscode	ausdrücklich	iterativ	lebende Specs

Kein Ansatz ist grundsätzlich besser — sie treffen verschiedene Teams. Gemeinsam ist allen dreien: Absicht wird geschrieben, bevor Code entsteht, jede Phase erzeugt ein Markdown-Artefakt für die nächste, und der Coding Agent liest diese Artefakte als Kontext.

uv tool install specify-cli --from git+https://…
/speckit.constitution   # Grundsätze einmalig
/speckit.specify        # Anforderungen
/speckit.plan           # technischer Plan
/speckit.tasks          # Aufgabenliste
/speckit.implement      # Umsetzung
/speckit.converge       # Abgleich mit dem Stand

npm install -g @fission-ai/openspec@latest
openspec init
/opsx:propose   # openspec/changes/warteliste/
                #   proposal.md  design.md
                #   specs/       tasks.md
/opsx:apply     # umsetzen
/opsx:archive   # nach openspec/archive/

Szenario	Naheliegend
kleines Team, bestehende Anwendung	knapper, änderungsorientierter Weg
reguliertes Unternehmensprojekt	feste Kette mit schriftlichen Grundsätzen
schneller interner Prototyp	eigener Minimalprozess, zwei Artefakte

Entscheidend ist, dass die Wahl begründet ist — nicht, dass sie vollständig ist.

Modul: BMad, Spec Kit und OpenSpec im Vergleich

Der eigene Team-Workflow

Frage	Festlegung
Wo geht eine Anforderung ein?	Ort und Format
Was steht mindestens in einer Spec?	Pflichtfelder
Welche Entscheidungen werden notiert?	Kriterium dafür
Was darf ein Agent tun?	Rechtestufe je Umgebung
Welche Tests sind verbindlich?	Ebenen und Zuständigkeit
Wie wird geprüft?	Linsen und Reihenfolge
Wer gibt frei?	Namen, nicht Rollen
Was wird dokumentiert?	Nachweis je Änderung
Wann wird abgebrochen?	Grenzen und Eskalation

Wo eine Antwort fehlt, entscheidet später der, der gerade dasitzt. Festgehalten wird das auf einer Seite im Repository, nicht in einer Präsentation:

Aufgabentypen:   trivial | Feature | riskant
Kontextartefakte: AGENTS.md, SPEC.md, Stories
Werkzeuge:       zugelassen und verboten
Skills:          Kontext, Spec, Build, Review
Tests:           Ebene je Aufgabentyp
Rechte:          Stufe je Umgebung
Menschen:        wer prüft, wer gibt frei
Messgrößen:      Nacharbeit, Durchlaufzeit

Als Messgrößen taugen: Anteil der Änderungen, die nach dem Merge nachgebessert werden · Zeit vom Eingang bis zur Freigabe · Zahl der Reviewbefunde, die sich als echter Defekt bestätigten · Anteil der Sitzungen ohne Rückfrage.

Modul: Eigener Team-Workflow

Typische Fallen

Scope Drift. Aus einer Story wird ein Umbau, den niemand beauftragt hat — und aus einer Validierungsregel ein umgebautes Buchungsmodul.
Der Diff wird überflogen statt gelesen. Die Zusammenfassung des Agenten ist nicht das Ergebnis; dort steckt die eigentliche Arbeit.
Zustimmungsfalle. Der Agent bewertet seinen eigenen Diff im selben Kontext und findet ihn schlüssig — auch alle Linsen im selben Kontext heben die Unabhängigkeit auf.
Grüne Tests ohne Bezug zur Anforderung. Sie messen die Implementierung an sich selbst; Mocks ersetzen dann genau die Abhängigkeit, die geprüft werden sollte.
Zurückgestellte Arbeit wird nie wieder angesehen und gilt als erledigt.
Der Subagent gibt eine Behauptung zurück, die niemand am Code prüft; Zusammenfassungen verlieren genau das Detail, das den Fehler ausmacht.
Ein Subagent ohne Sandbox-Angabe darf mehr, als beabsichtigt war.
Parallele Einheiten schreiben in dieselben Dateien und hinterlassen einen halben Stand.
Ein eigener KI-Prozess neben dem echten Prozess wird bald umgangen — und Pipeline- und Container-Konfiguration werden weniger streng geprüft als Code.
Bestätigungen, die zu häufig verlangt werden, erteilt man reflexhaft; eine Freigabematrix ohne benannte Personen entscheidet nichts.
Zwei Ansätze parallel im selben Repository erzeugen zwei Wahrheiten.
Der Rückblick entfällt, weil das Ergebnis ja gestimmt hat. Regeln werden dann ergänzt, aber nie gestrichen.

Zum Seminar Spec-driven & Agentic Software Development