Warum ist die Position des Prompt Engineers verschwunden?

Der Hauptgrund für das Verschwinden der Position ist die Verbesserung der Modellfähigkeiten. Frühe Modelle benötigten sorgfältig entworfene Prompts, um gute Ergebnisse zu liefern, aber mit der gesteigerten Befehlsbefolgungsfähigkeit der Modelle liefert normales Natur Sprache bereits stabile Ergebnisse. Der technische Schutzwall der Position war zu flach; mit jeder Modellgeneration nahm der Wert der spezialisierten Prompt-Arbeit ab, bis sie schließlich durch die technische Iteration der Modellhersteller verdrängt wurde.

Welche drei Kernfähigkeiten sollten Programmierer 2026 entwickeln?

Programmierer sollten 2026 drei Fähigkeiten schwerpunktmäßig entwickeln: Urteilsvermögen (Klarheit über Ziele, Grenzen und Abnahmekriterien vor dem Aufruf der KI), Abnahmefähigkeit (Erstellung von Checklisten für häufige KI-Fehlermuster, um versteckte Mängel zu erkennen, die „zu 80 % richtig und zu 20 % falsch“ sind) und Notfallfähigkeit (Einrichtung von Datensicherungen, Rollback-Plänen und Parallelabgleichsmechanismen, um eine schnelle Wiederherstellung bei KI-Ausfällen zu gewährleisten).

Wie kann man die Fähigkeit zur Abnahme von KI-Ergebnissen systematisch verbessern?

Die Verbesserung der Abnahmefähigkeit erfordert die Erstellung einer persönlichen Checkliste, die Checkpoints aus eigenen Projektunfällen zusammenfasst und nach Modulen kategorisiert (Datenklasse: Prüfung von Kennzahlen und Grenzwerten; Schnittstellenklasse: Prüfung von Idempotenz und Timeouts; Prozessklasse: Prüfung von Ausnahmezweigen und Rollback-Pfaden). Die Liste sollte mit 5 Punkten beginnen, sich innerhalb eines halben Jahres auf etwa 20 Punkte erweitern und regelmäßig durch Review aktualisiert werden. Der Schlüssel liegt darin, nicht die Checkliste anderer zu kopieren, sondern die eigenen Fallen aufzuzeichnen.

Ist das Prompt Engineering tot? Die drei Fähigkeiten, die Programmierer 2026 wirklich trainieren sollten

Einleitung: Die vor drei Jahren heiß begehrte Jobbezeichnung ist dieses Jahr auf Jobbörsen kaum noch zu finden

2023 schrieb Anthropic eine Stelle als „Prompt Engineer“ aus. Das Gehaltsspektrum wurde detailliert kolportiert, angeblich nach oben offen, und die globalen Tech-Medien berichteten zwei Wochen lang darüber. In diesen Monaten wurden Prompt-Vorlagen zu einer Modeerscheinung: „Rollenspielmethode“, „CoT-Zauberformeln“, „Große Sammlung magischer Prompts“ – die Kursanbieter wurden zuerst reich, und eine große Menge Leute lernten die Vorlagen auswendig. Drei Jahre später ist auf dem Arbeitsmarkt des Jahres 2026 die Berufsbezeichnung „Prompt Engineer“ kaum noch auffindbar – nicht umbenannt, sondern verschwunden. Gleichzeitig sind KI-Programmierung, KI-Planung und KI-Analyse in den täglichen Ablauf eingezogen; die Schwelle ist so niedrig, dass sogar Praktikanten sie bedienen können.

Damit kehrte die alte Frage in neuem Gewand in die Kommentarspalten zurück: „Ist der Prompt-Kurs, für den ich damals Geld ausgegeben habe, umsonst gewesen?“ „Wenn es den Job nicht mehr gibt, zählt dieses Handwerk noch?“ Diese Frage zielt in die falsche Richtung. Das Handwerk ist nicht verschwunden, es hat sich aufgelöst – wie Salz, das in der Suppe aufgeht, unsichtbar wird, aber den Geschmack ausmacht. In dieser Folge zerlegen wir genau das: Warum Prompt Engineering als Job gestorben ist, in welche drei Dinge es sich als Fähigkeit aufgelöst hat und wohin Programmierer 2026 trainieren sollten.

