Bloomberg behauptet, KI-Programmierung verursacht Produktivitäts-Panik. Sie diagnostizieren die falsche Krankheit.
Bildschirm leuchtet im Dunkeln, alle anderen sind schon seit Stunden weg. Scrolle durch Tech-Twitter, als Bloomberg zuschlägt: "Claude Code und die große Produktivitätspanik von 2026."
Ich lese den ganzen Artikel. Und ich hatte diese gespaltene Reaktion, die man bekommt, wenn ein Arzt deine Symptome perfekt beschreibt und dann das falsche Medikament verschreibt. Ja, der Schmerz ist real. Nein, deswegen tut es nicht weh.
Bloomberg schreibt 3.000 Wörter über AI-Agenten, die zu viel Code zu schnell produzieren. Sie erwähnen nicht ein einziges Mal, dass niemand den Agenten sagt, was sie produzieren sollen. Dreitausend Wörter über eine Krankheit, und sie vergessen den Erreger.
TL;DR - Bloombergs "Produktivitätspanik"-Artikel trifft die Symptome, aber versaut die Diagnose. Die Panik kommt nicht daher, dass AI zu schnell schreibt. Sie kommt vom Fehlen von Spezifikationen. Vibe-Coding ohne Verträge produziert Code mit 2,74x mehr Sicherheitslücken, macht erfahrene Entwickler 19% langsamer (während sie denken, sie sind 24% schneller), und erzeugt eine 40%ige Wahrnehmungs-Realitäts-Lücke. Die Lösung ist nicht, deine Agenten zu verlangsamen. Es ist, ihnen zu sagen, was sie bauen sollen, bevor sie anfangen zu bauen.
Die Symptome sind real. Die Ursache liegt woanders.
Ich führe meine eigenen Projekte. Kein VP, der mir wegen Agent-Auslastungsraten im Nacken sitzt. Und trotzdem hat mich AI den größten Teil von 2025 langsamer gemacht.
Nicht auf dem Papier. Auf dem Papier sah alles unglaublich aus. Features in Stunden ausgeliefert. Commits häufen sich. Das Git-Log sah aus, als hätte ich ein Fünfer-Team. Aber ich debuggte mehr als ich baute. Ich las Code, den ich in meinen eigenen Repos nicht erkannte. Ich verbrachte den Dienstag damit zu reparieren, was Montags "produktive" Session kaputt gemacht hatte.
Wenn du in dieser Schleife warst, weißt du bereits, dass der Bloomberg-Artikel etwas Wahres dran hat.
Eine UC Berkeley-Studie verfolgte eine 200-Personen-Organisation und fand heraus, dass selbst als Mitarbeiter Arbeit an AI-Agenten auslagerten, sie länger arbeiteten. Die Forscher nennen es "Task-Expansion". Die AI erstellt Output, der Output erstellt Aufräumarbeiten, das Aufräumen erstellt Überstunden. Ein VP bei DocuSketch sagte Bloomberg, er brauche "noch ein paar AI-Interaktionen vor dem Schlafengehen", was wie Sucht klingt, aber wie Angst liest, wenn du dir je Sorgen gemacht hast, bei einem Tool zurückzufallen, das alle anderen schon zu beherrschen scheinen.
Also ja. Die Panik ist real.
Aber Bloomberg hört bei "Agenten erzeugen Druck" auf und stellt nie die Anschlussfrage: warum erzeugt mehr Output mehr Arbeit?
Weil der Output keine Spezifikation hat. Das ist die ganze Antwort. Ein Agent ohne Beschränkungen ist ein Junior-Dev mit unendlicher Energie und null Kontext. Er wird produzieren. Er wird selbstbewusst produzieren. Und was er produziert wird fast richtig sein, was schlimmer ist als falsch, weil du es nicht bemerkst, bis es die Produktion tut.
Bloomberg sagt das nie. Teilweise weil Bloomberg ein Finanzmedium ist und die Zielgruppe nicht der Ingenieur ist, der um 2 Uhr morgens debuggt, sondern der Investor, der ein Portfolio neu kalibriert. Dieser Artikel erschien sechs Tage nachdem Claude Code Security Cybersecurity-Aktien um 5–9% abstürzen ließ. Das Timing ist kein Journalismus. Es ist Marktkontext.
Und teilweise weil die echte Ursache zu benennen, "niemand schreibt Specs vor dem Prompting", eine langweilige Schlagzeile macht. "Produktivitätspanik" verkauft Abonnements. "Schreibt bessere Prompts" nicht.
Bloomberg verkauft die Panik. Niemand verkauft die Lösung.
Die Daten, mit denen Bloomberg hätte anfangen sollen
Alle profitieren davon, die Panik am Leben zu halten. "AI-Transformation"-Berater bekommen einen neuen Markt. Governance-Anbieter bekommen ein neues Segment. Finanzmedien bekommen Engagement. Senior-Devs bekommen einen Grund, sich unersetzlich zu fühlen. Niemand hat einen Anreiz darauf hinzuweisen, dass die Lösung langweilig ist.
Aber die Daten zeigen trotzdem auf langweilig.
METR führte eine der wenigen rigorosen Studien dazu durch, eine randomisierte kontrollierte Studie mit 16 erfahrenen Open-Source-Entwicklern über 246 echte Aufgaben. Entwickler mit AI-Tools waren 19% langsamer als ohne. Aber hier ist der Teil, der dich erschrecken sollte: sie nahmen sich selbst als 24% schneller wahr. Das ist eine 40%ige Lücke zwischen Realität und dem, was dein Gehirn dir sagt.
Ich kenne diese Lücke. Ich habe in ihr gelebt. Code erscheint auf dem Bildschirm, dein Gehirn registriert "Fortschritt", und du überspringst die Verifikation, weil sich alles schnell anfühlt. Du wirst deine eigene schlechteste QA-Abteilung.
Veracode testete AI-generierten Code über mehr als 100 LLMs in vier Sprachen. 45% enthielten Sicherheitslücken. 2,74 mal mehr Schwachstellen als von Menschen geschriebener Code. Und nicht weil die Modelle dumm sind. Niemand spezifizierte die Beschränkungen. Ein LLM wird fröhlich einen Login-Flow ohne Rate-Limiting, ohne Input-Sanitization, mit Credentials im Klartext bauen. Es wurde ihm nicht gesagt, es nicht zu tun. Also tat es es nicht.
CodeRabbit analysierte über 10 Millionen Pull-Requests und fand heraus, dass AI-Code 2,25 mal mehr Business-Logic-Bugs produziert. "Business Logic" ist buchstäblich das Zeug, das eine Spezifikation definiert, Dinge wie Benutzerberechtigungen, Edge-Cases, Zustandsübergänge. Genau das Territorium, das Vibe-Coding überspringt, weil "die AI wird es schon rausfinden."
Und Anthropics eigene Studie vom Januar 2026 fand heraus, dass Entwickler mit AI 17% schlechter bei Post-Task-Quizzes abschnitten. Größte Lücke: Debugging-Fragen. Wir verstehen weniger von dem, was wir ausliefern. Wir hörten auf zu definieren, was wir erwarten, bevor wir Enter drücken, und dann sind wir überrascht, dass das Ergebnis nicht passt.
Keine dieser Zahlen sagt "AI ist gefährlich." Jede einzelne sagt "AI ohne Spec ist gefährlich."
Bloomberg verwechselte das Tool mit der Nutzung. Diese Studien haben Grenzen, METR waren 16 Entwickler, Veracode testete verschiedene LLMs mit wer weiß welchen Prompts. METRs eigene Nachfolgestudie vom Februar 2026 deutet auf Beschleunigungen hin, während sich Tools weiterentwickeln, aber ihre Daten zeigen auch, dass die Wahrnehmungslücke bestehen bleibt, Entwickler können immer noch nicht sagen, wie schnell sie tatsächlich sind. Die genauen Zahlen sind diskutierbar. Die Richtung nicht.
Wie ich ein Fremder in meiner eigenen Codebase wurde
Hier ist meine echte Geschichte und sie ist dümmer als du denkst. Der Typ, der über Prompt-Verträge schreibt, wurde von der Nichtnutzung eines solchen zerstört. Schuster und seine Kinder, barfuß, das ganze Klischee.
Ich baute ein Dashboard für eine meiner SaaS-Apps. Standard-Zeug: Metriken-Seite, Convex-Backend, Clerk-Auth, ein paar Charts. Die Art von Sache, die ich oft genug gemacht habe, um gefährlich zu sein. Das war bevor ich Prompt-Verträge formalisierte, damals als jede Session pure Vibes war.
Ich öffnete Claude Code im vollen Vibe-Modus. Spezifizierte die Architektur nicht. Listete die Bibliotheken nicht auf, die ich wollte. Einfach "bau mir ein Dashboard mit Auth und Charts." Zwanzig Minuten später, funktionierende Seite. Daten fließen. Charts rendern. Ich fühlte mich, als hätte ich einen Cheat-Code freigeschaltet.
Drei Tage später brauchte ich einen Filter hinzuzufügen. Einfaches Feature. Sollte 10 Minuten dauern.
Ich öffnete die Codebase und fand TanStack Query überall.
Ich nutze TanStack Query nicht. Ich habe TanStack Query nie genutzt. Ich wusste kaum, was TanStack Query war. Claude hatte entschieden, dass mein Data-Fetching-Layer ein Caching- und Synchronisations-Framework brauchte, das ich nie berührt hatte, es in jede Komponente verdrahtet und das ganze State-Management darum gebaut.
Das Dashboard funktionierte. Ich konnte nicht erklären warum. Ich konnte es nicht modifizieren ohne etwas kaputt zu machen, weil ich die Abstraktionen nicht verstand, die es zusammenhielten. Einen Datumsfilter hinzuzufügen bedeutete, TanStack Querys Invalidation-Patterns zu verstehen, und ich googelte Grundkonzepte über ein Tool in meinem eigenen Projekt wie ein Tourist, der einen Sprachführer in einem Land liest, in dem er angeblich lebt.
Zwei Tage ein Framework zu lernen, das ich nie gewählt hatte, um Code zu modifizieren, den ich angeblich geschrieben hatte, in einem Projekt, das ich angeblich besitze. Eigentlich, lass mich das umformulieren. Zwei Tage die Steuer auf eine Entscheidung zu zahlen, die ich nie getroffen hatte.
Eine drei-Zeilen-Spec hätte das alles verhindert: "Nutze fetch + Convex-Hooks für Daten. Keine externen State-Management-Bibliotheken. Halte es einfach genug, dass ich es um 1 Uhr morgens ohne Dokumentation debuggen kann."
Das war kein Einzelfall. In den nächsten zwei Monaten verfolgte ich meine Sessions. Das Muster war immer identisch. Agent mit vagem Ziel starten. Code bekommen, der kompiliert. Deployen. Die Lücke zwischen dem, was ich meinte und was ich sagte, entdecken. Etwas debuggen, von dem ich nicht mal wusste, dass es da war.
Das Schlimmste ist nicht die verschwendete Zeit. Es ist das Gefühl. Du hast es gebaut, aber du besitzt es nicht. Dein Repo sieht aus wie das Haus von jemand anderem. Die METR-Daten über Entwickler, die denken, sie sind schneller, ergeben plötzlich perfekten Sinn, du glaubst wirklich, du lieferst aus, bis du etwas ändern musst.
Der Agent war nicht das Problem. Mein Prompt war es.
Die Lösung: Verträge, nicht Unterhaltungen
Hier hörte ich auf, Claude Code wie einen Chatbot zu behandeln und fing an, es wie einen Auftragnehmer zu behandeln, der absolut dein Badezimmer mit Marmor fliesen wird, wenn du nicht Keramik spezifizierst.
Vor jeder Session: was der Agent produzieren muss, was er nicht anfassen darf, wie ich das Ergebnis verifiziere. Ich nenne es einen Prompt-Vertrag. Nicht weil er rechtlich bindend ist, sondern weil er die gleiche Klarheit erzwingt. Beide Parteien kennen den Umfang. Niemand wacht mit einem Framework auf, das er nicht eingeladen hat.
Ich baute das vollständige Prompt-Verträge-Framework nach genug solcher Katastrophen. Die Kurzversion: Ziel, Beschränkungen, erwartetes Output-Format, Fehlerbedingungen. Vier Felder. Neunzig Sekunden zum Schreiben. Spart Stunden des Debuggings und null Überraschungs-Frameworks.
Ich bin nicht der Einzige, der darauf kommt.
Ein arXiv-Paper vom Januar 2026 dokumentierte ein Finanzdienstleistungs-Team, das von freiform AI-Prompting zu spec-first Workflows mit OpenAPI-Verträgen wechselte. Integrations-Zykluszeit fiel um 75%. Die AI wurde nicht schlauer. Die Menschen wurden klarer.
Kent Beck, der Typ hinter TDD und Extreme Programming, veröffentlichte "Augmented Coding: Beyond the Vibes", wo er eine produktions-konkurrenzfähige B+ Tree-Bibliothek in Rust mit strukturiertem AI-Prompting baute. Sein Framing: Vibe-Coding produziert Code, der funktioniert. Strukturiertes Prompting produziert Code, den du warten kannst. Da ist ein Unterschied, und er zeigt sich in Monat drei.
Und genau das fand Red Hat heraus. Vibe-codierte Projekte stoßen konsistent an eine Wand um die Drei-Monats-Marke. Der Code funktioniert, dann tut er es nicht, und niemand kann erklären warum, weil die ursprünglichen Prompts weg sind und die Codebase keine dokumentierte Absicht hat. Nur Vibes. Ehemalige Vibes. Tote Vibes.
Prompt-Verträge werden dich bei der Exploration nicht retten. Wenn du wirklich nicht weißt, was du baust, vibe weg. Schnell, billig, wegwerfbar. Das Problem beginnt, wenn Vibe zum Standard für alles wird, einschließlich Code, der in die Produktion geht und Code, auf den andere Menschen angewiesen sind. Das ist keine Exploration. Das ist Fahrlässigkeit mit extra Schritten.
Specs sind keine Bürokratie. Sie sind der kürzeste Weg zum Ausliefern.
Die Leichen, die Vibe-Coding hinterlassen hat
Bloomberg berichtet über Kapital. Diese Geschichten handeln von Handwerk. Verschiedene Panik, gleiche Grundursache.
Daniel Stenberg wartet cURL, das Tool, das auf ungefähr 20 Milliarden Geräten läuft. Im Juli 2025 dokumentierte er, dass 20% der Bug-Bounty-Einreichungen AI-generierter Schrott waren. Selbstbewusste, detaillierte, komplett erfundene Schwachstellen-Reports. Jeder einzelne kostete 3–4 Security-Team-Mitglieder stundenlang. Bestätigungsrate brach unter 5% zusammen. Er schloss das ganze Programm im Januar 2026. Seine Worte: "Zeit und Energie, die komplett verschwendet wird, während sie auch unseren Lebenswillen beeinträchtigt."
Die Reporter waren nicht böswillig. Sie richteten eine AI auf cURL ohne Spec dafür, was eine echte Schwachstelle ausmacht. Das Modell generierte plausiblen Müll. Gleiches Muster wie mein TanStack-Desaster, nur auf Ökosystem-Ebene.
Dann ist da Adam Wathan, der Tailwind CSS erschuf. Januar 2026: 75% seines Engineering-Teams, entlassen. Tailwind war populärer denn je, mehr Downloads, mehr Projekte, mehr Adoption. Umsatz um 80% gesunken. Docs-Traffic um 40% gesunken. AI-Tools haben Tailwind auswendig gelernt und generieren Klassen inline, also besucht niemand mehr die Docs. Das Geschäftsmodell scheiterte nicht. Es wurde von AI ohne Attribution, Kontext oder Bezahlung konsumiert. Ich denke oft über dieses hier nach, weil es bedeutet, du kannst das Adoptions-Spiel gewinnen und trotzdem verlieren 💀
Mitchell Hashimoto, Mitgründer von HashiCorp (baute Terraform und Vagrant), führt Ghostty, einen Terminal-Emulator. Bis Januar 2026 ertrank er in AI-generierten Drive-by-Pull-Requests. Geringer Aufwand, ungeprüft, kaputt. Seine Antwort: permanente Sperren. Sein Framing: "Das ist keine Anti-AI-Haltung. Das ist eine Anti-Idiot-Haltung."
Drei Fälle. Drei Domänen. Eine Struktur: Output generiert ohne Definition dessen, was "gut" bedeutet. Code ohne Verträge. Reports ohne Kriterien. PRs ohne Standards.
Die AI produzierte Volumen. Die Menschen ertranken darin. Bloomberg berichtete über nichts davon, weil Stenberg, der eine Bug-Bounty schließt, keine Aktienkurse bewegt. Aber wenn du Dinge baust, ist das die Panik, die wirklich wichtig ist.
Wenn du Struktur über Vibes angewandt auf Tooling sehen willst, gilt das gleiche Prinzip: definiere die Schnittstelle, bevor du das Feature baust.
Was Bloomberg hätte schreiben sollen
Die "Produktivitätspanik" ist kein AI-Problem. Es ist ein Übergangsproblem. Wir sind in der Phase, wo jeder das Tool hat und niemand die Methode.
Bloomberg benennt das nicht, weil ein Artikel über Panik ohne Lösung mehr Engagement generiert als ein praktischer mit einer Lösung. Beschreibe die Angst, verkaufe das Abonnement, mach weiter. Das ist das Modell. Ein diagnostischer Artikel mit einer Heilung ist weniger teilbar als einer, der jeden Leser seine eigene Angst darauf projizieren lässt.
Denk darüber nach, was "AI-Müdigkeit" tatsächlich beschreibt. Der DocuSketch-VP, der sagt, er braucht mehr AI-Interaktionen vor dem Schlafengehen, ist nicht süchtig. Er hat Angst. Wenn ich dieses Tool nicht meistere, wird jemand, der es tut, meinen Platz einnehmen. Bloomberg rahmt das als Wellness-Problem ein, weil "Arbeiter haben Angst vor Obsoleszenz" ein härterer Verkauf an die C-Suite-Zielgruppe ist, die für Bloomberg Terminal-Zugang zahlt.
Die einzige echte Antwort auf Ersetzbarkeit ist Kompetenz. Nicht Panik. Nicht längere Stunden. Nicht mehr Prompts vor dem Schlafengehen.
Kompetenz bedeutet zu wissen, wie man das Tool lenkt, nicht nur wie man es bedient. Es bedeutet, eine drei-Zeilen-Spec zu schreiben, bevor man einen Agenten startet. Es bedeutet, deine Architektur-Entscheidungen zu besitzen, anstatt sie drei Tage später im Framework von jemand anderem zu entdecken. Es bedeutet, AI wie einen Auftragnehmer zu behandeln, nicht wie einen Mitgründer.
Das ist nicht kompliziert. Es ist nur nicht viral 🤷♂️
Die Panik ist real. Die Diagnose ist falsch. Und der Artikel ist das Produkt.
Ich schreibe darüber, was tatsächlich funktioniert, wenn du mit AI-Agenten baust, kein Hype, kein "10x deine Produktivität"-Unsinn, nur das Zeug, das ich getestet habe und das Zeug, das kaputt ging. Der Subscribe-Button ist genau da, wenn das dein Ding ist.
*Das Cover-Bild ist AI-generiert, weil meine Design-Fähigkeiten 2019 beim Zentrieren eines Divs ihren Höhepunkt erreichten und es seitdem bergab ging.
Produktivitäts-Panik mit KI-Agenten? Die Lösung liegt nicht im Bremsen, sondern im präzisen Spezifizieren. Unsere wöchentliche Newsletter-Einblicke zeigen dir, wie.