Spec-First Engineering (RFC-gesteuerte KI-Entwicklung)

1. Konzeptüberblick und systemisches Problem

Die häufigste Falle für Einsteiger im Vibe-Coding ist die Eile. Der Entwickler öffnet eine agentische IDE und tippt sofort in den Chat: "Erstelle mir eine Warenkorb-Seite mit Promo-Codes". Der Agent generiert 1000 Zeilen Code in 15 Sekunden, aber:

• Es wird ein veralteter Hook anstelle des modernen State-Managers des Projekts verwendet.
• Die Berechnung der Promo-Codes erfolgt clientseitig statt auf dem Backend (Sicherheitslücke).
• Typnamen werden dupliziert und die Lokalisierung wird komplett ignoriert.

Spec-First Engineering ist das goldene Gesetz des produktiven KI-gestützten Codings: Fasse niemals Code an, bevor ein genehmigter Plan vorliegt. Der Ingenieur fungiert als Chief Architect, formuliert einen umfassenden Vertrag (implementation_plan.md), klärt Edge Cases ab und gibt erst dann den Befehl zur Generierung an den Agenten.

2. Architektonische Taxonomie und mentales Modell

┌─────────────────────────────────────────────────────────────┐
│                 SPEC-FIRST ENGINEERING CYCLE                │
├─────────────────────────────────────────────────────────────┤
│ 1. Intent Exploration (Дослідження наміру)                  │
│    • Brainstorming, Edge-Case Interview ("Grill-Me")        │
│    • Визначення Anti-Goals (чого НЕ повинно бути)           │
├─────────────────────────────────────────────────────────────┤
│ 2. Formal Spec Artifact Creation                            │
│    • Types & Data Contracts (TypeScript interfaces / Zod)   │
│    • File Mutation Map ([NEW], [MODIFY], [DELETE])          │
│    • Verification Criteria (Automated test commands)        │
├─────────────────────────────────────────────────────────────┤
│ 3. Human Gate & Peer Approval                               │
│    • Інженер рецензує план, вносить корективи               │
├─────────────────────────────────────────────────────────────┤
│ 4. Deterministic Autonomous Execution                       │
│    • Агент виконує план покроково без відхилень             │
└─────────────────────────────────────────────────────────────┘

3. Praktische Ingenieurs-Szenarien im Production-Umfeld

01. Interviewing des Modells vor Feature-Entwicklung (Grill-Me-Pattern)

Bevor der Plan geschrieben wird, gibt der Entwickler die Anweisung: "Ich möchte das Stripe Payment System integrieren. Stelle mir fünf kritische Fragen zur Webhook-Verarbeitung, zu doppelten Zahlungen und zur Sicherheit, bevor du den Plan schreibst." Dies deckt versteckte Probleme bereits in der Ideenphase auf, nicht erst im Production-Betrieb.

02. Schutz vor architektonischer Erosion

Wenn ein Projekt von einem Team aus drei Ingenieuren mit Agenten betreut wird, müssen alle Änderungen zunächst über einen PR in den Ordner docs/specs/ laufen. Das Team erkennt die Absicht, bevor das Modell 50 neue Komponenten erstellt.

4. Fallstricke, typische Fehler und Sicherheit

• Analysis Paralysis (Übermäßige Bürokratie): Einen 20-seitigen Plan für eine Änderung der Button-Farbe zu schreiben, ist Zeitverschwendung. Für triviale Änderungen gilt die Regel des direkten Editierens. Spezifikationen sind nur für Aufgaben erforderlich, die mehr als zwei Dateien oder die Business-Logik betreffen.
• Plan-Drift während der Ausführung (Spec Drift): Wenn der Agent beim Coding ein neues Detail entdeckt und die Architektur eigenmächtig ändert, ohne die Spezifikation zu aktualisieren, verliert das System seine Steuerbarkeit. Verlangen Sie vom Agenten, den Plan bei unvorhergesehenen Schwierigkeiten stets zu aktualisieren.

5. Strategisches Fazit für Ingenieure im Jahr 2026

In einer Welt, in der Codegenerierung null Cent kostet, wird die wertvollste Ingenieurskompetenz nicht die Tipppgeschwindigkeit sein, sondern die Tiefe und Präzision bei der Formulierung technischer Spezifikationen. Wer die Spezifikation beherrscht, kontrolliert das System.