Ich schrieb das Prompt Contracts Buch. Kapitel 4 sprengte mein eigenes Framework.

Der Vertrag sagte return a JSON array of contacts. Ich hatte kein Limit gesetzt, keine Paginierung. Der KI-generierte Code bestand jeden Test. Dann zog ein User einen Report über ein großes Segment und der Browser starb unter 5.000 Kontakten, die in einem Blob ausgespuckt wurden.

Der Code war korrekt. Der Vertrag war der Bug.

Ich veröffentlichte einen Artikel über Prompt Contracts. Er wurde oft genug geteilt, dass ein Buch daraus Sinn machte. Und beim Schreiben kamen drei Dinge hoch, die ein einzelner Artikel nicht abdecken konnte. Der Vertrag, der bricht, während der Code perfekt ist. Die Grenze zwischen verlässlichem Code und verlässlichen Fakten. Und der Instinkt, der verkümmert, wenn man zu lange delegiert.

5.000 Kontakte, Null Fehler, Ein Abgestürzter Browser

Ich baute das Ding an einem Wochenende. Kleines Tool zum Synchronisieren von Distributor-Kontakten für einen WooCommerce-Shop, komplettes Backend KI-generiert aus einem Prompt Contract. Datenmodell, API-Endpunkte, Validierung, alles vorab spezifiziert. Inklusive dieser Zeile: "return a JSON array of contacts matching the filter criteria."

Jedes Akzeptanzkriterium erfüllt. Ich deployete an einem Freitagnachmittag, bevor ich mit den Kindern schnorcheln ging (weil ich anscheinend friedliche Wochenenden hasse).

Montag. Ein User mit 5.000 Kontakten in seinem Distributor-Segment klickt "Export." Browser wird weiß. Tab crasht. Kein Fehler, keine elegante Degradation. Nur ein toter Tab und ein JSON-Blob von der Größe einer Kurzgeschichte im Speicher.

Die KI wich nicht vom Vertrag ab. Nicht um eine einzige Zeile. Sie tat genau das, was ich verlangte, und genau deshalb brach es.

Kapitel 4 des Buchs beschäftigt sich mit dieser Frage: hat die KI den Vertrag gebrochen, oder schrieb ich einen Vertrag, der das falsche Verhalten spezifizierte?

Drei Muster von Vertragsfehlern kamen aus diesem Kapitel. Fehlende Edge Cases: der Vertrag sagte "return contacts", aber nie, was passiert, wenn es 5.000 sind (keine Paginierung, kein Cap, das Fehlen einer Beschränkung ist selbst eine schlechte Spezifikation). Falsche Domain-Annahmen: ich nahm an, Kontakte wären Dutzende, vielleicht Hunderte, aber diese Annahme lebte in meinem Kopf, nicht im Dokument. Und Über-Spezifikation der kosmetischen Sachen, während die strukturellen Grenzen nirgends waren: ich hatte das exakte JSON-Nesting detailliert, die Feldnamen, die Typen. Aber maximale Payload? Fallback wenn sie zu groß ist? Nichts.

Der Fix war nicht besseres Prompting. Drei Fragen. Ich fügte drei Fragen zum Workflow hinzu:

Here is my contract for [feature].
Before generating any code:
- What edge cases am I not covering?
- What assumptions am I making that aren't written down?
- Where does this break at scale?

Drei Fragen. Das war's. Die KI zerlegt deine Spezifikation, bevor sie eine Zeile schreibt. Du flickst die Löcher, dann generierst du.

Das ist der Loop, den das Buch dokumentiert. Nicht prompt, generate, fix the code, reprompt (der naive Zyklus, der die Spezifikation einfriert, während du Symptome flickst). Der echte Zyklus: spezifizieren, generieren, verifizieren, DIE SPEZIFIKATION überarbeiten. Die Spezifikation ist das lebende Dokument. Der Code ist der Output. Wenn der Output bricht, fixst du den Input.

Die erste Version jedes Vertrags ist ein Entwurf. Immer. Der Bauchgefühl-Test hilft zu entscheiden, ob du überhaupt einen Vertrag brauchst (mehr dazu später). Aber sobald du entscheidest, dass du einen brauchst, nimm an, dass er Löcher hat. Der Loop ist das Produkt, nicht das Dokument.

Der Artikel sagte: schreib einen Vertrag. Das Buch musste antworten: und wenn der Vertrag selbst der Bug ist?

Einen kaputten Vertrag kannst du fixen (Spezifikation patchen, regenerieren). Das nächste Problem ist hinterhältiger, weil der Vertrag es überhaupt nicht fixen kann.

Das Framework Hat Eine Grenze, Die Der Artikel Nie Zog

