Die Vokabellücke

Du kannst nicht spezifizieren, was du nicht benennen kannst. Und die Leute, die es benennen könnten, haben den geringsten Anreiz dazu.

Paul Bakaus hat ein Vokabelheft geschrieben.

Kein Kinderbuch. Ein Werkzeug für Entwickler, die mit AI Interfaces bauen. Bakaus, ehemals Google, hat mit Impeccable einen "Vocabulary Layer" gebaut: sieben Referenzdateien mit Begriffen, Definitionen und Anti-Patterns. Kein Framework, keine Komponentenbibliothek, kein Code. Nur Wörter.

Ergebnis: 1,59x bessere Qualität im Tessl-Benchmark. Null Modelländerung. Null Prompt-Engineering. Nur Vokabular.

Der Mechanismus ist banal, wenn man ihn einmal gesehen hat. "Schöne Farben" liefert generischen Output. "OKLCH tinted neutrals with warm base hue" liefert eine kohärente Palette mit perceptual uniformity. "Guter Text" liefert 16px Inter. "Fluid type scale with optical sizing and proper vertical rhythm" liefert eine responsive Hierarchie, die atmet. "Padding hinzufügen" liefert willkürliche Werte. "8px baseline grid with optical alignment" liefert ein System.

Die AI konnte das alles schon. Es hat nur niemand danach gefragt, weil den meisten Nutzern die Wörter fehlten.

Das universelle Muster

Das klingt nach einem Design-Problem. Ist es nicht.

Strategie: Ein Director sagt "wir brauchen AI-Transformation." Was meint er? Bolt-on-Tooling? Strukturelle Operating-Model-Veränderung? Workforce Restructuring? Context Engineering im Sinne von Text 5? Ohne die Wörter, um zu unterscheiden, bekommt er das generische Paket. Und das generische Paket ist Floor.

Marketing: Bain hat gerade gezeigt, dass Brands für die Agent-Ökonomie optimieren müssen. Aber die meisten CMOs können den Unterschied zwischen GEO, SEO und "Agent Readiness" nicht benennen. Wer es nicht benennen kann, kann es nicht beauftragen.

Produktentwicklung: Nate B. Jones hat "Prompting" in vier Disziplinen zerlegt: Prompt Craft, Context Engineering, Intent Engineering, Specification Engineering. Die meisten Unternehmen optimieren auf Stufe 1, weil sie die Wörter für Stufe 2 bis 4 nicht kennen.

Die Kernbeobachtung: Die Capability Gap liegt nicht in der AI. Sie liegt im Prompt. Und der Prompt ist nicht schlecht, weil der Mensch dumm ist. Der Prompt ist schlecht, weil dem Menschen das Fachvokabular fehlt, um zu beschreiben, was er eigentlich will.

Erinnert ihr euch an die Floor/Ceiling-Unterscheidung? "Schöne Farben" ist Floor. "Tinted neutrals" ist der Anfang von Ceiling. Der Abstand zwischen beiden IST die Vokabellücke. Und die Vokabellücke bestimmt, wo eure Commodity-Grenze verläuft.

Zurück zum Wasserfall

Wer seit den Neunzigern in der Softwareentwicklung unterwegs ist, erkennt das Muster.

Wasserfall-Projekte funktionierten so: Alles im Voraus planen, spezifizieren, abnicken, dann durchbauen. Das Problem war nie der Prozess. Das Problem war, dass Menschen schrecklich darin sind, im Voraus zu wissen, was sie wollen. Und noch schlechter darin, es präzise zu artikulieren. Jedes Wasserfall-Projekt, das in der Implementierung entgleiste, entgleiste nicht wegen schlechter Entwickler. Es entgleiste, weil die Spezifikation nicht stimmte.

Agile hat das gelöst. Nicht durch bessere Planung, sondern durch kürzere Zyklen. Iterieren statt spezifizieren. Bauen, zeigen, korrigieren. Scrum, Kanban, Sprints: institutionalisierte Prozesse, um die menschliche Unfähigkeit zur präzisen Vorab-Spezifikation zu kompensieren.

