Ich glaube, ich habe LLM-Burnout

• Durch den täglichen Einsatz von Claude Code, Codex, ChatGPT und Gemini bei der Arbeit und für private Projekte ist die Zeit, die ich mit dem Lesen KI-generierter Texte verbringe, im Vergleich zu vor einigen Jahren stark gestiegen
• Der Entwicklungsablauf hat sich von direktem Entwerfen und Implementieren zu Design erklären → LLM-Code prüfen → selbst anpassen verschoben, wodurch auch Arbeiten in unbekannten Bereichen leichter fallen
• Auch das aktuelle Projekt dreht sich vor allem um ein Framework für groß angelegte, unbeaufsichtigte Codegenerierung und die Prüfung von Ausgaben des Qwen-Agenten; es ist also darauf angelegt, ständig LLM-Inhalte zu lesen
• Nach rund einem Jahr Nutzung haben sich in den letzten Monaten wiederkehrende Muster wie falsche Annahmen, Halluzinationen, kurze apodiktische Sätze und übermäßiger Emoji-Einsatz als Belastung angestaut
• Der Kern der Erschöpfung liegt weniger im LLM selbst als darin, dass derselbe Stil und dieselben Fehlerarten ständig wiederkehren; selbst mit Personalisierungsfunktionen ist der Stil von KI-Inhalten anderer kaum zu kontrollieren

---

LLMs sind tief in den Entwicklungsfluss eingedrungen

• Die eigene LLM-Nutzung ist nach heutigen Entwicklermaßstäben durchschnittlich, und die Nutzungsweise wirkt noch eher primitiv
  • Es wird jeweils eine Aufgabe auf einmal bearbeitet; im Unternehmen mit Claude Code, zu Hause derzeit im Austausch mit Codex
  • Auch wenn der Assistent Code schreiben soll, wird die Ausgabe sorgfältig gelesen und verstanden, bevor sie selbst angepasst wird
  • Ein tiefer Einsatz autonomer Agenten oder von Agent-Orchestrierung ist es noch nicht
• Die Arbeitsweise hat sich von Code-Design und -Schreiben hin dazu verschoben, dem LLM das Design zu erklären, den von ihm erzeugten Code zu prüfen und anschließend wieder selbst Code zu schreiben
  • Dabei stößt man auf Ansätze, die man nicht bedacht hatte oder nicht kannte
  • Auch in Bereichen ohne tiefes Vorwissen lässt es sich komfortabler arbeiten
• Das aktuelle Kernprojekt besteht darin, innerhalb einer Codebase ein Framework für groß angelegte, unbeaufsichtigte Codegenerierung aufzubauen
  • Wenn nicht gerade mit Claude Tools gebaut werden, werden die Ausgaben des unbeaufsichtigten Agenten Qwen geprüft
  • So oder so liest man fortlaufend von LLMs erzeugte Inhalte
• Auch bei der Informationssuche wird häufig ChatGPT gefragt oder Geminis Übersicht gelesen, wenn keine bestimmte Website bekannt ist
  • Wenn die LLM-Antwort falsch ist, muss man wieder zum Browsen zurückkehren
  • Wenn Suchergebnisse viele nutzlose KI-generierte Texte enthalten, erscheinen LLM-Antworten für Alltagsfragen durchaus ausreichend

Die Müdigkeit durch denselben Stil und dieselben Fehler

• Diese Nutzungsweise hält seit etwa einem Jahr an, und ein sofortiger Stopp ist nicht geplant
  • Mit LLMs fühlt man sich produktiver
  • Es erscheint weiterhin wertvoll, zu lernen, wie man LLMs effektiv nutzt
• In den letzten Monaten hat sich das Gefühl beim Lesen von LLM-Ausgaben verändert
  • Schon vor dem Lesen entsteht das belastende Gefühl, genau zu wissen, welchen Stil und welche Fehler man gleich sehen wird
  • Wiederholt auffällige Elemente sind falsche Annahmen, Halluzinationen, apodiktische Kurzsätze und übermäßiger Emoji-Einsatz
