Das Problem mit KI-Entwicklung heute: Ein KI-Tool erhält eine vage Beschreibung (“Baue mir eine Dashboard-App”) und liefert Code, der technisch korrekt aussieht, aber an den eigentlichen Anforderungen vorbeigeht. Das Resultat? “Vibe Coding” – Code, der sich richtig anfühlt, aber die falschen Probleme löst.

Die Lösung: Spec-Driven Development. Statt direkt zu coden, werden erst klare, überprüfbare Spezifikationen definiert. Diese werden zur “Single Source of Truth” – für Entwickler, Teams und KI-Tools.

Dieser Artikel zeigt verschiedene Ansätze: von modernen KI-First-Tools wie Spec Kit bis zu bewährten Frameworks wie BDD. Plus: Wie heute schon mit einfachen Tools wie PlantUML und OpenAPI begonnen werden kann.

Vibe Coding vs. Spec-Driven: Ein Praxisvergleich

Typischer Vibe-Coding-Prompt:

Baue mir eine Anmelde-Seite mit React

Resultat: Eine generische Login-Form, die technisch funktioniert, aber deine spezifischen Anforderungen nicht trifft.

Spec-Driven Approach:

## User Authentication Spec

### Functional Requirements
- Login mit E-Mail und Passwort
- "Passwort vergessen" Link
- Nach erfolgreicher Anmeldung: Redirect zu /dashboard
- Bei Fehlern: Inline-Validierung ohne Seitenrefresh

### UI Requirements  
- Mobile-first Design
- Accessible (ARIA Labels, Keyboard Navigation)
- Brand Colors: #1e40af (Primary), #f59e0b (Accent)

Resultat: Code, der exakt deine Anforderungen erfüllt.

1. Spec Kit – Spezifikation als Ausgangspunkt

Spec Kit ist ein Beispiel für die KI-native Variante von spec-driven Entwicklung:

• Chaos-Prompts → strukturierte Spezifikation (Markdown)
• Spezifikation → Plan → Tasks → Code
• Integration mit Copilot, Gemini CLI, Cloud Code

Workflow (Beispiel):

speckit specify "Dashboard mit Datenvisualisierung"
speckit plan
speckit tasks
speckit implement T1 T2

Was passiert hier? Statt einem KI-Tool zu sagen “baue ein Dashboard”, wird zuerst genau definiert, was das Dashboard können muss. Die KI arbeitet dann gegen diese strukturierte Spezifikation – nicht gegen vage Ideen.

Einordnung: Spec Kit zeigt, wie sich der klassische Gedanke “erst spezifizieren, dann implementieren” in die KI-Ära übersetzt.

2. Warp.md – Das Meta-Layer-Denken

Während Spec Kit konkrete Werkzeuge liefert, beschreibt warp.md die Meta-Ebene:

• Ein Dokument oder Layer, das Intention, Spezifikation, Plan und Tasks synchronisiert
• Dient als „Warp Drive” zwischen Entwicklerintention und KI-Implementierung
• Setzt auf Transparenz: jede Entscheidung und jeder Schritt wird dokumentiert

Beispiel warp.md:

# warp.md
- Single Source of Truth: spec.md
- Review Gates: jede Phase muss bestätigt werden
- Automatische Tests aus den Spezifikationen ableiten

Einordnung: Warp ist weniger ein Tool als ein Denkmuster: Spezifikationen sind nicht statisch, sondern lebendig, versionierbar und KI-integriert.

3. Kiro (AWS) – Agentic IDE

Kiro bringt Spec-Driven Development direkt in die IDE:

• User Stories → Tech Plan → Tasks
• Agenten übernehmen Umsetzung, Entwickler reviewt
• Tiefe Integration mit AWS-Umgebung

Workflow:

kiro init project-name
kiro specify "Echtzeit-Dashboard für IoT-Daten"
kiro plan
kiro implement T1

Einordnung: Kiro ist ein kommerzieller Brückenschlag: spec-driven Methoden werden in die IDE verlagert, wo Entwickler ohnehin arbeiten.

4. BDD-Frameworks – Behavior Driven Development

