Die meisten Ratschläge zum Prompten taugen für ernsthafte Arbeit immer noch nicht.

Sie sagen dir, du sollst „klar sein“, „Kontext geben“ und „mit dem Modell iterieren“. Fürs Brainstorming ist das in Ordnung. Um Code in ein echtes Repo auszuliefern, ist es schwach. Wenn du promptest, als würdest du chatten, bekommst du die Fehlerbilder eines Chats. Fehlende Dateien. Stillschweigende Annahmen. Seltsame Formatierung. Halb richtigen Code, der plausibel aussieht, bis die Tests fehlschlagen.

Deshalb ist die aktuelle Debatte um Spec-driven Development wichtig. Kritische Stimmen nennen es „Wasserfall mit Markdown“, „Spec Drift“ und „Token verbrennende Zeremonie“. Manchmal haben sie recht. Eine aufgeblähte Spec kann deine Zeit genauso schnell verschwenden wie ein vager Prompt. Aber der Gegenwind zielt teilweise auf das falsche Ziel. Das Kernproblem ist nicht Struktur. Es ist schlechte Struktur. Schlampiges Prompten fühlt sich schnell an, bis das Ergebnis wiederholbar sein muss.

Der nützliche Wechsel ist einfacher, als der Diskurs ihn klingen lässt. Hör auf, Prompts als Gespräche zu behandeln. Behandle sie als Funktionen. Gib ihnen eine Signatur, einen Body, einen Rückgabetyp und eine Fehlerbehandlung. Dann versionierst du sie, testest sie und änderst sie, sobald sie sich nicht mehr wie erwartet verhalten.

Diese Sichtweise taucht in Entwicklerkreisen immer wieder auf, auch im Reddit-Thread „specs beat prompts“. Es ist dieselbe Idee wie in Simon Willisons Arbeit zu Agentic Engineering und in Drew Breunigs Texten über den Aufstieg von Spec-driven Development. Wenn du ein praktisches Beispiel für diese Denkweise in einem Produkt-Workflow suchst, lohnt sich wie MeshBase Claude Opus für Next.js einsetzt, weil der Text den KI-Einsatz an echten Umsetzungsgrenzen festmacht statt an vagem Prompt-Theater.

Inhalt

Hör auf, mit deiner KI zu chatten, und programmier sie

Der kürzeste Weg zu besserem KI-Output: Hör auf, um „Hilfe“ zu bitten, und fang an, eine Schnittstelle zu definieren.

Ein Prompt im Gesprächston lädt das Modell ein, Lücken zu füllen. Manchmal ist das nützlich. Bei Coding-Arbeit läuft genau da meistens etwas schief. Das Modell rät deine Dateigrenzen, deine Architektur, deine Namensregeln und deine Risikotoleranz. Dann verschwendest du Zeit damit, Entscheidungen zu korrigieren, um die du es nie gebeten hast.

Was sich ändert, wenn du in Funktionen denkst

Ein Funktionsaufruf ist absichtlich langweilig. Er erwartet bestimmte Inputs. Er erledigt eine Aufgabe. Er gibt etwas zurück, über das du nachdenken kannst. Wenn du Prompts genauso behandelst, hörst du auf, Motivationsaufsätze an ein Modell zu schreiben, und fängst an, Verträge zu schreiben.

Dieser Vertrag zählt, weil strukturiertes Prompten in der Praxis die Zuverlässigkeit verbessert. Atlan berichtet in seinem Guide zu Prompt Engineering, dass strukturierte Prompt-Engineering-Prozesse KI-Fehler im Vergleich zu unstrukturierten Inputs um bis zu 76 % reduzieren können.

Faustregel: Wenn eine Aufgabe, falsch erledigt, die Produktion kaputt machen würde, formulier sie nicht wie eine beiläufige Bitte.

Das heißt nicht, dass jede Aufgabe eine riesige Spec braucht. Es heißt, dass dein Prompt so ernst genommen werden sollte wie jede andere Schnittstelle, von der du abhängst.

Eine Prompt-Funktion hat vier Teile

Nimm eine typische Brownfield-Aufgabe. Ein Agent soll auf einer bestehenden Seite mit Abrechnungseinstellungen ein Banner für ein Rate Limit ergänzen, ohne UI anzufassen, die nichts damit zu tun hat.