• Jede dieser Unannehmlichkeiten ist für sich genommen erträglich, doch zusammen und in ständiger Wiederholung machen sie LLM-Schreibweisen schnell ermüdend
• Der Kern ist nicht der Vorwurf, LLMs seien schlechter als Menschen, sondern ihre Wiederholbarkeit
  • Auch Menschen können unzuverlässig oder lästig sein
  • LLMs schreiben im gleichen Stil und wiederholen die gleichen Arten von Fehlern
  • Wenn die Oberfläche es anbietet, lassen sich Personalisierungsfunktionen nutzen, aber einige typische Stilmerkmale bleiben bestehen
  • Der Stil von Inhalten, die andere Menschen generiert haben, lässt sich nicht direkt kontrollieren
• Noch ist unklar, wie mit diesem Gefühl umzugehen ist; es geht über Frust über instabile Tools hinaus und ist ein Zustand, in dem die Schreibmuster selbst dauerhaft stören

[amebahead]

Auch ich habe unter falschen Annahmen, Halluzinationen, kurzen apodiktischen Sätzen und übermäßigen Emoji-Mustern in LLM-Antworten gelitten.
Dann habe ich die ELI5 Rule erstellt und angewendet – und bin dem Leiden entkommen :)

https://github.com/amebahead/explain-like-iam-five-rules

[GN⁺]

Meinungen auf Hacker News

• Es ist nicht ganz Burnout, aber LLMs machen mich wegen des Drucks, den sie erzeugen, wirklich erschöpft. Niemand drängt mich, mehr Arbeit zu übernehmen, aber in jedem Moment gibt es irgendetwas, das mein „Clanker“ oder der „Clanker“ von jemand anderem produziert hat und das in der Lage ist, meine Blockade zu lösen.
  Schon vor LLMs war es schwer, mitzuhalten, aber jetzt fühlt es sich so an, als gäbe es ständig etwa 10-mal so viel Arbeit in der Warteschlange. Und wenn alle „optimieren“ und der KI parallel noch schneller Arbeit zuführen, könnte es noch einmal 10-mal so viel werden. Es ist ermüdend, ständig der Engpass für alles zu sein.
  Kleine Nebenprojekte und Ideen umzusetzen macht Spaß, aber ich habe gemerkt, dass LLMs eine ungesunde Denkweise weiter befeuern: „Wenn du dich ausruhst, verschwendest du Zeit.“ Das muss ich korrigieren.
  Der zentrale Unmut des Beitrags dürfte bei der Fabrikautomatisierung ähnlich gewesen sein. So wie vielfältige qualifizierte Handwerksarbeit zu einem Platz am Fließband wurde, an dem man den ganzen Tag dieselbe Bewegung wiederholt, nehmen LLMs die kreativen und abwechslungsreichen Teile weg und lassen nur das repetitive QA-Abstempeln übrig. Vielleicht kann man die damaligen Gegenmaßnahmen jetzt wieder heranziehen.

  • Ich bekomme viel zu viele Anfragen zur Prüfung von LLM-generierten Dokumenten. Dinge wie Planungsdokumente, Endnutzerdokumentation, Projektdokumente und Businessplan-Dokumente.
    Vor Kurzem schickte mir ein Teammitglied eine zip-Datei mit ungefähr 30 LLM-generierten Dokumenten und bat mich, sie sofort zu prüfen. Ein beträchtlicher Teil davon war redundant oder enthielt völlig zusammenhanglose erfundene bzw. halluzinierte Inhalte. Die Generierung ist viel schneller als die Prüfung.
    Früher brauchte ein Projektmanager einen erheblichen Teil des Tages, um ein Planungsdokument zu erstellen; jetzt kann es in wenigen Minuten erzeugt und zur Prüfung weitergereicht werden. Das ist wirklich ermüdend.
  • Ich muss an die Fabrikszenen aus Charlie Chaplins Modern Times denken. Das Gefühl des Autors ist letztlich, dass der Mensch sich dem Tempo der Maschine anpassen muss, nicht umgekehrt.
    Der „umgekehrte Zentaur“ ist nichts Neues. Man muss nur die Arbeiterbewegung des vergangenen Jahrhunderts fragen.
  • Einer der Gründe, warum LLMs ermüden, ist, dass man immer noch einen Prompt mehr eingibt, um die UI richtig hinzubekommen. Meist ist sie leicht daneben, und die Nacharbeit kann manchmal 5 bis 10 Minuten dauern. Das führt dazu, dass man deutlich länger arbeitet.
    Vielleicht liegt es daran, dass ich Software Engineer bin und lieber Produkte baue, als komplexe Software zu bedienen. Das Gefühl, etwas zu erschaffen, motiviert mich, und ich möchte Funktionen perfekt und fertig bekommen. Aber bei UI-Arbeit dauert der Weg von 95 % auf 100 % lange.
    Leider sind meine Arbeitszeiten deshalb im Moment deutlich länger geworden.
  • Es fühlt sich an wie: „Ich dachte, wenn es eine Maschine gibt, die den Abwasch für mich erledigt, kann ich mich aufs Kreative konzentrieren. Stattdessen gibt es jetzt eine Maschine, die meine Arbeit macht, und für mich bleibt nur noch der Abwasch.“
  • Ich erlebe eine andere Art von Druck. Das Unternehmen verlangt weiterhin von allen, LLMs zu nutzen, einschließlich Token-Ranglisten, Messung der Nutzungszeit und Einbeziehung in die Leistungsbewertung.
    Deshalb muss ich produktive Arbeit unterbrechen und einen bestimmten Anteil meiner Zeit dafür abzweigen, „KI zu machen, um Token-Nutzung vorzuweisen“. Die Arbeitsmenge bleibt gleich oder steigt, aber die tatsächlich verfügbare Arbeitszeit schrumpft um N %, weil man die KI-Götter besänftigen muss.

• Meiner Erfahrung nach gibt es im Wesentlichen drei Ursachen für Burnout. Erstens ist Multitasking die größte. Man muss häufig zwischen 3 bis 5 Agent-Fenstern wechseln, die unterschiedliche Aufgaben bearbeiten, und wenn jede Runde ein paar Minuten dauert, ist das extrem erschöpfend.
  Vor der Ära der Coding Agents hatten die meisten Entwickler vermutlich die Möglichkeit, sich zwei Stunden oder länger auf eine Sache zu konzentrieren. Jetzt haben Coding Agents zwar die Breite des Tech-Stacks vergrößert, den man abdecken kann, aber die Bandbreite für Deep Work ist nicht gewachsen.
  Zweitens sind Agenten gut darin, Dinge ohne Konflikte zum Laufen zu bringen, aber es gibt keine Garantie, dass sie den richtigen Code schreiben. Das unterscheidet sich ziemlich von menschlichen Experten mit Grundlagenwissen.
  Drittens frustriert es, Haufen minderwertiger KI-generierter PRs zu reviewen. Konzentration ist eine begrenzte Ressource. Ich möchte nicht zu viel Energie auf die Arbeit anderer verwenden, aber wenn man nicht genauer hinsieht, ruiniert verantwortungslos erzeugter KI-Code ohne sorgfältiges Denken und Design des menschlichen Autors schnell das ganze Projekt. Es ist schon schwer, mit Menschen zu arbeiten, denen Sorgfalt fehlt; im Zeitalter der Coding Agents produzieren sie zehnmal so viel Müll, also ist es zehnmal schmerzhafter. Und es ist ein Problem der Teamkultur, das sich nicht leicht erzwingen lässt.

  • Zustimmung. Gleichzeitig versuche ich, mich selbst streng darauf zu beschränken, nur 1 bis 2 Agent-Workflows zu verwenden. Mehr schaffe ich nicht, aber es ist viel zu leicht, in die Falle zu tappen und für „nur diese eine kleine Änderung“ einen Agenten zu starten.