Shi Wen: Die Berufsbezeichnung „Prompt Engineer“ ist seit drei Jahren abgekühlt. Was ist deine erste Reaktion – längst tot oder zu Unrecht gestorben?

Yong Liang: Längst tot, und völlig zu Recht. Aber vorher eine Klarstellung: Gestorben ist die „Position“, nicht die „Fähigkeit“. Diese beiden muss man trennen; mischt man sie, kommt man zu falschen Schlussfolgerungen wie „umsonst gelernt“.

Shi Wen: Dann lass uns das gründlich besprechen: Warum diese Position sterben musste, in welche drei Fähigkeiten sie sich verwandelt hat, wie man jede trainiert und was ein gewöhnlicher Ingenieur wie ich jetzt tun sollte.

Q1: Warum „Prompt Engineer“ als Position nicht lange überleben konnte

Yong Liang: Weil es nie ein eigenständiger Beruf war, sondern ein temporärer Patch für die Zeit unzureichender Modellfähigkeiten.

Als ich 2023 diese Stellenausschreibung sah, war meine erste Reaktion nicht Neid, sondern Neugier: Was macht diese Person nach der Einstellung den ganzen Tag? Überlegen, wie man mit dem Modell spricht? Der Schutzwall dieser Arbeitsinhalte ist zu flach. Die Entwicklung der letzten drei Jahre hat diese Urteil bestätigt. In meinem Team gab es wirklich einmal so jemanden: 2024 eingestellt, spezialisiert auf Prompt-Optimierung, die Arbeit war wirklich gut, die Prompts stabil und wiederverwendbar. Aber ab der zweiten Hälfte 2025 wurde seine Arbeit deutlich dünner – das Modell wurde zwei Generationen weiterentwickelt, die Befehlsverständnisfähigkeit stieg, und die früher sorgfältig entworfenen dreiteiligen Zauberformeln sind jetzt mit einem einfachen Satz in Klartext erledigt. Später sagte er mir selbst: Chef, meine Hauptaufgabe besteht jetzt darin, zu prüfen, ob die von der KI geschriebenen Prompts gut sind.

Der technische Grund für das Verschwinden der Position ist nicht kompliziert: Frühe Modelle waren ein System, das „beschwichtigt“ werden musste; bei derselben Aufgabe unterschied sich die Ausgabequalität drastisch, je nachdem, wie man es formulierte, deshalb wurde „Beschwichtigen“ zu einem Handwerk. Aber jedes Mal, wenn Modellhersteller eine neue Version veröffentlichen, bewegen sie sich in Richtung „keine Beschwichtigung nötig“ – stärkere Befehlsbefolgung, längeres Kontextfenster, stabilere Werkzeugaufrufe. Die Fortschrittsrichtung der Modelle ist genau die Richtung, in der das Handwerk Prompt Engineering verschwindet. Das Endziel der Fortschritte eines Handwerks ist die eigene Arbeitslosigkeit; so etwas ist in der Softwaregeschichte mehr als einmal passiert: Ingenieure, die sich auf Browserkompatibilität spezialisiert hatten, Ingenieure für Flash-Optimierung, sie alle sind so abgetreten.

Deshalb fasse ich meine Schlussfolgerung direkt: Prompt Engineering starb daran, dass es „nur mensch-maschinelle Übersetzung“ war. Das Schicksal des Berufs des Übersetzers ist es, von Zweisprachigen verdrängt zu werden. Und wenn jeder Programmierer gezwungen ist, zweisprachig zu sein – sowohl Business versteht als auch KI bedienen kann – gibt es keine Notwendigkeit mehr für Vollzeitübersetzer. Das ist keine Tragödie, sondern Reifung der Branche.

Q2: Die erste zu trainierende Fähigkeit ist das Urteilsvermögen – was bedeutet das konkret und wie trainiert man es?

Yong Liang: Urteilsvermögen bedeutet „wissen, was man der KI auftragen soll“. Das klingt wie eine Banalität, ist aber tatsächlich die größte Trennlinie.