Ein schwacher Prompt sieht so aus:

  • „Füg auf der Abrechnungsseite eine Warnung zum Rate Limit hinzu.“
  • „Nutz das bestehende Designsystem.“
  • „Sorg dafür, dass die Tests weiter durchlaufen.“

Das ist kein Vertrag. Das ist ein Wunsch.

Ein Prompt im Funktionsstil sieht eher so aus:

Teil Was er tut Beispiel
Signatur Legt die nötigen Inputs fest Zieldateien, Ziel des Features, Einschränkungen
Body Beschreibt das Verhalten exakter Umfang, Designregeln, Erwartungen an Tests
Rückgabetyp Legt die Form des Outputs fest Unified Diff, JSON, Dateiliste, Markdown-Bericht
Fehlerbehandlung Steuert, wie es scheitert nach fehlendem Kontext fragen, unsichere Änderungen verweigern

Du sagst nicht mehr „Bitte mach etwas“. Du sagst „Mit diesen Inputs erzeugst du diese Art von Ergebnis, oder du scheiterst auf eine bekannte Weise“.

Das ist der Unterschied zwischen Prompten für Neues und Prompten für verlässliche Arbeit.

Das Paradigma „Prompt als Funktion“ erklärt

Eine Prompt-Funktion ist einfach ein API-Vertrag in natürlicher Sprache.

Sie nutzt immer noch Englisch. Sie profitiert immer noch von Beispielen. Aber das mentale Modell ändert alles. Du bewertest Prompts nicht mehr danach, ob sie klug klingen. Sondern danach, ob sie bei gleichen Inputs stabile Outputs liefern.

Ein Diagramm, das das Paradigma „Prompt als Funktion“ in der KI erklärt, mit Inputs, Verarbeitung, Verträgen und strukturiertem Code-Output.

Was sich ändert, wenn du in Funktionen denkst

Der größte Unterschied: Mehrdeutigkeit wird zum Bug statt zur Stilfrage.

KI-Teams in Unternehmen behandeln Prompts bereits so. Eine Branchenanalyse beschreibt eine geschichtete Prompt-Architektur, in der dauerhafte System-Prompts von aufgabenspezifischen User-Prompts getrennt sind, damit Teams Grundverhalten, Einschränkungen, Kontext und Richtliniengrenzen festlegen können. Dieselbe Quelle merkt an, dass Prompts Struktur, Länge, JSON- oder Tabellenformate und Ton ausdrücklich vorgeben können. Deshalb sieht Prompten in Produktion eher nach Schnittstellendesign aus als nach Chatten, wie Airias Beitrag zu strukturierter Prompt-Architektur erklärt.

In der Praxis heißt das: Dein Coding-Prompt kann eine stabile äußere Hülle und einen aufgabenspezifischen inneren Payload haben.

Zum Beispiel:

  • Die Systemebene legt Sicherheitsregeln fürs Repo, Coding-Standards und das Verhalten beim Verweigern fest.
  • Die Aufgabenebene liefert die Feature-Anfrage, Dateipfade, Akzeptanzkriterien und das Output-Schema.
  • Die Bewertungsebene prüft, ob das Ergebnis zu deiner Rubrik passt.

Das ist nicht übertrieben. So reduzierst du den Prompt Drift nach dem Motto „gestern hat es noch funktioniert“.

Eine Prompt-Funktion hat vier Teile

Hier das Muster in einfachen Worten.

  1. Signatur Du legst die Parameter fest, die der Agent bekommen muss. Pfad zum Repo. Dateien im Scope. Für Nutzende sichtbares Ergebnis. Einschränkungen. Fehlt einer davon, ist der Aufruf ungültig.

  2. Body Du legst fest, was als korrektes Verhalten gilt. Dazu gehören Geschäftsregeln, Architekturgrenzen, Namensregeln und das, was nicht angefasst werden darf.

  3. Rückgabetyp Du gibst das Output-Format vor. Nicht „gib mir den Code“. Sondern: Gib einen Plan in Markdown zurück, ein JSON-Objekt oder eine Liste von Datei-Patches mit Begründung.

  4. Fehlerbehandlung Du sagst dem Modell, was es tun soll, wenn sich der Vertrag nicht erfüllen lässt. Eine klärende Frage stellen. needs_input zurückgeben. Unsichere Annahmen verweigern.