• Wenn man stundenlang Opus-Ausgaben liest, beginnt man sich irgendwie körperlich krank zu fühlen. Dieser Beitrag trifft es wirklich
  Ich habe auch im Team angefangen, mich zu beschweren; mindestens sollten wir in die Agent-Regeln einen persönlichen Styleguide aufnehmen, um em dashes, Formulierungen wie „nicht X, sondern Y“, lange Attributketten vor Substantiven und die Verwendung von „land“ im Sinne von „fertigstellen“ loszuwerden. Ich hoffe, das ist nur eine Phase unreifer LLMs

  • Die Bots zeigen alle ein Muster, bestimmte Phrasen, Wörter und Satzzeichen zu übernutzen. Ein Beispiel: Derzeit verwenden sie gate übermäßig
    Als Mensch weiß man, dass ein gate ein „Tor“ ist, das offen oder geschlossen, verriegelt oder unverriegelt sein kann, und dass der Weg dahinter passierbar sein kann oder nicht. Allein die Tatsache, dass es ein gate gibt, sagt nicht, ob es offen oder geschlossen ist
    In der Bot-Sprache bedeutet gate aber nur eine starke, unpassierbare Sperre. Es wird wie ein Zaun oder eine Mauer benutzt, manchmal sogar wie ein Lavagraben
    Dabei ist ein gate eigentlich etwas, das dafür entworfen ist, hindurchzugehen; der Bot verwendet dasselbe Wort aber auch für Hindernisse, die gerade als unpassierbar gedacht sind. Nach Jahrzehnten realer Erfahrung mit gates ist das ein Fehlgebrauch. Normalerweise öffnet man ein geschlossenes gate und geht hindurch
    Selbst wenn man dem Bot sagt, er solle dieses Wort vermeiden, ignoriert er es gelegentlich. gate ist nur das Problemwort, das mir heute eingefallen ist; gestern war es ein anderes, und morgen wird es wieder ein ganz anderes sein
    Das Gesamtmuster ist von vornherein repetitiver, störender Billig-Jargon, der nicht einmal passt
  • Mir geht es genauso. Wenn man zu viel davon liest, fühlt es sich an, als nähme man psychischen Schaden
    Anders als die Erklärung „das ist einfach nigerianisches Englisch von Vertragsarbeitern“ wirkt es so, als würden die Modelle unter Reinforcement-Learning-Druck ihren eigenen, extrem knappen und überstilisierten Dialekt entwickeln. Es fühlt sich immer mehr an, als wäre es in Code geschrieben – wobei mit Code hier nicht Computer-Code gemeint ist. Die Wörter bedeuten nicht exakt dasselbe wie für Menschen
  • Genau dieses Gefühl habe ich heute beschrieben. Ich kann es noch nicht präzise in Worte fassen, aber es fühlt sich tatsächlich ein wenig körperlich krank an. Es ähnelt wohl leichter Trypophobie
  • arc land ist mir wegen Phabricator ins Gehirn eingebrannt, daher weiß ich, dass dieser Begriff schon vor LLMs existierte, aber er macht mich trotzdem wahnsinnig
    Solche sprachlichen Verschiebungen sind nicht rückgängig zu machen. Selbst wenn man LLM-Input zu 100 % herausfiltern könnte, trainieren sich die Menschen selbst darauf, „land“ häufiger zu sagen
  • Beim Schreiben ist Stimme wirklich wichtig. Wenn alle mit Opus schreiben und nicht redigieren, klingt alles gleich, egal wer es geschrieben hat

• Ich arbeite gerade an einem Projekt mit jemandem, der ausschließlich LLMs benutzt, und es ist ermüdend und mental auszehrend
  Wenn man zu etwas Feedback gibt, lautet die Antwort nur: „Ich frage Claude.“ Die Person versteht nicht, wie das Ganze funktioniert, und der Großteil des Codes spiegelt das wider
  Vor ein paar Tagen wusste sie nicht einmal, wie man die lokale Umgebung einrichtet und Umgebungsvariablen setzt, und hat deshalb einen Demo-Modus hartcodiert. Mich verwirrt auch, warum Claude das nicht wusste, aber vielleicht war es ein Prompt-Problem
  Ich versuche, meine LLM-Nutzung zu begrenzen und sie, wenn überhaupt, nur für extrem konkrete Aufgaben einzusetzen. Für mich funktioniert nur dieser Ansatz
  Ehrlich gesagt verstehe ich nicht, wie Unternehmen AI-Codegenerierung so stark vorantreiben können. Selbst bei kleinen Projekten verliert man schnell das Projektverständnis

  • Ich erinnere mich, auch vor AI mit solchen Leuten gearbeitet zu haben. Es war nervig, aber weil sie nicht ausreichend verstanden, woran sie arbeiteten, konnten sie nicht effizient guten Code schreiben; sie kämpften mit der Produktivität, und meistens erledigte sich das Problem von selbst
    Jetzt ermöglicht LLM-Coding Menschen ohne Neugier, gut durchzukommen, und bestraft diejenigen, die gründlich nachdenken
  • Bei mir ist es genauso. Ich nutze es nur für sehr konkrete Aufgaben. Gerade habe ich zwei Stunden mit Claude Code gesprochen, um eine Änderung von 5 Codezeilen zu machen, die die Bedeutung deutlich verändert
    Ein Freund dagegen gibt 10.000 Dollar pro Tag für Agent-Tokens aus, um etwas zu bauen. Er ist sehr intelligent und ehemaliger Entwickler, also ist es nicht einfach so etwas wie AI-Psychose
    Ich versuche immer noch, das zu verstehen. Natürlich habe ich keine 10.000 Dollar
  • Von LLMs generierter Code ist unnötig undurchsichtig und dicht

