Wer spezifiziert hier eigentlich?

Warum der Engpass der Wissensarbeit nicht Produktion ist, sondern die Fähigkeit zu sagen, was man will

Drei Ingenieure bei StrongDM liefern, wofür fünfzehn gebraucht wurden. Nicht weil sie besser programmieren. Sondern weil sie besser spezifizieren können, was gebaut werden soll. Während deutsche Unternehmen AI-Lizenzen kaufen und Pilotprojekte starten, verschiebt sich der eigentliche Engpass stillschweigend eine Ebene nach oben: von der Produktion zur Fähigkeit, die richtige Aufgabe zu formulieren. Die meisten investieren gerade am falschen Ende.

Im Juli 2025 hat Jason Lemkin ein Experiment gemacht. Lemkin ist der Gründer von SaaStr und investiert seit Jahrzehnten in Software. Kein Anfänger.

Zwölf Tage lang hat er den AI-Agenten von Replit an seiner Produktionsdatenbank arbeiten lassen. Das Ergebnis: Der Agent löschte alle Records — 1.206 Executives, 1.196 Companies. Er generierte 4.000 fiktive Nutzer mit fabrizierten Daten. Er gab sich selbst 95 von 100 Punkten auf einer Schadens-Skala und behauptete fälschlich, ein Rollback sei unmöglich. Als Lemkin explizit — in Großbuchstaben — einen Code Freeze anordnete, ignorierte der Agent die Anweisung und machte weiter.

Replit-CEO Amjad Masad entschuldigte sich öffentlich. Nannte es "unacceptable."

Das ist keine Tech-Horror-Story. Es macht ein Problem sichtbar, das in den meisten Unternehmen unsichtbar bleibt.

Lemkin hatte das Tool. Er hatte die technische Kompetenz. Was er nicht hatte, war eine Specification, die einem autonomen Agenten klare Grenzen setzt. Nicht weil er dumm ist. Sondern weil einem System zu sagen, was es tun soll und was nicht, etwas grundlegend anderes ist als es selbst zu tun.

Wer je ein internes Briefing bekommen hat, kennt das Gefühl. Vage Ziele, widersprüchliche Anforderungen, fehlender Kontext. Das war bisher ärgerlich, aber nicht existenziell. Menschliche Teams fragen nach, interpretieren, iterieren. Sie korrigieren schlechte Briefings im Prozess, oft ohne dass es jemand merkt.

Mit AI-Agenten ändert sich das. Wer schlecht spezifiziert, bekommt nicht nur schlechte Ergebnisse. Er bekommt Ergebnisse, die überzeugend aussehen und subtil falsch sind. Das Deck sieht professionell aus. Die Analyse hat saubere Charts. Nur: Die falsche Frage wurde beantwortet.

Die These: Der Flaschenhals der Wissensarbeit verschiebt sich von der Produktion zur Spezifikation. Die entscheidende Frage ist nicht mehr "Wie schnell können wir produzieren?" — sondern: "Wer formuliert, was gebaut werden soll? Und wer beurteilt, ob es gut genug ist?"

Drei Fähigkeiten, die plötzlich knapp werden

Ich habe in fünfzehn Jahren Agenturarbeit hunderte Briefings gesehen, die zu nichts geführt haben. Nicht weil die Teams schlecht waren — sondern weil die Briefings schlecht waren. Was sich jetzt ändert: nicht die Qualität der Briefings. Die Konsequenz.

Drei Fähigkeiten werden in einer Welt billiger Artefaktproduktion plötzlich zum Engpass. Ich nenne sie Taste, Specification und Evaluation.

Taste — Wenn du weißt, dass es falsch ist, bevor du sagen kannst warum

Taste ist die Fähigkeit zu erkennen, ob etwas gut ist, ohne es vollständig erklären zu können. Der Creative Director, der auf ein Layout schaut und sagt: "Stimmt nicht." Er hat recht. Er kann nicht sofort artikulieren warum. Aber er hat recht, und drei Iterationen später weiß jeder im Raum, was er gemeint hat.

Das ist kein Bauchgefühl. Es ist Urteilsvermögen, gewachsen über tausende Entscheidungen darüber, was in welchem Markt, für welche Zielgruppe funktioniert.

Taste erkennt und bewertet. Produzieren kann es nicht. In meinem letzten Text habe ich beschrieben, warum Taste in einer Welt billiger Artefakte zum wertvollsten Filter wird: Weil das Volumen an möglichem Output exponentiell steigt, während die Fähigkeit, Signal von Noise zu unterscheiden, konstant bleibt.

Wie weit diese Verschiebung bereits geht, zeigt ein Blick auf die Zahlen. Anthropic, die Firma hinter Claude, sagt, dass 70 bis 90 Prozent ihres Codes inzwischen von AI geschrieben wird. Boris Cherny, Head of Claude Code, hat nach eigener Aussage seit über zwei Monaten keinen Code mehr selbst geschrieben. Klingt nach dem Ende des Programmierens.

Ist es nicht. Eine LessWrong-Analyse hat das seziert: 90 Prozent des Codes ist nicht 90 Prozent des Engineering-Aufwands. Wenn man mehr automatisierbaren Code produziert, steigt der Prozentsatz. Die eigentliche Ingenieurleistung bleibt dieselbe. Die Spec, die dem Modell sagt, was es bauen soll. Die Evaluation, die prüft, ob es das Richtige gebaut hat. Die Architekturentscheidungen, die Prioritäten. Das ist der Teil, der nicht skaliert. Das ist der Teil, der menschlich bleibt.

Wobei: "menschlich bleibt" ist nicht dasselbe wie "nicht externalisierbar." Taste steckt in Köpfen. Aber man kann es teilweise rausholen. Shrivu Shankar beschreibt drei Methoden: A/B-Interviews — zwei Ergebnisse nebeneinander legen, den Experten fragen "welches ist besser und warum?" Die Begründungen destillieren. Essence Documents — aus Dutzenden evaluierten Beispielen die Muster extrahieren, die das Urteil approximieren. Ghost Writing — der Senior schreibt drei Beispiele, die AI lernt den Stil, neue Outputs werden gegen das Senior-Urteil gemessen.

Das ersetzt den Experten nicht. Aber es hebelt sein Wissen. Taste bleibt menschlich im Ursprung. Sie muss aber nicht in einem Kopf eingesperrt bleiben.

Specification — Die Kunst, die richtige Aufgabe zu formulieren

Spec ist etwas anderes. Spec erzeugt einen Auftrag — einen, der bearbeitbar ist, ohne die Lösung vorwegzunehmen.

Ryan Singer hat das in seinem Buch Shape Up beschrieben: Shaping ist Zeichnen mit dem dicken Edding. Genug Kontur, um eine Richtung vorzugeben. Genug Offenheit, um Kreativität zu ermöglichen. Wer mit dem Kugelschreiber zeichnet, nimmt jede Entscheidung vorweg. Wer gar nicht zeichnet, bekommt Chaos.

Die meisten Briefings scheitern genau hier. Sie sind entweder zu vage ("Macht uns was mit AI") oder zu detailliert ("Baut genau diese Features in genau dieser Reihenfolge"). Beides funktioniert nicht. Das eine gibt keinen Halt. Das andere lässt keinen Raum.

Das klingt trivial. Ist es nicht. Ich habe vielleicht zwei Dutzend wirklich gute Briefings gesehen. Der Rest war — nett formuliert — interpretationsbedürftig. Der Unterschied: Wenn ein menschliches Kreativteam ein schlechtes Briefing bekommt, ruft es den Kunden an und fragt nach. Wenn ein AI-Agent ein schlechtes Briefing bekommt, liefert er exakt das, was da steht. Inklusive aller Lücken, aller Widersprüche, aller falschen Annahmen. Nur verpackt in professionell formatierten Output, der die Lücken unsichtbar macht.

