Der KI-Goldrausch ist leise woandershin gezogen

Vor ein paar Wochen bin ich zufällig in Vercels State of Vibe Coding Report gefallen. Ich war eigentlich auf der Suche nach einer Statistik zu etwas ganz anderem. Vierzig Minuten später steckte ich tief in einem Stapel völlig zusammenhangloser Tabs:

• Ein Hacker-News-Thread, der behauptet, KI-Prompt-Engineering sei tot
• Ein weiterer, der darauf besteht, dass Vibe Coding Cursor getötet hat
• Ein LogRocket-Beitrag, der das Gegenteil vertritt – dass wir Prompt Engineering von den Toten zurückholen sollten

Nichts davon war das, was ich lesen wollte. All das war interessanter als das, was ich lesen wollte.

Alle kreisen um dieselbe Verschiebung

Was mich packte, war keine einzelne Behauptung. Es war ein Muster. Alle kreisten um dieselbe Verschiebung. Niemand konnte sich darauf einigen, wie man sie nennt.

• Der eine nannte es Vibe Coding.
• Der nächste nannte es Agenten-Orchestrierung.
• Ein dritter bestand darauf, dass die eigentliche Geschichte sei, wie MCP leise tragfähiger wird als der Prompt selbst – es gibt bereits ein kleines Ökosystem von Repos, das genau um diese Idee gebaut ist.

Dann drifteten die Antworten weiter – zu Observability, Eval-Pipelines und Berechtigungsgrenzen. Auf dem Papier hat nichts davon etwas gemeinsam. Code schreiben, Architektur entwerfen und ein System absichern stehen üblicherweise unter verschiedenen Jobtiteln. Aber je mehr Threads ich folgte, desto mehr sahen sie aus wie Räume im selben Haus.

Zwei Jahre lang war die interessante KI-Geschichte die vom Reden mit Modellen. Als ChatGPT zum ersten Mal auftauchte, zählten die Worte, die man wählte, tatsächlich. Stell einen Satz um, und die Antwort konnte von nutzlos zu brillant kippen. Die Leute behandelten das wie ein neu entdecktes Handwerk. Sie sammelten Prompts. Sie verglichen Notizen. Sie bauten persönliche Bibliotheken von Formulierungen, die funktionierten. Das war kein Hype. Eine Weile war das Gespräch mit dem Modell wirklich das Produkt. Gut in diesem Gespräch zu werden, war eine echte Fähigkeit.

Der Engpass ist nicht verschwunden – er ist umgezogen

Diese Annahme altert schnell. Öffnen Sie Cursor oder Claude Code heute und achten Sie darauf, was Sie nicht mehr tun. Sie grübeln nicht mehr über einem Prompt. Sie beschreiben, was Sie wollen, beantworten eine oder zwei Rückfragen, und ein funktionierendes Feature erscheint. Manchmal holprig. Manchmal beunruhigend poliert. So oder so kommt es schnell genug, dass die Konversation längst weitergezogen ist. Das Modell wurde gut genug darin, einen ersten Entwurf von Software zu produzieren – und der interessante Engpass hat gepackt und ist umgezogen. Nicht verschwunden. Umgezogen. Dieser Unterschied zählt, denn ein verschwundener Engpass und ein verlegter sehen aus der Distanz identisch aus – und verhalten sich aus der Nähe völlig unterschiedlich.

Eine Zeile aus diesem Vercel-Report ist mir hängen geblieben: Englisch wird zu einer der am schnellsten wachsenden Programmiersprachen, weil mehr Menschen Software beschreiben, als sie Zeile für Zeile zu implementieren. Es liest sich wie eine Schlagzeile, gebaut für Retweets. Wer aber genug Zeit mit dem aktuellen Tooling verbringt, dem fällt das Widersprechen schwer. Der Teil, den man leicht übersieht: Die interessante Veränderung ist nicht, dass Englisch Python ersetzt. Es ist das, was mit allem passiert, das um die Implementierung herum sitzt, sobald Implementierung billig wird. Kosten verteilen Aufmerksamkeit eher um, als dass sie sie beseitigen. Man hört nicht auf, sich für das zu kümmern, was billig geworden ist – man muss nur nicht mehr darüber nachdenken. Diese frei gewordene Aufmerksamkeit muss irgendwo landen.