In den Jahren, in denen ich Teams geleitet habe, habe ich ein stabiles Phänomen beobachtet: Mit demselben KI-Toolset unterscheidet sich die Output-Qualität zweier Personen um eine Größenordnung. Der Unterschied liegt kaum in der Bedienkompetenz, sondern im ersten Satz – welches Problem man der KI gibt. Die schwache Nutzung ist, eine große und leere Anforderung komplett hineinzuwerfen: „Mach mir ein Patientennachsorge-System“. Die KI ist auch sehr bemüht und liefert eine strukturell vollständige, professionell aussehende Sache, aber das Verständnis der Anforderung und das, was du wirklich willst, sind mit hoher Wahrscheinlichkeit nicht dasselbe. Die starke Nutzung ist, das Problem zuerst in klar abgegrenzte Aufgaben zu zerlegen: Wer ist das Objekt der Nachsorge, was sind die Auslösebedingungen, welche Schritte müssen vom Menschen geprüft werden, woher kommt das Daten und wohin geht es, und es dann Stück für Stück der KI zu übergeben.

Die Fähigkeit, Probleme zu zerlegen, ist im Wesentlichen das Verstehen von Geschäftsbeschränkungen. Wenn ich Leute einstelle, stelle ich jetzt immer eine Frage: Du hast drei Tage und einen KI-Assistenten, senke die No-Show-Rate bei Terminen in der Ambulanz. Was ist dein erster Schritt? Die meisten fangen an, technische Mittel aufzulisten. Die Antwort, die ich hören will, ist zuerst zu klären: Wie ist die Definition von No-Show, wo sind die historischen Daten, was zählt als Erfolgserfüllung, und ob Ärzte verärgert werden, wenn man die Terminregeln ändert. Das sind die Rohstoffe des Urteilsvermögens; die KI kann es nicht für dich tun, weil diese Beschränkungen in deiner Branchenerfahrung verwurzelt sind.

Wie trainiert man Urteilsvermögen? Ich habe für mein Team eine Regel aufgestellt: Bevor man mit der KI arbeitet, schreibe drei Zeilen – was ich will, was ich nicht will, und was als Erfolg zählt. Erst danach den Dialog öffnen. Diese Gewohnheit zwingt dich dazu, das Denken abzuschließen, bevor du die KI aufrufst, und das Denken selbst wird vom Modell verstärkt; wer das Denken spart, dessen Faulheit wird ebenfalls vom Modell verstärkt. Nach drei Monaten im Review ist der Unterschied zwischen denen, die die drei Zeilen schreiben, und denen, die es nicht tun, mit bloßem Auge sichtbar. Offensichtlich ist die KI ein Vergrößerungsglas; ein Vergrößerungsglas produziert kein Urteilsvermögen, es vergrößert nur das, was du bereits hast.

Q3: Die zweite ist die Abnahmefähigkeit – Man sieht, ob die KI-Lieferung stimmt, kann man das trainieren?

Yong Liang: Man kann es trainieren, und man muss es trainieren, denn wenn die KI scheitert, sieht es nicht so aus wie Anfänger sich vorstellen („auf den ersten Blick falsch“), sondern „zu 80 % richtig“.

Das ist der Punkt, den ich am stärksten betonen möchte. Das Gefährlichste an dem, was die KI liefert, sind nicht die offensichtlichen Fehler – die sieht jeder. Es ist, dass es zu 80 % falsch und zu 20 % richtig ist, und die 80 % Fehler an den Stellen versteckt sind, die am professionellsten aussehen. Letztes Jahr hatten wir ein Projekt, in dem die KI einen Codeabschnitt zur Abstimmung der Krankenversicherungskasse generierte. Die logische Struktur war wunderschön, die Kommentare waren standardisierter als die meiner Senior-Ingenieure, beim Review ging es fast im Sekundentakt durch. Vor dem Go-Live lief ich wie üblich die Abnahmeliste durch; auf der Liste stand ein Punkt: „Ist die Buchungsrichtung der Abstimmungsdifferenz für Erstattungsszenarien berücksichtigt?“. Ein Check ergab: Falsch. Die KI hatte die Buchung nach „Zahlungsrichtung“ geschrieben, im Erstattungsszenario war die Richtung komplett umgekehrt. Dieser Fehler wäre ohne diesen Check-Punkt auch nach zehnmaligem Review nicht unbedingt aufgefallen, weil jede Zeile „richtig aussah“.

