Der Mensch in der Schleife ist müde

 (pydantic.dev)
2 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • LLM-Programmierung steigert die Produktivität, vergrößert aber zugleich die Ermüdung durch Aufsicht, weil Entwickler Absicht und Qualität ständig weiter kontrollieren müssen, was Zufriedenheit und Nachhaltigkeit erschüttert
  • Modelle erzeugen schnell plausiblen Code, können aber bei komplexen Änderungen die konsistente Absicht verfehlen, sodass der Mensch zum Qualitäts-Gate wird, der die gewachsene Menge an Ergebnissen prüft und korrigiert
  • Auch wenn die Zahl der Aufgaben, die man beginnen kann, stark steigt, bleibt die Zahl der Aufgaben, die man sorgfältig abschließen kann, an menschliches Denken und Aufmerksamkeit gebunden, während die kleinen Belohnungen des Codings abnehmen und die kognitive Last der Prüfung zunimmt
  • In Bereichen mit tiefem Verständnis lassen sich LLMs wirksam steuern, doch in Bereichen mit oberflächlicher Expertise neigen sie eher zu Plausibilität als zu Genauigkeit, sodass Geschmack und Architektururteil wichtiger werden
  • Software Engineering verschwindet nicht, sondern schrumpft und wird neu geordnet; die knappe Ressource ist nicht das Schreiben von Code selbst, sondern menschliche Aufmerksamkeit, technisches Urteilsvermögen und die Fähigkeit, eine konsistente Vision des Systems zu erhalten

Nützliche, aber instabile LLM-Programmierung

  • LLM-Programmierung ist praktisch nützlich und zugleich instabil; wer diese Instabilität ignoriert, riskiert, dass Entwickler ausbrennen
  • Auch das Team von Pydantic erlebt dieselbe Verwirrung, während es Datenvalidierung, den Aufbau von AI-Agenten und Werkzeuge für Production Observability entwickelt
  • Im Kern geht es nicht darum, ob AI Programmierer ersetzt, sondern darum, wie sich die aktuelle Developer Experience verändert hat und womit sie verbessert werden kann

Das Gefühl, Dinge noch mit der Hand zu bauen

  • Programmieren bot lange ein Gefühl des Erschaffens: etwas allein mit Logik zu bauen und tiefe Abstraktionsebenen direkt zu handhaben
  • Aus der Erfahrung, Software Engineering nicht durch formale Informatikausbildung, sondern durch Versuch und Irrtum gelernt zu haben, wirken Architektur- und Codequalitätsprinzipien eher wie angesammelte Narben als wie Lehrbuchregeln
  • Auch Low-Code-/No-Code-Tools der 2010er und Produkte wie Dreamweaver warben mit dem Versprechen, etwas ohne Code zu bauen, erfüllten die Erwartungen aber nicht vollständig, weil sie intern Spaghetti-Code erzeugten
  • Aktuelle AI-Tools haben im Unterschied zu früher die Lücke zwischen Versprechen und Realität auf ein bedeutendes Maß verkleinert, und genau deshalb fühlen sie sich noch beunruhigender an