Ein Prompt wird wiederverwendbar, wenn jemand anderes ihn ausführen kann, ohne zu raten, was du gemeint hast.

Hier eine abgespeckte Signatur:

type GenerateFeaturePrompt = {
  featureName: string
  goal: string
  filesInScope: string[]
  filesOutOfScope: string[]
  acceptanceCriteria: string[]
  outputFormat: "json"
  onMissingContext: "ask"
}

Das ist das Modell. Keine Magie. Einfach strengeres Software-Denken, angewandt auf Schnittstellen aus Sprache.

Input-Verträge für deine Prompts entwerfen

Probleme mit der Zuverlässigkeit beginnen meist, bevor das Modell ein einziges Token schreibt.

Schlechte Input-Verträge zwingen den Agent, Lücken mit Vermutungen über deine Codebase, deine Standards und deine Absicht zu füllen. In der Praxis heißt das: verschwendete Läufe, verrauschte Diffs und Code, der technisch funktioniert, aber die Form des Systems verletzt.

Eine Cartoon-Figur, die Datenblöcke in eine Maschine füttert, als Bild für einen validierten Input-Vertrag für KI.

Behandle den Input eines Prompts so, wie du eine Funktionssignatur in Produktionscode behandelst. Wenn ein Parameter wichtig ist, deklarier ihn. Wenn eine Abhängigkeit das Verhalten ändert, benenn sie. Wenn die Aufgabe Vorbedingungen hat, mach sie explizit. Prompten wird zuverlässiger, wenn du Kontext nicht mehr als Klumpen behandelst, sondern als Schnittstelle.

Für Coding-Agents umfasst ein brauchbarer Input-Vertrag meist fünf Felder:

  • Aufgabendefinition
    Beschreib die für Nutzende sichtbare Änderung konkret. „Füg unter /forgot-password ein Formular zum Zurücksetzen des Passworts hinzu, das eine E-Mail schickt, wenn das Konto existiert“ gibt dem Agent ein Ziel, das er umsetzen und testen kann.

  • Grenzen des Scopes
    Sag, welche Dateien sich ändern dürfen und welche Teile des Systems tabu sind. Wenn Änderungen auf app/routes/forgot-password.tsx und lib/email.ts beschränkt sind, sag das.

  • Relevanter Kontext
    Nimm Fakten auf, die das Modell aus einem Teil des Repo-Kontexts nicht sicher ableiten kann. Validierungs-Library, Auth-Provider, Konventionen für Komponenten, Test-Runner, Sicherheitsvorgaben.

  • Akzeptanzkriterien
    Definier „fertig“ so, dass ein Agent es ausführen oder prüfen kann. Enge Kriterien verhindern Outputs, die „richtig aussehen“ und im Review durchfallen. Ein gutes Muster ist in Akzeptanzkriterien, die Agents tatsächlich ausführen können beschrieben.

  • Bekannte Unbekannte
    Liste Annahmen auf, die noch bestätigt werden müssen. Wenn eine Umgebungsvariable, ein API-Vertrag oder eine Geschäftsregel unklar ist, leg diese Unsicherheit offen, statt den Agent drumherum erfinden zu lassen.

Prompt-Design ähnelt dann stark Spec-driven Development, und diese Überschneidung ist manchen Devs unangenehm. Gut so. Das soll sie auch sein. Eine Spec ist eine Steuerfläche. Sie begrenzt Improvisation. Das fühlt sich langsamer an, wenn du Prompten im Chatstil gewohnt bist, aber es ist schneller, als drei plausible Umsetzungen zu reviewen, die auf drei verschiedenen versteckten Annahmen beruhen.

Ein typischer Fehlerfall lautet: „Bau Feature X mit den bestehenden Mustern.“ In einem echten Repo sind „bestehende Muster“ oft eine Mischung aus alten Entscheidungen, halb fertigen Migrationen und lokalen Ausnahmen. Der Agent wird sich für eines entscheiden. Vielleicht bist du mit dieser Wahl nicht einverstanden, und jetzt debuggst du die Mehrdeutigkeit deines Prompts, statt das Feature auszuliefern.