Jetzt haben wir AI-Agenten, die einen ganzen Sprint Code in einer Stunde durchlaufen. Und plötzlich sind wir zurück beim Wasserfall. Denn der Agent braucht am Anfang eine klare Spezifikation. Er kann nicht zwischendurch fragen "meintest du das so?" Er arbeitet mit dem, was da steht. Und was bei den meisten da steht, ist: vage.

Das ist die Ironie. Zwanzig Jahre Agile haben uns beigebracht, dass wir nicht gut spezifizieren können. AI-Agenten setzen genau das wieder voraus. Wir haben ein Werkzeug, das schneller ausführt als je zuvor, und es scheitert an derselben Stelle wie der Wasserfall: an unserer Unfähigkeit, präzise zu sagen, was wir wollen.

Es gibt zwei Antworten darauf. Die eine: bessere Specs. Alles im Voraus klären, den Agent laufen lassen. Wasserfall mit schnellerer Ausführung. Die andere: kürzere Einheiten. Die Planung kollaborativ, mit der AI als Sparringspartner, der Varianten zeigt, Optionen eröffnet, die richtigen Fragen stellt. Die Ausführung autonom. Interaktive Architektur, autonome Ausführung.

Beide Antworten laufen an derselben Stelle zusammen: Du brauchst die Wörter. Entweder um die Spec zu schreiben. Oder um im Dialog mit dem Agenten die richtige Richtung zu finden. Die Vokabellücke bleibt der Engpass.

Rejection als Vokabular-Generator

Nate B. Jones hat einen Satz geschrieben, der das Problem von der anderen Seite aufrollt: "Your prompts are disposable. Your rejections compound."

Die These: Jede Rejection ist ein Wissens-Schöpfungsmoment.

Eine Partnerin reviewed ein Pitch-Deck und sagt: "Wo ist unser proprietärer Insight zu Customer Switching Costs? Jede Firma mit demselben Modell hätte dieses Framing liefern können." In dem Moment hat sie eine Constraint definiert, die vorher nicht existierte. Und sie hat es in Wörtern getan, die präzise genug sind, um sie zu encodieren.

Nate zerlegt das in drei Dimensionen:

  1. Recognition: erkennen, dass etwas falsch ist. Setzt Domänenwissen voraus.
  2. Articulation: erklären WARUM es falsch ist. Setzt Vokabular voraus.
  3. Encoding: die Constraint dauerhaft festhalten. Setzt Infrastruktur voraus.

Die Vokabellücke sitzt zwischen Recognition und Articulation. Du SPÜRST, dass der Output nicht stimmt. Aber ohne die richtigen Wörter bleibt deine Rejection vage. "Das ist nicht richtig" statt "du behandelst alle Covenants gleich, aber DSCR-Monitoring hat völlig andere Trigger als Zinsdeckungs-Checks." Vage Rejection verdunstet. Präzise Rejection compounded.

Das ist dasselbe Prinzip wie DDBs Bad Ideas Board aus Text 6. Das Board definiert das Vokabular des Ablehnens: "generisch", "offensichtlich", "darauf käme jeder." Dann zwingt es das Team, die Wörter für das Bessere zu finden. Der Bad Ideas Board ist institutionalisierte Rejection; ein Vokabular-Generator.

Die Kaskade und die Vokabellücke

Im letzten Text habe ich beschrieben, welche fünf Fähigkeiten das Ceiling vom Floor trennen: Terrain, Intent, Taste, Spec, Evaluation. Die Kaskade, die als Flywheel funktioniert.

Die Vokabellücke betrifft jede einzelne Stufe.

Ohne die Wörter für euer Terrain beschreibt ihr euren Markt in Allgemeinplätzen. Ohne die Wörter für euren Intent bleibt "wir wollen AI-Transformation" eine leere Absichtserklärung. Ohne Taste-Vokabular könnt ihr nicht artikulieren, warum ein Ergebnis nicht stimmt. Ohne Spec-Vokabular bekommt der Agent generischen Output. Und ohne Evaluation-Vokabular könnt ihr nicht prüfen, ob das Ergebnis dem entspricht, was ihr definiert habt.