Die tatsächliche Erfahrung von „Code schreibt sich selbst“

  • Code schreibt sich bis zu einem gewissen Grad tatsächlich selbst, aber die menschliche Erfahrung, ihn zu prüfen, anzuleiten und wieder auf Kurs zu bringen, kann sich eher verschlechtern
  • Der Maintainer von Pydantic AI, Douwe, musste morgens regelmäßig rund 30 PRs prüfen, die die AIs anderer über Nacht erstellt hatten, und jede davon sofort beurteilen
    • Die Versuchung ist groß, sogar die Prüfung an AI zu delegieren, doch dann bleibt die Frage offen, was der Mensch eigentlich noch tut
  • Selbst wenn man fast zwei Tage lang einen Ausführungsplan für das LLM schreibt und ihn wiederholt präzisiert, kann das Modell React-Hooks in Storybook-Story-Dateien verschieben oder aufgrund eines falsch gelesenen Plans nicht existierende Komponenten erstellen
  • Solche Fehlschläge sind weniger bloßes Unvermögen als vielmehr mangelnde Konsistenz
    • Das Modell ist klug genug, plausiblen Code zu erzeugen, kann aber über eine komplexe Änderung hinweg nicht immer eine einzige Absicht beibehalten
  • Der Mensch muss eine Absicht im Kopf bewahren und gleichzeitig große Mengen an „größtenteils richtigem“ Output ständig beurteilen; dabei entsteht eine neue Form von Aufsichtserschöpfung
  • Auch die Belohnung im Open Source, mit realen Menschen Features zu bauen und deren Fähigkeiten zu fördern, nimmt ab
    • Wenn Arbeit in die Black Box der AI hineingeht, lernt auf der anderen Seite niemand mehr, sodass die Befriedigung der Zusammenarbeit verloren geht

Die Falle wachsender Arbeitsintensität

  • Die von Simon Willison vorgestellte Berkeley-Haas-Studie kommt zu dem Schluss, dass AI-Nutzung die Arbeit nicht verringert, sondern die Arbeitsintensität erhöht
    • Am Ende des Tages bleibt der Druck, nur noch einen Prompt mehr einzugeben oder nur noch ein Feature mehr fertigzustellen
    • Das Gefühl, den Plan fast vollendet zu haben, kann dazu führen, dass man bis fast 2 Uhr morgens weiter promptet
  • Marcelo von Pydantic scherzt, man solle fünf Claude-Code-Sessions öffnen, wenn eine Session hängen bleibt
    • Gemeint ist: Wer damit beschäftigt ist, anderen Sessions Feedback zu geben, merkt womöglich nicht einmal, dass eine Session stehen geblieben ist
  • Durch parallele Arbeit steigt die Zahl der Dinge, die man anfangen kann, stark an, aber nicht die Zahl der Dinge, die man sorgfältig beenden kann
    • Für den Abschluss braucht es das menschliche Gehirn als nicht parallelisierbare Ressource

Der Defekt der menschlichen Belohnungsfunktion

  • So wie die Belohnungsfunktion im Machine Learning gute Ergebnisse für Agenten definiert, gab es auch beim händischen Coding kleine Belohnungen wie Problemlösung, das Verstehen komplexer Logik, eine erfolgreiche Kompilierung und ein Gefühl von Kontrolle
  • LLM-gestützte Programmierung automatisiert genau die Arbeit, die diese Dopamin-Belohnungen erzeugte, und ersetzt sie durch die kognitive Last von Prüfung und Aufsicht
    • Die befriedigenden Teile nehmen ab
    • Die aufreibenden Teile nehmen zu
    • Neue Belohnungen, die die Lücke füllen, gibt es noch nicht
  • Dass die Produktivität steigt, während die Zufriedenheit sinkt, ist kein persönlicher Makel, sondern ein Defekt der Feedback-Schleife und muss als eigenes technisches Problem behandelt werden

Isolation und variable Belohnung

  • LLM-Programmierung kann zu einer sehr einsamen Tätigkeit werden, bei der Mensch und Maschine Prompts, Korrekturen und Prüfungen wiederholen
  • Momente, in denen man Kollegen etwas fragte, Probleme gemeinsam aussprach und die kleine Freude einer Lösung teilte, werden durch einen weiteren Prompt ersetzt
  • In Teams mit ohnehin schwacher Kollaborationskultur schrumpft die Kommunikation zwischen Menschen noch stärker, und es wird schwieriger zu erkennen, dass andere dieselben Probleme haben
  • Dass Ergebnisse manchmal großartig und manchmal Müll sind, ohne dass man es im Voraus weiß, erzeugt eine variable Belohnungsstruktur ähnlich einer Skinner Box
  • Man kann bei Bedarf auch direkt selbst Code schreiben, aber LLM-gestützte Arbeit und manuelles Arbeiten folgen sehr unterschiedlichen Denkweisen, sodass der Wechsel unangenehm ist
    • Sich selbst zu erlauben, zwischen beiden Modi zu wechseln, erfordert Reife und Selbstvertrauen