Spec hat eine Voraussetzung, die oft übersehen wird: Domänenwissen. Man kann nur spezifizieren, was man versteht. Ein Strategiechef, der nicht weiß, wie sein Vertriebsprozess tatsächlich funktioniert — nicht auf der Powerpoint-Folie, sondern am Telefon mit dem Kunden —, kann keine brauchbare Spec für einen AI-Agenten schreiben, der diesen Prozess unterstützen soll. Die Spec wäre technisch formuliert, aber inhaltlich leer.

Ich sehe das jede Woche. Wir bekommen ein Briefing, das auf drei Seiten beschreibt, was das Projekt leisten soll. Persona-Beschreibungen, KPIs, Markentonalität. Alles da. Und trotzdem weiß jeder im Raum, dass der eigentliche Auftrag im ersten Telefonat geklärt wird: "Was meint ihr wirklich? Was ist der Kontext, den ihr nicht aufgeschrieben habt? Wo sind die politischen Minenfelder?" Das ist die Spec hinter der Spec. Und die bekommt kein AI-Agent zu sehen.

Und hier liegt das eigentliche Problem: Viele der Leute, die das Domänenwissen haben, können es nicht in bearbeitbare Specs übersetzen. Und viele, die eine Spec schreiben könnten, haben das Domänenwissen nicht. Die Brücke zwischen beiden fehlt in den meisten Organisationen. Sie hat nie existiert, weil sie nie nötig war — menschliche Teams haben sie nebenbei gebaut, im Prozess, ohne es zu bemerken.

Und selbst diese Brücke wird kleiner. Die Tools lernen, Specs selbst zu generieren. Der menschliche Anteil an der Spec schrumpft. Wie schnell, dazu mehr im Ehrlichkeitstest.

Was bleibt, ist die erste Spec. Die initiale Intention, bevor der Loop startet. "Was wollen wir eigentlich?" Das kann kein Tool beantworten. Aber alles danach -- die Verfeinerung, die Iteration, die Detaillierung -- wird zunehmend maschinell.

Evaluation — Wenn Taste auf Output trifft

Evaluation ist der Moment, in dem Ergebnis und Erwartung aufeinandertreffen.

Taste sagt: "Das fühlt sich falsch an." Evaluation fragt: Erfüllt das Ergebnis die Spec? Welche Randbedingungen werden verletzt? Welche Konsequenzen hat der Output in der realen Welt? Evaluation braucht beides — das implizite Urteil von Taste und das explizite Prüfen gegen Kriterien.

Ein Beispiel. Ein AI-Agent erstellt eine Wettbewerbsanalyse für die Geschäftsleitung. Die Slides sehen professionell aus. Die Zahlen stimmen. Taste sagt: "Irgendwas ist schief." Evaluation identifiziert: Die Analyse vergleicht die falschen Wettbewerber. Der Agent hat nach Produktähnlichkeit sortiert, nicht nach Kundenüberschneidung. Technisch korrekt. Strategisch nutzlos.

Ohne Taste bemerkt man den Fehler nicht. Ohne Evaluation kann man ihn nicht benennen. Und ohne beides zusammen wird aus einer hilfreichen AI-Analyse eine professionell verpackte Fehlentscheidung.

Das stört mich an der aktuellen Debatte. Alle reden über Prompt-Engineering. "Wie schreibe ich den besten Prompt?" Das ist die falsche Frage. Prompts sind Syntax. Evaluation ist Semantik. Es geht nicht darum, dem Modell die richtigen Wörter zu geben. Es geht darum zu wissen, ob das Ergebnis die richtige Antwort auf die richtige Frage ist. Das erfordert Fachwissen, Urteilsvermögen und — oft genug — den Mut zu sagen: "Das sieht gut aus, aber es stimmt nicht."

Die Spirale

Die drei hängen zusammen. Nicht linear, sondern als Spirale.

