---
titel: "Spec-first auf einem Blatt"
adresse: https://anvil-coder.tech/spec-first
beschreibung: "Das Argument für Spec-Driven Development auf einer Seite: warum das Review-Bottleneck nicht am Tippen hängt, welche drei Mechaniken den Unterschied machen — und was das Werkzeug ausdrücklich nicht verspricht. Zum Ausdrucken gesetzt."
sprache: de
---

Für die interne Diskussion

# Spec-first auf einem Blatt

Wer sein Team überzeugen will, braucht kein Deck — er braucht eine Seite, die die Einwände ernst nimmt. Diese hier ist zum Ausdrucken gesetzt: Cmd/Ctrl+P genügt.

## Das Problem heisst nicht Tippen

KI-Assistenten erzeugen Code schneller, als Teams ihn prüfen können — der Engpass ist das Review, nicht die Umsetzung. Und je länger ein Chat-Verlauf, desto weiter driftet das Ergebnis vom Ziel: die Anforderung stand nie fest, bevor der erste Code entstand.

## Die Umkehrung: erst die Spezifikation, dann alles andere

Spec-Driven Development dreht die Reihenfolge: erst wird beschrieben und geprüft, was entstehen soll — daraus folgen Architektur und Code. Bei Anvil Coder heisst dieser Einstieg[Spec-Studio](https://docs.anvil-coder.tech/docs/spec-studio): sechs geführte Abschnitte, aus denen echte Tickets werden. Welche Story läuft, entscheidet weiterhin ein Mensch.

## Drei Mechaniken, die den Unterschied machen

- **Gate statt Hinweis:** [Guardrails](https://anvil-coder.tech/guardrails) sind maschinenlesbare Regeln — ein Verstoss ist ein Befund im Lauf, kein Review-Kommentar.

- **Commit je Schritt:** jeder Arbeitsschritt hinterlässt einen eigenen Commit — [die Historie ist der Nachweis](https://anvil-coder.tech/blog/commit-historie-als-nachweis), nicht ein Tausend-Zeilen-Diff.

- **Der Mensch merged:** das Ergebnis ist ein Entwurf eines Pull-Requests;[Aufsicht oder Freigabe stellt ihr je Projekt ein](https://anvil-coder.tech/blog/aufsicht-ist-keine-alles-oder-nichts-frage) — ohne gesetzte Stufe läuft der Auftrag durch.

## Was das Blatt nicht verspricht

Kein Ersatz fürs Review: ob eine fachliche Entscheidung richtig ist, bleibt Urteilsarbeit des Teams. Build und Test im Lauf sind zuschaltbar, keine Selbstverständlichkeit. Und eine Spezifikation macht schlechte Anforderungen nicht gut — sie macht sie sichtbar, bevor Code entsteht.

## Der nächste Schritt

Den Weg einmal konkret nachlesen:[von der Spezifikation zum geprüften Pull-Request](https://anvil-coder.tech/blog/from-spec-to-pull-request). Oder mit einem echten Backlog-Item prüfen, was die Zerlegung leistet —[die Demo](https://anvil-coder.tech/demo) arbeitet ohne Drehbuch.