hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/wiki/concepts/llm/spec-driven-development-harness.md

2.9 KiB
Raw Blame History

created updated sources tags
2026-07-02 2026-07-02
youtube/2026-07-02_david-tielke-enterprise-ki-softwareentwicklung.md
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 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

External Sources