Deine KI schreibt keinen schlechten Code. Du schreibst schlechte Spezifikationen.
Die Outreach-Kampagne lief seit 10 Minuten, als die Benachrichtigung eintraf. Eine E-Mail an einen Kontakt, den mein gesamtes System seit 6 Monaten stillschweigend gemieden hatte. Mein Fehler. Zu spät...
Ich las die Spezifikation noch einmal. Da stand: "Follow-up mit aktiven Interessenten." Das war's. Keine Ausschlussliste, keine Statusfilter, keine Einschränkung, wen man nicht kontaktieren sollte. Claude führte exakt das aus, was ich geschrieben hatte, ohne zu zögern, ohne etwas auszulassen.
Die Spezifikation ist der Flaschenhals, nicht das Modell, nicht der Prompt.
Mir fehlte eine Zeile. Claude erledigte den Rest.
Der Agent hatte Zugriff auf die komplette Kontaktliste. Alle: aktive Interessenten, ruhende Leads, ein Distributor, mit dem wir vor 6 Monaten stillschweigend die Zusammenarbeit beendet hatten, und 2 oder 3 Personen aus einer Partnerschaft, die so geendet war, dass niemand sie per automatisierter E-Mail wieder aufgreifen wollte. Die Spezifikation erwähnte nichts davon. Da stand "aktive Interessenten", was in meinem Kopf eine Bedeutung hatte, die aus monatelangem Kontext, 12 informellen Entscheidungen und mindestens einem unangenehmen Gespräch bestand, das ich komplett vergessen hatte zu dokumentieren.
Claude wusste nichts davon. Claude kannte nur die Spezifikation.
Also machte es Follow-ups. Mit allen, die nicht explizit ausgeschlossen waren. Professionell, prompt, exakt in dem Ton, den ich verlangt hatte. Die Kontaktliste hatte kein "Nicht kontaktieren"-Flag, weil ich nie daran gedacht hatte, eines hinzuzufügen. Die Spezifikation hatte keine Ausschlussregeln, weil ich annahm, die seien offensichtlich. Der Agent arbeitete mit dem, was existierte, nicht mit dem, was ich beabsichtigt hatte.
Das ändert sich mit der Ausführungsgeschwindigkeit von KI: Ein menschlicher Entwickler mit derselben Spezifikation hätte vielleicht eine Rückfrage gestellt, oder eine Ermessensentscheidung getroffen, oder zumindest bei den Grenzfällen gezögert. Ein Agent zögert nicht. Er liefert. (In C nennt man das undefined behavior. Bei KI-Agenten heißt es "die Spezifikation, die ich geschrieben habe".)
Claude hat keinen Fehler gemacht. Ich habe eine Tür offen gelassen.
(Und ja, danach habe ich jede andere Spezifikation durchgelesen, die ich für diese Pipeline geschrieben hatte. Fand beim ersten Durchgang 4 weitere fehlende Einschränkungen.)
GIGO galt schon immer.
GIGO: Garbage In, Garbage Out. Das Prinzip stammt aus 1957, geprägt auf militärischen Großrechnern, als Programmierer entdeckten, dass falsche Eingabedaten mit perfekter Konsistenz falsche Ausgaben produzierten. Die Maschine führte korrekt aus. Das Problem lag immer vorgelagert.
Das waren keine Einheiten mit Urteilsvermögen. Es waren IBM 709s, die Lochkarten lasen. Mehrdeutigkeit war keine Option. Input war binär, Output war binär, und die Lücke dazwischen war immer der Mensch.
60 Jahre lang beschrieb GIGO ein Datenqualitätsproblem. Schlechte Trainingsdaten rein, schlechte Modellvorhersagen raus. Diese Betrachtung gilt noch immer. Was sich geändert hat, ist die Ebene, auf der der Müll eindringt.
Bei KI-Agenten dringt Müll auf der Spezifikationsebene ein, nicht auf der Datenebene. Der Input ist keine beschädigte CSV-Datei. Es ist eine unvollständige Spezifikation: eine zu locker formulierte Regel, ein zu weit gefasster Scope, eine Ausschlussliste, die nur in jemandes Kopf existiert. Der Agent absorbiert keine Mehrdeutigkeit. Er führt durch sie hindurch aus, mit der Geschwindigkeit, die du ihm gegeben hast, gegen alle Daten, auf die er Zugriff hat.
Mir ist diese Woche aufgefallen, dass meine IDE alle 2 Sekunden automatisch speichert. Diese Einstellung hatte ich über die Jahre mindestens 5 Mal an und aus, und ich kann mich ehrlich gesagt nicht erinnern, wie ich es eigentlich wollte. Die Einstellung fühlt sich wichtig genug an, um als Einstellung zu existieren, aber nicht wichtig genug, um den Grund aufzuschreiben. Jedenfalls sind wir schlecht darin, die kleinen Entscheidungen zu dokumentieren.
Google benannte den neuen Flaschenhals letzten Monat
Im Mai 2026 landete ein Google-Whitepaper von Osmani, Saboo und Kartakis auf Kaggle und blieb ein paar Wochen relativ unbemerkt, bevor die Entwickler-Community aufholte. Das Hauptargument: Der Wandel, den wir durchleben, ist keine neue Sprache oder ein neues Framework. Es ist ein Wechsel vom Code schreiben zum Intent ausdrücken, und die meisten Fehler, die als "KI-Probleme" auftauchen, sind tatsächlich Intentionsprobleme vorgelagert.
Nach ihren Zahlen nutzen etwa 85% der professionellen Entwickler inzwischen regelmäßig KI-Coding-Agenten, wobei rund 41% des gesamten neuen Codes KI-generiert ist. Bei dieser Größenordnung läuft eine vage Spezifikation mit Generator-Geschwindigkeit gegen Live-Kundendaten. Code-Review fängt nichts davon ab. Und die Mathematik potenziert sich schnell: Wenn auch nur ein Bruchteil dieser generierten Codebasen auf unvollständigen Spezifikationen läuft, hört die Angriffsfläche für Vorfälle wie meinen Outreach-Fall auf, Grenzfall-Territorium zu sein. Es wird zum Standard.
Die zentrale Einordnung des Papers: "Die meisten Agent-Fehler sind, ehrlich betrachtet, Konfigurationsfehler." Nicht Fähigkeitslücken im Modell. Konfigurationsfehler im Harness. Osmani schrieb separat in seinem Blog nach dem Whitepaper, dass wenn ein Agent etwas Unerwartetes tut, sein erster Schritt ist, das Harness zu prüfen, nicht das Modell zu hinterfragen. Meist ist es ein fehlendes Tool, eine zu locker formulierte Regel oder eine Leitplanke, die er vergessen hat hinzuzufügen. Das passt exakt zu dem, was mit meiner Outreach-Pipeline passiert ist.
Der frühere Bloomberg-Artikel diagnostizierte am Ende die falsche Krankheit: Sie sahen die Symptome korrekt (Produktivitätspanik, fehlerhafte KI-Outputs, Scope Creep) und gaben den Tools die Schuld. Das Whitepaper ist präziser. Fähigkeitsfehler und Konfigurationsfehler sind verschiedene Probleme, die auf verschiedene Lösungen hinweisen. Eine Lösung ist ein besseres Modell. Die andere ist, die Spezifikation zu schreiben, die man hätte schreiben sollen, bevor man etwas ausgeführt hat.
Hier bricht deine To-Do-App-Spezifikation zusammen.
Versuch das mal. Schreibe eine Spezifikation für eine To-Do-App, die einen echten Produktionsvorfall verursacht. Task hinzufügen, Task abschließen, Task löschen, Tasks auflisten. Es gibt keinen Ort, wo die Spezifikation so schlimm schiefgehen kann, dass sie etwas Echtes beschädigt. Der schlimmste Fall ist ein Item, das als abgeschlossen markiert wird, obwohl es das nicht sein sollte.
Jetzt schreibe eine Spezifikation für eine Outreach-Automatisierung, die Partner-Kontakte und aktive Accounts berührt. Wer wird kontaktiert, unter welchen Bedingungen, wann ausgeschlossen, von welcher Liste, basierend auf welchem Statusfeld, mit welcher Überschreibung für Accounts im Wartezustand, und was ist mit den 2 Partnern, die sich gerade in einer Vertragsverhandlung befinden, die du seit 3 Wochen persönlich abwickelst? Jede einzelne dieser fehlenden Einschränkungen ist eine Tür, durch die der Agent gehen wird.
Es ist im Grunde der Unterschied zwischen der Tutorial-Zone und dem ersten echten Dungeon. Gleiche Mechaniken, komplett anderes Konsequenzen-Set. Die meisten vibe-codierten Spezifikationen werden für die Tutorial-Zone geschrieben und im Dungeon deployed.
Die meisten Builder wenden To-Do-App-Spezifikations-Disziplin auf Produktions-Tools mit realen Auswirkungen an. "Follow-up mit aktiven Interessenten" lässt offen, was "aktiv" genau bedeutet, welche Kontakte freiwillig pausiert sind und welche persönlich von jemandem bearbeitet werden, der nicht glücklich sein wird, eine automatisierte E-Mail landen zu sehen. "Produktkatalog mit Partner-Feed synchronisieren" sagt nichts über Referenzen aus, die gerade in der Vertragsüberprüfung stehen. "Eingehende Bestellungen verarbeiten" gibt dem Agenten null Anleitung, was mit einer Bestellung zu tun ist, die bereits vom vorherigen Lauf bearbeitet wurde.
Jede fehlende Einschränkung ist etwas, das der Agent auf welche Weise auch immer die Daten es möglich machen interpretieren wird, mit der Geschwindigkeit, die du ihm gegeben hast. Bei Partner-Feed-Größenordnung, bei Outreach-Größenordnung, bei jeder Größenordnung, wo das Tool echte Accounts oder echtes Geld berührt, ist das Hinterlassen von Lücken in der Spezifikation kein Versehen, das du in der QA abfängst. Es ist ein Produktionsvorfall, der auf die richtige Kombination aus Daten und Timing wartet.
Der Agent baut beides mit derselben Zuversicht. Domain-Komplexität überträgt sich nicht automatisch in Spezifikations-Komplexität. Du musst es schreiben.
Was ich gebaut habe, um die Lücken zu fangen.
Nach dem Outreach-Vorfall habe ich eine Spezifikations-Verfeinerungs-Schicht zwischen den Builder und den Agenten bei jeder neuen Automatisierung gesetzt. Nichts Kompliziertes: Ein von Claude geführter Dialog, der vor der ersten Code-Zeile läuft. Er schreibt nicht die Spezifikation. Er stellt Fragen, die du beantworten musst.
Fragen wie: Wen oder was sollte dieser Agent unter keinen Umständen berühren? Welche impliziten Geschäftsregeln regieren diese Domäne, die du nie irgendwo aufgeschrieben hast? Was zählt als "erledigt" und was zählt als "niemals anfangen"? Was passiert an den Rändern: ein abgelaufener Account, ein Kontakt in einer Streitigkeit, ein von der Rechtsabteilung geflaggtes Produkt, eine bereits vom vorherigen Lauf verarbeitete Bestellung?
Als ich es das erste Mal bei einer neuen Distributions-Automatisierung verwendete, war der ursprüngliche Input "Produktkatalog mit Partner-Feed synchronisieren." Erste Frage, die das Tool generierte: "Gibt es Produktkategorien, die von dieser Synchronisation ausgeschlossen werden sollten?" Ich saß etwa 5 Sekunden da. Dann öffnete ich ein Dokument von vor 4 Monaten und fand 12 Produktreferenzen, die als unter Vertragsüberprüfung geflaggt waren. Ich hatte nie auch nur einmal daran gedacht, sie in die Spezifikation aufzunehmen.
Diese Stille nach der Frage ist ihre eigene Diagnose. Zögern über 2 Sekunden = fehlende Einschränkung. Derselbe Instinkt wie "merge to main" zu drücken, wenn man den Testlauf übersprungen hat. Dein Bauchgefühl weiß es, bevor dein Gehirn es tut.
Der Wert ist nicht das Ausgabedokument. Es sind die 10 Minuten Unbehagen, bevor der Agent läuft. Ich denke, das fängt nur das ab, was dir auf irgendeiner Ebene bereits halb bewusst ist. Wenn eine Einschränkung dir nie in den Sinn gekommen ist, wird keine Frage sie an die Oberfläche bringen. Das ist die ehrliche Obergrenze.
Spezifizieren ist die Fähigkeit. Prompting ist eine Teilmenge.
Prompt Engineering ist die Fähigkeit, besseren Output von einem Modell in einer gegebenen Unterhaltung zu bekommen. Spezifizieren ist die Fähigkeit zu definieren, was der Agent tun darf, wen er berühren kann, auf welche Daten er einwirken kann und wo er aufhört. Das sind verschiedene Disziplinen, die auf verschiedenen Ebenen des Stacks operieren.
Ein sauberer Prompt bringt dir eine bessere Antwort innerhalb des Scopes, den der Agent bereits hat. Eine sorgfältige Spezifikation definiert, was der Scope ist. Der Builder, der saubere Prompts gegen eine lockere Spezifikation schreibt, shipped schnell und bricht Dinge in der Produktion. Der Builder, der sorgfältig spezifiziert, shipped langsamer am Anfang und erholt sich später von weniger Vorfällen. Mit KI, die Lieferzeiten von Wochen auf Stunden komprimiert, bedeutet "später" jetzt denselben Nachmittag.
Wenn du auf Projektebene und nicht nur auf Unterhaltungsebene operieren willst, deckt das vollständige Prompt Contracts Framework genau das ab: was der Agent generieren kann, was er modifizieren kann, was explizite menschliche Freigabe erfordert. Das ist es, wozu ich nach genug Vorfällen wie dem E-Mail-einen gewechselt bin.
Der Ansatz, den ich in Vibe Coding, For Real darlege, deckt die frühere Phase ab: bevor jede Code-Generierung startet, definiere die Grenzbedingungen der Domäne, nicht nur die Feature-Liste. Was das System niemals tun sollte und welche Geschäftsregeln nie aufgeschrieben wurden, weil jeder annahm, sie seien offensichtlich.
Ein Agent hat keine Intuition darüber, was du meintest. Nur darüber, was du geschrieben hast.
3 Fragen, bevor Claude Zugriff bekommt.
Die Vorfall-E-Mail wäre nicht durch ein besseres Modell oder einen besseren Prompt verhindert worden. Sie wäre durch 10 zusätzliche Minuten Spezifikationsarbeit verhindert worden, bevor der Agent lief.
3 Fragen, die ich jetzt stelle, bevor ein Agent Zugriff auf Live-Daten bekommt:
Wen oder was sollte dieser Agent unter keinen Umständen berühren? Nicht "wer ist von diesem Batch ausgeschlossen", sondern wer ist dauerhaft tabu, unabhängig vom Status, unabhängig von der Listenmitgliedschaft, unabhängig davon, was die Daten zeigen. Diese Ausschlüsse müssen explizit in der Spezifikation stehen, nicht durch Kontext impliziert werden.
Welche impliziten Geschäftsregeln hast du nie irgendwo aufgeschrieben? Denk an: die Partnerschaft, die du im November stillschweigend pausiert hast, die Produktreferenzen, die in einem Rechtsüberprüfungs-Dokument sitzen, das niemand öffnet, die 2 oder 3 Kontakte, denen du persönlich gesagt hast "Das übernehme ich" und die du nie irgendwo im System geflaggt hast. Jede einzelne davon ist eine Einschränkung, von der der Agent nichts weiß, es sei denn, du schreibst sie auf.
Was ist das tatsächliche Risikolevel dieses Projekts? Nicht was du hoffst, dass das Risiko ist, sondern was passiert, wenn der Agent auf allem läuft, worauf er Zugriff hat. Eine falsch kategorisierte Aufgabe in einer To-Do-App kostet dich 30 Sekunden. Eine E-Mail an den falschen Partner kostet dich eine Beziehung und einen Vormittag. Eine modifizierte Bestellung in einem Live-E-Commerce-Feed kostet dich einen Abrechnungsvorfall und möglicherweise einen Kunden. Der Detailgrad in der Spezifikation muss dem Risikolevel in der Domäne entsprechen, nicht nur der Feature-Anzahl.
Die Vorfall-E-Mail kostete mich einen Vormittag und eine berufliche Beziehung zu reparieren. Der Agent lief exakt wie spezifiziert. Ich habe nur vergessen, die Einschränkung zu schreiben.
So funktioniert es jetzt. Die KI führt aus, was du schreibst, nicht was du denkst.
muss wohl lernen, explizit zu sein jetzt...
Quellen
- Osmani, A., Saboo, S., Kartakis, S. (2026, Mai). The New SDLC With Vibe Coding. Google / Kaggle. https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
- Osmani, A. (2026, Juni). The New Software Lifecycle. https://addyosmani.com/blog/new-sdlc-vibe-coding/
- Eveilleau, P. (2026). Vibe Coding, For Real. Amazon Kindle. https://a.co/d/0d7xiVlX
Dieser Post kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern).