Dieses Dokument beschreibt, wie man mit KI-Agenten produktionsreife Software entwickelt, gesteuert durch Semantic Anchors.
Semantic Anchors sind kompakte Begriffe, die in LLMs zuverlässig reiches Domänenwissen aktivieren. Statt seitenlange Anweisungen zu schreiben, referenziert man ein Konzept, das das Modell bereits tief versteht. "Nutze TDD, London School" ist kürzer als Test-Driven Development mit Mocks und Outside-In-Design zu erklären. "Folge arc42" ist kürzer als 12 Architektur-Abschnitte zu beschreiben. Die Prompts bleiben kurz, präzise und wartbar.
Dieser Workflow wurde verwendet, um vier Open-Source-Projekte zu bauen, alle 100% KI-generiert. Die goldene Regel: Ich prompte nur, ich fasse den Code nie selbst an. Jede Zeile Code, jeder Test, jede Dokumentationsdatei wurde von der KI unter meiner Anleitung geschrieben.
-
dacli: Ein vollständiges CLI-Tool mit Spezifikation, Architekturdokumentation, Tests und Benutzerhandbuch. Von einer KI gebaut, von 5 verschiedenen LLMs gegengelesen.
-
Semantic Anchors Website: 228+ GitHub Stars, Dokumentation und eine Videoserie.
-
Vibe Coding Risk Radar: Eine interaktive Webanwendung zur Bewertung von KI-Coding-Risiken.
-
Bausteinsicht: Bidirektionale Synchronisation zwischen einem strukturierten JSON-Architekturmodell und draw.io-Diagrammen — Architecture-as-Code trifft draw.io.
|
Note
|
Semantic Anchors sind im Dokument mit ⚓ gekennzeichnet. Ein Klick auf einen Anker führt zur vollständigen Definition auf der Semantic Anchors Website. |
|
Important
|
Dieser Workflow ist für Greenfield-Projekte konzipiert, die von Grund auf mit KI-Unterstützung gebaut werden. Für bestehende Codebasen siehe Workflow-Anpassung für Brownfield-Projekte. |
Der häufigste Fehler beim KI-Coding ist der Prompt "Baue mir ein CLI-Tool" mit der Erwartung eines funktionierenden Ergebnisses. Das ist so, als würde man einen Junior-Entwickler bitten, aus einem Einzeiler-Briefing eine komplette Anwendung zu bauen. Das Ergebnis ist bestenfalls unvorhersehbar.
Dieser Workflow geht den umgekehrten Weg: Die Arbeit wird in kleine, klar definierte Schritte zerlegt, und der Agent bearbeitet jeden davon eigenständig. Jeder Schritt erzeugt ein konkretes Artefakt, das man bei Bedarf prüfen kann.
Das Paradox: Je kleiner man die einzelne Aufgabe macht, desto mehr Autonomie kann man dem Agenten geben. Ein vages "Baue mir X" erfordert ständige Kontrolle. Ein präzises "Implementiere Issue #42 mit TDD, basierend auf Spec und Architektur in src/docs/" kann eigenständig laufen. Die Phasen in diesem Dokument sind darauf ausgelegt, genau solche präzisen, abgeschlossenen Aufgaben zu erzeugen.
Das hängt direkt mit Eichhorst’s Principle zusammen, das Shannons Noisy-Channel-Theorem auf LLM-Coding anwendet. Ein LLM ist kein deterministisches Werkzeug. Es ist ein verrauschter, nicht-deterministischer Kanal. Es halluziniert, verliert Kontext und liegt manchmal schlicht falsch. Aber ein Agent in einer Schleife korrigiert sich selbst: Der Compiler meldet einen Fehler, der Agent liest ihn, fixt den Code, führt die Tests aus, liest den Fehlschlag, korrigiert die Logik und wiederholt — bis alles grün ist. Das ist keine Magie — das ist Fehlerkorrektur, genau wie Shannon sie beschrieben hat.
Wer einen LLM promptet und das Ergebnis ins Projekt einfügt, betreibt eine offene Schleife. Kein Compiler-Check, keine Test-Suite, kein Review. Das LLM rät einmal und man hofft, dass es richtig geraten hat. Wenn ein Agent Code schreibt, den Compiler ausführt, die Tests laufen lässt und iteriert bis alles passt, ist das eine geschlossene Schleife. Dasselbe Prinzip, das einen Thermostaten funktionieren lässt.
Verschiedene Tests korrigieren verschiedene Fehlerklassen. Der Compiler fängt Syntaxfehler. Unit-Tests fangen Logikfehler. BDD-Tests fangen Domänenfehler. Jede Schicht erhöht die Zuverlässigkeit des Kanals. Ungetesteter Code ist ein unkorrigierter Kanal — das Rauschen geht direkt durch.
Die Konsequenz: Bessere Tests schlagen bessere Prompts. Eine umfassende Test-Suite macht aus einem mittelmäßigen Modell einen zuverlässigen Coding-Partner. Und wenn die Komplexität einer Spezifikation die Kapazität des LLM übersteigt, helfen mehr Tokens nicht. Die Antwort sind kleinere Spezifikationen, klarere Grenzen und bessere Tests.
Jeder kleine Schritt in diesem Workflow ist eine kurze Übertragung über den verrauschten Kanal. Kurze Übertragungen mit Fehlerkorrektur sind weit zuverlässiger als eine lange, unkontrollierte Übertragung.
Diese Prinzipien gelten für alle Phasen:
- ⚓ Plain English nach Strunk & White
-
Alle Dokumentation verwendet kurze Sätze, aktive Sprache und keine überflüssigen Wörter. Für deutschsprachige Dokumentation gilt analog ⚓ Gutes Deutsch nach Wolf Schneider.
- ⚓ Conventional Commits
-
Alle Commits folgen einem standardisierten Format für eine saubere, maschinenlesbare Git-History.
- ⚓ Docs-as-Code nach Ralf D. Müller
-
Dokumentation lebt im Repository als AsciiDoc, gebaut von docToolchain. Docs-as-Code behandelt Dokumentation wie Quellcode: versioniert, reviewt und automatisch gebaut.
- ⚓ Definition of Done
-
Code besteht alle Tests, Feature-Branch ist gemergt oder PR erstellt, Dokumentation ist aktualisiert, Architekturentscheidungen sind dokumentiert.
Bevor es losgeht, die Projektinfrastruktur aufsetzen:
-
Git-Repository initialisieren
-
docToolchain installieren und das ⚓ arc42-Template herunterladen
-
KI-Coding-Umgebung mit einer
AGENTS.mdkonfigurieren (oder toolspezifisches Äquivalent wieCLAUDE.md) -
Dem KI-Agenten Zugriff auf GitHub oder GitLab über die CLI geben (
ghoderglab). Der Agent braucht das später für Issues, Pull Requests und ADR-Diskussionen. Für Nachvollziehbarkeit empfiehlt sich ein eigener Account. -
Entsprechend Eichhorst’s Principle Fehlerkorrektur-Schichten für das Projekt aufsetzen: Linter, Pre-Commit-Hooks, CI-Pipelines und statische Analyse. Jede Schicht fängt eine andere Fehlerklasse ab und macht den LLM-Kanal zuverlässiger. Der Vibe Coding Risk Radar kann helfen, die passenden Checks für das Risikoprofil des Projekts zu bestimmen. Diese Checks entfalten ihre volle Wirkung erst mit den ersten Zeilen lauffähigen Codes — früh aufsetzen, aber mit wachsendem Projekt erneut prüfen.
cd <your-project>
curl -Lo dtcw https://doctoolchain.org/dtcw
chmod +x dtcw
./dtcw docker downloadTemplateDetails und andere Plattformen: Offizielle Installationsanleitung.
AGENTS.md ist ein offener Standard zur Steuerung von KI-Coding-Agenten.
Die Datei liegt im Repository-Root und wird automatisch zu Beginn jeder Session gelesen.
Sie dient als Projektgedächtnis: Coding-Konventionen, Architekturentscheidungen, Dateistruktur und Verweise auf wichtige Dokumente.
Die meisten KI-Coding-Tools unterstützen sie oder haben ein Äquivalent (Claude Code nutzt z.B. CLAUDE.md).
Eine minimale AGENTS.md für diesen Workflow:
# Project: <Projektname>
## Key Documents
- PRD: src/docs/specs/prd.adoc
- Specification: src/docs/specs/
- Architecture: src/docs/arc42/
- Reviews: src/docs/reviews/
## Conventions
- Documentation: Plain English according to Strunk & White
- Testing: TDD (London or Chicago School as appropriate)
- Code: DRY, SOLID, KISS, Ubiquitous Language (DDD)
- Commits: Conventional Commits, reference issue number
- Branches: feature/<issue-description>Im weiteren Verlauf wird der KI-Agent die Datei selbst weiter pflegen.
Beim Start einer neuen KI-Session liest der Agent die AGENTS.md und hat sofort den nötigen Kontext.
|
Tip
|
Vor jedem neuen EPIC den Kontext komprimieren.
Innerhalb einer Session das Kontextfenster im Auge behalten.
An natürlichen Übergängen (z.B. nach Abschluss eines Issues) manuell komprimieren, statt zu warten, bis das Modell im ungünstigen Moment auto-komprimiert und dabei wichtigen Kontext verliert.
Der Agent holt sich den Kontext automatisch aus |
Die eigene Idee in eigenen Worten der KI erklären. Das ist die eine Stelle, an der mehr besser ist. Folgende Aspekte abdecken:
-
Das Problem, das gelöst werden soll
-
Wer es nutzen wird (Zielgruppe)
-
Wie das gewünschte Ergebnis aussieht
-
Einschränkungen: Budget, Zeitrahmen, Tech-Stack-Präferenzen, Plattform
-
Was es nicht ist: Explizite Grenzen helfen der KI, Scope Creep zu vermeiden
-
Inspiration: Ähnliche Tools oder Ansätze, die man gesehen hat
Diese Aspekte in beliebiger Reihenfolge abdecken. Der nächste Schritt bringt Struktur in die rohen Ideen.
Die KI auffordern, die ⚓ Sokratische Methode zur Klärung der Anforderungen zu nutzen.
Use the Socratic Method to help me clarify requirements for [your project].
Ask me at most 3 questions at a time. Challenge my assumptions.
Keep asking until you fully understand the requirements.Das aktiviert gezieltes Fragen, Hinterfragen von Annahmen und produktiven Umgang mit Nicht-Wissen. Die Einschränkung "höchstens 3 Fragen" verhindert Fragen-Überflutung.
Zusätzliche Anker für strukturierte Abdeckung:
Use the Socratic Method combined with MECE to clarify requirements.⚓ MECE (Mutually Exclusive, Collectively Exhaustive) stellt sicher, dass die Fragen alle Bereiche überlappungsfrei abdecken.
Den Dialog fortführen, bis man mit der KI zufrieden ist, dass die Anforderungen klar sind.
Die KI bitten, ein ⚓ Product Requirements Document (PRD) als AsciiDoc zu schreiben. Ein PRD erfasst das Was und Warum, nicht das Wie: Problemstellung, Ziele, Nutzer-Personas, Erfolgskriterien und Scope-Grenzen.
Write a PRD based on our discussion. Save it as src/docs/specs/prd.adoc.Schritt 4 baut die Spezifikation in Schichten auf: von der Scope-Ermittlung (Actor-Goal-Liste) über Use Cases auf Persona-Ebene bis zu technischen System-Spezifikationen und ergänzenden Modellen.
Zuerst den Scope mit einer ⚓ Actor-Goal-Liste entdecken:
Create an Actor-Goal List from the PRD.
For each actor, list every goal they have against the system.
Apply the Goal Level test: "Does the actor go home happy if this goal
is achieved?" — if yes, it's a User Goal. If not, it's a Subfunction
(extract only when reused). Save as src/docs/specs/actor-goal-list.adoc.Use Cases auf User-Goal-Ebene aus der Actor-Goal-Liste generieren. Diese beschreiben, was Akteure erreichen wollen und wie das System reagiert — in Prosa, auf einem Abstraktionsniveau, das Stakeholder reviewen können.
Create Persona Use Cases from the PRD and Actor-Goal List.
For each User Goal, write a Use Case in Cockburn's Fully Dressed format:
- Primary Actor and Stakeholders & Interests
- Trigger, Preconditions
- Main Success Scenario (numbered steps)
- Extensions (alternative/failure paths, referencing step numbers)
- Postconditions (Success Guarantee and Minimal Guarantee)
- Business Rules (BR-001, BR-002, ...)
Then add for each Use Case:
- Activity Diagram covering all flows (not just the happy path)
- Acceptance criteria in Gherkin format (Given/When/Then)
Save as .adoc files in src/docs/specs/.Jeder Use Case in ⚓ Cockburns Fully Dressed Format definiert:
-
Primary Actor: Wer den Use Case initiiert und das Ziel hat.
-
Stakeholders & Interests: Wer noch am Ergebnis beteiligt ist und was sie davon brauchen.
-
Trigger: Das spezifische Ereignis, das den Use Case auslöst ("Benutzer klickt auf Absenden", "System empfängt Webhook"). Ohne Trigger weiß weder die KI noch ein Tester, wann der Use Case beginnt.
-
Main Success Scenario: Die nummerierten Schritte des Happy Path, jeder beschreibt beobachtbares Systemverhalten.
-
Extensions: Benannte Verzweigungen (3a, 4b, …) für Fehlerbehandlung, Validierungsfehler und Randfälle — mit Verweis auf den Schritt, von dem sie abzweigen.
-
Nachbedingungen (Postconditions): Der garantierte Systemzustand nach erfolgreicher Ausführung (Success Guarantee) und die minimale Garantie auch bei Fehlschlag (Minimal Guarantee). Nachbedingungen sind das, was die Tests prüfen.
-
Geschäftsregeln (Business Rules): Nummerierte Regeln (BR-001, BR-002, …) für Validierungslogik, Berechnungen oder Domäneninvarianten. Geschäftsregeln machen implizites Wissen explizit. Ohne sie erfindet die KI eigene Validierungslogik — oder lässt sie komplett weg.
Je präziser der Use Case, desto weniger muss die KI bei der Implementierung raten. Cockburns Format ist bewusst prosabasiert — es schreibt keine bestimmte Notation vor. Activity-Diagramme und Gherkin sind komplementäre Darstellungsformen, die wir darauf aufsetzen:
⚓ Gherkin (Given/When/Then) liefert Akzeptanzkriterien, die sowohl für Menschen lesbar als auch maschinell testbar sind. Diese Kriterien werden später die Grundlage für TDD.
Activity Diagrams definieren Abläufe, Fehlerpfade und Randfälle visuell — die KI kann ihnen bei der Implementierung folgen, um alle Zweige abzudecken, nicht nur den Happy Path.
System Use Cases aus den Persona Use Cases ableiten. Wo Persona Use Cases beschreiben, was Akteure wollen, beschreiben System Use Cases, was das System an seinen technischen Schnittstellen tut — API-Endpunkte, CLI-Befehle, Events, Dateiformate.
Derive System Use Cases from the Persona Use Cases.
For each system interface (API endpoint, CLI command, event, file format):
- Trigger and Preconditions (technical: HTTP method, auth token, system state)
- Input: format, validation rules, constraints
- Processing: steps the system performs (reference Business Rules)
- Output: response format, status codes, payload schema
- Error responses: codes, messages, recovery hints
- Non-functional: performance budget, rate limits, timeouts
Use EARS syntax (When/While/If/Shall) for individual requirements
where applicable. Save as src/docs/specs/system-use-cases.adoc.System Use Cases schließen die Lücke zwischen stakeholder-orientierten Persona Use Cases und der Implementierung. Sie sind der Input, den die KI braucht, um korrekte API-Handler, CLI-Parser und Event-Prozessoren zu generieren, ohne technische Details zu erraten.
Simon Martinellis AI Unified Process nennt das den Übergang von Business Use Cases zu System Use Case Specifications — dieselbe Unterscheidung auf anderer Granularitätsebene.
Nicht jede Anforderung passt in einen Use Case. Ergänzende Spezifikationen je nach Projekttyp erstellen:
Based on the Use Cases, create supplementary specifications:
- Entity Model: entities, attributes, relationships, constraints (as PlantUML ERD)
- State Machines: for entities with lifecycle behavior (as PlantUML state diagrams)
- Interface Contracts: DTOs and schemas at system boundaries
- Validation Rules: cross-cutting rules not tied to a single use case
Save in src/docs/specs/.Welche ergänzenden Specs man braucht, hängt vom Projekt ab. Ein CLI-Tool braucht vielleicht nur ein Entity Model. Eine Webanwendung braucht typischerweise alle vier. Die KI fragt nach, wenn etwas fehlt — der Feedback-Loop (Schritt 8) fängt Lücken früh auf.
Die KI bitten, aus der Spezifikation eine Architektur abzuleiten:
Fill the arc42 template in src/docs/arc42/ based on the specification in src/docs/specs/.
Use PlantUML C4 diagrams for architecture visualization.Das arc42-Template wurde im Vorbereitungsschritt heruntergeladen. Die KI kennt die Template-Struktur und füllt die 12 Abschnitte passend.
⚓ arc42 bietet 12 Abschnitte, die alles von Kontextabgrenzung bis Deployment abdecken.
⚓ C4 Diagrams kombiniert mit PlantUML ermöglichen textbasierte Architektur-Visualisierung auf vier Ebenen: Context, Container, Component, Code. Da die Dokumentation AsciiDoc verwendet, werden PlantUML und andere Text-to-Diagram-Tools nativ unterstützt — die KI generiert Diagramme als Code, und der Build rendert sie automatisch.
Architekturentscheidungen werden als ⚓ ADRs nach Nygard dokumentiert. Jedes ADR folgt der Struktur: Titel, Status, Kontext, Entscheidung, Konsequenzen.
Für jede Entscheidung wird eine ⚓ Pugh-Matrix mit 3-Punkt-Skala (-1, 0, +1) erstellt, um Alternativen gegen Qualitätskriterien zu bewerten.
Document this architecture decision as an ADR according to Nygard.
Evaluate alternatives using a Pugh Matrix with a 3-point scale (-1, 0, +1).
Align criteria with the quality goals defined in the arc42 documentation.
Create a GitHub issue for discussion before finalizing.Die KI erstellt jeden ADR zunächst als GitHub/GitLab Issue. Man prüft das Issue, kommentiert oder genehmigt es. Erst nach Freigabe wird der ADR in die arc42-Dokumentation übernommen. So ist jede Architekturentscheidung über die Issue-Historie nachvollziehbar. Alle ADRs müssen sich an den Qualitätsanforderungen aus arc42 Abschnitt 10 orientieren.
Ein Architektur-Review mit der ⚓ Architecture Tradeoff Analysis Method (ATAM) durchführen:
Conduct an ATAM review of the architecture in src/docs/arc42/.
Focus on the quality attributes defined in our quality goals.
Document the results as a review report in src/docs/reviews/.ATAM bewertet systematisch die Architektur gegen Qualitätsattribut-Szenarien. Dieser Schritt kann nach signifikanten Architekturänderungen wiederholt werden.
Implementierungs-Issues aus der Spezifikation generieren:
Create EPICs and User Stories as GitHub issues based on the specification
in src/docs/specs/. Reference the arc42 documentation for technical context.
Follow the INVEST criteria for User Stories.
Use MoSCoW prioritization for the initial backlog order.
Mark dependencies between issues with labels or cross-references.⚓ INVEST stellt sicher, dass User Stories Independent, Negotiable, Valuable, Estimable, Small und Testable sind.
⚓ MoSCoW (Must have, Should have, Could have, Won’t have) liefert klare Priorisierung.
Die initiale Backlog-Reihenfolge folgt der EPIC-Sequenz. Die KI dokumentiert Abhängigkeiten zwischen Issues (z.B. "blocked by #12"), damit die Implementierungsreihenfolge klar ist. Mit wachsendem Projekt das Backlog regelmäßig groomen und nach neuen Erkenntnissen priorisieren.
Create a feature branch for this EPIC.
Select the next logical issue from the backlog (respect dependencies).
Analyze it and document your analysis as a comment on the issue.
Implement it using TDD (choose London or Chicago School as appropriate).
Each test references its Use Case ID for traceability. Commit when done.
Check if the spec or architecture docs need updating.Für jedes Issue:
-
Analysieren: Die KI untersucht das Issue, prüft zugehörige Specs und Architektur, checkt Abhängigkeiten zu anderen Issues und postet eine Analyse als Kommentar
-
Mit TDD implementieren: Die KI schreibt zuerst Tests, dann die Implementierung. Jeder Test referenziert die Use-Case-ID, die er verifiziert (z.B.
UC-01). Die KI wählt den passenden Mechanismus für die Sprache — Annotationen in Java, Kommentare in JavaScript, Docstrings in Python. Das schafft Rückverfolgbarkeit von Tests zu Spezifikationen ohne zusätzliches Tooling. -
Committen: Nach Implementierung und grünen Tests committen mit Referenz auf die Issue-Nummer
-
Docs prüfen: Fragen, ob Spezifikation oder Architekturdokumentation basierend auf den Erkenntnissen aktualisiert werden muss
TDD (Test-Driven Development) gibt es in zwei Schulen:
-
⚓ TDD, London School (Mockist): Unit Under Test isolieren, Abhängigkeiten mocken. Gut für interaktionslastigen Code.
-
⚓ TDD, Chicago School (Classicist): Verhalten über die öffentliche API testen, echte Kollaborateure nutzen. Gut für zustandsbasierte Logik.
Die KI wählt die passende Schule basierend auf den Code-Eigenschaften.
Während der Implementierung werden Lücken in Spezifikation oder Architektur auffallen. Das ist normal und erwartet. Regelmäßig die KI fragen:
Based on what we learned during implementation, does the specification
or architecture documentation need updating?Die Docs aktualisieren, bevor es weitergeht. So bleibt die Spezifikation ein lebendiges Dokument statt eines veralteten Artefakts. Die Spec ist nicht nur ein Mittel zur Codegenerierung — sie bleibt die autoritative Beschreibung des Systemverhaltens, gepflegt neben dem Code, solange das Projekt lebt.
Die KI bitten, die Codebasis zu reviewen:
Conduct a code review following the Fagan Inspection method.
Focus on correctness, maintainability, and adherence to the specification.
Document findings as a review report in src/docs/reviews/.Fagan Inspection ist ein strukturierter, systematischer Review-Prozess mit definierten Rollen und Phasen. Er findet Defekte, die Tests allein nicht aufdecken.
|
Tip
|
Ein anderes KI-Modell oder eine frische KI-Session für Reviews nutzen. Eine KI, die ihren eigenen Code reviewt, hat dieselben blinden Flecken wie ein Entwickler, der seinen eigenen Code liest. |
Conduct a security review based on the OWASP Top 10.
Document findings and recommendations in src/docs/reviews/.
Create GitHub issues for any vulnerabilities found.⚓ OWASP Top 10 deckt die kritischsten Sicherheitsrisiken für Webanwendungen ab. Auch für CLI-Tools oder Libraries identifiziert die Methodik gängige Schwachstellenmuster.
Sobald der Code V1-Status erreicht hat, gründlich explorativ testen:
Execute the tool and test it thoroughly. Focus on edge cases, unexpected
inputs, and error handling. The goal is to find bugs, not to confirm
that it works. Create a GitHub issue immediately for each bug you find.Das unterscheidet sich von den TDD-Tests während der Implementierung. Jene Tests verifizieren spezifiziertes Verhalten. Exploratives Testen sucht gezielt nach nicht-spezifiziertem Verhalten und Randfällen. Die KI führt das Tool direkt aus und interagiert damit wie ein echter Benutzer.
Jeden Bug aus dem explorativen Testen analysieren und fixen. Nach dem Fix zurück zu Schritt 11 und erneut testen. Wiederholen, bis keine Bugs mehr gefunden werden.
Jeder Fix folgt derselben TDD-Disziplin: einen fehlschlagenden Test schreiben, der den Bug reproduziert, dann fixen.
Dieser Workflow ist optimiert für Greenfield-Projekte mit einem einzelnen Entwickler und KI-Unterstützung. Überlegungen für andere Kontexte:
- Teamprojekte
-
Pull Requests statt direkter Merges nutzen. ADR-Diskussionen in GitHub Issues werden mit mehreren Reviewern wertvoller. Verschiedene KI-Modelle für verschiedene Review-Rollen einsetzen.
- Größere Projekte
-
Die Arbeit in mehrere Feature-Branches pro EPIC aufteilen. ATAM-Reviews nach jeder größeren Architekturänderung durchführen, nicht nur einmal. Das Backlog häufiger groomen, je größer das Projekt wird.
- Legacy-Codebasen
-
Dieser Workflow geht von einem Neustart aus. Siehe Workflow-Anpassung für Brownfield-Projekte für eine Anleitung zu Reverse Engineering, Basis-Testabdeckung und inkrementeller Migration mit Bounded Contexts.
- Frontend / HTML-Anwendungen
-
Dieser Workflow funktioniert gut für Backend-Code, CLIs und Bibliotheken, wo Compiler und TDD starke Fehlerkorrektur bieten. Frontend-Anwendungen lassen sich mit dem gleichen Ansatz bauen, aber konsistente UI ist schwerer automatisiert zu überprüfen. Die Fehlerkorrekturschichten, die Backend-Entwicklung zuverlässig machen (Compiler-Fehler, Test-Failures), haben kein direktes Äquivalent für visuelle Konsistenz.
Als Gegenmaßnahme: mit einem Design-System oder einer Komponentenbibliothek starten und einzelne Komponenten testen, bevor man Gesamtseiten integriert. Visual Regression Testing mit Playwright-Screenshot-Vergleichen in die CI-Pipeline aufnehmen. Das bedeutet erheblichen Mehraufwand gegenüber Backend-Projekten, aber ohne diese Maßnahmen tendiert die KI zu funktionalen, aber visuell inkonsistenten Ergebnissen.
Die wichtigsten Einzeiler pro Phase mit den Semantic Anchors, die sie aktivieren:
| Phase | Prompt | Anker |
|---|---|---|
Anforderungen |
|
|
PRD |
|
|
Persona Use Cases |
|
|
System Use Cases |
|
|
Ergänzende Specs |
|
— |
Architektur |
|
|
ADR |
|
|
ATAM |
|
|
Backlog |
|
INVEST, MoSCoW |
Implementierung |
|
TDD London / Chicago, SOLID, DRY, DDD |
Code Review |
|
Fagan Inspection |
Security |
|
|
Testen |
|
— |
Querschnitts-Anker für alle Phasen: Docs-as-Code (Ralf D. Müller), Conventional Commits, Plain English / Strunk & White.
Dieses Dokument beschreibt einen transparenten Workflow mit Standard-Prompts. Keiner der Prompts verwendet Rollenspiel-Muster wie "Du bist ein Experten-Tester" oder "Agiere als Senior Architect." Das ist Absicht. Semantic Anchors aktivieren das richtige Wissensgebiet, ohne dem Modell eine Rolle vorzuspielen. "Führe eine Fagan Inspection durch" ist präziser als "Du bist ein erstklassiger Code-Reviewer."
In der Praxis profitiert der Workflow stark von spezialisiertem Tooling. MCP-Server wie Responsible Vibe MCP setzen agentische Workflows mit Phasen-Gates und Review-Checkpoints durch. Serena bietet semantische Code-Navigation, sodass der Agent mit Symbolen und Referenzen statt mit Rohtext arbeiten kann. Skill-Systeme wie Superpowers kodifizieren wiederverwendbare Prozessmuster wie TDD, Debugging und Code-Review-Workflows. Playwright MCP ermöglicht dem Agenten die Steuerung eines Browsers für End-to-End-Tests und exploratives Testen von Webanwendungen. Diese Tools automatisieren die Disziplin, die dieses Dokument manuell beschreibt.
Das Ziel dieses Dokuments ist Transparenz. Jeder Schritt ist sichtbar, jeder Prompt ist reproduzierbar, und nichts hängt von proprietärem Tooling ab. Wer den Prozess verstanden hat, kann beliebige Tools einsetzen, die das Einhalten erleichtern.
Dieser Workflow zeigt, wie Semantic Anchors KI-gestützte Entwicklung systematisch und wiederholbar machen. Jeder Prompt bleibt kurz, weil der Anker das vollständige Konzept aktiviert. Die Fehlerkorrektur-Schichten (Spezifikation, Architektur-Review, TDD, Code Review, Security Review, exploratives Testen) stapeln sich, um den verrauschten LLM-Kanal zuverlässig zu machen.
Man muss kein Experte in jeder hier aufgeführten Methodik sein. Die KI kennt diese Konzepte. Die eigene Aufgabe ist es zu wissen, welchen Anker man wann einsetzt, und die Ergebnisse zu verifizieren.
Beim nächsten Projekt ausprobieren. Mit der Sokratischen Methode für die Anforderungen starten und sehen, wohin es führt. Wer Anker entdeckt, die im eigenen Workflow gut funktionieren: zur Sammlung beitragen.
Wer mit diesem Greenfield-Workflow vertraut ist, kann ihn auf bestehende Codebasen anpassen. Siehe Workflow-Anpassung für Brownfield-Projekte für eine Schritt-für-Schritt-Anleitung.
-
Birgitta Böckeler, Exploring Gen AI (martinfowler.com) — eine kritische Analyse von Spec-Driven-Development-Tools (Kiro, spec-kit, Tessl) und deren Trade-offs. Untersucht, wo aufwändige Upfront-Spezifikationen helfen und wo sie Overhead erzeugen.
-
Simon Martinelli, AI Unified Process — eine anforderungsgetriebene Methodik, die Rational-Unified-Process-Prinzipien mit KI-Tooling kombiniert. Behandelt KI als Konsistenz-Engine, die Code aus sich entwickelnden Spezifikationen regeneriert, in vier Phasen: Inception, Elaboration, Construction, Transition.
-
Ralf D. Müller & Simon Martinelli, Spec-Driven Development (software-architektur.tv, Folge 298) — Podcast-Diskussion darüber, wie Spezifikationen und Anforderungen in den Mittelpunkt KI-gestützter Entwicklung rücken, und warum iterative Verfeinerung besser funktioniert als perfekte Upfront-Specs.
-
Johannes Rabauer, LLM Coding mit Semantic Anchors: Von Vibe Coding zur echten Java-App (rabauer.dev, Mai 2026) — Zusammenfassung einer zweistündigen Live-Coding-Session, die den vollständigen Workflow am Beispiel eines Fahrplans für Modelleisenbahnen durchspielt. Zeigt, wie Semantic Contracts das Problem der Kontext-Persistenz über Sessions hinweg lösen und warum Docs-as-Code-Praxis jetzt für LLM-Kontext doppelt zahlt.