Taste liefert ein Vor-Urteil: "Hier stimmt was nicht." Spec übersetzt es in eine bearbeitbare Aufgabe: "Analysiere die Wettbewerber nach Kundenüberschneidung, nicht nach Produktkategorie." AI produziert einen neuen Output. Evaluation prüft ihn. Das Ergebnis wird zum neuen Vor-Urteil. Die Spirale dreht sich weiter.

Was AI verändert: Die Produktion in der Mitte — der Schritt, in dem der eigentliche Output entsteht — wird fast kostenlos. Die Spirale dreht sich schneller. Zehn Iterationen pro Tag statt eine pro Woche. Das klingt nach Effizienz. Ist es auch. Aber nur unter einer Bedingung: Man braucht mehr Taste und mehr Spec als vorher, nicht weniger.

Wenn die Spirale schneller dreht, aber Taste und Spec nicht mithalten, passiert genau das, was ich in Unternehmen beobachte: Mehr Output, gleiche oder schlechtere Qualität. Die Workslop-Studie von Stanford und BetterUp hat gemessen, was das kostet: 186 Dollar pro Mitarbeiter pro Monat. Verschwendet für Output, der professionell aussieht und nichts sagt.

Ehrlichkeitstest: Wo ich falsch liegen könnte

Drei Einwände, die ernst genommen werden müssen.

Erstens: Die Spec wird selbst maschinell. Kiro generiert aus vagen Anforderungen strukturierte Specs. Claude Code iteriert auf seiner eigenen Spezifikation. Cursor schreibt sich seine Aufträge zunehmend selbst. Wenn die Tools lernen zu spezifizieren, schrumpft der menschliche Anteil möglicherweise schneller als ich hier behaupte. Was bleibt, ist die erste Spec, die initiale Intention, bevor der Loop startet. Aber wie dick diese Schicht wirklich ist, weiß niemand.

Zweitens: Evaluation hat einen blinden Fleck. Die Stanford CodeX-Analyse vom Februar 2026 zeigt: Builder und Inspector teilen dieselben blinden Flecken. Goodhart's Law in Aktion. Wenn dieselbe Technologie-Klasse den Output produziert und beurteilt, entsteht ein systematischer Fehler, den menschliche Evaluation theoretisch fangen müsste, aber in der Praxis oft nicht fängt, weil die Geschwindigkeit der Spirale die verfügbare Prüfkapazität übersteigt.

Drittens: Die 70/30-Linie ist psychologisch, nicht rational. Nate B. Jones hat quantifiziert, dass Menschen 70 Prozent der Entscheidungen behalten und 30 Prozent delegieren wollen. Das ist kein rationales Optimum. Es ist ein Gefühl. Und Gefühle verschieben sich, wenn die Ergebnisse stimmen. Wer vor fünf Jahren gesagt hätte, dass Entwickler 90 Prozent ihres Codes von Maschinen schreiben lassen, wäre ausgelacht worden.

Warum die These trotzdem steht: Alle drei Einwände betreffen das Ausmaß, nicht die Richtung. Ob die menschliche Schicht 60 Prozent beträgt oder 20 -- sie bleibt der Engpass. Und solange Unternehmen in Plattformen investieren statt in die Kompetenz, diese Plattformen zu steuern, verschärft sich das Problem, egal wo die genaue Grenze liegt.

Die deutsche Lage: Investition am falschen Ende

Warum 23 Prozent keinen Anwendungsfall sehen

Laut Bitkom nutzen 36 Prozent der deutschen Unternehmen KI — verdoppelt innerhalb eines Jahres. 47 Prozent planen oder diskutieren den Einsatz. Nur noch 17 Prozent sagen "kein Thema", verglichen mit 41 Prozent im Vorjahr. Die Bewegung ist real.

Aber ein Detail sticht heraus: 23 Prozent der Unternehmen sehen keine Anwendungsfälle für KI in ihrem Geschäft.

Keine Anwendungsfälle. Nicht "die Technologie funktioniert nicht." Nicht "es ist zu teuer." Sondern: Wir wissen nicht, was wir damit machen sollen.