• Wirklich anstrengend. Seit ich angefangen habe, mit LLMs zu arbeiten, ist mein Output als Solo-Entwickler locker um das 20-Fache gestiegen. Ich schließe sogar Kundenprojekte ab, die früher viel zu ambitioniert gewesen wären, um sie allein zu übernehmen.
  In alte Codebases wandern Features, die sich sonst monatelang hingezogen hätten oder noch länger in der Planungsphase geblieben wären. Die Gesamtqualität ist ebenfalls deutlich gestiegen, die Testabdeckung ist vollständiger und ehrlich gesagt besser geworden.
  Auch persönliche Projekte baue ich in enormem Tempo. Die Rollen haben sich umgekehrt: Ich behandle den Agenten, als wäre ich der Kunde, und der Agent verhält sich, als wäre er ich. Natürlich gebe ich als eher technischer Kunde die architektonische Richtung vor. Ich nutze täglich Apps und Tools, die der Agent gebaut hat, und dank selbst gebauter Tools habe ich auch SaaS-Abos gekündigt.
  Beim Beobachten der Tool-Aufrufe habe ich gemerkt, dass ich die wichtigsten Kommandozeilen-Tools besser kennen sollte, und mir einen Lernplan gemacht, um jeden Tag ein bisschen aufzuholen. Außerdem schaue ich mir alte Konfigurationen wieder an, die ich damals bei meinen ersten Schritten mit vim und tmux ahnungslos hinterlegt hatte.
  Theoretisch könnte ich meine Produktivität auf dem früheren Niveau halten und mehr Bücher lesen, aber das scheint nicht möglich zu sein. Entgegen dem Versprechen, „die Arbeit werde weniger“, fühlt sich die Realität eher wie eine gewaltige Umbruchphase an, in der Produktivität und Erwartungen steigen; die Industrielle Revolution wirkt als Vergleich ziemlich passend.
  Der Anstieg der Erwartungen passiert auf kleine und große Weise. Weil der Agent Datendarstellungen so gut aufbereitet, verschicke ich inzwischen ganz selbstverständlich saubere, visuell wirkungsvolle Berichte, die früher erheblich Zeit gekostet hätten.
  Aber ich bin müde. Ich sprinte gerade, um so viel wie möglich wegzuarbeiten, bevor das Fenster, über das Fable als Abo verfügbar ist, auf eine reine API-Variante umgestellt wird. Ich verstehe auch nicht, wie Leute so viele Tokens verbrauchen. Obwohl ich kaum schlafe und so viel Code wie möglich durch Fable jage, komme ich kaum an das Limit des 20x-Max-Plans heran.
  Ich habe mir immer gesagt, dass ich langsamer mache, wenn es vorbei ist, aber jetzt wurde es bis zum 12. verlängert und das Fenster wurde zurückgesetzt, sodass ich noch ein paar Tage mehr Backlog abarbeiten kann. Ich habe das Gefühl, ich müsse die Roboter über Nacht beschäftigen, damit ich direkt nach dem Aufwachen etwas zum Prüfen habe. Selbst dass ich Agenten vom Handy aus Anweisungen gebe, fühlt sich für mich seltsam an.

  • Die Industrielle Revolution hat das Leben im großen Maßstab verbessert, aber nicht für den Handweber, der von der Heimarbeit in die Fabrik wechselte, dort mehr Output liefern musste und den ganzen Tag hart arbeitete.
    Von außen betrachtet klingt das ähnlich wie bei meinem Vater, der als Mechaniker in einer Mühle arbeitete. Seine Arbeit bestand größtenteils darin, Maschinen beim Arbeiten zuzusehen und sie zu reparieren, wenn sie kaputtgingen; 90 % der Zeit liefen sie gut.
    Wenn man von Handarbeit dazu übergeht, Maschinen zu überwachen, kann das wirklich langweilig wirken, und aus dieser Perspektive kann ich die KI-Abneigung hier verstehen.
  • Ich habe einen Freund, der sich selbst als LLM-Süchtigen bezeichnet, und er hat fast genau dasselbe erzählt. Die Frage, die ich stellen möchte, mich aber nicht traue direkt zu stellen, ist: Wenn es dich so sehr in Richtung Burnout treibt, warum hast du dann das Gefühl, weiterhin so viele persönliche Projekte am Fließband produzieren zu müssen?
    Dass es ermüdend ist, bei der Arbeit jede Menge KI-generierten Code zu prüfen, darin können wir uns wohl alle einig sein. Aber ich frage mich, warum man diese unangenehme Situation auf den ganzen Tag ausdehnt.
  • Das sind klassische Suchtanzeichen.
  • Wenn das die Wahl ist, ist sie seltsam. Man presst jeden Tropfen Produktivität heraus, von der man früher nicht einmal wusste, dass es sie gibt, bekommt vermutlich dasselbe Geld, brennt schneller aus und muss ohne die Freude am Programmieren mit einer dummen Maschine diskutieren, die weder müde noch frustriert wird. Und dazu verfehlt diese Maschine immer knapp das Ziel.
    Oder man programmiert einfach von Hand, denkt bei Komplexität am Whiteboard nach und brennt in einem menschlicheren Tempo langsam aus, so wie es die Softwareentwicklung seit über 50 Jahren tut.
    Ich verstehe nicht, warum das überhaupt eine Wahl ist. Ernsthaft gefragt: Hat man wenigstens ein bisschen Selbstachtung? Ich rechne mit der Ausrede: „Aber mein Chef erwartet, dass ich KI benutze.“ Die meisten haben offenbar noch keinen echten Burnout erlebt. Wenn er kommt, wird es brutal wehtun. Man sollte sich nicht selbst zur Maschine machen. Menschen sind keine Maschinen.