Ähnlichkeit mit dem Übergang zum Responsive Design

  • Als das Web um 2009 von Layouts mit fester Breite in Pixeln zu fließendem Responsive Design überging, erlebten Designer ebenfalls einen Verlust an Kontrolle
  • Für Menschen, die Identität und Professionalität auf präzisen Layouts und perfekten Grids aufgebaut hatten, war die Vorstellung, dass ein Design je nach Bildschirmbreite und Gerät frei fließt, eine grundlegende Veränderung
  • Designer, die sich an den Wandel anpassten, verwarfen ihre bisherigen Fähigkeiten nicht, sondern ordneten sie neu
    • Das Gespür für Proportionen und das Verständnis von Hierarchien blieben wichtig
    • Die Fixierung auf pixelgenaue Kontrolle wurde weniger wichtig
    • Systeme, Anpassungsfähigkeit und das Gestalten für Unsicherheit wurden wichtiger
  • Der aktuelle AI-Übergang verläuft viel schneller und unter anderen Rahmenbedingungen als der Wechsel zum Responsive Design
    • Die Veränderung durch Responsive Design zog sich über Jahre, die aktuelle Veränderung läuft im Monatsrhythmus
    • Auch damals verloren Agenturen Kunden und Designer Aufträge, aber es ging nicht mit derselben existenziellen Angst einher wie heute
  • Dennoch gilt auch für LLM-basiertes Coding das Muster, dass Technik nicht verschwindet, sondern sich weiterentwickelt und Kernkompetenzen wichtiger werden
  • Dass Engineers nicht mehr jeden Code selbst schreiben, mindert ihren Wert nicht zwangsläufig; aber weil sie zum Qualitäts-Gate für viel mehr Output werden, brauchen sie stärker die Fähigkeit, gute Ergebnisse zu erkennen

Überlebende Expertise und neue Arbeitsweisen

  • In einer Umgebung, in der jeder plausible UIs und kompilierenden Code erzeugen kann, werden Geschmack und Nuancen, reifes Architektururteil und unkonventionelle Entscheidungen auf Basis echter Expertise zum Unterscheidungsmerkmal
  • Je tiefer man einen Bereich, seinen Code, seine Entscheidungen und Trade-offs versteht, desto erfolgreicher kann man LLMs anleiten
  • Je oberflächlicher die Expertise in einem Bereich ist, desto weiter entfernt sich das Ergebnis von Production Readiness und nähert sich eher einem eindrucksvoll plausiblen als einem tatsächlich richtigen Zustand
    • Das Modell weiß nicht, was es nicht weiß, und füllt Lücken selbstbewusst; das ist eine Fehlform, die auch beim Menschen vorkommt
  • Für komplexe Pläne kann man ein Pre-Mortem einsetzen
    • Man lässt eine neue LLM-Session annehmen, der Plan sei katastrophal gescheitert, und bittet sie dann, die Ursachen zu diagnostizieren
    • Das hilft, Lücken in der Spezifikation zu finden, die jemand übersehen kann, der zwei Tage lang auf Details geschaut hat
  • Ein Engineer bei Pydantic entwickelte ein Tool, das aus Tausenden früheren Code-Review-Kommentaren Regeln extrahiert und sie als anfängliche Anleitung in einer AGENTS.md-Datei bündelt
    • Das ist eine Destillation von Expertise: über Jahre implizit angesammeltes technisches Urteilsvermögen wird in Anweisungen übersetzt, denen LLMs folgen können
  • Menschen, die sich an den Wandel anpassen, haben starke, in der Praxis gewonnene Urteilskriterien und unterscheiden zwischen Prinzipien, die weiterhin gelten, und Gewohnheiten, die nur aus früheren Bandbreitenbeschränkungen entstanden sind
  • Sie werfen ihre Maßstäbe nicht weg, sind aber bereit, ihren Arbeitsfluss zu verändern