Die Rejection-Logik verschärft das. Rejection erzeugt Constraints. Constraints sind Vokabular in codierter Form. Codiertes Vokabular senkt die Kosten zukünftiger Spezifikation. Je reicher euer Rejection-Vokabular, desto präziser werden eure Specs, und desto weiter verschiebt sich eure Commodity-Grenze. Und je besser eure Specs, desto bessere Ergebnisse bekommt ihr; was wiederum euer Urteilsvermögen schärft, weil ihr feinere Unterschiede erkennt. Das Flywheel dreht sich. Aber nur, wenn die Wörter da sind.

Was Bakaus für Design mit sieben Referenzdateien gelöst hat, ist im Kern dasselbe wie Andrej Karpathys program.md: eine Datei mit Constraints und Geschmack, gegen die ein Agent 700 Experimente fährt. Nicht "erst A, dann B, dann C", sondern ein Netz von Regeln, die gleichzeitig gelten und sich gegenseitig beeinflussen. Taste als Constraint-System.

Die Angst-These

Don Norman hat 1988 in The Design of Everyday Things einen Grundsatz formuliert: Gutes Design externalisiert Wissen. Es legt Informationen in die Welt, statt sich darauf zu verlassen, dass der Mensch alles im Kopf behält. Der Türklinken-Test: Eine gut gestaltete Tür zeigt dir, ob du drücken oder ziehen sollst. Eine schlechte zwingt dich, zu raten.

Auf Organisationen übertragen: Gutes organisatorisches Design externalisiert institutionelles Wissen. Dokumentiert, durchsuchbar, maschinenlesbar. Schlechtes belässt es im Kopf. Beim Müller, bei der Partnerin, in den ungeschriebenen Regeln.

Das habe ich in Text 5 als das Müller-Problem beschrieben. Hier kommt die Verschärfung.

Die Anreizstruktur belohnt das Gegenteil von Externalisierung.

Der Müller wird nicht befördert, weil er gut dokumentiert. Er wird gebraucht, weil er der Einzige ist, der die Sonderkonditionen kennt. Die Partnerin, deren Rejection-Vokabular zwanzig Jahre komprimierter Branchenerfahrung repräsentiert: wenn sie das in einem Constraint-System encodiert, was macht sie dann noch? Der Senior-Entwickler, der als Einziger den Legacy-Code versteht: seine Jobsicherheit IST die Nicht-Dokumentation.

Je wertvoller das Wissen, desto geringer der Anreiz, es zu teilen.

Die Menschen mit dem reichsten Vokabular für präzise Rejection haben den geringsten Anreiz, es zu encodieren. Nicht aus Böswilligkeit. Sondern weil die Struktur es belohnt. Wer sein Wissen teilt, macht sich ersetzbar. Wer es hortet, bleibt unverzichtbar.

Das ist kein neues Muster. Aber AI macht es teuer.

Nate B. Jones hat parallel dazu den Blick nach unten beschrieben: Die Junior-Pipeline trocknet aus, weil die Einstiegsaufgaben, an denen Juniors Taste entwickeln, an die Maschine gehen. Weniger Juniors, die durch Rejection lernen. Weniger Nachwuchs, der das Vokabular aufbaut. Das ist das Seed-Corn-Problem.

Die Angst-These ist der Blick nach oben: Die Seniors horten ihren Taste aktiv. Zwei Richtungen, dasselbe Ergebnis. Die Vokabellücke wächst von beiden Seiten.

Das Flywheel, und warum es nicht automatisch funktioniert

Wenn du heute als Wissensarbeiter mit AI-Agenten arbeitest, tust du im Kern dasselbe wie ein guter Manager: Kontext setzen, Intention kommunizieren, korrigieren, nachsteuern. Nur in kleinerem Maßstab, schnellerem Takt und mit einer Maschine statt einem Team.

Und hier entsteht eine Dynamik, die über das individuelle Arbeiten hinausgeht.

Wenn du gezwungen bist, Terrain, Intent und Taste so zu kodieren, dass ein Agent damit arbeiten kann, baust du gleichzeitig Artefakte, die auch für Menschen nützlich sind. Neue Teammitglieder können davon lernen. Führungskräfte können dagegen prüfen. Cross-funktionale Teams können sich daran ausrichten.

