Wer schlecht promptet, hat immer recht

Ich bin Software-Architekt und arbeite seit zwei Jahren täglich mit AI. Und ich sage das offen: Die AI schreibt effizienter besseren Code als ich. Vorausgesetzt, ich lasse sie und führe sie richtig. Diesen Satz bringen die wenigsten meiner Kollegen über die Lippen. Das ist kein Zufall.

Der Grund, warum AI bei dir schlechten Code schreibt, bist du.

Das klingt hart, also lass es mich erklären. Ich meine nicht, dass du dumm bist oder AI nicht bedienen kannst. Ich meine etwas Unbequemeres. Viele von uns haben ein leises Interesse daran, dass AI schlecht bleibt. Und wir liefern uns den Beweis dafür gleich selbst mit.

Das Motiv

Fangen wir mit dem an, worüber niemand gern spricht. Solange AI Fehler macht, bleibt der Entwickler unersetzlich. Jede Halluzination, jeder kaputte Build, jeder Code, der fast stimmt, aber eben nicht ganz, ist eine kleine Beruhigung. Mich braucht man noch.

Ein Werkzeug, das plötzlich besser wird als das eigene Handwerk, ist keine gute Nachricht für das eigene Standing. Es ist eine Bedrohung. Und Menschen argumentieren erstaunlich kreativ gegen Dinge, die sie bedrohen. Das ist keine böse Absicht, sondern Selbsterhaltung. Aber sie färbt das Urteil ein, ohne dass man es merkt.

Der Vorwand

Und hier schließt sich der Kreis. Dieses Motiv braucht einen Beweis, und den liefern sich viele selbst. Über die Art, wie sie AI benutzen.

Man nehme den bestehenden Workflow, der oft ohnehin nicht besonders effizient ist, und klebe AI an eine einzelne Stelle. Ein Prompt an den alten Prozess. Kein Kontext, keine Konventionen, keine Spezifikation, keine Teststruktur. Das Ergebnis ist mittelmäßig. Natürlich ist es das. Und dieses hausgemachte Ergebnis wird dann als Urteil über die Technologie verkauft: Siehste, kann AI eben noch nicht.

Das ist kein Urteil. Das ist ein Alibi.

Der Kreislauf ist geschlossen. Die Fehlanwendung erzeugt Fehler. Die Fehler bestätigen das Ego. Das Ego rechtfertigt die Fehlanwendung. Wer schlecht promptet, bekommt am Ende genau das Ergebnis, das er insgeheim sehen wollte, und behält recht.

Das kennen wir schon

Neu ist dieses Muster nicht. Fast jede Branche, die von einem digitalen Angreifer überrollt wurde, hat vorher denselben Satz gesagt: Die Neuen können das doch noch gar nicht richtig. Der stationäre Einzelhandel hat Amazon lange als Nischenphänomen für Bücher abgetan. Der klassische Modehandel hat Zalando belächelt, bis die Innenstädte sich leerten. Das Taxigewerbe war sich sicher, dass eine App niemals ein echtes Transportunternehmen ersetzt, und dann kam Uber. Meistens war die Gewissheit, dass die Neuen es noch nicht draufhaben, in Wahrheit ein Wunsch, der sich als Urteil verkleidet hat.

Dass wir gerade mitten in derselben Bewegung stecken, zeigen die Zahlen. Laut dem Stack Overflow Developer Survey 2025 nutzen 84 Prozent der Entwickler AI-Tools oder planen es. Im selben Jahr ist das Vertrauen in die Ergebnisse aber auf 29 Prozent gefallen. Eine kontrollierte Studie von METR macht es noch anschaulicher: Erfahrene Entwickler schätzten, mit AI 24 Prozent schneller zu sein. Gemessen wurden sie 19 Prozent langsamer. Sie hatten ihren Workflow eben nicht angepasst. AI einschalten und AI gut einsetzen sind zwei verschiedene Dinge.

Was die anderen längst tun

Während ein Teil der Branche noch über die Fehler von einzelnen Prompts diskutiert, ist der Stand der Technik längst weiter. Die Debatte über den einen enttäuschenden Prompt ist ungefähr so aktuell wie ein Nokia mit Tastatur.

Was heute funktioniert, nennt sich Spec-Driven Development, kombiniert mit orchestrierten Agenten. Das Prinzip ist immer dasselbe, ob mit GitHub Spec Kit, OpenSpec, AWS Kiro oder BMAD. Man beschreibt zuerst präzise, was entstehen soll: die Geschäftslogik, die Regeln, die Akzeptanzkriterien. Aus dieser Spezifikation plant ein Agent die Arbeit, ein anderer setzt sie um, ein dritter prüft das Ergebnis gegen die Spec, und bei Abweichungen wird korrigiert. Planung, Ausführung, Prüfung, Korrektur. Möglichst ohne dass ein Mensch jede einzelne Schleife von Hand anstößt.