Nutz einen Vertrag wie diesen:

Task: Add forgot-password request flow

Goal:
Let users submit email addresses to request a reset link.

Files in scope:
- app/routes/forgot-password.tsx
- app/routes/api.forgot-password.ts
- lib/email/reset.ts

Files out of scope:
- signup flow
- login flow
- database schema
- shared button components

Constraints:
- use Zod for validation
- use existing toast pattern from app/routes/login.tsx
- do not reveal whether an email exists
- keep copy plain and short

Acceptance criteria:
- form validates email on submit
- API returns same success message for existing and non-existing accounts
- reset email sender is called only for valid addresses
- tests cover success and invalid-input paths

If blocked:
- ask one clarifying question
- do not invent missing environment variables

Dieses Format funktioniert, weil es dem Modell weniger Gelegenheiten gibt, an der falschen Stelle zu improvisieren. Außerdem bekommst du etwas, das du versionieren, reviewen und aktualisieren kannst, wenn sich die Codebase ändert.

Dieser Punkt mit der Versionierung ist wichtig. Sobald Prompts Teil der Auslieferung werden, brauchen sie dieselbe Hygiene wie Code. Leg sie zusammen mit der Feature-Spec ab. Knüpf Änderungen am Vertrag an Code Reviews. Wenn ein Prompt nach einem Framework-Upgrade oder einem Architekturwechsel anfängt zu scheitern, diff den Vertrag so, wie du ein API-Schema diffen würdest. Teams, die über SDD streiten, übersehen oft diesen praktischen Mittelweg. Du brauchst keinen riesigen Anforderungsprozess. Du brauchst Inputs, die stabil genug sind, dass der Agent gegen einen bekannten Vertrag arbeitet statt gegen Repo-Folklore.

Dieselbe Regel gilt auch außerhalb der Code-Generierung. Aufgaben mit versteckten Annahmen gehen kaputt, wenn der Prompt diese Annahmen unausgesprochen lässt. Coding-Agents machen das Scheitern nur schneller sichtbar, weil der Output in deinem Repository landet statt in einem Chatfenster.

Ein kurzes visuelles Beispiel hilft, wenn du dir diese Gewohnheit für deinen Arbeitsalltag zulegen willst.

Output-Verträge und Validierung durchsetzen

Ein Prompt ohne Output-Vertrag ist keine Funktion. Er ist ein Vorschlag.

Dieser Unterschied zählt, sobald ein Agent Dateien schreibt, Pull Requests öffnet oder einen weiteren Schritt in deiner Pipeline speist. Ist die Rückgabeform locker, füllt das Modell die Lücke mit Fließtext, Vorbehalten und erfundener Selbstsicherheit. Im Chat ist das in Ordnung. In einem Repo ist es teuer.

Eine Tabelle, die Vor- und Nachteile strukturierter Output-Verträge im Prompt Engineering für KI vergleicht.

Zuverlässige Teams definieren Rückgabetypen so, wie sie API-Antworten definieren. Für die Arbeit mit Agents sind die üblichen Muster:

  • Strukturiertes JSON für Validatoren, CI-Checks und verkettete Agent-Schritte
  • Markdown mit festen Überschriften für menschliches Review und Freigabe
  • Patch-Pläne Datei für Datei, wenn die Umsetzung einen Checkpoint braucht
  • Status-Objekte, die blockierte oder unsichere Arbeit klar sichtbar machen

Ein einfacher Output-Vertrag könnte so aussehen:

{
  "status": "success | needs_input | unsafe",
  "summary": "short description",
  "files_to_change": [
    {
      "path": "app/routes/forgot-password.tsx",
      "change": "add form and validation"
    }
  ],
  "open_questions": [],
  "acceptance_checks": []
}

Damit hast du etwas, das du parsen, diffen, validieren und ablehnen kannst, bevor das Modell Code außerhalb des Scopes anfasst.

Fehlerzustände vorab definieren