Das Unsichtbare wird sichtbar. Gute Manager haben das immer intuitiv getan: Kontext setzen, Intention kommunizieren, korrigieren. Aber es wurde nie systematisiert, weil der Aufwand im Verhältnis zum Nutzen zu hoch war. AI-Agenten verändern diese Gleichung. Weil der kodierte Kontext jetzt direkt handlungsfähig ist; nicht nur als Dokumentation, sondern als operativer Input.

Terrain füttert Intent. Intent schärft Taste. Taste wird zur Spec. Die Spec erzeugt besseren Output. Besserer Output erzeugt präzisere Rejection. Präzisere Rejection erweitert das Taste-Vokabular. Und das erweiterte Vokabular verbessert das nächste Terrain.

Wenn man das auf ein Team skaliert, mit ihren Agenten, und auf eine Abteilung und auf eine Organisation, verbessert sich nicht nur die Agent-Qualität. Es verbessert sich die Kommunikation und Ausrichtung zwischen Menschen. Weil dieselbe Klarheit, die einen Agenten funktionieren lässt, auch menschliche Zusammenarbeit verbessert. Das war die Lütke-Beobachtung aus Text 5: Die Disziplin, Probleme mit genug Kontext zu formulieren, dass sie ohne Rückfragen lösbar sind, hat ihn nicht zu einem besseren AI-Nutzer gemacht. Sondern zu einem besseren CEO.

Epic Systems hat das in der Praxis bewiesen. 45 Jahre lang Klinik-Workflows encodiert, Rejection für Rejection, Hospital für Hospital. 305 Millionen Patientenakten, nahe null Churn. Der Moat ist nicht die Software. Der Moat ist das encodierte Urteilsvermögen von Generationen von Klinikern.

Wo ich falsch liegen könnte

Das Flywheel kann schlechten Geschmack genauso zementieren wie guten. Der Qualitätsmaßstab eines Managers ist oft persönlich und inkonsistent. Wenn das Flywheel läuft, akkumuliert es das, was hineingegeben wird, und das ist nicht automatisch richtig. Es braucht eine Governance-Schicht; einen Weg, die Taste-Ebene über die Zeit herauszufordern und weiterzuentwickeln, nicht nur zu akkumulieren. Ohne das zementiert ihr die Vorurteile von 2026 in die Infrastruktur von 2030.

Die Vokabellücke ist kein Skill-Gap, den man mit Training schließt. Wenn ich sage "lernt die Wörter", klingt das nach "schickt eure Leute in einen Kurs." Ist es nicht. Vokabular in diesem Sinne ist komprimierte Erfahrung. "Tinted neutrals" ist nicht ein Begriff, den man auswendig lernt. Es ist ein Konzept, das man versteht, weil man hundert Farbpaletten gesehen und bewertet hat. Die Vokabellücke schließt sich durch Praxis, nicht durch Seminare. Und sie schließt sich durch Rejection: durch das wiederholte Artikulieren, warum etwas nicht gut genug ist.

Die Angst-These ist kein Vorwurf. Es ist rationales Verhalten in einer irrationalen Anreizstruktur. Die meisten AI-Transformationsinitiativen scheitern nicht an der Technologie. Sie scheitern daran, dass sie von den Menschen verlangen, genau das Wissen zu externalisieren, das ihre Existenzberechtigung darstellt. Du kaufst das beste Tool der Welt, und die Leute füttern es mit dem Minimum. Wer das ändern will, muss die Anreize ändern, nicht die Tools.

Was daraus folgt

Nicht: "Jeder muss jetzt Vokabeln lernen." Das ist die naive Version.

Erstens: Vocabulary Layers als Investition. Was Bakaus für Design gemacht hat, braucht jede Domäne. Nicht als Glossar, sondern als Constraint-Set mit Anti-Patterns. Euer Fachvokabular so aufbereiten, dass ein AI-Agent damit arbeiten kann, und dass neue Mitarbeiter damit lernen können. Das ist dieselbe Investition.