Ein älterer, aber sehr ähnlicher Ansatz:

• Spezifikationen in natürlicher Sprache (Gherkin)
• Gleichzeitig Tests & Dokumentation
• Etablierte Tools: Cucumber, SpecFlow, Behat

Beispiel:

Feature: Datenvisualisierung
  Scenario: Nutzer lädt Daten hoch
    Given ein CSV mit Messwerten
    When der Nutzer auf "Visualisieren" klickt
    Then wird ein Liniendiagramm angezeigt

Einordnung: BDD ist quasi die Low-Tech-Vorstufe dessen, was Spec Kit automatisiert: Anforderungen werden in ausführbare Szenarien gegossen.

5. OpenAPI / AsyncAPI – Spezifikationen für Schnittstellen

Hier steht API-Design als Spezifikation im Mittelpunkt:

• JSON/YAML-Definitionen als Quelle der Wahrheit
• Daraus generieren Tools automatisch Server-Stubs, Clients und Tests

Beispiel OpenAPI:

paths:
  /users:
    get:
      summary: Liste aller Nutzer
      responses:
        '200':
          description: OK

Einordnung: API-Spezifikationen sind ein etabliertes Muster, das den gleichen Geist trägt: erst definieren, dann implementieren.

6. Model-Driven Engineering (MDE) – Modelle zuerst, Code später

Model-Driven Engineering ist ein Ansatz, bei dem nicht der Code im Vordergrund steht, sondern abstrakte Modelle, die dann automatisiert in Code übersetzt werden.

Idee:

• Entwickler definieren UML-Diagramme, DSLs (Domain-Specific Languages) oder andere Modellartefakte
• Aus diesen Modellen generieren Tools automatisch Codegerüste, Datenbanken oder Tests
• Änderungen erfolgen zuerst am Modell – der Code wird dann neu abgeleitet

Beispiel (UML → Java Codegerüst):

Ein Klassendiagramm in UML generiert automatisch eine Java-Klasse:

public class Customer {
    private String name;
    private String email;

    public String getEmail() {
        return email;
    }
}

Einordnung:

• Pro: Sehr gut, um große Systeme konsistent zu halten, besonders in Enterprise-Architekturen
• Contra: Schwerfällig, wenn sich Anforderungen oft ändern; Modelle werden manchmal zur Last
• Spec-Driven Richtung: Zeigt, dass Spezifikationen auch grafisch und formal sein können – und Code nur eine Ableitung ist

7. Contract-Based Development – Vertrauen ist gut, Verträge sind besser

Beim Design by Contract wird jede Funktion mit formalen Bedingungen versehen. So wird sichergestellt, dass Eingaben, Ausgaben und Zustände immer den Anforderungen entsprechen.

Idee:

• Preconditions: Bedingungen, die erfüllt sein müssen, bevor eine Funktion aufgerufen wird
• Postconditions: Bedingungen, die nach der Ausführung garantiert erfüllt sein müssen
• Invariants: Regeln, die über die gesamte Lebenszeit eines Objekts gelten

Beispiel (Python mit icontract Library):

from icontract import require, ensure

@require(lambda amount: amount > 0)
@require(lambda amount, balance: amount <= balance)
@ensure(lambda result: result >= 0)
def withdraw(balance: int, amount: int) -> int:
    return balance - amount

print(withdraw(100, 30))   # ✅ funktioniert
print(withdraw(100, 200))  # ❌ bricht mit ContractViolation ab

Einordnung:

• Pro: Erhöht die Zuverlässigkeit; Fehler werden früh erkannt
• Contra: Zusätzlicher Schreibaufwand, nicht in allen Sprachen unterstützt
• Spec-Driven Richtung: Hier verschmelzen Spezifikationen mit Code – die Spezifikation ist Teil der Implementierung

8. Moderne KI-Workflows und leichtgewichtige Tools

Viele der vorgestellten Ansätze stammen aus klassischen Entwicklungspraktiken (UML, MDE, Contracts). Doch im KI-Zeitalter haben sich die Anforderungen verschoben: Spezifikationen müssen leicht zu erstellen, maschinenlesbar und versionierbar sein.