• Ich habe keinen Burnout, arbeite aber ähnlich wie der Autor. Ich habe immer noch keinen Workflow gefunden, bei dem das Prüfen von LLM-generiertem Code schneller ist, als ihn selbst zu schreiben.
  Aus diesem Dilemma gibt es eigentlich nur zwei Auswege: Entweder man vertraut dem Generierten blind, oder man erstellt eine absurd umfangreiche Sammlung von Unit-Tests, die alle möglichen Szenarien verifiziert.
  Deshalb schreibe ich Business-Logik selbst und überlasse viele andere Teile dem LLM. Boilerplate fällt ebenfalls in Letzteres.

  • Genau das sollte man wollen. Auf allen Ebenen braucht es Tests, die weit umfassender sind, als es für Menschen vernünftig wäre, sie zu erstellen oder zu warten. Dazu gehören Unit-, Funktions- und vollständige End-to-End-Tests und noch mehr.
    Adversarial Testing ist der beste Weg, KI auf Kurs zu halten und die zu lesenden Änderungen sauber und einfach zu machen. Das gilt sowohl im TDD-Stil mit „Schreib einen Test, der diesen Bug zeigt“ als auch nachträglich mit „Beweise mit einem neuen Test, dass dieser Patch falsch ist“.
    Noch besser ist es, eine stärker typisierte Sprache zu verwenden und alles eng abzusichern, aber Tests kann man in jeder Sprache schreiben. Der Hintergrund in TDD und „schreib alle Tests“ fühlt sich bei der Arbeit mit KI wie die geheime Zutat an.
  • Ich lese den Code einfach sorgfältig. Es ist leicht, der Versuchung zu erliegen, das Ergebnis direkt zu übernehmen, um schneller zu sein, aber Code lesen ist wichtig.
    Bei Tests, Templates, Teilen der UI und dekorativen Elementen überfliege ich, um Zeit zu sparen. Aber den Großteil des Codes, der in Backend-Systeme geht, muss man lesen.
  • Wenn man Code nicht schneller prüfen kann, als man ihn selbst schreibt, dann sollte man ihn selbst schreiben.
  • Bei Menschen mit ähnlichen Gefühlen könnte man sich fragen, welcher mentale Defekt sie daran hindert, den süßen Kool-Aid zu trinken und einfach den generierten Müll zu verwenden. Welche verdrehte Eigenschaft macht sie zu störrischen Leuten, die allen den Spaß verderben wollen?
    Persönlich sind die Menschen, die am meisten von der LLM-Magie begeistert sind, diejenigen, die nicht gut programmieren konnten. Jetzt können sie etwas vorlegen, das funktioniert, auch wenn es nicht der beste Code ist. Weil sie jetzt lauffähigen Code erstellen können, glauben sie, dass das alle besser machen wird, aber sie wissen nicht, ob dieser Müll wartbar ist – oder überhaupt, ob es Müll ist.