Die Abnahmefähigkeit ist genau dagegen gerichtet. Die Abnahmeliste in meinem Team hat jetzt über vierzig Punkte, nach Modulen kategorisiert: bei Datenklasse Prüfung von Kennzahlen und Grenzwerten, bei Schnittstellenklasse Prüfung von Idempotenz und Timeouts, bei Prozessklasse Prüfung von Ausnahmezweigen und Rollback-Pfaden. Hinter jedem Listenpunkt steht ein echter Unfall. Die erste Sache für neue Mitarbeiter ist nicht das Lernen von Codestandards, sondern das Auswendiglernen dieser Liste und das Lesen von Unfall-Reviews. Nach einem halben Jahr ist ihre Immunität gegen KI-Outputs aufgebaut – nicht, dass sie der KI nicht vertrauen, sondern dass sie wissen, wo sie genauer hinschauen müssen.

Das ist nichts Geheimnisvolles, es ist nur das alte Qualitätsbewusstsein des Software Engineerings, das im KI-Zeitalter neue Kleider bekommen hat. Früher nahm man von Menschen geschriebenen Code ab, jetzt nimmt man von KI geschriebenen Code ab; die Prüfpunkte haben sich geändert, die grundlegende Anforderung an Sorgfalt nicht. Früher brauchte man diese Liste nicht, weil Fehler von Menschen Muster folgten; Fehler der KI sind zufälliger, deshalb ist die Liste jetzt noch wichtiger.

Q4: Die dritte ist die Notfallfähigkeit – Wenn die KI scheitert, kann man den Laden retten, wie zeigt sich das im Alltag?

Yong Liang: Notfallfähigkeit bedeutet „wenn ein Unfall passiert, kannst du ihn unter Kontrolle halten“. Es ist die einzige der drei Fähigkeiten, die man nicht beschleunigen kann, die man nur durch Unfälle füttern kann.

Ich erzähle eine wahre Geschichte. Diesen Frühling ging ein KI-unterstütztes Berichtsmodul live. In der Nacht überschrieb eine Datensynchronisationsaufgabe eine Charge von Feldern zur Krankengeschichte bei historischen Patienten. Der Alarm ging um 23:30 Uhr. Der diensthabende Ingenieur überprüfte eine halbe Stunde lang und urteilte, dass das von der KI generierte Skript für inkrementelle Synchronisation unter Randbedingungen sich anomal verhielt – Bestandsdaten mit Datumslücken wurden nicht erkannt und als neue Daten doppelt geschrieben. Die Bewältigung lief in mehreren Schritten ab: Erst die Synchronisationsaufgabe stoppen, um die Blutung zu stillen, dann die Auswirkung bewerten – wie viele Patienten betroffen sind, welche Abteilungsberichte verunreinigt sind, ob die Daten zurückgerollt werden können. Zum Glück hatte man vor dem Go-Live einen Trick angewandt: Vor der Synchronisation wurde ein vollständiger Snapshot gemacht, der Rollback war in 40 Minuten erledigt, und am nächsten Vormittag ging der Unfallbericht an den Leiter der Informatik und die Klinikleitung. Vom Alarm bis zur Blutstillung insgesamt eine Stunde und 50 Minuten.

Im Nachhinein im Review machten technische Gründe nur 30 % aus, die restlichen 70 % waren menschliche Fehler: Bei der Abnahme hatte niemand daran gedacht, die Synchronisationsskripte mit „schmutzigen Daten“ mit Datumslücken zu testen – das ist die in Q3 erwähnte Abnahmeblindheit; im Go-Live-Prozess fehlte der Notfallschritt „Parallelabgleich am ersten Tag“. Seitdem haben wir in allen von der KI generierten Modulen, die Datenschreibvorgänge beinhalten, im Go-Live-Prozess zwei Zwänge hinzugefügt: Parallelabgleich am ersten Tag und vollständiger Snapshot. Diese beiden Punkte sind die Konkretisierung der Notfallfähigkeit: Eingestehen, dass die KI Fehler macht, und vorher proben, was man tut, wenn sie fehlerhaft ist.

