Zurück zum Blog

Spec-Driven Development für AI Coding: Vom Prompt zur belastbaren Software

AISoftware QualityEngineering LeadershipSoftware Architecture

AI Coding ist in vielen Entwicklungsteams vom Experiment zum normalen Arbeitsmodus geworden. Der Engpass liegt nicht mehr darin, schnell Code zu erzeugen, sondern darin, ob dieser Code zum Produkt, zur Architektur und zum Risiko des Unternehmens passt. Spec-Driven Development macht Spezifikationen wieder zum Steuerungsinstrument, bevor Agenten und Assistenten große Teile der Umsetzung übernehmen.

Was Spec-Driven Development verändert

Spec-Driven Development bedeutet nicht, alte Pflichtenhefte zurückzubringen. Gemeint ist ein schlanker, versionierter Arbeitsmodus: Anforderungen, Randbedingungen, Akzeptanzkriterien und technische Entscheidungen werden so beschrieben, dass Menschen und AI Coding Tools daraus konsistent arbeiten können.

Tools wie GitHub Spec Kit oder Kiro popularisieren diesen Ansatz, aber der Wert hängt nicht am Tool. Entscheidend ist, dass die Spezifikation nicht nachträgliche Dokumentation ist, sondern führendes Artefakt im Entwicklungsprozess.

Für wachsende Teams verändert das vier Dinge:

  • Produktklarheit: Der Agent bekommt nicht nur eine Aufgabe, sondern nachvollziehbare Ziele, Nicht-Ziele und Akzeptanzkriterien.
  • Architekturdisziplin: Sicherheits-, Daten- und Integrationsgrenzen stehen vor der Implementierung fest.
  • Review-Fokus: Code Reviews prüfen nicht nur Syntax und Stil, sondern Abweichungen von der Spezifikation.
  • Weniger Wissensverlust: Entscheidungen bleiben sichtbar, wenn Teammitglieder wechseln oder Agenten iterativ weiterarbeiten.

Wo Teams mit Spec-Driven Development starten sollten

Der beste Startpunkt ist nicht ein kompletter Prozesswechsel, sondern ein Feature mit klarem Geschäftswert und überschaubarem Risiko. Dort kann das Team lernen, welche Spezifikationen für Agenten wirklich hilfreich sind. Eine minimale Spezifikation kann so aussehen:

feature: invoice-export
business_goal: "Finance can export monthly invoices without developer support"
acceptance_criteria:
  - "Export includes only invoices visible to the current tenant"
  - "CSV columns remain stable for existing accounting imports"
  - "Every export is written to the audit log"
architecture_constraints:
  - "No direct database access from the UI layer"
  - "Reuse existing permission checks"

Wichtig ist, dass Product, Engineering und Security dieselbe Spezifikation lesen können. Wenn die Datei nur für Entwickler verständlich ist, verfehlt sie ihren Zweck.

Typische Warnsignale sind:

  • Prompts ersetzen Entscheidungen: Unklare Fachlogik wird erst während der Codegenerierung entdeckt.
  • Akzeptanzkriterien fehlen: Tests prüfen technische Pfade, aber nicht den geschäftlichen Zweck.
  • Agenten ändern Architektur nebenbei: Neue Libraries, APIs oder Datenmodelle entstehen ohne bewusste Entscheidung.
  • Reviews kommen zu spät: Das Team diskutiert Grundsatzfragen erst im Pull Request.

Warum das wichtig ist

Spec-Driven Development ist kein zusätzlicher Bürokratieschritt. Es ist eine Antwort auf ein ökonomisches Problem: AI Coding senkt die Kosten der Codeerzeugung, aber nicht automatisch die Kosten für Verständnis, Betrieb, Sicherheit und Wartung.

Für Führungskräfte zählt deshalb nicht, ob ein Team mehr Code produziert. Entscheidend ist, ob es schneller belastbare Produktänderungen liefern kann, ohne technische Schulden, Compliance-Risiken oder Abhängigkeit von einzelnen Senior-Entwicklern zu erhöhen.

Wer AI Coding produktiv einsetzen will, braucht Spezifikationen als Qualitätsgrenze: klein genug für Geschwindigkeit, konkret genug für Review und stabil genug für spätere Änderungen. Eine Architecture & AI Review kann klären, ob der aktuelle Entwicklungsprozess dafür tragfähig ist oder ob Agenten nur bestehende Unschärfen skalieren.