Prompt Contracts produzieren verlässlichen Code. Sie produzieren keine verlässlichen Fakten.

Dieser Satz steht nirgends im ursprünglichen Artikel. Er konnte nicht. In einem einzelnen Artikel zeigst du das Framework funktionierend, du kartographierst nicht, wo es aufhört. Ein Buch lässt dich damit nicht davonkommen.

Ein Stripe-Webhook validiert entweder die Signatur oder nicht. Ein Datenbankschema respektiert entweder den Index oder nicht. Für Code-Logik eliminiert der Vertrag Halluzinationen. Die KI generiert, was du spezifiziert hast, die Tests bestätigen es, fertig.

Aber mein WooCommerce-Tool generiert auch Reports mit echten Distributor-Daten. Kontakt-URLs, Audience-Zahlen, Partner-Namen. Dinge, die in der Welt existieren, nicht im Vertrag. Und hier brachte der Vertrag Halluzinationen von 30% auf etwa 15% runter. Runter, nicht weg.

15% klingt klein, bis du Karen aus der Buchhaltung triffst. Jede Pipeline hat eine. Sie ist die Person am anderen Ende, die sich nicht für deine saubere Architektur interessiert. Karen interessiert sich dafür, dass Zeile 47 des Quartalsreports einen Distributor auflistet, der nicht existiert. Du kannst erklären, dass der Code technisch korrekt ist. Karen wird erklären, dass der Kunde angerufen hat und dass dein technisch korrekter Report die Firma wie Amateure aussehen ließ. Karen gewinnt diese Diskussionen immer. 🤷

Die METR-Studie fand eine 39-44%-Lücke zwischen dem, wie produktiv Entwickler denken, dass sie mit KI sind, und wie produktiv sie tatsächlich sind. Ox Security ging weiter: 10 wiederkehrende Anti-Pattern in 80-100% von KI-generiertem Code, was sie "eine Armee talentierter Junioren ohne Aufsicht" nannten. Der Vertrag ist die Aufsicht für Code. Für Fakten, die die KI aus ihren Trainingsdaten zieht oder aus dem Nichts erfindet, hat der Vertrag keine Zuständigkeit.

Für Produkte, wo der Wert im Code liegt (die meisten SaaS), reicht das Framework. Für Produkte, wo der Wert von Fakten abhängt, die die KI generiert, brauchst du eine Verifikationsschicht obendrauf. Das Buch dokumentiert beide Seiten. Der Artikel hatte nur Platz für eine.

Und diese Woche macht die Grenze sichtbarer. 1.234 Community Skills für Claude Code. Neun Kategorien, von Deployment bis Testing bis Dokumentation. Jeder einzelne automatisiert Generierung. Wie viele automatisieren Verifikation von faktischen Outputs? Ich scrollte durch die Top 10. Null.

1.234 Skills um Code zu generieren. Der eine, um Fakten zu verifizieren, existiert noch nicht.

Was folgt, ist weder technisch noch faktisch. Es ist persönlich, und es war das schwerste Kapitel zu schreiben.

Die Fähigkeit, Die Das Buch Mir Beibrachte, Die Kein Slash Command Ersetzen Kann

Ich schrieb diesen Vertrag vor drei Monaten für einen Partner-CSV-Import:

feature: partner-csv-import
acceptance_criteria:
  - Parse CSV with headers: name, url, category, audience_size
  - Validate each row: name non-empty, url valid format,
    audience_size integer > 0
  - Skip malformed rows, log them to stderr
  - Output clean JSON array to stdout
edge_cases:
  - Empty CSV → exit 0, empty array
  - CSV > 50,000 rows → stream processing, never load full file
  - Duplicate URLs → keep first occurrence, log duplicates

Und hier ist, was ich letzte Woche für ein Wegwerf-Script zum Umbenennen von Bilddateien generierte:

rename all .png files in /uploads to kebab-case, lowercase

Kein Vertrag. Keine Akzeptanzkriterien. Keine Edge Cases. Eine Zeile.

Der Unterschied ist der Bauchgefühl-Test. Der CSV-Import berührt Partner-Daten, die in Produktions-Reports einfließen. Wenn der Parser stillschweigend Zeilen verwirft oder eine URL korrumpiert, treffen echte Menschen echte Entscheidungen auf falschen Daten. Mein Bauch zieht sich zusammen. Vertrag. Das Bilder-Umbenennen? Wenn es einen Dateinamen verhunzt, führe ich es einfach nochmal aus. Schulterzucken. Vibe Code.

Der ursprüngliche Artikel hatte einen einfachen Pitch: schreib einen Vertrag, lass die KI coden. Das Buch musste den unbequemen zweiten Teil hinzufügen: aber halte deinen Instinkt am Leben.

