46 Prozent hören nicht auf, wenn sie aufhören wollten

Ein Entwickler hat eine Nacht durchgeprompted, weil er glaubte, das Modell werde bald abgeschaltet, und vorher noch seine Token verbrauchen wollte. Danach landete er im Krankenhaus. Der Tweet darüber kam auf 4,7 Millionen Impressions, und die häufigste Reaktion darunter war keine Empörung, sondern Ratlosigkeit: Wie kommt man vom Prompten in die Notaufnahme?

Key Takeaways (TL;DR)

• Setze das Zeitlimit auf das Problem, nicht auf den Tag: Wenn ein Prompt-Zyklus nach 15 Minuten keine Lösung bringt, brich ab statt nachzulegen.
• Behandle den Drang nach dem nächsten Prompt als Eigenschaft des Werkzeugs: Der Sog entsteht aus dem Belohnungsmuster, nicht aus deiner mangelnden Disziplin.
• Erzwinge ein hartes Ende, statt es zu planen: Grenzen, die von Willenskraft abhängen, halten genau bis zum nächsten interessanten Fehler.
• Behalte den Teil der Arbeit, der dich noch etwas kostet: Wer nur noch abnimmt, verliert genau die Fähigkeit, die das Abnehmen rechtfertigt.
• Prüfe zuerst, was dein Team belohnt: Individuelle Limits halten nur, wenn Aufhören ohne Nachteil möglich ist.

Basiert auf “The True Cost of AI Coding” von Scott Tolinski. Das Original findest du hier: youtube.com

Der nächste Prompt funktioniert wie ein Spielautomat

Scott Tolinski, Entwickler und Host des Syntax-Podcasts, hat den Fall nicht als Kuriosität abgehakt, sondern eine Umfrage aufgesetzt. Fast 1.300 Antworten kamen in einer Woche zurück. Erste Frage: Wie oft promptest du weiter, obwohl du eigentlich Schluss machen wolltest? 46 Prozent tun das oft oder täglich.

Diese Gruppe wurde mit einer zweiten Frage gekreuzt, der nach dem Schlaf seit dem Umstieg auf KI-Tools.

Das ist die stärkste Korrelation der gesamten Erhebung, und sie beweist keine Ursache: Wer schlecht schläft, sitzt vielleicht ohnehin länger am Rechner, und die Stichprobe ist selbstselektiert. Beide Effekte treten trotzdem gemeinsam auf, bei fast der Hälfte der Befragten.

Die Psychologin Dr. Courtney Tolinski ordnet das Prompt-Muster als variables Belohnungssystem ein, wie es auch Spielautomaten nutzen: Gelegentlich kommt die perfekte Lösung zurück, meistens nicht, und genau diese Erwartungshaltung hält die Motivation hoch, den Hebel noch einmal zu ziehen. „Nur noch einmal” ist damit keine Willensschwäche, sondern die vorhersehbare Reaktion auf ein Belohnungsschema mit Zufallskomponente.

Adam Elmore, seit 17 Jahren in der Softwareentwicklung, hat die Eskalation durchgemacht. Vor dem Burnout stand eine Phase extrem intensiver KI-Nutzung, danach 16 Tage Krankheit, in denen nicht einmal Spazierengehen möglich war. Sein Rückblick auf die Nächte davor:

“I didn’t want the AI ever stalling. If it wasn’t burning tokens, I felt like I was leaving something on the table.”

Das Warnsignal war unspektakulär. Er hatte plötzlich keine Lust mehr, morgens aufzustehen, und zögerte, sein Büro zu betreten. Zum ersten Mal in rund 17 Jahren.

Die gesparte Zeit kommt als Verantwortung zurück, nicht als Freizeit

Die Werkzeuge funktionieren, das ist der unstrittige Teil: Der AI Index Report 2026 weist für Entwickler mit GitHub Copilot 26 Prozent mehr abgeschlossene Pull Requests aus. Nur landet dieser Gewinn nicht dort, wo man ihn vermuten würde. Auf die Frage, wie oft sie das Gefühl haben, mehr produzieren zu müssen, weil KI es eben möglich macht, antworten 65 Prozent mit oft oder täglich. Zwei von drei.