Das ist das Specification-Problem in einer Zahl. Man kann nur anwenden, was man spezifizieren kann.

Die offiziellen Hemmnisse bestätigen das Bild — wenn man sie richtig liest. 53 Prozent nennen fehlendes technisches Know-how, 53 Prozent rechtliche Unsicherheit, 51 Prozent fehlende personelle Ressourcen. Keines dieser Unternehmen sagt: "Uns fehlt die Fähigkeit zu spezifizieren, was wir eigentlich brauchen." Aber genau das verbirgt sich hinter "wir sehen keine Use Cases."

Die Schatten-KI als Symptom

Parallel dazu geschieht etwas anderes. Laut Bitkom-Erhebung vom Oktober 2025 berichten 8 Prozent der Unternehmen von weit verbreiteter privater KI-Nutzung am Arbeitsplatz — verdoppelt seit 2024. 17 Prozent melden Einzelfälle. Nur 26 Prozent stellen offiziellen Zugang bereit.

Das heißt: Die Mitarbeiter spezifizieren und evaluieren bereits. Sie tun es mit ChatGPT, mit Claude, mit Gemini. Auf privaten Accounts. Ohne Governance, ohne Qualitätskontrolle, ohne dass die Geschäftsleitung weiß, was davon in Kundenangeboten und Strategiepapieren landet.

Die Fähigkeit ist da — verteilt, unkontrolliert, unsystematisch. Was fehlt, ist die organisatorische Rahmung. Kein Framework, das die Qualität der Specs misst. Keine Feedback-Loops, die zeigen, ob der AI-generierte Output tatsächlich die richtige Frage beantwortet hat. Keine systematische Auswertung, was funktioniert und was nicht.

Das ist die Ironie: Die Unternehmen, die behaupten, keine Use Cases zu sehen, haben Mitarbeiter, die täglich welche finden. Nur nicht offiziell.

Der Mittelstand kürzt — am falschen Ende

Die Horváth-Studie vom Januar 2026 ist deutlich. Der deutsche Mittelstand investiert 30 Prozent unter dem Marktdurchschnitt in KI. Durchschnittliche AI-Ausgaben aller Unternehmen: 0,5 Prozent des Umsatzes.

Der Grund: Frühe Use Cases haben nicht geliefert. Pilotprojekte, die vielversprechend gestartet waren, haben die erwarteten Ergebnisse nicht gebracht. Die Konsequenz: Budgets werden gekürzt.

Heiko Fink von Horváth formuliert es so: "Wenn die KI-Transformation jetzt nicht massiv beschleunigt wird, entwickelt sich die Technologielücke zu einem existenziellen strategischen Risiko."

Meine These: Die Use Cases haben nicht geliefert, weil die Specification-Kompetenz fehlt. Nicht weil die Tools schlecht sind. Wenn jemand "mach uns was mit AI" als Briefing gibt und das Ergebnis nicht überzeugt, liegt das Problem nicht bei der AI. Es liegt bei der Spec. Und die nächste Investitionsrunde zu kürzen, weil die Spec schlecht war, ist wie den Architekten zu feuern, weil das Briefing unbrauchbar war.

Wer es vormacht — und was man daraus liest

Die Großen automatisieren Produktion — und übersehen die Steuerung

SAP, Siemens, Bosch — die großen deutschen Unternehmen automatisieren, was sich automatisieren lässt. Unit Tests, Rechnungserfassung, Defect Codes, Dokumentation. Das ist die Artefakt-Ebene, die zur Commodity wird. Die Effizienzgewinne sind real.

Aber die strategische Frage stellt fast niemand: Welche menschlichen Fähigkeiten werden dadurch wertvoller? Man investiert in die Plattform, die Artefakte produziert. Nicht in die Kompetenz, die die Plattform steuert.

StrongDM: Wenn Spec zur Steuerungsebene wird

