57 lines
2.9 KiB
Markdown
57 lines
2.9 KiB
Markdown
|
---
|
||
|
|
created: 2026-07-02
|
||
|
|
updated: 2026-07-02
|
||
|
|
sources:
|
||
|
|
- youtube/2026-07-02_david-tielke-enterprise-ki-softwareentwicklung.md
|
||
|
|
tags: [concept, software-engineering, spec-driven, test-harness, ai-development]
|
||
|
|
---
|
||
|
|
|
||
|
|
# Spec Driven Development mit Harness
|
||
|
|
|
||
|
|
**Spec Driven Development mit Harness** ist ein KI-gestütztes Entwicklungsansatz, bei dem eine formale Spezifikation (Requirements → Beschreibung) zuerst erstellt und dann von der KI in Code umgesetzt wird. Ein **Test-Harness** validiert automatisch, ob der generierte Code die Spezifikation erfüllt.
|
||
|
|
|
||
|
|
## Ursprung
|
||
|
|
|
||
|
|
Das Konzept wurde von **David Tielke** in seinem [45-Tage-Enterprise-KI-Experiment](https://www.youtube.com/watch?v=eLDHrqKplVI) als **Phase 2-3** der Evolutionsleiter identifiziert. Es ist der Übergang von Mikro-Management (Phase 1) zu systematischem, qualitätsgesteuertem Vorgehen.
|
||
|
|
|
||
|
|
## Wie es funktioniert
|
||
|
|
|
||
|
|
1. **Requirements Engineering:** Anforderungen werden formal spezifiziert (User Stories, API-Verträge, Datenmodelle)
|
||
|
|
2. **Harness-Erstellung:** Ein Test-Harness wird generiert oder manuell erstellt — er kodifiziert die Spezifikation als ausführbare Tests
|
||
|
|
3. **KI-Generierung:** Die KI generiert Code aus der Spezifikation, geführt durch den Harness
|
||
|
|
4. **Automatische Validierung:** Der Harness prüft, ob der generierte Code die Spezifikation erfüllt (API-Tests, Workflow-Tests, WireMock für Service-Isolation)
|
||
|
|
5. **Iterate:** Bei Fehlern wird die Spezifikation verfeinert oder der Harness erweitert
|
||
|
|
|
||
|
|
## Verwandtschaft mit Karpathy's LLM-Wiki-Pattern
|
||
|
|
|
||
|
|
Die Struktur ist eng verwandt mit dem **[[llm-knowledge-base.md]]**-Pattern (Karpathy):
|
||
|
|
|
||
|
|
| Karpathy Wiki | Spec Driven Development |
|
||
|
|
|---------------|------------------------|
|
||
|
|
| Raw (Quellmaterial) | Spezifikation (Requirements) |
|
||
|
|
| LLM-compiled (Wiki) | KI-generierter Code |
|
||
|
|
| Q&A (Validierung) | Test-Harness (Validierung) |
|
||
|
|
|
||
|
|
Beide Patterns folgen dem Prinzip: **Mensch erstellt die Quelle (Spezifikation/Wiki-Raw), KI kompiliert (Code/Wiki-Page), automatische Validierung prüft das Ergebnis (Tests/Q&A).**
|
||
|
|
|
||
|
|
## Teststrategie-Komponenten
|
||
|
|
|
||
|
|
Tielke verwendete folgende Test-Strategie im Enterprise-Experiment:
|
||
|
|
|
||
|
|
- **API-Tests** — Service-Endpunkte werden direkt getestet
|
||
|
|
- **Workflow-Tests** — N8n-Integrationen werden durchgetestet
|
||
|
|
- **WireMock** — Service-Isolation: externe Dependencies werden gemockt
|
||
|
|
- **TDD (ab Phase 4)** — Tests werden zuerst geschrieben, dann implementiert die KI
|
||
|
|
|
||
|
|
## Verbindungen
|
||
|
|
|
||
|
|
- **[[vibe-coding-vs-enterprise.md]]** — Übergeordnete Konzept-Seite mit allen 5 Phasen
|
||
|
|
- **[[../../people/david-tielke.md]]** — Der Experimentator
|
||
|
|
- **[[llm-knowledge-base.md]]** — Strukturelle Verwandtschaft (raw → LLM → validation)
|
||
|
|
- **[[llm-model-fusion-ensembles.md]]** — Harness als Validierungsschicht analog zu Fusion-Benchmarks
|
||
|
|
|
||
|
|
## External Sources
|
||
|
|
|
||
|
|
- David Tielke, „Der Moment, der die Softwareentwicklung geändert hat!" — https://www.youtube.com/watch?v=eLDHrqKplVI
|
||
|
|
- WireMock — http://wiremock.org
|
||
|
|
- N8n — https://n8n.io
|