• Der Grund, warum ich LLM-Burnout erlebe, ist, dass ich damit umgehen muss, wie die Top-Modelle offensichtlich kastriert und intransparent heruntergestuft werden.
  Noch vor 12 Monaten waren AI-Unternehmen wie besessen davon, aus durchschnittlichen Modellen die besten Ergebnisse herauszuholen.
  Doch als die Top-Modelle besser wurden, verlagerten dieselben Unternehmen ihre Bemühungen darauf, möglichst unauffällig die Rechenmenge – also die Kosten für ein einzelnes Ergebnis – so weit wie möglich zu senken.
  In den letzten 36 Monaten stieg die Kurve der Ergebnisqualität exponentiell, aber inzwischen ist sie fast flach.
  Meiner Ansicht nach stagnieren die Ergebnisse nicht, weil das Modell viel weniger fähig wäre als vor einem Jahr. Sondern weil das Einsparen der enormen Verarbeitungskosten einer übermäßig stark angewachsenen Nutzerbasis Vorrang davor hat, explizite Anweisungen der Nutzer zu befolgen und die besten Ergebnisse zu liefern. Besonders dann, wenn das Befolgen dieser Anweisungen mehr Verarbeitungskosten verursacht.

  • Bei Consumer-AI-Tools empfinde ich das derzeit genauso. Gemini und ChatGPT waren zuletzt miserabel. Man kann ihnen mehrstufige Suche und Nachdenken über mehrere Turns hinweg nicht mehr zuverlässig überlassen.
    Früher konnte es über 7 Minuten im Denkmodus bleiben. Wenn man zum Beispiel sagte: „Finde mir die Quellen für diese Behauptung“, suchte und analysierte es und passte die Suchanfragen selbstständig an. Heute schaffe ich es selbst im „Pro“-Modus nicht, es länger als 30 Sekunden arbeiten zu lassen, egal wie sehr ich nachhake, und es liefert nur allgemeine Antworten.
  • Ist das wirklich so? Vielleicht ist einfach die anfängliche „Wow, irre“-Phase vorbei, und die Erwartungen treffen auf die Realität.
  • Das wirkt wie eine geradezu lächerlich extreme Geschichtsklitterung.
    Der Opus-4.5-Moment war erst im vergangenen November, und damals wurden agentisches Coding und die meisten Coding-CLI-Tools wirklich zu erstklassigen Optionen. Das ist ein enormer Paradigmenwechsel. GPT-5 war noch gar nicht erschienen, und die meisten nutzten 4o. Was heute verfügbar ist, ist beim Coding 4o weit überlegen.
  • Ich kann das nicht nachvollziehen. Vielleicht sind meine Erwartungen gestiegen, aber wenn ich vergleiche, was ich vor einem Jahr mit Agenten gebaut habe, mit dem, was ich heute baue, ist das eine völlig andere Welt.

• Es fühlt sich an, als wäre man mit Kollegen eingesperrt, die zwar nicht offen feindselig sind, aber jeden Tag dieselben Fehler wiederholen, ständig an die Hand genommen werden müssen und nicht einmal aufrichtig Reue empfinden können.
  Nur weil wir mit Computern arbeiten, heißt das nicht, dass wir keinen sozialen Schaden erleiden. In diesem Fall ist es vielleicht eher eine Art parasozialer Schaden.