Der Kern der Notfallfähigkeit ist nicht Technik, sondern psychologische Gewohnheit: Immer annehmen, dass es kaputtgeht, und dass du dabei bist, wenn es kaputtgeht. Im Interview frage ich immer: „Was war der schwerwiegendste Online-Unfall, den du erlebt hast?“. Kandidaten, die darauf keine Antwort haben, zögere ich selbst bei hoher technischer Punktzahl. Denn Menschen, die noch nie in eine Falle getreten sind, fehlt die Ehrfurcht vor den Outputs der KI, und Ehrfurcht ist der Ausgangspunkt der Notfallfähigkeit.

Q5: Die Position ist weg, das Handwerk hat sich aufgelöst – wie soll ein normaler Programmierer 2026 eigentlich trainieren?

Yong Liang: Alle drei zusammen trainieren, aber die Reihenfolge ist wichtig: erst Urteilsvermögen, dann Abnahmefähigkeit, die Notfallfähigkeit wächst mit den Unfällen von selbst.

Konkret vier umsetzbare Tipps. Erstens: Mach „zuerst drei Zeilen schreiben“ zur Muskelgedächtnis: Bevor du die KI nutzt, schreibe klar, was du willst, was du nicht willst und was als Erfolg zählt. Dieser Schritt trainiert das Urteilsvermögen, die Kosten sind am geringsten, die Wirkung am schnellsten, die Trennlinie bei den neuen Leuten in meinem Team zeigt sich hier. Zweitens: Erstelle dir eine persönliche Abnahmeliste, kopiere nicht die von anderen – jeder Punkt muss einer eigenen Falle entsprechen, in die du getreten bist. Fang mit 5 Punkten an zu sammeln, nach einem halben Jahr hast du 20, und du bist der Mensch im Team, der KI-Outputs am genauesten einschätzen kann. Die Orte, wo die KI Fehler macht, haben eine starke persönliche Relevanz: Die Module, die du viel nutzt, das Business, für das du verantwortlich bist, da werden die Fallen wiederkehren.

Drittens: Nimm aktiv Arbeiten mit Rollback-Anforderung an. Datenmigration, Systemwechsel, Batch-Jobs – diese Arbeiten haben eine hohe Unfalldichte und sind das Schlachtfeld, um Notfallfähigkeit zu trainieren. Hab keine Angst, die Schuld zu übernehmen; Schuld übernommen zu haben ist ein Vermögen, die wertvollste Zeile in meinem Lebenslauf ist nicht, welches Projekt gelungen ist, sondern welcher Unfall von mir unter Kontrolle gebracht wurde. Viertens: Behandle „der KI beizubringen, wie man arbeitet“ als neues Grundhandwerk und schreibe es in den Alltag: Nach jeder Aufgabe verbringst du zehn Minuten damit zu überlegen, wie man diese Arbeit das nächste Mal der KI überträgt und wie man verifiziert, ob sie es richtig macht. Dieser Schritt integriert das Erbe des Prompt Engineerings – wie man Absichten klar ausdrückt – in die tägliche Arbeit; die Position ist tot, diese Handlung lebt am Anfang und Ende jeder Aufgabe weiter.

Das Gemeinsame beim Training dieser drei Dinge ist: Es kostet kein Geld, keine Kurse, keine Vorlagen, alles basiert darauf, dass man in echten Aufgaben „eingelegt“ wird. Die Leute, die 2023 Vorlagenkurse kauften, wollten Abkürzungen nehmen; 2026 wissen die, die es durchschauen, dass es keine Abkürzungen mehr gibt – das ist keine schlechte Nachricht, es bedeutet, dass der Wettbewerb wieder auf harte Fähigkeiten zurückgeht, und harte Fähigkeiten kann jeder trainieren.