Die knappe Ressource, sichtbar in der Schleife

  • Der aktuelle AI-Trend beendet den Beruf des Software Engineers nicht, könnte aber zu einer starken Schrumpfung und grundlegenden Neuordnung der Branche führen
  • Sorgen über Verdrängung, Kompetenzabbau und darüber, zurückzufallen, wenn man sich nicht schnell genug bewegt, sind berechtigt
    • Die letzte Sorge wird manchmal übertrieben, ist aber nicht völlig unbegründet
  • Der eigentliche Engpass war nie der Code, sondern menschliche Aufmerksamkeit, technisches Urteilsvermögen und die Fähigkeit, eine konsistente Vision des Systems aufrechtzuerhalten
  • Weil sich zuvor das Schreiben von Code wie der schwierige Teil anfühlte, war dieser Engpass weniger sichtbar; mit der Automatisierung des Schreibens wird nun klarer, dass menschliche Fähigkeiten die eigentliche knappe Ressource sind
  • Entwickler können produktiver und zugleich weniger glücklich und instabiler sein; auch Teams, die solche Tools bauen, erleben dieselben Probleme und justieren ihre Belohnungsfunktion in Echtzeit nach
  • Code und Entwicklungsweise verändern sich, aber der Mensch ist weiterhin in der Schleife, und der entscheidende Zustand der Gegenwart ist die Erschöpfung des menschlichen Teilnehmers

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Je schwieriger manuelles Coden war, desto größer wurden die kleinen Belohnungen wie Problemlösung, Verständnis der Logik, erfolgreicher Build und ein Gefühl von Kontrolle. Agentisches Coden hingegen erfordert unabhängig vom Umfang der Funktion immer wieder eine ähnliche Aufsicht: Anfangs fühlt es sich aufregend an, als würde man auf einer Produktivitätswelle reiten, doch die befriedigenden Anteile nehmen ab, die kognitive Last der Review steigt, und man ist schnell erschöpft.

    • Mehr als den Job zu verlieren, fürchte ich, bald die Arbeit selbst nicht mehr zu mögen. Aufgaben, bei denen Anweisungen an ein LLM kaum Zeit sparen, erledige ich selbst; außerdem überarbeite ich die Ausgabestruktur so, dass sie für Menschen leichter verständlich ist, und bewahre mir so ein Gefühl von Kontrolle.
    • Mein Antrieb liegt weniger darin, wie der Code entstanden ist, sondern darin, ob mehr Menschen das gebaute Produkt nützlich finden. Ich habe immer zuerst an die Nutzer gedacht und bei Bedarf Abkürzungen genommen; die Balance zwischen wartbarem Code und Release-Geschwindigkeit lässt sich auch mit LLMs halten.
    • Entwicklung könnte sich von einem wissensbasierten Beruf in etwas verwandeln, das eher wie niedrig bezahlte Fabrikarbeit wirkt. Um ein LLM anzuleiten, braucht man deutlich weniger Wissen und Erfahrung als beim eigenen Schreiben; auf LinkedIn werden sogar Menschen mit kaum Erfahrung oder auf Junior-Niveau als AI Engineers eingestellt.
    • Ich spüre Dopamin, wenn ich eine Schleife baue, in der die KI ihre eigenen Ausgaben testet. Je stärker die Rube-Goldberg-artige Automatisierung war – etwa Codex per Netzwerk-USB-C-Tastatur-Dongle, Fingerbot und Webcam fernzusteuern, damit auf einem bestimmten Notebook mit Linux-Kernel der Ruhezustand funktioniert –, desto zufriedenstellender war es.
    • Bei persönlichen Projekten steigt die Zufriedenheit sogar, weil sich Funktionen leichter bauen lassen und die Ergebnisse zugleich ausgefeilt und konsistent sind. Wenn man sich einen Monat lang auf ein Projekt konzentriert, erzielt man ziemlich gute Resultate; da Neuschreiben und Aufräumen der Struktur billiger geworden sind, kann man den Design Space tatsächlich breiter erkunden. Frustrierend ist es aber oft trotzdem; zur Hälfte liegt das an meinem Kontext-Providing, zur Hälfte an grundsätzlichen Grenzen des Modells.

  • Ich nutze Claude mit Freude bei der Arbeit und in privaten Projekten; der Kern ist, der Verlockung des Agenten zu widerstehen und ihn als Codegenerator zu behandeln. Man öffnet nur eine Session, arbeitet den Plan gründlich aus, beobachtet dann die schrittweise Ausführung und prüft sowie korrigiert nach jedem Schritt die Richtung; so behält man auch am Ende einen guten Überblick über den Codezustand.
    Wenn man es fast wie einen One-Shot nutzen will, muss man in der Planungsphase nicht nur die Architektur, sondern auch den konkreten Code ausarbeiten, der wichtige Entscheidungen beeinflusst. Da Refactoring so billig ist wie nie, sollte man schwer verständliche Stellen sofort mit dem LLM korrigieren; dabei aber jeweils nur ein LLM an genau einer Sache arbeiten lassen und selbst durchgehend beteiligt bleiben.

    • Nach einigen Monaten Arbeit mit Claude habe ich gelernt, am Anfang Details ausführlich zu besprechen und bei Bedarf sogar ein Gerüst zu bauen, bevor ich es ausführen lasse; das habe ich unter https://github.com/ctomkow/claude/blob/main/README.md zusammengefasst. Ich refactore erfolgreich lange aufgeschobenen Legacy-Code in eine neue Architektur.
      Gibt man Claude volle Kontrolle, führen das unvermeidliche Chaos und die Hindernisse zur Erschöpfung. Wenn man selbst codet, wenn man will, und an Claude übergibt, wenn man müde ist, kann man auch das Gefühl der Kontrolle über die Codebase behalten.
    • Ich füge nur die nötigen Codeausschnitte in einen vom Editor völlig getrennten Chat ein, diskutiere dort Einschränkungen und Ideen und übertrage es bei Zufriedenheit in den Editor, um Namen und Implementierung weiter zu verfeinern. Klare oder angenehme Aufgaben erledige ich selbst, und an Architekturentscheidungen muss man beteiligt bleiben, um sich mit dem Projekt verbunden zu fühlen und es tief zu verstehen.
    • Vibe Coding ist selbst mit mehreren Agenten-Loops eher erschöpfend als ein Assistenzwerkzeug-Ansatz, bei dem man die Ausgabe aus der Nähe betrachtet.
    • Selbst wenn man schrittweise arbeitet, muss jemand anderes bei der Review das gesamte Ergebnis auf einmal mit frischem Blick betrachten; die Review-Belastung sinkt daher nicht.
    • Man kann höchstens zwischen zwei Arbeitsflüssen wechseln; bei mehr führt der Kontextwechsel dazu, dass der Kopf völlig erschöpft ist.

  • Wenn ich Code von Kollegen oder Mitarbeitenden reviewe, verbrauche ich den Großteil meiner mentalen Energie nicht nur für die technische Stichhaltigkeit des Feedbacks, sondern auch für Ego, unterschiedliche Architekturperspektiven, einen höflichen Ton, zusätzliche Arbeitslast und Teamdynamiken. Bei einem LLM muss man sich dagegen nicht um emotionale Auswirkungen kümmern, sodass Review und Kurskorrektur viel einfacher sind.

    • Wenn ich weiß, dass ein Kollege mein Feedback wieder an die KI weitergibt, schreibe ich eher für die KI als für einen Menschen und übermittle die Änderungsliste viel kürzer und direkter.
    • Als Tech Lead habe ich bei jedem PR Widerstand im Sinne von „das reicht doch“ erlebt; bei einem LLM kann ich ohne Gegenwehr verlangen, es auf die richtige Weise noch einmal zu machen, was angenehm ist.

  • Auf der Arbeit haben wir angefangen, statt human in the loop Human on the hook zu sagen. Das beschreibt treffender eine Struktur, in der Menschen bei Erfolg keine Anerkennung bekommen, bei Fehlern aber verantwortlich sind – also nur dann wichtig werden, wenn es Probleme gibt.

  • Code zu schreiben war für mich nie der schwierige Teil. Schnelles Tippen, modales Editieren in Vim, Unix-Befehle, Skripte und Shortcuts, Git, IDE-Refactorings und Java habe ich so weit beherrscht, dass ich, wenn ich wusste, was ich bauen wollte, mit Gedankengeschwindigkeit arbeiten konnte.
    Ins Stocken gerate ich nicht wegen Tippen oder Syntax, sondern wenn ich über die Form des Codes und die richtige Änderung nachdenke; wenn es schwierig wird, baue ich bessere Abstraktionen, IDE-Werkzeuge oder Unix-Pipelines einschließlich sed. Deshalb war der Flaschenhals nicht das Schreiben von Code, sondern Denken und Urteilen.
    Dass AI Coding sich wie ein großer Sprung anfühlt, könnte daran liegen, dass überraschend viele Entwickler nie mit hervorragenden Werkzeugen in Berührung gekommen sind oder sie nicht gemeistert haben. Wäre ich heute in meinen Zwanzigern, hätte ich weniger Zeit darauf verwendet, solche Fähigkeiten zu lernen; für mich wurde Software Engineering aber gerade in dem Moment attraktiv, als ich verstand, dass daran nichts Magie ist.

    • Die Formulierung „KI ist gut darin, so zu wirken, als könne sie Dinge, die man selbst nicht gut kann“ passt sehr gut. Wenn man im Programmieren ungeübt ist, wirken KI-Ausgaben schnell und hervorragend; für erfahrene Entwickler ist es mit Anweisen, Warten, Überzeugen, Korrigieren und Refactoring zusammen möglicherweise nicht schneller als es selbst zu tun.
      So wie KI-Bilder für mich großartig wirken, weil ich schlecht zeichne, könnte AI Programming nach demselben Prinzip bewertet werden.

  • Die Müdigkeit, die viele spüren, entsteht aus dem Verlust von Kontrolle, wenn größerer Vortrieb und größeres Chaos zusammenkommen. LLMs liegen irgendwo zwischen Genie und Kleinkind; vom Rücksitz aus zuzusehen ist aufregend und beängstigend zugleich.
    Nach einer Weile schnellen Fahrens wird man wohl feststellen, dass Gehen gar nicht schlecht war – und dass die Chance, tatsächlich am gewünschten Ziel anzukommen, dabei sogar höher war.

  • LLM-Coding fühlt sich an, als würde man den Hebel eines Spielautomaten ziehen: ein Ritual vollziehen, hoffen, dass es diesmal klappt, und es wiederholen. Fehler in der normalen Programmierung haben konsistente Ursachen, und das System ist darauf ausgelegt, diese Ursachen zu verstehen und möglichst dauerhaft zu beseitigen. Erfahrene Entwickler probieren nicht wahllos herum und verbuchen einen Erfolg dann als etwas, dessen Grund unbekannt ist.
    Wenn man ohnehin schon erschöpft ist, weil man mit mehreren Stakeholdern zu tun hat, die sich nicht einmal darauf einigen können, was das System überhaupt ist, hat man vielleicht längst gewusst, dass menschliche Aufmerksamkeit und ingenieurmäßiges Urteilsvermögen schon immer der eigentliche Engpass waren.

    • Als ich gerade erst Programmieren lernte und Web-Apps baute, hing ich bis spät in die Nacht am Rechner und riet blindlings „Vielleicht funktioniert es, wenn ich das hier versuche?“ Mit wachsender Erfahrung und durch typisierte Sprachen, Compiler und LSP verstand ich besser, was funktionieren würde, und konnte statt in süchtig machendes Herumraten in einen befriedigenden Flow-Zustand kommen.
      Coding mit Claude fühlt sich an wie eine Rückkehr in diese Ratephase, und das will ich nicht. Am nützlichsten sind LLM-Gespräche allerdings in Bereichen, in denen ohnehin viel blindes Raten vorkommt, etwa bei DevOps-artigen Aufgaben, bei denen komplexe APIs und mehrere Komponenten zusammengefügt werden müssen.
    • Statt sich zu einigen, lassen Stakeholder nun von LLMs unausgereifte Pläne und Quartalsziele erstellen und überlassen ihnen Design, Stories, technische Details, Implementierung und Code-Review. Im gesamten Prozess verschwinden kritisches Denken und Verifikation, während sich Designdokumente und Code mit unklarem Zweck anhäufen, denen man kaum noch folgen kann.
      Pläne können sich jederzeit ändern, und die Wahrscheinlichkeit steigt, dass sie aus einem Impuls heraus komplett neu geschrieben werden.

  • Dem Kern des Artikels stimme ich zu, aber an vielen Stellen schimmert der typische Claude-Stil durch, und Texte zu lesen, die jemand mit AI geschrieben hat, ist noch ermüdender.

    • Wahrscheinlicher als ein direkt von AI geschriebener Text ist, dass er redigiert und geprüft wurde, um zum Unternehmensstil zu passen. LLMs selbst wurden ebenfalls auf solche Schreibweisen trainiert.
    • Der Text wurde größtenteils von AI verfasst, aber es steckt deutlich mehr menschliches Eingreifen darin als in gewöhnlichen AI-Texten, daher stört er mich nicht so sehr wie üblich.
    • An stilistischen Fingerabdrücken wie der Wiederholung von „It’s not“ und der Verwendung von Gedankenstrichen würde ich ihn als AI-generiert einstufen.
    • Wenn sich jemand nicht die Mühe gemacht hat, ihn selbst zu schreiben, möchte ich mir auch nicht die Mühe machen, ihn zu lesen.

  • Das erinnert an den Artikel The Animal is Tired von 2021: https://www.robinhobb.com/blog/archives/2021-05

    • Da die Originalseite IPs blockiert, kann man ihn auf dem weniger restriktiven Mirror https://archive.is/RWxXP lesen. Den eigenen Verfall zu spüren, kann eine der größten Traurigkeiten sein, und es trifft jeden.
      Selbst wenn man den eigenen Körper mehr geschont hätte, wäre man am Ende vielleicht an denselben Punkt gelangt und hätte dabei wertvolle Erinnerungen verpasst. Man sollte auf seinen Körper achten, ihn aber nicht behandeln wie einen Trank in einem Spiel, den man bis zum Schluss nicht benutzt, weil man ihn vielleicht für den nächsten Kampf braucht. Jeder Teil unseres Körpers kann entweder einmal für einen größeren Zweck geopfert werden oder gar nicht.
      Schon bei diesem Gedanken muss ich weinen; ich stecke also immer noch in einer emotionalen Krise.

  • Die Forschungs-PR von Berkeley Haas, wonach der Einsatz von AI die Arbeitsintensität erhöht, ist eindrucksvoll, aber obwohl der HBR-Artikel https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... und die Pressemeldung https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo... seit mehr als fünf Monaten online sind, finde ich weder die eigentliche Studie noch einen Preprint.
    Soweit bekannt, handelt es sich lediglich um etwa 40 qualitative Interviews in einem Unternehmen einer einzigen Branche, daher ist es schwierig, die Verlässlichkeit der Ergebnisse zu bewerten, ohne die Methodik prüfen zu können.