Wir haben dieses Stück schon einmal gesehen

Wir haben genau diese Umverteilung schon einmal erlebt, bei einer anderen Ressource. Cloud Computing hat Infrastruktur nicht abgeschafft. Es machte das Hochfahren von Infrastruktur so reibungslos, dass Unternehmen plötzlich weit mehr davon bereitstellten, als jedes Rechenzentrumsbudget erlaubt hätte. Niemand hatte FinOps geplant – die Grundlage dahinter wurde nicht einmal vor 2019 gegründet, Jahre nachdem die Beschränkung, die sie adressiert, längst gegriffen hatte. FinOps tauchte auf, als die alte Beschränkung – wie schwer es war, an einen Server zu kommen – sich aufgelöst hatte. Eine neue Beschränkung nahm ihren Platz ein: herauszufinden, wohin all die Ausgaben eigentlich flossen. Überfluss beseitigt das schwere Problem nicht. Er verlegt es dorthin, wo der Überfluss entsteht.

KI-Coding-Tools spielen dasselbe Stück – vielleicht ist das der Grund, warum Gespräche darüber immer wieder dorthin driften, wo niemand hinwollte. Jemand zeigt ein Feature, das Cursor in zwanzig Minuten gebaut hat. Drei Antworten später debattieren die Leute über Kontextfenster – in Threads, die stark an diesen hier erinnern. Oder darüber, warum ein Agent dieselbe API dreißigmal aufrief, weil niemand eine Abbruchbedingung definiert hatte. Oder darüber, wie man überhaupt bewertet, ob der Output gut war. Ich habe diese Abschweifungen früher als Fokusverlust des Threads gelesen. Das sehe ich nicht mehr so. Die Abschweifung war das eigentliche Thema. Die Demo war nur die Tür hinein.

Systeme, die nicht stillstehen

Was dafür sorgt, dass sich das weniger wie Beschleunigung anfühlt und mehr wie eine wirklich andere Art von Problem, liegt im Verhalten dieser Systeme. Traditionelle Software ist deterministisch – gleiche Eingabe, gleiche Ausgabe, solange nichts von außen dazwischenkommt. Sprachmodelle stehen nicht so still:

• Ihre Ausgaben verschieben sich.
• Die Modelle selbst werden einem unter den Füßen weg aktualisiert.
• Sie sind zunehmend mit Tools, APIs und anderen Agenten verdrahtet, die in Echtzeit eigenständige Entscheidungen treffen.

Nichts davon macht sie unzuverlässig, genau genommen. Es bedeutet: Das System, das um sie herum gewickelt ist, trägt jetzt Gewicht, das früher im Code selbst wohnte. Ein Prompt kann an einem Nachmittag funktionierenden Code erzeugen. Ein Produktionssystem muss sich sechs Monate später noch erklären können – wenn jemand fragt, warum ein autonomer Workflow eine Rückerstattung genehmigt hat, die er nicht hätte genehmigen dürfen, oder eine Information ausgespuckt hat, die er nicht hätte ausspucken dürfen. Das sind nicht dieselben Probleme. Und sie werden nicht mit derselben Fähigkeit gelöst.

Vom Overhead zur eigentlichen Designarbeit

Je länger ich mit diesem Gedanken sitze, desto weniger fühlt es sich wie eine Revolution der Programmierung an. Es fühlt sich eher an wie eine Umverteilung dessen, wohin Engineering-Aufwand fließt.

• Boilerplate wird dünner.
• Syntax hört auf, gute Engineers von großartigen zu trennen.
• Implementierung wird schneller, bis sie sich fast beiläufig anfühlt.

Währenddessen wandert das, was sich früher wie Overhead anfühlte, weiter nach vorn in den Prozess – Architekturdiagramme, Eval-Frameworks, Fragen danach, wer oder was welche Berechtigung hat. Irgendwann hört es auf, Overhead zu sein. Es wird zur eigentlichen Designarbeit. Observability ist nicht mehr etwas, das man nach einem Incident anschraubt. Es wird Teil dessen, was man von Anfang an baut. Nichts davon kommt in einem Demovideo gut rüber – wahrscheinlich bekommt es deshalb online weniger Aufmerksamkeit als ein Modell, das in neunzig Sekunden eine App schreibt. Es ist auch, soweit ich das beurteilen kann, der Faktor, der am ehesten darüber entscheidet, ob diese App zwei Jahre später noch gesund ist.