Miranda Heath forscht als Sozialwissenschaftlerin zu Burnout in der Softwareentwicklung und speziell zu Teams mit KI-Agenten. Ihre Beobachtung deckt sich mit der Zahl: Der Arbeitsinhalt verschiebt sich vom Coden zum Reviewen und Entscheiden, die Verantwortung steigt, und darüber liegt der Druck, schneller zu liefern. Dazu kommen Führungskräfte, die die Arbeit im Detail nicht kennen, KI aber für eine Wunderwaffe halten und die Kapazität entsprechend höher ansetzen.

Die Eskalationslogik dahinter ist sauber durchdacht und genau deshalb gefährlich: Wenn eine Konversation mit einem Agenten läuft, gehen auch zwei, und wenn vier gehen, laufen über Nacht beliebig viele weiter. Mark Erikson, Redux-Maintainer mit über 20 Jahren Berufserfahrung, kann diese Kette nachvollziehen und stellt trotzdem die Frage, die darin fehlt: Warum wollen wir so schnell sein, wie viel des Outputs ist brauchbar, und was macht das mit unseren Köpfen? Der eingesparte Aufwand kommt als Review-Last zurück, und Review ist längst der Engpass, wie die Diskussion um Cognitive Debt zeigt.

59 Prozent halten ihre Skills für schlechter, und es sind dieselben mit weniger Spaß

Zwei weitere Fragen betrafen nicht die Umstände, sondern das Handwerk. Werden deine Coding-Fähigkeiten besser, halten sie sich, oder werden sie schlechter? 59 Prozent sehen ihre Fähigkeiten auf der abnehmenden Seite. Und wie viel Freude oder Flow bringt Programmieren heute im Vergleich zu vorher? 54 Prozent sagen: weniger.

Entscheidend ist nicht die Höhe der Werte, sondern ihre Überschneidung: Es sind größtenteils dieselben Personen. Wer glaubt, das Handwerk zu verlieren, hat auch am wenigsten Spaß daran. Das ist eine Selbsteinschätzung und keine Messung, aber der Mechanismus dahinter ist bekannt: Das Gehirn baut ab, was nicht genutzt wird, wie das Instrument aus der Schulzeit, das nach 15 Jahren noch für die Basics reicht, aber für nichts darüber hinaus. Dass dieser Abbau bei KI-Nutzung messbar auftritt, zeigt die Forschung zum Lernverhalten.

Erikson beschreibt das als Identitätsfrage: Er ist Programmierer, und woran er im letzten Jahr am meisten gelitten hat, war das Gefühl, dass KI ihm diese Identität wegnimmt. Seine Antwort war kein Verzicht, sondern ein bewusst langsamerer Workflow: Er nimmt Aufgaben, bei denen er die Richtung vorgibt, lässt Recherche- und Architektur-Dokumente vor dem ersten Edit entstehen, geht den Plan durch, bis beide Seiten dasselbe darunter verstehen, und liest den Code am Ende selbst.

Ein Paper formuliert den Kern präziser als jede Umfrage: KI liefert ein Ergebnis, aber ein Ergebnis ist noch keine Antwort. Es wird erst zu einer, wenn ein Mensch es bewertet und die Verantwortung übernimmt. Wer diesen Schritt auslässt, besitzt den Code nicht.

Das stärkste Gegenargument steckt in den Agenten-Zahlen

Wer als Konsequenz „weniger Agenten” erwartet, findet in den Daten das Gegenteil. Zwei von drei Befragten lassen ein bis zwei Agenten parallel laufen, weniger als 200 kommen auf vier oder mehr. Je mehr Agenten jemand betreibt, desto größer ist die Freude an der Arbeit, und desto seltener kommt das Gefühl auf, Fähigkeiten zu verlieren. Das ist plausibel: Wer fünf Agenten koordiniert, entscheidet mehr über Architektur und weniger über Semikolons.

Der Einwand hat zwei Haken. Erstens nehmen mit der Agentenzahl auch die Schlafstörungen zu, beide Kurven laufen parallel nach oben. Zweitens bleibt offen, ob diese Gruppe ihr Niveau tatsächlich hält oder ob sie schon so viel verloren hat, dass ihr das Urteil darüber fehlt. Bei vier und fünf Agenten ist die Datenbasis ohnehin dünn.