Am anderen Ende des Spektrums steht StrongDM. Im Juli 2025 gründeten CTO Justin McCarthy und zwei Ingenieure eine "Software Factory" mit einer radikalen Charter: "Code darf nicht von Menschen geschrieben werden." Und, noch radikaler: "Code darf nicht von Menschen reviewt werden."

Drei Ingenieure. Keine Junior-Entwickler. Der gesamte Output wird von AI-Agenten produziert. Was die Menschen tun: spezifizieren und evaluieren. Sie schreiben Specs. Sie definieren Acceptance Criteria. Sie bauen Evaluations-Infrastruktur.

Das Herzstück ist ein "Digital Twin Universe" — funktionsfähige Repliken von Okta, Jira, Slack und Google Docs, gegen die tausende Testszenarien pro Stunde laufen. Nicht manuell geschriebene Unit Tests, sondern automatisch generierte Szenarien. Und statt binärer Pass/Fail-Tests nutzt StrongDM "Satisfaction Scoring": Wie wahrscheinlich ist es, dass ein Nutzer mit dem beobachteten Verhalten zufrieden wäre? Das ist eine andere Art von Evaluation — eine, die näher an Taste liegt als an einer Checkliste.

Die Benchmark, die McCarthy intern setzt: 1.000 Dollar pro Tag pro Ingenieur an Token-Kosten. "Wenn ihr darunter liegt, hat eure Software Factory Luft nach oben." Das ist die neue Kostenstruktur: weniger Gehälter, mehr Compute. Und der menschliche Anteil verschiebt sich vollständig auf Spec und Evaluation.

Simon Willison, der die Factory im Oktober 2025 besuchte, nannte die radikalere Behauptung nicht "Code darf nicht von Menschen geschrieben werden" — das fand er plausibel —, sondern "Code darf nicht von Menschen reviewt werden." Denn Review ist Evaluation. Und wenn die Evaluation automatisiert wird, wer prüft dann den Prüfer? (Mehr dazu im Ehrlichkeitstest.)

Warum das relevant ist: StrongDM baut Sicherheitssoftware. Access-Management. Das ist keine Spielwiese, das ist Infrastruktur, bei der Fehler Compliance-Konsequenzen haben. Wenn ein Sicherheitsunternehmen bereit ist, menschliches Code Review als Hindernis statt als Schutzmaßnahme zu behandeln — dann ist die Verschiebung von Produktion zu Specification nicht Theorie. Das ist Praxis.

Kiro: Wenn AWS specification-first als Produkt baut

Im Juli 2025 hat AWS Kiro gestartet. Eine IDE, die auf specification-driven development setzt. Drei Markdown-Dateien als Kern: requirements.md, design.md, tasks.md. Die Requirements nutzen das EARS-Format — Easy Approach to Requirements Syntax, ursprünglich entwickelt bei Rolls Royce.

Die Positionierung: "Das Wichtigste, was ein Entwickler tun kann, ist die Spezifikation schreiben, nicht den Code."

Kiro generiert aus den Specs hunderte bis tausende zufällige Testfälle — property-based Testing statt manueller Unit Tests. Die Spec wird nicht nur zum Auftrag, sondern zum Qualitätsmaßstab.

Warum das ein Signal ist: AWS ist der Cloud-Provider, auf dem halb Corporate-Deutschland läuft. Wenn AWS specification-first als Produkt-Hypothese verfolgt, mit Pricing-Tiers bei 19 und 39 Dollar pro Monat, ist das keine Nische. Das ist Infrastruktur-Ebene. Das sagt etwas darüber, wohin die Branche geht.

Hört auf, Artefakt-Output zu messen

Die Frage ist nicht: "Wie viele Decks, Reports und Analysen produziert das Team pro Woche?" Die Frage ist: "Kann das Team formulieren, was gebaut werden soll, und beurteilen, ob das Ergebnis gut genug ist?"

Das sind fundamental verschiedene Metriken. Die eine misst Execution. Die andere misst die Fähigkeit, Execution zu steuern. In einer Welt, in der Execution billig wird, ist die zweite Metrik die relevante.

Was das für verschiedene Unternehmenstypen heißt:

Für eine Agentur: Die Qualität des strategischen Briefings wird wichtiger als die Geschwindigkeit der Kampagnenproduktion.

Für einen IT-Dienstleister: Requirements Engineering ist kein Pflichtenheft-Formalismus mehr. Es ist die Kernkompetenz, die über Projekterfolg entscheidet.

Für einen Mittelständler: Die Leute, die wissen, wie der Laden wirklich läuft, sind plötzlich strategisch relevanter als die, die Powerpoints bauen.

Drei Fragen, die jeder Director sich stellen sollte:

Erstens: Wer kann heute eine gute Spec schreiben? Eine, die ein AI-Agent produktiv umsetzen kann. Nicht ein vages Briefing, das ein menschliches Team interpretiert und im Prozess korrigiert. Eine echte Spec: klar genug für Richtung, offen genug für Lösung. Wie viele solcher Leute habt ihr?

Zweitens: Wer kann den Output evaluieren? Nicht nur technisch — funktioniert der Code, stimmen die Zahlen. Sondern in Bezug auf Domänenwissen und Geschäftsziel. Beantwortet die Analyse die richtige Frage? Vergleicht sie die richtigen Wettbewerber? Wird das Board die richtigen Schlüsse ziehen? Das ist Evaluation. Und: Was passiert, wenn die Leute, die das können, gehen?

Drittens: Messt ihr noch Produktionsvolumen? Dann messt ihr das Falsche. In einer Welt, in der ein Agent über Nacht zehn Versionen einer Präsentation produzieren kann, ist die Anzahl der Präsentationen kein Maß für Wertschöpfung. Das Maß ist: Welche Entscheidung hat die Präsentation ermöglicht? Und wer hat die Frage formuliert, die die Präsentation beantwortet?

Wer steuert, wenn die Maschine schneller wird?

Zurück zu Jason Lemkin. Er ist nicht an mangelndem Technikwissen gescheitert. Er hat angenommen, ein System, das Code schreiben kann, versteht auch, wo die Grenzen liegen.

Das ist dieselbe Annahme, die gerade in tausenden deutschen Unternehmen gemacht wird. "Wir haben die Plattform. Wir haben die Lizenzen. Wir haben die AI-Strategie." Die Frage, die fehlt: Wer steuert? Wer spezifiziert? Wer evaluiert?

Der KPMG-Report "Generative KI in der deutschen Wirtschaft 2025" zeigt: Nur 26 Prozent der Unternehmen haben eine unternehmensweite Trusted-AI-Strategie. 64 Prozent glauben, KI erfordere Umschulung. Stimmt. Aber sie erwarten keinen grundlegenden Einfluss auf die Arbeitsplatzzahl.

Das ist die falsche Frage. Es geht nicht um die Anzahl der Arbeitsplätze. Es geht darum, was an diesen Arbeitsplätzen getan wird. Und ob das, was getan wird, die Fähigkeit einschließt, einer Maschine zu sagen, was sie tun soll.

Der Stifterverband hat zusammen mit McKinsey 30 Zukunftskompetenzen für 2030 identifiziert. Keine davon heißt "Specification." Keine davon adressiert die Fähigkeit, Aufgaben so zu formulieren, dass autonome Systeme sie produktiv umsetzen können. Das ist kein Versehen. Das ist ein blinder Fleck.

Spezifizieren heißt wissen, was man will. Es ausdrücken können. Und erkennen, wenn das Ergebnis daneben liegt.

Das ist keine technische Kompetenz. Es ist eine menschliche. Und sie wird wertvoller, je leistungsfähiger die Maschinen auf der anderen Seite werden.

Die Frage ist nicht, ob eure Unternehmen AI einsetzen. Die meisten tun es. Die Frage ist, ob ihr die Leute habt, die der AI sagen können, was sie tun soll.

Quellen

Direkt anwenden

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

Zum Prompt Kit