Genau hier glänzen leichtgewichtige Tools wie PlantUML, Mermaid oder OpenAPI, weil sie sich direkt in KI-gestützte Entwicklungs-Workflows integrieren lassen.

PlantUML – Diagramme aus Text

PlantUML beschreibt UML-Diagramme in einer einfachen Textsyntax.

Vorteile:

• Versionskontroll-freundlich (Git)
• Einfach zu generieren und zu ändern
• Perfekt für KI-Integration

KI-Use-Case: Eine KI kann Spezifikationen oder User Stories automatisch in PlantUML-Code übersetzen → Entwickler erhält sofort ein visuelles Modell.

Beispiel (Klassendiagramm):

@startuml
class Customer {
  - name : String
  - email : String
  + getEmail() : String
}
@enduml

Die KI kann dieses Snippet direkt erzeugen und anschließend den Java-/Python-Code implementieren.

Mermaid – Diagramme in Markdown

Mermaid hat eine ähnliche Philosophie wie PlantUML, ist aber besonders stark in Markdown-Workflows integriert (GitHub, Notion, Obsidian).

Vorteile:

• Nahtlose Integration in Docs, Wikis, GitHub READMEs
• KI-Use-Case: Prompts → Mermaid-Diagramme → sofort als lebendige Doku im Repo sichtbar

Beispiel (Flowchart):

flowchart TD
    A[User Prompt] --> B[Spec Kit]
    B --> C[Spek-Datei]
    C --> D[KI Implementierung]

Damit lassen sich Workflow-Spezifikationen visuell dokumentieren – ohne teure Enterprise-Modeling-Tools.

OpenAPI – Spezifikationen für APIs

OpenAPI (früher Swagger) definiert Schnittstellen in YAML/JSON.

Vorteile:

• Starke Ökosystem-Unterstützung
• Automatische Code-Generierung
• Mock-Server, Tests

KI-Use-Case: Eine KI kann direkt aus User Stories eine OpenAPI-Spezifikation generieren → daraus entstehen automatisch Server-Stubs, Client-SDKs und Tests.

Warum gerade diese Tools?

• Textbasiert → leicht in Prompts, Git und CI/CD integrierbar
• Maschinenlesbar → KI kann Spezifikation erzeugen und daraus Code ableiten
• Kollaborativ → Entwickler, KI-Agents und Doku-Tools arbeiten auf derselben Basis
• Kostengünstig → Open Source oder sehr günstig, im Gegensatz zu komplexen Enterprise-Suiten

Einstieg in Spec-Driven Development

1. Sofort umsetzbar (heute):

• Bevor KI-Tools um Code gebeten werden: 3-5 Stichpunkte aufschreiben, was der Code genau tun soll
• Markdown für einfache Spezifikationen nutzen (funktioniert mit allen Tools)
• Für APIs: Mit OpenAPI-Definitionen starten statt direkt mit Code

2. Nächste Woche:

• PlantUML oder Mermaid für ein aktuelles Projekt ausprobieren
• Für eine Funktion erst die Spezifikation schreiben, dann den Code
• Eine bestehende API nachträglich mit OpenAPI dokumentieren

3. Mittelfristig:

• Moderne Tools wie Spec Kit testen (falls verfügbar)
• “Spec-First” als Teamprozess etablieren
• Spezifikationen in die CI/CD-Pipeline integrieren

4. Für größere Teams:

• BDD-Framework einführen (Cucumber, SpecFlow)
• Contract-based Development für kritische Schnittstellen
• Spec-Review vor Code-Review

Warum das funktioniert: Spezifikationen sind nicht nur Dokumentation – sie sind Steuerinstrumente. Sie helfen KI-Tools, besseren Code zu schreiben, und Entwicklern, bessere Entscheidungen zu treffen.

Der Paradigmenwechsel: Vom “Vibe Coding” hin zu strukturierten, überprüfbaren Spezifikationen, die sowohl Menschen als auch KI verstehen. Das ist der Schlüssel für qualitativ hochwertigen, KI-unterstützten Code.