Der Satz, der einem 2026 überall begegnet, lautet: Die Spec ist der Prompt. Die Spezifikation ist kein Dokument mehr, das jemand einmal liest und dann vergisst. Sie ist die Instanz, gegen die geprüft wird. Die AI baut die Software und sichert mit Tests gegen genau diese Spec ab, dass das Gebaute auch tut, was gefordert war.

Warum das für Unternehmen der eigentliche Punkt ist

Hier wird es geschäftlich interessant, und zwar egal, welcher Technologie-Stack im Haus steht.

Wenn die Spezifikation zur Quelle der Wahrheit wird, dann wird die Geschäftslogik selbst zum eigentlichen Wert. Nicht der Code, der sie umsetzt. Der Code wird zum Ergebnis, das man austauschen kann. Wer seine Fachlichkeit sauber als Spec fasst, besitzt etwas Wiederverwendbares und Prüfbares, das den nächsten Technologiewechsel übersteht. Wer sie nur im Code und in den Köpfen einzelner Entwickler hat, besitzt vor allem ein Risiko.

Und die Größenordnung ist kein Marketing. GitHub berichtet, dass Teams mit Spec Kit Features mit etwa einer Größenordnung weniger Komplett-Neuanläufen ausliefern als mit spontanem Prompting. AWS dokumentiert für sein Tool Kiro Fälle, in denen ein Feature, das vorher 40 Stunden gebraucht hätte, in unter 8 Stunden menschlicher Arbeit fertig war, weil es zuerst als Spec formuliert wurde. Dieser Unterschied liegt nicht am Modell. Er liegt an der Struktur davor.

Für Führungskräfte heißt das ganz konkret: Die sinnvolle Investition ist nicht, mehr Lizenzen zu verteilen und auf das Beste zu hoffen. Sie besteht darin, die Fähigkeit aufzubauen, Geschäftslogik präzise zu beschreiben und in überprüfbare Kriterien zu übersetzen. Das ist die eigentliche neue Kernkompetenz.

Die Rolle verschiebt sich, sie verschwindet nicht

Jetzt die versöhnliche Wahrheit, gerade für die Entwickler, die bis hierher gelesen haben, ohne den Laptop zuzuklappen. Ihr werdet nicht ersetzt. Aber eure Rolle verschiebt sich.

Der Wert lag nie im Tippen der Zeilen. Er lag darin, das Problem zu verstehen, es in die richtigen Teile zu zerlegen und zu beurteilen, ob das Ergebnis wirklich taugt. Genau das bleibt und wird sogar wichtiger. Der Mensch wird zum Gatekeeper. Produktverständnis, das Schreiben der Spec, Urteilskraft, Freigabe. Er prüft und verantwortet, statt jede Zeile selbst zu schreiben.

Wer sein Selbstwertgefühl an die Zeilen hängt, die er von Hand tippt, hängt es an genau den Teil, der gerade verschwindet.

Die praktische Konsequenz ist unbequem, aber einfach. Nimm dir die nächste Aufgabe, die du reflexartig selbst runtertippen würdest, und zwing dich, sie stattdessen als Spec zu formulieren. Beschreib, was gebaut werden soll, welche Regeln gelten, woran man erkennt, dass es funktioniert. Lass die AI bauen und gegen deine Kriterien testen. Das erste Mal fühlt es sich langsamer an. Das ist normal, du verlagerst die Arbeit nur von den Fingern in den Kopf. Genau dorthin, wo sie hingehört.

Fazit

Hochmut kommt vor dem Fall. Der Hochmut, um den es hier geht, ist aber keine Arroganz gegenüber der Technologie. Es ist die Weigerung, den eigenen Workflow neu zu bauen, bequem getarnt als nüchternes Urteil über die AI.

Ein Beispiel dafür läuft gerade live, und diesmal ist der Ausgang noch offen: die deutsche Autoindustrie. Jahrelang galt die chinesische Konkurrenz als billig und unausgereift, als etwas, das man nicht ernst nehmen muss. Heute baut man hektisch um und kauft Software zu, weil man den Anschluss beinahe verpasst hätte. Niemand weiß, wie diese Geschichte ausgeht. Aber das Muster am Anfang ist exakt dasselbe.

Die AI wird besser, ob dein Workflow mitzieht oder nicht. Die einzige offene Frage ist, ob du weiter recht behalten willst oder ob du anfängst, richtig gut zu werden.