Wenn Code aufhört, knapp zu sein – was ist es dann?

Unter all dem hat sich auch noch etwas Leiseres verschoben. Jahrzehntelang war Software teuer genug zu schreiben, dass Unternehmen ganze Teams darum organisierten, mehr davon zu produzieren. Größere Backlogs. Größere Planungszyklen. Mehr Menschen, deren ganzer Job darin bestand, Ideen in Code zu verwandeln. Wenn Code aufhört, knapp zu sein – was wird stattdessen knapp? Mein Instinkt sagt: nicht Engineering-Talent im Abstrakten. Sondern Urteilsvermögen.

• Urteilsvermögen darüber, was überhaupt gebaut zu werden verdient.
• Urteilsvermögen darüber, wo Autonomie wirklich sinnvoll ist – und wo deterministische, handgeschriebene Logik immer noch die sicherere Wette.
• Urteilsvermögen darüber, welche Entscheidungen beim System bleiben und welche immer zu einem Menschen zurücklaufen sollten – egal, wie fähig das Modell in der Demo wirkt.

Nichts davon ist, genau genommen, eine neue Fähigkeit. Sie saß jahrelang im Hintergrund, überschattet davon, wie viel Aufmerksamkeit die Implementierung einst forderte. Erst jetzt wird sie sichtbar, wo die Implementierung leise geworden ist.

Wir stellen immer noch die falsche Frage

Ich glaube nicht, dass wir das mentale Modell, mit dem wir diese Tools vergleichen, wirklich aktualisiert haben. Wir fragen immer noch, welcher Coding-Assistent „besseren Code schreibt". Das ist ungefähr so, als würde man fragen, welcher Cloud-Anbieter eine virtuelle Maschine am schnellsten hochfährt.

Im Moment, auf dem Papier, ist das Claude Fable 5 – das Modell, über das alle reden, seit es im Juni erschienen ist, und der aktuelle Spitzenreiter auf den meisten Coding-Bestenlisten. So sieht dieser Vergleich konkret aus, für alle, die mitzählen:

†SWE-bench Pro nutzt aktiv gepflegte Repos ohne öffentlich durchgesickerte Ground Truth – ein härterer, neuerer Test als SWE-bench Verified. Der Score von GLM-5.2 ist daher nicht direkt mit den Zeilen darüber vergleichbar. Preise und Platzierungen verschieben sich monatlich; dies ist eine Momentaufnahme von Juli 2026, aus Anthropics Preisdokumentation, OpenAI und LLM Stats, das offizielle Model Cards und unabhängige Benchmark-Reproduktionen aggregiert.

Nichts davon ist eine schlechte Frage. Aber alles davon ist eine enge. Sie überspringt fast alles, was passiert, nachdem die VM gebootet ist – oder nachdem das Feature ausgeliefert wurde. Meine Vermutung: Die Unternehmen, die am Ende vorne liegen, werden nicht die mit den schärfsten Prompts sein und nicht einmal die mit dem höchsten Score in dieser Tabelle. Es werden die sein, die außergewöhnlich gut darin geworden sind, das zu betreiben, was die KI bereits für sie gebaut hat: die unglamouröse Arbeit, ein probabilistisches System ehrlich zu halten, wenn es live ist, beobachtet wird und gebraucht wird. Wir sehen dasselbe Muster von der anderen Seite in unserem Automotive-KI-Engagement, wo die Modelle der leichte Teil waren und das Produktionssystem darum herum das eigentliche Projekt.

Das ist eine seltsame Art von Vorteil. Er fotografiert nicht gut. Aber es ist das Muster, über das ich immer wieder stolpere – jedes Mal, wenn ich hinter die Demo schaue.

---

Wenn Sie etwas davon gepackt hat – hier hat es angefangen:

• Vercel – The State of Vibe Coding
• Hacker News – AI Prompt Engineering Is Dead
• Hacker News – Vibe Coding Killed Cursor
• cline/cline – ein Subagent in einer Endlosschleife, keine Abbruchbedingung in Sicht
• LogRocket – das Plädoyer, Prompt Engineering zurückzuholen

Ich schreibe das vor allem auf, damit ich selbst den Faden nicht verliere.