Entwickler, die angefangen haben, GitHub Copilot, ChatGPT oder Cursor zu nutzen, beschreiben oft dieselbe Honeymoon-Phase. Aufgaben, die einst zwei Stunden dauerten, erledigen sich nun in zwanzig Minuten. Boilerplate verschwindet mit einem Tab-Tastendruck. Doch bald taucht in Foren und Slack-Channels eine leisere Beschwerde auf: Erschöpfung. Das Tool schreibt den Code, aber der Prozess selbst zehrt an den Kräften. Das Problem ist nicht der Code an sich. Es ist die Arbeit, ihn zu konsumieren.
Der Flaschenhals, auf den sich niemand vorbereitet hat
Jahrzehntelang war die Begrenzung im Software Engineering die Tippgeschwindigkeit. Egal wie schnell man dachte, die Finger und das Syntaxwissen setzten das Limit. KI-Assistenten haben dieses Limit eingerissen. Sie können hunderte Zeilen über mehrere Dateien hinweg produzieren, noch bevor man den ersten Block fertig gelesen hat. Diese Geschwindigkeit klingt nach Freiheit, erzeugt aber einen unerwarteten Stau. Plötzlich ist der langsamste Teil der Pipeline die Fähigkeit, das, was gerade auf dem Bildschirm erschienen ist, zu lesen, zu verstehen und zu verifizieren. Man ist zum Vollzeit-Code-Reviewer des eigenen Projekts geworden – nur dass der Autor ein Algorithmus ist, der niemals schläft und niemals müde wird.
Diese Umkehrung der Arbeitsweise verändert die Textur einer Coding-Session. Anstatt zwischen Kreation und leichter Verifizierung zu wechseln, steckt man in einem dauerhaften Validierungsmodus fest. Und Validierung ist kein passives Lesen. Es ist eine aktive, von Misstrauen geprägte Analyse. Jeder Variablenname, jede Randbedingung und jede Import-Anweisung muss einen mentalen Filter passieren, weil die KI kein persönliches Risiko trägt. Sie wird nicht um 3 Uhr morgens geweckt, wenn der Production-Job fehlschlägt.
Warum das Gehirn an seine Grenzen stößt
Die Müdigkeit ist keine Faulheit. Es ist eine vorhersehbare Kollision zwischen reißerischem Output und begrenzter menschlicher Bandbreite.
Volumen-Überlastung. Ein typischer KI-Vorschlag kann eine komplette React-Komponente, deren Styling-Logik, Utility-Funktionen und Unit-Tests umfassen – alles in einem Rutsch. Das Arbeitsgedächtnis kann nur eine begrenzte Menge gleichzeitig halten. Wenn der Bildschirm mit Dutzenden neuen Zeilen gefüllt wird, muss das Gehirn sie entweder zu abstrakten Mustern komprimieren oder sie sequenziell scannen. Beide Strategien verbrauchen Aufmerksamkeit. Nachdem man mehrere dieser Blöcke geprüft hat, setzt der mentale Muskelkater ein. Man liest zwar, aber man erfasst den Inhalt nicht mehr wirklich.
Die Vertrauenslücke. KI-generierter Code wirkt autoritär. Die Einrückung ist perfekt. Die Variablennamen sind sinnvoll. Kommentare erscheinen sogar an den richtigen Stellen. Aber Autorität ist nicht gleich Korrektheit. Der Code könnte eine veraltete API verwenden, einen Edge Case bei Null-Eingaben übersehen oder eine subtile SQL-Injection-Schwachstelle einführen. Da man weiß, dass dies passieren kann, kann man den Code nicht nur überfliegen. Man muss jede Return-Anweisung und jeden Logikzweig mit der Wachsamkeit eines Security-Audits prüfen. Dieses Maß an Genauigkeit, über Stunden hinweg aufrechtzuerhalten, ist kognitiv extrem aufwendig. Das ist derselbe Grund, warum Sicherheitskontrollen am Flughafen in kurzen Schichten arbeiten: Dauerhafte Wachsamkeit lässt schnell nach.
Workflow-Mismatch. Die meisten Entwicklungsumgebungen und Teamprozesse setzen immer noch einen menschlichen Rhythmus von „Schreiben, dann Testen“ voraus. Die Codebasis wächst in menschlichem Tempo, und Code-Reviews finden in geplanten Intervallen statt. Wenn die KI in diese Pipeline eingepresst wird, bricht der Flow. Man generiert zwanzig Zeilen, hält inne, um sie zu verifizieren, bittet um eine Überarbeitung, verifiziert erneut, geht zur nächsten Funktion über und verliert dabei den Faden der übergeordneten Architektur. Das ständige Context Switching zwischen kreativer Generierung und skeptischer Validierung erzeugt Reibung. Die IDE wurde für Autoren entwickelt, nicht für Editoren, die unter einem kontinuierlichen Zeitdruck arbeiten.
Die Erschöpfungsspirale
Diese Faktoren füttern einen Kreislauf, der sich im Laufe des Tages verschlimmert.
Der Assistent spuckt in Sekunden eine Feature-Implementierung aus. Dann verbringt man fünfzehn Minuten damit, Imports nachzuverfolgen, die Typkompatibilität zu prüfen und mentale Simulationen von Edge Cases durchzuführen. Nach der dritten oder vierten Runde lässt die Konzentration nach. Man beginnt, Code-Schnipsel zu akzeptieren, die „meistens richtig aussehen“. Fehler schlüpfen durch. Um das zu kompensieren, verlangsamt man sein Tempo, was den anfänglichen Geschwindigkeitsvorteil wieder zunichtemacht. Man beendet den Tag mit mehr Rohcode als gewöhnlich, aber mit weniger Vertrauen in diesen und mit Kopfschmerzen, die darauf hindeuten, dass man härter gearbeitet hat, nicht smarter.
Wenn Geschwindigkeit gefährlich wird
Wenn sich dieses Muster verfestigt, reicht der Schaden über einen schlechten Nachmittag hinaus.
Burnout kommt leise. Er zeigt sich als Unbehagen beim Öffnen eines Projekts oder als Unfähigkeit, noch einen weiteren pastellfarben markierten Codeblock ohne Irritation anzusehen. Wenn das primäre Werkzeug, das einem helfen soll, zur primären Quelle der Erschöpfung wird, folgt darauf Frust.
Dann gibt es den Kompetenzverlust. Der „Muskel“, die Intention in Syntax zu übersetzen, schwächt sich ab, wenn man aufhört, dies zu tun. Man mag zwar immer noch Systeme gut entwerfen können, aber die feingliedrige Routine – zu wissen, warum sich eine bestimmte Schleifenstruktur falsch anfühlt, oder sich daran zu erinnern, wie sich eine bestimmte Bibliothek unter Last verhält – schwindet, wenn eine Autocomplete-Ebene die Details übernimmt. Mit der Zeit läuft man Gefahr, eher ein passiver Kurator als ein aktiver Ingenieur zu werden.
Die unmittelbarste Gefahr ist jedoch ein nachlässiges Deployment. Unter dem Druck, die Geschwindigkeit beizubehalten, und erschöpft von stundenlangem Lesen von Maschinenausgaben, deployen Entwickler manchmal Code, den sie nicht vollständig validiert haben.