Schluss

Shi Wen: Zum Schluss, fasse diese Folge mit einem Satz zusammen?

Yong Liang: Prompt Engineering ist nicht tot, es hat nur die Hülle „Position“ abgestreift und wurde zu Urteilsvermögen, Abnahmefähigkeit und Notfallfähigkeit – früher hat man jemanden eingestellt, um die KI zu besänftigen, jetzt wird verlangt, dass jeder sie besänftigen kann, durchschauen kann und auffangen kann.

Shi Wen: Diesen Satz schenken wir euch allen. Bis zum nächsten Mal.

[Technische Tiefe] Warum „Prompt-Vorlagen“ dich nicht retten können: Drei Ebenen aus der Perspektive der Modellentwicklung

In dieser Folge haben wir wiederholt gesagt, es habe sich „in ein Handwerk aufgelöst“. Für die technischen Leser zerlege ich, warum Vorlagen zwangsläufig versagen. Das ist keine Mystik, sondern durch die Fähigkeitskurve der Modelle bestimmt.

Erste Ebene: Die generationale Anhebung der Befehlsbefolgung. Das Befehlsverständnis früher Modelle war probabilistisch; änderte man die Formulierung, schwankte das Ergebnis. Das Wesen von Vorlagen war es, mit hoher Redundanz diese Unsicherheit abzufedern – Zauberformeln wie „Du bist ein Senior-Experte, bitte denke Schritt für Schritt“ dienten dazu, dem Modell Beschränkungen aufzuerlegen und den Suchraum zu verkleinern. Aber ab der GPT-4-Generation ging die Befehlsbefolgung von „muss besänftigt werden“ zu „kann normale Sprache verstehen“, und jede nachfolgende Generation verstärkt diese Richtung. Je stabiler die Beschränkung, desto nutzloser die Redundanz, desto kürzer der Lebenszyklus der Vorlage. Vorlagen, die 2023 wertvoll waren, sind 2026 größtenteils zu rituellen Handlungen geworden – harmlos, aber sie erzeugen keinen Qualitätsunterschied mehr.

Zweite Ebene: Kontext-Engineering hat das Prompt-Engineering ersetzt. Der wahre Faktor, der die Output-Qualität bestimmt, ist von „wie man diesen einen Satz sagt“ zu „ob die Materialien für das Modell vollständig sind“ gewandert. RAG, langer Kontext, Skill-Dateien, Gedächtnissysteme – bei diesem Zeug geht es um die Fähigkeit des Retrievals und der Organisation, nicht um die Formulierung. Dieselbe Frage: Wenn man ihr genaue interne Dokumente und Schnittstellenverträge füttert und sie in Klartext fragt, gewinnt sie gegenüber der Variante, wo man ihr nichts füttert, aber mit einer raffinierten Vorlage fragt. Deshalb ist die Arbeit der spezialisierten Prompt Engineers dünner geworden – die Wertschöpfung ist auf die Kontextseite gewandert.

Dritte Ebene: Abnahme und Notfall wurden die neue Hauptkampfseite des Engineerings. Wenn die Generierungskosten gegen Null tendieren, verschiebt sich der Flaschenhals von „wie generiert man Gutes“ zu „wie identifiziert man Schlechtes“. Eval-Systeme, automatisierte Tests, Abgleichsskripte, Rollback-Pläne – diese früheren Nebenrollen von Ops und Qualitätssicherung treten im KI-Zeitalter auf die Bühne. Die Obergrenze der KI-Kapazität eines Teams hängt nicht mehr davon ab, wie schlau das Modell ist, sondern wie dicht die Abnahmepipeline ist und wie schnell der Notfallprozess. Das führt zurück zur Schlussfolgerung dieser Folge: Die drei neuen Fähigkeiten entsprechen drei Ingenieursphasen – Urteil entspricht der Aufgabenzerlegung, Abnahme entspricht der Qualitätspipeline, Notfall entspricht dem Ops-Plan. Die Position ist tot, die Phasen sind noch da und sogar wichtiger geworden.