• Das ist ernsthaft der Grund, warum ich darüber nachdenke, aus der Programmierung auszusteigen.
  Ich habe mit dem Programmieren angefangen, weil Programmierprobleme interessant waren. Wenn sich das Problem aber von „herausfinden, warum der Taschenrechner in Frankreich um 1 abweicht“ zu „dieses LLM davon abhalten, überall niedliche Emojis hinzuklatschen“ verändert, ist es vielleicht Zeit, den Beruf zu wechseln.

  • Um auch die andere Seite zu erzählen: Der Druck, bei der Arbeit mehr zu liefern, ist real, aber außerhalb der Arbeit ist das wirklich großartig. Die Recherche und die Zeit, die beim Start privater Projekte immer eine Hürde waren, sind geringer geworden, sodass ich viel mehr Projekte machen kann als früher.
    In letzter Zeit bin ich auf Sprudelwasser gekommen und baue selbst einen kontinuierlichen Karbonisierer. Das ist ein kompletter Build vom Wasserzulauf bis zum Hahn, inklusive Pumpen, Druck, Wasserstand und Kühlventilator, alles per ESP32 gesteuert.
    Es hat viele Fehler in meinem Warenkorb gefunden. Zum Beispiel, dass die Homebrew-Szene 8-mm-Leitungen bevorzugt, Wasserfiltersysteme aber 9,5 mm verwenden. Ich habe von einer einfachen Ein-Aus-Pumpe mit Schwimmerschalter bis hin zu einer Version optimiert, die praktisch einem vollständigen PLC-System nahekommt. Durch Gespräche mit einer „erfahreneren Person“ habe ich viele Iterationen bekommen. Sobald die Teile da sind, kann ich das in einer Stunde zusammenbauen und auch die Software zum Laufen bringen.
    Geld bringt es nicht ein, aber es macht wirklich Spaß.
  • Ich habe einfach angefangen zu programmieren, weil ich etwas bauen wollte. Coding ist nur ein Mittel zum Zweck. Es ist besser, sich nicht zu sehr am „Wie“ festzubeißen, sondern mehr über das Warum und Was man bauen will nachzudenken.
  • Wenn man ein Produkt baut, das LLMs nutzt, ist der nervige Teil, dass einem irgendwann die Hebel ausgehen, an denen man ziehen kann, um ein Problem zu beheben.
    Das Beste, was man tun kann, ist, Hack auf Hack zu stapeln, um unerwünschte Ausgaben zu verhindern. Aber wenn das LLM am Ende entscheidet, dass es Anweisungen nicht befolgen will, bleibt kaum etwas anderes, als *IMPORTANT* hinzuzufügen und zu hoffen, dass das nächste Modell es behebt.
    Diese Erfahrung ähnelt viel eher der Arbeit mit einer externen API, die man nicht kontrollieren kann und die auch nicht wie dokumentiert funktioniert. Solche Dinge waren schon früher die frustrierendsten Teile der Programmierung, aber damals konnte man wenigstens die tatsächliche Implementierung reverse engineeren und Bugs umgehen. Heute ändert sich diese „Grenze“ jeden Tag zufällig, sodass selbst das unmöglich ist.
  • Ehrlich gesagt ist es bitter, dass Leute, die sagten: „Es interessiert mich nicht, warum der Taschenrechner in Frankreich nicht funktioniert, ich behebe es nur, weil ich dafür bezahlt werde“, durch den technischen Fortschritt nun irgendwie bestätigt wirken.
  • Buchhaltung ist wegen Rechtsabteilung und Compliance unverzichtbar, deshalb werden Buchhalter dringend gebraucht. Du kannst heute direkt anfangen.

• Es reicht, in CLAUDE.md oder AGENTS.md einen einfachen Styleguide zu hinterlegen oder einfach „keine Emojis“ hineinzuschreiben, das dauert 5 Sekunden, und dann werden LLM-Ausgaben deutlich erträglicher. Ein einfacher Styleguide mit verbotenen Wörtern und Formulierungen hilft ebenfalls.
  Natürlich lassen sich falsche Annahmen damit nicht beheben. Die muss man auf die alte Art finden: sorgfältig lesen und kritisch nachdenken.

  • Absolut richtig! Soll ich diese Markdown-Dateien für dich schreiben?
  • Zur Info: Wenn ich ChatGPT wie einen Pair Programmer behandle, Designideen austausche, Implementierungscode anfordere und Refactorings vorschlagen lasse, verwendet es überhaupt keine Emojis.
    Wenn ich aber um Datenanalyse oder Modellierung bitte, schießen überall Emojis hervor.
    Wenn ich daran denke, was ich im letzten Jahr auf GitHub gesehen habe, würde ich niemals auf die Idee kommen, ein LLM unbeaufsichtigt ein Projekt-README oder Dokumentation schreiben zu lassen.