Zweitens: Rejection als Kernprozess etablieren. Nicht "Quality Gate"; das klingt nach Bürokratie. Sondern systematisches Artikulieren und Encodieren von Ablehnungen. Was DDB mit dem Bad Ideas Board für Kreativarbeit gemacht hat, lässt sich auf jede Disziplin übertragen: Lasst die AI den ersten Entwurf liefern. Dann fragt: Was stimmt daran nicht? Und, das ist der entscheidende Schritt: Schreibt die Antwort auf. Die Rejection wird vom Nebenprodukt zum Hauptprodukt.

Drittens: Interaktive Planung, autonome Ausführung. Nutzt die AI nicht als Wasserfall-Executor, dem ihr eine Spec über den Zaun werft. Nutzt sie als Planungspartner: Varianten zeigen lassen, Optionen vergleichen, die richtigen Fragen stellen lassen, bis die Spec scharf genug ist. Dann autonom ausführen lassen. Die Architektur ist kollaborativ. Die Ausführung ist autonom.

Viertens: Die Norman-Frage stellen. Don Normans Prinzip, angewandt auf eure Organisation: Ist dieses Wissen in der Welt oder nur im Kopf? Und was müsste passieren, damit es in die Welt kommt, ohne dass der Mensch, in dessen Kopf es steckt, sich bedroht fühlt? Das ist keine IT-Frage. Das ist eine Führungsfrage.

Die Denkwerkzeuge zu diesem Text helfen euch, eure eigene Vokabellücke zu kartieren. Der Vokabel-Scanner, der Rejection-Archäologe und der Horten-Test sind drei Prompts, die ihr auf die eigene Situation anwenden könnt. Zu den Denkwerkzeugen ->

Die Vokabellücke ist nicht ein weiterer Skill-Gap, den man mit Training schließt. Sie ist der sichtbare Ausdruck einer tieferen Spannung: Zwischen dem, was Organisationen brauchen (Wissen in der Welt, maschinenlesbar, teilbar, compound-fähig) und dem, was Individuen schützen (Wissen im Kopf, exklusiv, positionserhaltend).

AI macht diese Spannung nicht neu. Aber sie macht sie teuer. Weil die Maschine das Wissen, das du nicht aussprichst, auch nicht nutzen kann. Und weil jeder Wettbewerber mit denselben Tools denselben Floor erreicht.

Was differenziert, ist nicht die AI. Was differenziert, sind die Wörter.

Quellen und weiterführende Links

Primäre Referenzen im Text:

  • Paul Bakaus / Impeccable: Vocabulary Layer für AI-gestütztes Interface Design. 1,59x Qualitäts-Uplift durch sieben Referenzdateien, null Modelländerung.
  • Nate B. Jones: "Your prompts are disposable. Your rejections compound." (März 2026) – Recognition, Articulation, Encoding als Kaskade. Epic Systems als 45-Jahre-Rejection-Flywheel. – Nate's Newsletter
  • Nate B. Jones: "Beyond the Perfect Prompt" – Prompt Craft, Context Engineering, Intent Engineering, Specification Engineering als vier Disziplinen. – Nate's Newsletter
  • Don Norman: The Design of Everyday Things (1988) – Gutes Design externalisiert Wissen.
  • Andrej Karpathy: program.md – Taste als Constraint-System, gegen das ein Agent Experimente fährt.

Weiterführend:

  • Shrivu Shankar: "How to Stop Your Human From Hallucinating" (November 2025) – Menschliche "Halluzinationen" folgen denselben Mustern wie LLM-Halluzinationen: Jargon-Konflikte, fehlende Namenskonventionen, versteckte Dokumentation. "Activation" bedeutet intern etwas anderes als im Marketing. Die Vokabellücke existierte schon immer zwischen Menschen – AI macht sie nur teuer genug, um sie zu bemerken. – blog.sshh.io
  • DHH / Jason Fried: Shape Up – "The Goldilocks Phase" of Specification. Der Sweet Spot zwischen Over- und Under-Specification. "Rabbit Holes" (was man NICHT tun soll) sind strukturell identisch mit Bakaus' Anti-Patterns: Vokabular für Constraints. – basecamp.com/shapeup

Frühere Texte dieser Reihe:

Direkt anwenden

Dieses Prompt Kit übersetzt die Konzepte des Essays in konkrete Prompts, die du sofort nutzen kannst.

Zum Prompt Kit