Viele Prompt-Fehler sind Vertragsfehler. Dem Modell wurde nie gesagt, wie es scheitern soll.

Wenn du nur den Happy Path beschreibst, versucht der Agent ihn zu erfüllen, selbst wenn dem Repo Kontext fehlt, die Anfrage mit Einschränkungen kollidiert oder eine nötige Datei nicht existiert. Dieses Verhalten ist ein Grund, warum Prompt Engineering immer wieder wie Magie behandelt wird statt wie Softwaredesign. In der Praxis ist das Reliability Engineering. Du reduzierst mehrdeutige Zustände, bevor sie in Produktion landen.

Nutz explizite Regeln fürs Scheitern:

  • Fragen statt raten, wenn nötige Dateien, Details zum Schema oder Annahmen zur Umgebung fehlen
  • needs_input zurückgeben, wenn der Architekturkontext unvollständig ist
  • unsafe zurückgeben, wenn die Anfrage Scope, Sicherheit oder Systemvorgaben verletzt
  • Gebrochene Annahmen auflisten, statt sie zu glätten

Belohne nicht Selbstsicherheit. Belohne die Einhaltung des Vertrags.

Hier beginnt sich die Arbeit mit „Prompt als Funktion“ auch mit Spec-driven Development zu überschneiden. Ein Agent soll nicht einfach Output erzeugen. Er soll Output erzeugen, der sich gegen Akzeptanzkriterien, die Agents tatsächlich ausführen können, prüfen lässt. Das ist der nützliche Teil von SDD für kleine Teams. Keine zusätzliche Zeremonie. Weniger versteckte Annahmen, klarere Fehlerbilder und schnellere Reviews.

Output-Schemas wie versionierte Schnittstellen behandeln

Sobald ein Prompt echte Auslieferungsarbeit speist, wird das Schema Teil deiner Systemgrenze. planned_changes in files zu ändern oder needs_input in blocked umzubenennen ist ein Breaking Change, wenn nachgelagerte Tools den alten Vertrag erwarten.

Leg Prompt-Schemas neben den Code, den sie betreffen. Review sie in Pull Requests. Setz einen kleinen Validator davor, bevor Output eines Agents den nächsten Schritt erreicht. Wenn du schon in Dokumentation für AI Agents investierst, ist das das fehlende Stück, das diese Docs einsatzfähig hält statt nur gut gemeint.

Ein praktischer Validator kann einfach sein:

  • die Antwort parsen
  • unbekannte Keys ablehnen
  • Enum-Werte prüfen
  • scheitern, wenn Pflicht-Arrays fehlen
  • den Lauf stoppen, wenn status !== success

Dieses Muster klingt streng, weil es streng ist. Strenge ist der Punkt. Mit Agents lässt sich leichter arbeiten, wenn der Vertrag weniger Raum für Improvisation lässt.

Ein praktischer Output-Vertrag für Code-Arbeit

Hier ein Prompt-Ende, das ich oft verwende:

Return JSON only.

Schema:
{
  "status": "success | needs_input | unsafe",
  "summary": "string",
  "planned_changes": [
    {
      "filePath": "string",
      "reason": "string"
    }
  ],
  "questions": ["string"],
  "risks": ["string"]
}

Rules:
- Do not include markdown fences
- Do not include any keys not listed above
- If a required assumption is missing, set status to "needs_input"
- If the request conflicts with scope boundaries, set status to "unsafe"

Das funktioniert, weil der Agent nicht mehr entscheidet, wie eine gute Antwort aussieht. Das hat der Vertrag schon entschieden. Dadurch werden Wiederholungen sauberer, automatische Checks einfacher und Regressionen leichter erkennbar, wenn sich ein Prompt mit der Zeit ändert.

Praxisbeispiele mit modernen KI-Coding-Agents

Die Struktur bleibt über die Tools hinweg weitgehend gleich. Die Unterschiede zeigen sich darin, wie viel Repo-Kontext sie schon mitbringen, wie streng sie Formatvorgaben befolgen und wie viel Händchenhalten sie brauchen, wenn eine Aufgabe unübersichtlich wird.

Eine Vergleichstabelle mit den wichtigsten Funktionen und Einsatzfällen der AI Agents Cursor, Claude Code, Codex und Gemini.

Eine Aufgabe, vier Agents

Nimm eine konkrete Aufgabe. Du willst eine neue UserProfileCard-Komponente in einer React-App, plus Tests.

Der Auftrag:

  • UserProfileCard.tsx bauen
  • UserProfileCard.test.tsx hinzufügen
  • name, email und optional avatarUrl unterstützen
  • bestehende Tailwind-Konventionen befolgen
  • keine Layout-Dateien bearbeiten, die nichts damit zu tun haben

Die Hülle im Funktionsstil sieht für alle Agents so aus:

Function:
generate_component_with_test(inputContract) -> structured_result

Input contract:
- componentName: UserProfileCard
- targetDir: src/components/profile
- props:
  - name: string
  - email: string
  - avatarUrl?: string
- filesInScope:
  - src/components/profile/*
- filesOutOfScope:
  - src/pages/*
  - src/layouts/*
- constraints:
  - use TypeScript
  - use existing Tailwind utility style
  - no new dependencies
- acceptanceCriteria:
  - renders name and email
  - renders fallback avatar state
  - test covers optional avatarUrl
- outputContract:
  - return markdown with headings:
    - Summary
    - Files Created
    - Code
    - Test Notes
- onFailure:
  - ask for one missing pattern example before proceeding

Eine Basis-Signatur für Prompts, die du anpassen kannst

Die Anpassung ist meist klein.

Agent Worauf du Wert legst
Cursor benachbarte Dateien und Muster im Repo ausdrücklich nennen
Claude Code breiteren Architekturkontext und strengere Grenzen für den Scope geben
Codex Anweisungen kompakt und konkret halten
Gemini Format und Dateigrenzen ausdrücklich vorgeben

Ein paar praktische Hinweise:

  • Cursor profitiert oft von Anweisungen im Stil „übernimm dieses Muster aus Datei X“.
  • Claude Code ist stark, wenn du ihm eine größere Spec plus Einschränkungen gibst.
  • Codex schneidet meist besser ab, wenn du Füllstoff streichst und den Vertrag eng hältst.
  • Gemini reagiert meist besser, wenn die Form des Outputs klar ausbuchstabiert ist.

Das sind keine universellen Wahrheiten. Es sind Arbeitsheuristiken.

Wenn du Änderungen planst, bevor du sie einem Agent übergibst, ist KI-Planung, die deine Codebase kennt, die richtige Gewohnheit davor. Bessere Planung verringert die Entropie deiner Prompts.

Ergebnisse mit einer Rubrik bewerten, nicht nach Gefühl

Sobald sich Prompts wie Funktionen verhalten, kannst du sie wie Software bewerten.

Braintrust empfiehlt in seinem Artikel zur Prompt-Evaluierung, Outputs anhand versionierter Rubriken nach Dimensionen wie Korrektheit, Relevanz und Sicherheit zu bewerten, und schlägt vor, automatische Bewertungssysteme mit etwa 100 bis 200 von Menschen bewerteten Beispielen zu kalibrieren, bevor du dich auf automatisches Scoring verlässt.

Das ist wichtig, weil „Cursor hat es voll getroffen“ kein Testergebnis ist. Sondern eine Stimmung.

Eine schlanke Rubrik für die Komponenten-Aufgabe könnte Folgendes bewerten:

  • Korrektheit
    Erfüllt die Komponente den Prop-Vertrag und kompiliert sie?

  • Einhaltung des Scopes
    Ist der Agent innerhalb der erlaubten Dateien geblieben?

  • Stil
    Passt der Code zu den lokalen Konventionen?

  • Vollständigkeit der Tests Sind die Akzeptanzkriterien abgedeckt?

Gute Prompts liefern nicht nur Antworten. Sie liefern Antworten, die du benoten kannst.

Wenn dir die Doku-Seite davon wichtig ist, passt der Artikel von GitDocAI über Dokumentation für AI Agents gut zu diesem Workflow, weil die Zuverlässigkeit von Prompts und Docs, die Agents lesen können, eng zusammenhängen.

Prompts in einen Spec-driven Workflow einbinden

Einzelne Prompts helfen. Prompt-Bibliotheken helfen mehr.

Ein großer Nutzen zeigt sich, wenn deine Prompt-Funktionen vom zufälligen Chat-Verlauf zu einem Workflow mit stabilen Inputs, wiederverwendbaren Formaten und reviewbaren Outputs werden.

Screenshot von https://tekk.coach

Prompt-Bibliotheken schlagen Prompt-Improvisation

Ein Spec-driven Workflow gibt dir die fehlende mittlere Ebene zwischen „Ich habe eine Idee“ und „Der Agent hat zwölf Dateien geändert“.

Diese mittlere Ebene enthält meist:

  • die Problemstellung
  • die Grenzen des Scopes
  • Annahmen
  • Akzeptanzkriterien
  • Validierungsszenarien
  • Erwartungen an den Output

Deshalb tauchen spec-first- und spec-anchored-Ansätze in diesem Bereich immer wieder auf. Birgitta Böckelers Taxonomie ist hier nützlich, weil sie starres Spec-first-Denken von leichteren spec-anchored Workflows trennt. Addy Osmanis Spec-Format mit sechs Abschnitten ist aus demselben Grund nützlich. Es gibt allen, die als Solo Builder arbeiten, eine wiederholbare Form, ohne so zu tun, als bräuchte jede Aufgabe die volle Zeremonie.

Viele Teams wollen außerdem Übergabepunkte an Agents, die direkt in den Workflow eingebaut sind. Wenn du Muster vergleichst, ist Donelys Seite zu eingebauten Integrationen von AI Agents ein hilfreicher Kontrast, weil sie ein Ende des Integrationsspektrums zeigt, an dem Tools näher an der Umsetzungsebene sitzen wollen.

Wo Specs in den Loop passen

Das Modell „Prompt als Funktion“ passt sauber in einen Spec-driven Loop:

  1. Du definierst das Problem.
  2. Du hältst Einschränkungen und Akzeptanzkriterien fest.
  3. Du machst daraus eine strukturierte Spec.
  4. Du übergibst die Spec als Funktions-Body an einen Agent.
  5. Du validierst den Output gegen die Spec.

Genau da hilft ein kurzes internes Artefakt mehr als ein langer Prompt-Thread. Wenn du eine schlanke Version brauchst, reicht das minimale Spec-Format für die meisten Solo-Builder-Workflows.

Simon Willisons breitere Arbeit zu Agentic Engineering kommt beim selben Prinzip an. Prompts verhalten sich eher wie Softwarekomponenten als wie einmalige Nachrichten, sobald du sie über Aufgaben und Modelle hinweg wiederverwendest. Drew Breunigs Texte zu SDD liefern den Kontext zum Trend, aber der nützliche Teil ist nicht der Trend. Sondern die operative Disziplin.

Worauf es ankommt: Du schreibst den Vertrag einmal. Dann verfeinerst du ihn anhand von Fehlschlägen, statt jedes Mal bei null anzufangen.

Anti-Patterns und wann du die Regeln brechen solltest

Das Fehlerbild bei Spec-driven Arbeit ist nicht zu wenig Strenge. Sondern Zeremonie auf Produktionsniveau für Wegwerfaufgaben.

Solo Founder laufen da schnell rein. Eine einzeilige Textänderung braucht keinen versionierten Prompt, kein JSON-Schema und keine Regressions-Suite. Eine Migration, die Auth, Billing und Webhooks berührt, wahrscheinlich schon. Arbeit an der Zuverlässigkeit beginnt damit, zu entscheiden, wo Fehler teuer sind, und dort Struktur zu investieren.

Wann strikte Struktur hilft

Behandle Prompts wie versionierte Funktionen, wenn der Output wiederverwendet, reviewt oder gegen ein Live-System ausgeführt wird.

Nutz enge Input- und Output-Verträge für:

  • Änderungen an der Kern-API, bei denen ein falsches Feld Clients kaputt macht
  • Änderungen an der Authentifizierung, bei denen stillschweigende Annahmen Risiken schaffen
  • Brownfield-Refactorings, bei denen das Repo schon Narbengewebe hat
  • Features über mehrere Dateien, bei denen Akzeptanzkriterien Abstimmung brauchen

OpenAI empfiehlt in seiner Dokumentation zu Prompt Engineering, Modell-Snapshots festzupinnen und Evaluierungen laufen zu lassen, wenn sich das Verhalten des Modells ändert. Das ist der Software-Blickwinkel, den viele Teams übersehen. Der Prompt ist nur ein Teil. Das stabile Ergebnis entsteht aus dem Prompt, der Modellversion, den Checks und dem Loop, der aus Fehlern lernt.

Hier wird auch die breitere SDD-Debatte unübersichtlich. Kritische Stimmen haben in einem Punkt recht. Wenn jede Aufgabe mit einer langen Markdown-Spec beginnt, baust du Prozess-Overhead nach. Die Befürwortenden haben aber auch in etwas recht. Wenn Prompts Codeänderungen steuern, brauchen sie dieselben Kontrollen, die du schon für Code nutzt: Versionierung, Review, Tests und Rollback.

Wann du lockerer werden solltest

Prompte locker, wenn ein Fehler wenig kostet und das Ziel Erkundung ist.

Dazu gehört:

  • Ideen für Namen
  • UI-Brainstorming
  • grober Boilerplate-Code
  • Umsetzungsoptionen ausloten, bevor du dich festlegst

Es gibt einen Trade-off. Forschung zu Prompt-Design für Softwareaufgaben hat gezeigt, dass mehr Struktur nicht immer bessere Ergebnisse liefert, besonders in Brownfield-Codebases, wo generische Prompts oder gar kein detaillierter Prompt in manchen Settings aufgabenspezifische Anweisungen schlagen können, wie im Review zu den Trade-offs im Prompt Engineering diskutiert.

Die Faustregel ist einfach.

Nutz so wenig Struktur wie nötig, um teures Raten zu stoppen.

Ich habe erlebt, dass Agents mit einer kurzen Spec plus direktem Zugriff auf den Code besser abschneiden als mit einem langen Prompt voller Beispiele, die aus einem anderen Repo kopiert sind. Zusätzliche Details können den Suchraum in die falsche Richtung einengen. Sie können auch eine schlechte Annahme früh festschreiben.

Die Wartungskosten sind real

Strikte Prompts erzeugen Wartungsarbeit. Diesen Teil spielen Fans von „Prompt als Funktion“ manchmal herunter.

Modell-Updates können einen Few-Shot-Prompt schwächen. Alte Beispiele können den Agent an Muster binden, die deine Codebase nicht mehr will. Ein Vertrag, der vor sechs Wochen präzise aussah, kann aus dem Takt mit der Spec, den Tests oder dem Produkt selbst geraten. Dieselbe Review-Literatur merkt an, dass automatisierte Prompt-Methoden je nach Modell und Aufgabe unterschiedlich abschneiden und Zero-Shot in manchen Fällen Few-Shot schlagen kann.

Behandle Prompt-Assets also wie Code, der gepflegt werden muss.

  • nutz Specs für die Ausrichtung
  • nutz Prompts für die Ausführung
  • nutz Evaluierungen für Vertrauen

Wenn ein Prompt-Vertrag immer wieder bricht, refactor ihn wie Code. Lösch veraltete Anweisungen. Streich dekorative Beispiele. Zieh die Schnittstelle enger. Teil einen überladenen Prompt bei Bedarf in zwei engere auf. Manchmal ist die richtige Lösung sogar noch kleiner. Hör auf, eine riesige Spec zu übergeben, und übergib ein typisiertes Input-Objekt plus einen expliziten Akzeptanz-Check.

Die Regeln zu brechen ist in Ordnung, wenn du es absichtlich tust. Freier Chat ist während der Erkundung nützlich. Für wiederholbare Auslieferung ist er ein schlechter Standard. Die Grenze ist keine philosophische. Sie ist eine operative. Wenn du dasselbe Ergebnis zweimal brauchst, gib ihm Struktur. Wenn du nur eine schnelle Skizze brauchst, halt es locker.

Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich, ausgehend von dem, was sich in deinem Code geändert hat – dasselbe Board, dieselben Akzeptanzkriterien, und die Spec schließt sich, wenn der PR, der sie baut, gemergt wird.

Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.