Spec-first auf einem Blatt

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 EinstiegSpec-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 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, nicht ein Tausend-Zeilen-Diff.
• Der Mensch merged: das Ergebnis ist ein Entwurf eines Pull-Requests;Aufsicht oder Freigabe stellt ihr je Projekt ein — 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. Oder mit einem echten Backlog-Item prüfen, was die Zerlegung leistet —die Demo arbeitet ohne Drehbuch.