Ich arbeitete früh in meiner Laufbahn bei einer französischen Bank. Sie hatten COBOL-Batch-Jobs, die 25 Jahre in Produktion liefen. Niemand fasste sie an. Niemand musste. Die ganze mise en place funktionierte so gut, dass das Verstehen des Systems optional wurde. Bis eine regulatorische Änderung eine Modifikation erzwang, und die Entwickler, die das System verstanden, waren im Ruhestand. Weg. Nicht weil jemand einen Fehler machte. Weil das System zu lange zu verlässlich war.

Luciano Nooijen erzählte dem MIT Technology Review, dass seine Coding-Instinkte nach Monaten intensiver KI-Nutzung degradierten. Gleicher Mechanismus, nur von Jahrzehnten auf Monate komprimiert. Craig Weiss formulierte es diese Woche anders (und die Dev-Community stimmte laut genug zu, um es zu bemerken): der echte Burggraben ist Systemdesign und Produktdenken, nicht Syntax. Die Syntax wird delegiert. Das Urteilsvermögen kann nicht.

Der lustige Teil (oder erschreckende, je nachdem welchen Tag du mich fragst).

Wir gingen davon, jede Zeile Code zu lesen, dazu, ihn überhaupt nicht zu lesen. Und der Ersatz für "Ich habe das Zeile für Zeile verifiziert" ist nicht irgendein überlegenes automatisiertes Verifikationssystem. Keine Test Suite fängt alles. Wir laufen auf einem Gefühl jetzt. Das Ding wird explodieren. Das eine ist okay. Bei diesem hier, vorsichtig. Wir tauschten Code Review gegen Bauchcheck. Der fortschrittlichste Entwicklungsworkflow der Geschichte läuft auf deinem Magen. 🫠

Der Bauchgefühl-Test macht es zu einer Methode statt einem Raten. Stell dir den schlimmstmöglichen Output für die Aufgabe vor, die du delegieren willst. Datenbank korrumpiert. Zahlung doppelt belastet. Userdaten in den Logs exponiert. Bauch zieht sich zusammen: Vertrag. Schulterzucken: Vibe Code frei.

Ich baute das ursprüngliche Prompt Contracts Framework nach genug Katastrophen wie dem 5.000-Kontakte-Crash. Der Artikel erfasste die Richtung. Das Buch kartographiert das Terrain, Sackgassen inklusive.

Der Artikel lehrte ein Framework. Das Buch lehrte mich, wann ich es nicht verwenden soll.

Was Der Artikel Nicht Abdecken Konnte

Ein 10-Minuten-Read beweist eine Richtung. "Spezifikation schlägt Improvisation." Der Teil ist geklärt.

Aber ein 10-Minuten-Read lässt dich nicht mit den Fehlermodi sitzen. Der Vertrag, der der Bug ist. Die Grenze, wo Fakten anfangen und das Framework aufhört. Die langsame Erosion deines eigenen Urteilsvermögens. Ich schrieb das Buch, um tiefer in all das einzutauchen, für die Devs, die auf dieselben Mauern stoßen und mehr als eine Kompassrichtung wollen.

Das Buch heißt Prompt Contracts: How I Stopped Vibe Coding and Started Shipping Real Software With AI. Es ist jetzt auf Amazon.

---

Die Industrie wird Skills, Schichten, Abstraktionen stapeln. Diese Woche sind es 1.234. Nächsten Monat werden es 50.000 sein. Jede neue Schicht macht es bequemer, nie zu schauen, was darunter passiert.

Das Buch sagt nicht "hör auf zu stapeln." Es sagt: wisse, wo die Risse im Fundament sind. Der weise Mann baut sein Haus nicht auf Sand. Der Vertrag kann der Bug sein. Der Vertrag hat eine Grenze. Und dein Instinkt hat ein Verfallsdatum, wenn du ihn nicht benutzt.

Gefühl + Methode. Ship it.

---

Quellen

METR-Studie über KI-unterstützte Entwicklungsproduktivität (39-44% Wahrnehmungslücke). Ox Security, "Top 10 AI Code Generation Risks" (Anti-Pattern in 80-100% von KI-Code). MIT Technology Review, Luciano Nooijen über Coding-Instinkt-Atrophie.

Wenn du mit KI baust und die ehrliche Version willst (Lücken inklusive, nicht nur die Highlight-Reel), folge mit. Der nächste landet in deiner Inbox.

(*) Das Cover ist KI-generiert. Die drei Lücken im Artikel sind zertifiziert organisch, vom Hof auf den Tisch menschliche Fehler.