Dass Burnout kein Automatismus ist, zeigt Aaron Francis, VP of Marketing and Community bei Laravel. Er hat mit Frau und vier Kindern im Haus bis Mitternacht, manchmal bis zwei Uhr morgens Token verbrannt und ist trotzdem nicht ausgebrannt. Gegengesteuert hat er nicht therapeutisch, sondern geschäftlich: Wenn jeder andere Entwickler dieselben Möglichkeiten hat, ist es kein Goldrausch. Statt 40 Produkte in die Breite zu bauen, ging er bei einem oder zwei in die Tiefe, dort also, wo er einen echten Vorsprung hat. Wer nicht damit rechnet, dass ihm morgen jemand zuvorkommt, kann schlafen gehen.

Grenzen setzen ist eine Frage der Arbeitsbedingungen

Die Regeln von Aaron Francis wirken, weil sie nicht von der Tagesform abhängen. Das Bürolicht geht um 17 Uhr aus, und im Dunkeln sitzt niemand freiwillig weiter. Am Wochenende ist er Vater und öffnet das Notebook nur, wenn die Kinder schlafen. Prompt-Apps hat er vom Telefon verbannt, feste Termine mit Familie und Freunden stehen im Kalender.

Nur arbeitet er für sich selbst. Niemand schreibt ihm eine Deploy-Quote vor, niemand zählt seine Pull Requests. Jede dieser Grenzen setzt voraus, dass Aufhören ohne Nachteil möglich ist. Genau dort wird die Datenlage unangenehm: Laut AI Index Report 2026 liegt die Beschäftigung von Softwareentwicklern zwischen 22 und 25 Jahren knapp 20 Prozent unter dem Höchststand von 2022, während jede Altersgruppe über 30 im selben Zeitraum gewachsen ist. In den Jobs mit der höchsten KI-Exposition liegt der Rückgang gegenüber den am wenigsten exponierten bei rund 16 Prozent.

Der Bericht ordnet das vorsichtig ein, und das gehört dazu: Die Arbeitslosigkeit stieg in diesem Zeitfenster über alle Jobkategorien hinweg, in den am wenigsten KI-exponierten Bereichen sogar stärker. Ein Beweis, dass KI diese Stellen gestrichen hat, ist die Zahl nicht. Für die Frage nach dem Feierabend ist das zweitrangig: Wer 23 ist und den Eindruck hat, die Leiter werde hinter ihm eingezogen, promptet nachts weiter, egal welches Limit er sich vorgenommen hat. Dieser Druck kommt von oben, und das Muster ist aus der FOMO-Ökonomie bekannt: Nicht die Entwickler haben zuerst Angst, sondern die Ebene, die den KI-Invest rechtfertigen muss.

4 Schritte zur Umsetzung

1. Zeitlimit auf das Problem setzen, nicht auf den Tag: 10 bis 15 Minuten pro Prompt-Zyklus. Kommt die Lösung nicht, wird abgebrochen und das Problem anders angegriffen. Ein Tageslimit greift zu spät, weil die letzten drei Prompts immer die interessanten sind.
2. Ein hartes Ende bauen, das keine Disziplin braucht: Bürolicht auf Zeitschaltuhr, Prompt-Apps vom Telefon, feste Termine im Kalender, die andere Menschen betreffen. Grenzen, die nur im Kopf existieren, verlieren gegen einen halb gefixten Bug.
3. Einen Arbeitsanteil behalten, den du selbst fährst: Ziel und Plan formulierst du, Architektur-Dokumente entstehen vor dem ersten Edit, und den Code liest du selbst. Das ist langsamer, und genau das ist der Punkt.
4. Prüfen, wonach dein Team gemessen wird: PR-Anzahl, Cycle Time, Token-Nutzung. Wenn Output belohnt und Aufhören bestraft wird, ist das kein Selbstkontrollproblem, sondern ein Thema fürs nächste Team-Meeting. Und rede darüber mit Menschen, nicht nur mit dem Modell.

Für Tokens gibt es ein Budget und für Pull Requests eine Kennzahl. Für die Frage, wann ein Entwickler aufhören darf, gibt es beides nicht.