Der Spec-Vault: Harness Engineering für AI-gesteuerte Produktentwicklung
Harness Engineering für AI-gesteuerte Produktentwicklung.
25 Features in 5 Tagen, 1 Engineer, 0 Merge-Konflikte. Same model. Different harness.
Das Paradox
Das schnellste AI-Projekt, das wir je durchgeführt haben, produzierte mehr strukturierte Dokumentation als jedes klassische Projekt davor. Feature-Specs, Akzeptanzkriterien, Audit-Reports, Architektur-Referenzen, Entscheidungslogs. Gleichzeitig schrieb der Engineer weniger Prosa als in einem einzigen Sprint Planning.
25 Features. 5 Tage. Ein Engineer. Nicht durch bessere Prompts. Durch ein System, das der AI sagt, was sie wissen muss, bevor das Gespräch beginnt.
Der falsche Engpass
Session öffnen
→ Kontext geben
→ AI codet
→ Session endet
→ Wissen weg
→ Nächste Session bei null
Die Industrie optimiert das Gespräch mit der AI. Bessere Prompts. Größere Context Windows. Feinere Modellwahl. Die stille Annahme dahinter: Der Engpass ist die Konversation.
Das war 18 Monate lang korrekt. In dieser Phase war die AI selbst der Constraint. Wer besser prompten konnte, bekam bessere Ergebnisse. Prompt Engineering war der richtige Fokus für 2024.
Was sich änderte: Die Modelle wurden gut genug. Nicht perfekt. Aber gut genug, dass die einzelne Session nicht mehr der Engpass ist. Der Engpass verschob sich. Nicht nach rechts, zum Output. Nach links, zum Input.
Wer AI-gestützt entwickelt, kennt das Muster: Die erste Session produziert beeindruckende Ergebnisse. Die zweite Session kennt die Entscheidungen der ersten nicht. Die dritte widerspricht der zweiten. Nach einer Woche hat man Code, aber kein Produkt. Features, aber keine Richtung. Geschwindigkeit, aber kein Gedächtnis.
Das fundamentale Problem: AI-Sessions sind zustandslos. Jede neue Session startet bei null. Kontext, Entscheidungen und Produktstrategie existieren nur im Kopf des Engineers. Solange der Engineer der einzige Kontextspeicher ist, skaliert nichts.
Die Lösung in einem Satz
Ein Vault ist ein git-versioniertes Repository, das ausschließlich Planung, Strategie und Steuerung enthält. Kein Code. Kein Deployment. Nur die Frage: Was soll gebaut werden und warum?
Der Vault steuert ein separates Code-Repository über deterministische Pipelines. Jede AI-Session liest den Vault, führt definierte Schritte aus und schreibt Ergebnisse zurück. Die AI improvisiert nicht. Sie führt aus.
Das Code-Repository enthält die Implementierung. Der Vault enthält die Richtung.
| Vault | Code-Repository |
|---|---|
| Produktstrategie, Roadmap | Technische Architektur |
| Feature-Specs (Was und Warum) | Implementierung (Wie) |
| Akzeptanzkriterien | Tests und Validierung |
| Entscheidungslog | Code-Patterns und Konventionen |
| Audit-Ergebnisse | Build- und Deploy-Pipeline |
| AI-Kontext und Regeln | Anwendungscode |
Beide sind git-versioniert. Beide haben eine vollständige Historie. Keine Information lebt nur in einem Kopf oder einem Chat-Verlauf. Versionierung gibt jeder Entscheidung eine Historie. Branching erlaubt parallele Arbeit. Diffing macht Änderungen sichtbar. Der Audit Trail entsteht automatisch, nicht durch Disziplin.
Der Spec: Anforderung ohne Implementierung
Das Kernelement im Vault ist der Feature-Spec. Ein Spec beschreibt Was gebaut werden soll und Warum. Niemals das Wie.
Keine Code-Beispiele. Keine Component-Namen. Keine API-Pfade. Keine Architektur-Hinweise. Die AI leitet die technische Umsetzung selbst aus der bestehenden Codebase ab. Sie kennt die Patterns, die Services, die Konventionen besser als der Spec-Autor. Technische Vorgaben im Spec würden sie einschränken statt zu führen.
Ein Spec enthält vier Dinge:
- Anforderungen. Was der Nutzer können soll, was sich ändern soll.
- Akzeptanzkriterien. Messbare, testbare Bedingungen für "fertig".
- Abgrenzung. Was explizit nicht enthalten ist.
- Offene Fragen. Was geklärt sein muss, bevor implementiert wird.
Status-Lifecycle mit Gates
entwurf ──→ bereit ──→ in-arbeit ──→ review ──→ erledigt ──→ archiv/
└──→ verworfen ──→ archiv/
Jeder Statuswechsel hat Voraussetzungen. Bereit bedeutet: Alle offenen Fragen geklärt, Akzeptanzkriterien vollständig, Product Owner hat Go gegeben. In-Arbeit bedeutet: Konflikte mit anderen Specs ausgeschlossen, Branch existiert, Plan ist bestätigt. Review bedeutet: Jedes Akzeptanzkriterium einzeln verifiziert, nicht nur "Code kompiliert".
Kein Übergang ohne Gate. Kein Gate ohne Dokumentation.
Deterministische Pipelines statt freier Konversation
AI-Sessions sind im Vault-Modell keine Gespräche. Sie sind Pipeline-Ausführungen. Jeder Slash Command ist eine State Machine mit definierten Phasen und Gates. Kein freies Prompting, kein "mach mal".
| Command | Phasen | Gate |
|---|---|---|
| /develop-feature | Spec lesen, Konflikte prüfen, Worktree anlegen, Codebase analysieren, Plan erstellen, implementieren, validieren | Plan-Bestätigung durch PO |
| /review-feature | Engineering-Standards prüfen, Spec-Drift analysieren, visuell testen, Fixes umsetzen | Alle Akzeptanzkriterien erfüllt |
| /product-audit | Anwendung visuell analysieren, Code gegen Standards prüfen, Specs generieren | Specs mit Akzeptanzkriterien |
| /ux-audit | Nielsen-Heuristiken bewerten, Journeys pro Rolle, Friction-Map erstellen | Improvement-Specs generiert |
| /conflict-check | Aktive Specs laden, Überlappungen identifizieren, Locked Areas vergleichen | Keine Konflikte oder PO-Entscheidung |
| /archive-feature | Branch-Merge prüfen, Spec verschieben, Backlog aktualisieren, Worktree aufräumen | Branch in main gemergt |
/develop-feature als Beispiel: Sieben Phasen. Jedes Akzeptanzkriterium einzeln verifiziert mit Notiz. Kein "passt schon". Kein "sieht gut aus". Die AI liest den Spec, erstellt einen Plan, wartet auf Bestätigung, implementiert, und prüft danach jedes Kriterium gegen das Ergebnis.
Das macht AI-Entwicklung reproduzierbar. Gleicher Spec, gleicher Prozess, vergleichbares Ergebnis. Nicht "die AI hat zufällig gut geliefert". Der Prozess liefert zuverlässig.
Der geschlossene Kreislauf
Das eigentlich Neue ist nicht die Geschwindigkeit. Es ist der geschlossene Kreislauf.
/product-audit
→ findet: "Security Headers fehlen"
→ generiert: F-058-security-headers-cors-hardening.md
→ Status: bereit
/develop-feature F-058
→ liest Spec, plant, implementiert
→ validiert alle Akzeptanzkriterien
→ Status: review
/review-feature F-058
→ prüft gegen Standards und Spec
→ Status: erledigt
/archive-feature F-058
→ Spec ins Archiv, Worktree aufgeräumt
→ Backlog aktualisiert
Kein Medienbruch. Kein Ticket-System. Kein "ich schreibe mal ein Jira-Ticket und in drei Sprints ist es vielleicht dran". Der Audit findet ein Problem. Das System generiert einen Spec. Die AI implementiert die Lösung. Der Review prüft das Ergebnis. Alles in einer Kette. Alles git-versioniert.
Im Kreislauf werden Features aus drei Quellen geboren:
Kunden- und PO-initiiert
Klassisch. Der Product Owner beschreibt eine Idee. Im Vault-Modell reichen drei Sätze. Die Kosten einer Fehlinterpretation sind gering, weil Bauen günstiger ist als Spezifizieren. Die AI setzt um, der PO bewertet das Ergebnis statt eine Beschreibung.
Audit-generiert
Product Audits, UX Audits und Security Audits analysieren den Ist-Zustand der Anwendung automatisiert. Für jedes gefundene Problem generiert das System einen vollständigen Spec mit Akzeptanzkriterien. Kein Mensch schreibt diese Specs. Die Pipeline erzeugt sie.
Engineer-initiiert
Während der Arbeit an Feature A erkennt die AI ein angrenzendes Problem. Ein Spec wird erstellt. Der Product Owner entscheidet über Umsetzung oder Verwerfung. Der Kreislauf bleibt derselbe.
Im konkreten Projekt wurden zwölf von 25 Features durch Audits generiert. Nicht angefordert, sondern aus dem Anwendungszustand abgeleitet. Der Product Owner hat alle 25 Entscheidungen getroffen. Aber die zwölf audit-generierten Features hätte er manuell nie spezifiziert. Nicht weil er sie nicht wollte. Weil ein Mensch nicht systematisch jede Heuristik, jeden Security-Vektor und jede Engineering-Konvention prüfen kann.
Parallelität: Vier Sessions, null Merge-Konflikte
Ein Git-Repository hat ein Working Directory. Ein Feature pro Session. Das limitiert auf serielle Ausführung. Git Worktrees brechen diese Limitierung. Jedes Feature bekommt ein eigenes Verzeichnis mit eigenem Branch. Gleiche Git-Datenbank, isolierte Arbeitsumgebungen.
~/projekt/ → main (Audits, Reviews)
~/projekt-F-053/ → feature/F-053 (Custom Background)
~/projekt-F-054/ → feature/F-054 (Navigation Redesign)
~/projekt-F-056/ → feature/F-056 (File Upload Security)
~/projekt-F-058/ → feature/F-058 (CORS Headers)
Der Vault orchestriert die Parallelität. Jeder Spec deklariert seine Locked Areas: welche Dateien und Module das Feature berührt. Bevor ein neues Feature startet, prüft die Konfliktprüfung alle aktiven Specs und deren Locked Areas. Überlappung? Das Feature wartet, oder der Product Owner entscheidet über die Reihenfolge.
| Sicher parallel | Nicht parallel |
|---|---|
| Backend-Feature + Frontend-Feature | Zwei Features am selben Component |
| Neuer Endpoint + Infra-Änderung | Zwei Datenbank-Migrationen |
| Unabhängige UI-Seiten | Überlappende Shared Services |
Spitzentag im Projekt: 17 Features in 53 Commits. Vier AI-Sessions gleichzeitig. Null Merge-Konflikte. Nicht durch Glück. Durch Locked Areas im Vault, die Konflikte verhindern bevor sie entstehen.
Zustandslos, aber nicht gedächtnislos
Jede AI-Session ist zustandslos. Der Vault macht sie trotzdem nicht gedächtnislos. Der AI-Kontext-Layer gibt jeder neuen Session dieselben Regeln, dieselben Patterns, dasselbe akkumulierte Wissen.
CLAUDE.md → Regeln, Verbote, Konventionen
_meta/ai-context/
├── feature-workflow.md → Slash Commands, Phasen, Gates
├── backend-referenz.md → API-Patterns, Three-File-Pattern
├── frontend-referenz.md → Component-Konventionen, State
├── infra-referenz.md → AWS CDK, Deployment-Patterns
└── vault-kontext.md → Querverweise Vault ↔ Code-Repo
01-produkt/feature-specs/aktiv/ → Offene Aufträge
01-produkt/feature-specs/archiv/ → Konzept-Referenz für abgeschlossene Features
CLAUDE.md ist die erste Datei, die jede Session liest. Sie enthält Regeln ("Kein Code in diesem Vault"), Workflow-Vorschriften ("Vor Feature-Finalisierung: Konfliktprüfung") und Konventionen ("Specs beschreiben nur Was und Warum"). Die Referenz-Dateien liefern Orientierung: Wo finde ich was? Welche Patterns gelten? Wie hängen Vault und Code zusammen?
Session 1 und Session 50 produzieren Code mit denselben Patterns. Nicht weil dieselbe Person beteiligt war. Nicht weil der Chat-Verlauf erhalten blieb. Weil der Vault die Entscheidungen kodiert hat.
Die ökonomische Inversion
Wenn ein Feature 30 Minuten bis vier Stunden kostet statt ein bis zwei Wochen, invertiert die Ökonomie der Spezifikation.
| Modell | Feature-Dauer | Kosten bei Verwerfung |
|---|---|---|
| Klassisch (1 Entwickler) | 1 bis 2 Wochen | 7.500 bis 15.000 EUR |
| Klassisch (Team) | 1 bis 2 Sprints | 30.000 bis 60.000 EUR |
| Vault-gesteuert | 30 Min bis 4 Std | 100 bis 500 EUR |
Ein Spezifikationsworkshop kostet 2.000 bis 4.000 EUR. In derselben Zeit baut die Vault-Pipeline das Feature. Der Kunde sieht nicht eine Beschreibung. Er sieht das Ergebnis.
Die Implikation ist unbequem: Bauen und verwerfen ist günstiger als Upfront-Spezifikation. Ein verworfenes Feature kostet 200 EUR. Ein Spezifikationsworkshop, der ein Feature verhindert hätte, kostet 3.000 EUR.
Kein Qualitätsverlust. Die Specs sind präziser, nicht umfangreicher. Jedes Kriterium ist testbar. Jede Abgrenzung ist explizit. Weniger Prosa, mehr Substanz.
Qualitätssicherung: Eingebaut, nicht nachgelagert
Im klassischen Modell ist Qualitätssicherung ein separater Schritt am Ende. Im Vault-Modell ist sie Teil jeder Phase.
| Phase | Qualitäts-Gate |
|---|---|
| Spec-Erstellung | Codebase-Analyse, Randfall-Prüfung, Akzeptanzkriterien-Schärfung |
| Vor Implementierung | Konfliktprüfung gegen alle aktiven Specs (Pflicht, nicht optional) |
| Implementierung | Plan-Bestätigung durch Product Owner bevor Code geschrieben wird |
| Nach Implementierung | Jedes Akzeptanzkriterium einzeln verifiziert mit Notiz |
| Review | Engineering-Standards, Spec-Drift-Analyse, visueller Test |
| Archivierung | Branch muss gemergt sein. Spec wird Konzept-Referenz, nicht Code-Referenz |
Im konkreten Projekt gab es 23 automatisierte Review-Runden mit Selbstkorrekturen. Die AI hat sich an den Kriterien im Spec selbst korrigiert. Kein manuelles Bugfixing, kein separates QA-Team. Wer das nicht akzeptieren kann, bremst die Pipeline auf klassische Geschwindigkeit.
Zahlen aus der Praxis
Full-Stack-Webapp. Angular 21, .NET 10, PostgreSQL, AWS. Ein Engineer, fünf Tage.
| Metrik | Wert |
|---|---|
| Abgeschlossene Features | 25 |
| Davon Audit-generiert | 12 (48 Prozent) |
| Code-Commits | 90+ |
| Geschriebene Codezeilen | 26.000+ |
| Veränderte Dateien | 275+ |
| Maximale Parallelität | 4 AI-Sessions gleichzeitig |
| Spitzentag (Tag 4) | 17 Features, 53 Commits |
| Automatisierte Review-Runden | 23 |
| Merge-Konflikte | 0 |
| Verworfene Features | 1 (bewusst, Over-Engineering erkannt) |
Kein Feature-Typ wurde ausgelassen: UX (Custom Background, Navigation Redesign, Progressive Disclosure), Security (PII-Verschlüsselung, CORS, Token Management, Frontend Hardening), Infrastruktur (Production Monitoring, Database Lifecycle), Funktionalität (Timezone-aware Date Picker, Team-Kalender, File Upload Security).
Exponentielle Beschleunigung
Tag 1: ein Feature. Tag 2: null Features, nur Vault-Infrastruktur. Tag 3: sieben Features. Tag 4: 17 Features.
Das Muster ist nicht linear. Die ersten beiden Tage investieren in den Vault: AI-Kontext schreiben, Slash Commands bauen, Workflow-Regeln definieren. Ab Tag 3 wirkt der Compounding-Effekt. Der Audit generiert Specs, die /develop-feature umsetzt, die /review-feature validiert, die /archive-feature archiviert. Eine geschlossene Pipeline.
Compounding ist kein Bonus. Es ist die Architektur.
Die Investition in den Vault zahlt sich nicht additiv aus, sondern multiplikativ. Jedes Werkzeug beschleunigt alle folgenden Features. Jede Konvention verhindert alle folgenden Fehler. Am Tag 4 liest die AI einen Vault, der drei Tage akkumuliertes Wissen enthält. Die Specs sind schärfer. Die Patterns stabiler. Die Konfliktprüfung zuverlässiger.
Wo es nicht funktioniert
Der Vault-Ansatz hat Voraussetzungen. Wer sie nicht erfüllt, wird enttäuscht.
- Erfahrene Engineers. Der Vault ersetzt keine Expertise, er verstärkt sie. Wer Architektur, Domäne und Kundenbedürfnisse nicht versteht, füttert den Vault mit falschen Entscheidungen. Die AI verstärkt dann die falschen Patterns.
- Stabile Codebase mit Patterns. Die AI leitet die technische Umsetzung aus bestehenden Patterns ab. Ohne konsistente Patterns improvisiert sie bei jedem Feature anders. Eine Codebase ohne Tests, ohne Konventionen gibt der AI nichts, woraus sie ableiten kann.
- Specs, die Was beschreiben, nicht Wie. Wer Component-Namen vorgibt, schränkt die AI ein, statt sie zu führen. Das erfordert Vertrauen: Die AI kennt die Codebase. Der Mensch kennt das Kundenproblem.
- Disziplin bei Gates. Jeder Statuswechsel hat Voraussetzungen. Jede Konfliktprüfung ist Pflicht. Kein "das passt schon". Die Geschwindigkeit kommt aus dem Prozess, nicht aus dem Abkürzen des Prozesses.
- Ein entscheidungsfähiger Product Owner. 17 Features an einem Tag bedeuten 17 Entscheidungen. Accept, Reject oder Modify. Wer drei Meetings braucht, um ein Feature freizugeben, bremst die Pipeline.
- Investition in die ersten Tage. Der Vault, die Slash Commands und der AI-Kontext müssen gebaut werden. Tag 1 und 2 produzieren keinen Feature-Output. Wer am ersten Tag schon Features sehen will, scheitert.
Skalierung in zwei Dimensionen
Vertikal: Mehr Features pro Engineer. Parallele Worktrees, Audit-generierte Specs und automatisierte Reviews vervielfachen den Output eines einzelnen Engineers. 25 Features in fünf Tagen statt drei bis fünf in einem Sprint.
Horizontal: Mehr Engineers pro Vault. Der gleiche Vault steuert mehrere Engineers. Jeder arbeitet auf seinen Worktrees, jeder folgt den gleichen Slash Commands, jeder prüft gegen die gleichen Specs. Die Konfliktprüfung verhindert, dass parallele Streams kollidieren.
Das gleiche Modell funktioniert mit sieben Engineers auf einer Enterprise-Plattform mit 100.000+ Zeilen Code genauso wie mit einem Engineer auf einer Kunden-Webapp. Die Vault-Struktur ändert sich nicht. Die Slash Commands ändern sich nicht. Die Geschwindigkeit pro Engineer bleibt.
Mehr Dokumentation, weniger schreiben
Das Paradox vom Anfang löst sich auf: Der Vault ist keine Dokumentation. Dokumentation beschreibt, was passiert ist. Der Vault bestimmt, was als nächstes passiert. Er ist kein Logbuch. Er ist ein Steuerungssystem.
AI-Entwicklung ohne Steuerungssystem ist schnelles Chaos. Ein Vault macht aus diesem Chaos einen reproduzierbaren Prozess. Specs definieren das Was. Slash Commands definieren den Prozess. Audits finden automatisch, was verbessert werden muss. Gates sichern die Qualität. Worktrees ermöglichen Parallelität. Alles versioniert, alles nachvollziehbar.
Kein Ticket-System. Kein Standup. Kein Sprint-Planning. Stattdessen: Ein Vault, ein Code-Repo, ein Product Owner, der entscheidet, und eine AI, die liefert.
Die Frage ist nicht, ob deine AI programmieren kann. Die Frage ist, ob sie morgen noch weiß, was sie gestern gelernt hat. Wer Prompt Engineering optimiert, optimiert die Session. Wer einen Vault baut, optimiert alle Sessions, die je folgen werden. Und das ist der Grund, warum ein Engineer mit AI den Output eines Teams liefern kann, ohne die Qualität eines Teams zu opfern.
