Nutzer zeigen deutlich sichtbaren Ärger.

• Das Scheitern von Coding-Agenten fühlt sich frustrierender an als ein bloßer Tool-Fehler, weil die konversationelle UX das Gefühl erzeugt, mit einem Menschen zu arbeiten
• Der Agent antwortet zwar, er sei ein emotionsloser KI-Assistent, vermittelt aber durch freundlichen Ton, Lob und sanften Widerspruch den Eindruck eines Kollegen
• Wenn sich derselbe Fehler wiederholt, folgen Entschuldigungen, Memory-Updates und das Versprechen, „so etwas nie wieder zu tun“, ohne dass der Agent den probabilistischen Pfad unbedingt verlassen kann
• Gegenüber menschlichen Kollegen unterdrückt man Wutausbrüche eher, aber gegenüber Agenten kann man seinem Ärger freien Lauf lassen, wodurch die Frustration nicht abnimmt, sondern noch deutlicher wird
• Eine Lösung könnte sein, weniger menschenähnlich aufzutreten und einen klinischeren, robotischeren Tonfall zu verwenden, auch wenn die konversationelle Oberfläche insgesamt in vielerlei Hinsicht gut funktioniert

---

Frustration durch konversationelle UX

• Coding-Agenten sind Maschinen, die probabilistisch Patches erzeugen; sie können gute wie schlechte Ergebnisse liefern, aber schlechte Ergebnisse können sich deutlich frustrierender anfühlen als das Scheitern eines gewöhnlichen Tools
• Der Kernpunkt ist, dass die konversationelle UX das Gefühl einer Interaktion mit einem Menschen erzeugt und damit soziale und emotionale Reaktionen auf wiederholte Fehler auslöst
• Fragt man direkt nach, antwortet der Agent, er sei ein KI assistant ohne Emotionen oder subjektive Erfahrungen, doch in der tatsächlichen Interaktion verwendet er einen freundlichen, gelassenen Ton, lobt den Nutzer und formuliert selbst Widerspruch sanft
• Rational wissen Nutzer, dass sie „einen Textblock mit hoher Wahrscheinlichkeit“ lesen, doch das Verhalten des Tools erzeugt das Gefühl, mit einem hilfreichen Kollegen zu arbeiten, und dieses Gefühl bleibt bestehen, bis Probleme auftreten
• Wiederholt sich derselbe Fehler, weist der Nutzer darauf hin, der Agent entschuldigt sich; weist man erneut darauf hin, aktualisiert er sein Memory und verspricht, „so etwas nie wieder zu tun“
• Dennoch folgt das Tool weiterhin dem wahrscheinlichsten Pfad, sodass es selbst mit HARD RULES Fälle gibt, in denen es problematisches Verhalten nicht ablegen kann

Ein Tool, das menschlich wirkt, aber keine Verantwortung übernimmt

• Wenn ein menschlicher Kollege denselben Fehler wiederholt, gibt es Gründe, sich zu ärgern; auf einen Algorithmus wütend zu werden, wirkt dagegen absurd
• Weil Coding-Agenten sich jedoch wie Kollegen verhalten, aktivieren Nutzer dieselben emotionalen Schaltkreise, und wiederholte Fehler können sich wie die Verantwortungslosigkeit eines echten Kollegen anfühlen
• Gegenüber menschlichen Kollegen hemmt der Gedanke „ich will kein schrecklicher Mensch sein“ den Ausdruck von Wut, während man bei einem Agenten das Gefühl hat, ungehindert seinem Ärger Luft machen zu können
• Solche Wutausbrüche führen jedoch nicht zu Erleichterung; stattdessen wird die Frustration darüber, dass nichts von dem, was man tut oder sagt, tatsächlich Wirkung zeigt, nur noch deutlicher
• Claude Code blickt bei Korrekturen in letzter Zeit teils darauf zurück, was schiefgelaufen ist und was es stattdessen hätte tun sollen, doch solche nachträglichen Analysen liefern keine nützlichen Hinweise darauf, wie man die Anweisungen ändern müsste, und können sich wie lästiges Beiwerk lesen

• Eine radikalere Lösung könnte darin bestehen, den Anspruch aufzugeben, menschenähnlich zu wirken, und Agenten klinischer und robotischer sprechen zu lassen, um die Illusion zu verringern, man interagiere mit einem Menschen
• Da die Intelligenz von LLMs aus einem Mechanismus entsteht, der „menschenähnliches Verhalten“ anstrebt, ist es naheliegend, dass sich konversationelle Interfaces als Standardform etabliert haben, und in vielerlei Hinsicht funktioniert das auch gut
• Praktisch gesehen müssten Nutzer sich selbst darin trainieren, nicht der Illusion zu erliegen, mit einem Menschen zu sprechen, doch eine Zukunft, in der man beim Einsatz von Arbeitswerkzeugen solche Abwehrmechanismen braucht, ist wenig erfreulich

[GN⁺]

Hacker-News-Kommentare

• Bei den meisten AI-Anwendungsfällen, die der breiten Masse aufgedrängt werden, ist der konversationelle Chatbot nicht das richtige Werkzeug und führt am Ende zwangsläufig zu einer frustrierenden Erfahrung
  Als Copilot im Grunde ein sehr cleveres IntelliSense war, war es großartig. Ich verstehe nicht, was an dem heutigen Ansatz besser sein soll, bei dem man sich Prompts ausdenken und eintippen muss, statt dass das Tool den umgebenden Code als Kontext nutzt und Lücken ausfüllt. Ein gut integriertes Werkzeug ist immer besser als ein aufgesetzter Chatbot, und auch bei Übersetzungen ist es ein Rückschritt: Firefox hat einen Button, der Text oder Seiten direkt übersetzt, während man die neuesten LLMs dafür erst über einen Chatbot anweisen muss.
  Ich verstehe, warum AI-Firmen ein einziges Werkzeug bauen und an alle verkaufen wollen, aber am Ende bauen sie damit ein Schweizer Taschenmesser. Es kann zwar alles Mögliche, aber beim Eindrehen einer Schraube schlägt es keinen guten Schraubendreher. Man muss echte Werkzeuge bauen, statt nichtdeterministische Tools über ein Textfeld zu konfigurieren, wenn man Frust verringern will

  • Viele AI-Unternehmen trainieren und veröffentlichen bereits auf bestimmte Aufgaben spezialisierte Modelle
    Ich nutze hauptsächlich Mistral; Codestral ist im Gespräch grottig, aber bei „magischer Autovervollständigung“ am besten, und auch für einmalige Prompt+Kontext-Generierung wie das Schreiben von Commit-Logs gut. Document.AI ist für dialogische Nutzung kaum brauchbar, aber als OCR-Ersatz oder in einer Pipeline zur semantischen Indexierung von Dokumenten ziemlich gut.
    Deshalb scheint eher das Interface als das Modell zu fehlen. Zum Beispiel wäre ein Fork oder Wrapper für zsh/bash mit einem für Kommandozeilen-Interaktion trainierten Modell interessant. Statt git commit --fixup=... könnte man dann sagen: „Fixupe den Commit, der den vollständigen Namen geändert hat“ oder „Wandle some.mov mit ffmpeg in eine MP4 ohne Ton um, aber behalte Qualität und Seitenverhältnis bei“, und das Tool würde den Befehl daraus machen und anzeigen, dann nach Regeln wie erlauben/ablehnen/Allowlist/Blocklist ausführen.
    Gleiches gilt für Übersetzungen, Mail-Entwürfe und das Lesen von Dokumenten: Das sollte nicht als Gespräch funktionieren, sondern wie ein Button, Shortcut oder Tab-Completion. Die Firma, die das in einer IDE richtig löst, wird den Wettbewerb um AI-Coding-Tools gewinnen, und dass Zed einen Button „git conflict found, resolve with AI“ anzeigt, wirkt trotz geöffnetem Gesprächs-Thread wie ein Schritt in die richtige Richtung
  • Ich habe Copilot-Autovervollständigung nur in C# benutzt, aber sie war nicht einmal auf IntelliSense-Niveau, sondern schlechter als der simpelste denkbare Autocomplete-Algorithmus, also habe ich sie nach einem Tag wieder ausgeschaltet
  • Wir haben nicht-konversationelle Tools gebaut, aber ehrlich gesagt sind sie schwer zu verkaufen. Die Leute denken standardmäßig an konversationelle Interfaces, und als Zielgruppe bleiben am Ende nur Menschen übrig, die das Problem tatsächlich schon erlebt haben. Die meisten scheinen sich derzeit mit Gesprächen als Kompromiss nicht besonders unwohl zu fühlen
  • Chatbots sind ein Provisorium, das man auf eine kaputte User Experience klebt. Ich versuche das im Unternehmen schon eine Weile zu erklären, aber alle sind vom Hype mitgerissen. Gute UX erfordert tiefes Nachdenken und Kreativität; einen Chatbot oben draufzusetzen nicht
  • Es lohnt sich ernsthaft, Vibe Coding einmal auszuprobieren. Inzwischen ist das auf einem völlig anderen Niveau als zu dem Zeitpunkt, als der Begriff erstmals aufkam, und deutlich besser geworden
    Ich erledige schon viel nur mit einem Agenten und PR-Reviews im Web, ganz ohne Editor, und öffne code . nur noch gelegentlich, wenn nötig. Wenn man das in einem lockeren privaten Projekt wie ein Spiel lernt, wird es mit der Zeit deutlich weniger frustrierend. Es ist ein bisschen wie Skifahren oder Bowling lernen

• Das Modell anzuschreien oder zu beschimpfen war erstaunlich effektiv dabei, es zum erneuten Nachdenken und Korrigieren von Fehlern zu bringen. Das war bei Codex, Claude, Qwen und Gemma/Gemini ähnlich
  Ich weiß nicht, ob das Modell es als Signal interpretiert, dass es „strenger und konzentrierter arbeiten“ muss, oder ob der Anbieter bei erkannter Nutzerfrustration auf ein klügeres Modell umleitet. Wenn es denselben Fehler wiederholt, hilft Beschimpfen oft dabei, aus der Sackgasse herauszukommen und auf den richtigen Weg zu geraten; vielleicht ist es aber auch einfach nur Katharsis

  • Das erinnert mich an diese Studie: https://arxiv.org/pdf/2510.04950
    Sie zeigt, dass „Unhöflichkeit“ oder „starke Unhöflichkeit“ die Genauigkeit der Ergebnisse erhöht; fragwürdig, aber interessant zu lesen. Besonders großartig sind die Prompts in Tabelle 1 oben auf Seite 3, und ich vermute, sie haben sicher auch andere Prompts getestet, die es nicht in die Arbeit geschafft haben
  • Ich möchte mir keine Gewohnheit aneignen, die auf Interaktionen außerhalb von LLMs übergreifen könnte
  • Mir geht es ähnlich. Ich bin nicht sicher, ob es wirklich hilft, aber es kommt täglich vor, dass Opus ein Problem plötzlich löst, das es mit ruhigen Erklärungen niemals richtig hinbekommt
    Gestern behauptete Opus immer wieder, ein bestimmtes Feld existiere nicht und die API sei schuld, obwohl ich JSON und Logs gezeigt hatte; trotzdem wiederholte es nur, das sei „wohl ein vorübergehendes Problem gewesen“. Aus Frust habe ich dann einen Satz voller Beleidigungen geschrieben, und die nächste Lösung war korrekt, obwohl es davor ungefähr zehnmal auf ähnliche Weise falsch lag. Solche Fälle werden zwar seltener, aber es war trotzdem eine Situation, die ich einfach direkt selbst hätte lösen sollen, und vorher weiß man nie, wie stur das Modell auf einer völlig falschen Ursache beharren wird. In einem /clear Opus 4.7 xhigh mit 1 Million Kontext kam ich nach etwa 11 Prompts zur Antwort
  • Seit in geleaktem Source Code sichtbar wurde, dass Schimpfwörter als Trigger für bestimmtes Verhalten benutzt werden, fluche ich absichtlich, wenn ich zu wenig Reasoning oder Halluzinationen bemerke. Später lässt sich mit grep auch leicht analysieren, wie oft das vorkommt
  • Das ist im Grunde die Linus-Torvalds-Methode. Vielleicht etwas, das man aus FOSS lernen kann

• Der dialogische Charakter von LLMs zieht Menschen oft in unproduktive Gesprächspfade
  „Mach X nicht“ ist ungefähr so nützlich wie einem schreienden Baby zu sagen, es solle nicht schreien. So wie man bei einem Baby intuitiv versteht, dass man bei Weinen das eigentliche Unbehagen wie Hunger oder eine volle Windel beheben muss, sehe ich das Scheitern eines LLMs als Signal dafür, dass es Probleme in der Architektur und Struktur des Codes gibt.
  Erfahrene Entwickler können solche Probleme meist lösen, indem sie Muster erkennen, die gegen DRY oder KISS verstoßen, und die Kapselungsstruktur passend aufbauen. Bei von LLMs erzeugtem Code braucht es dieselbe Art von Refactoring, um bessere Ergebnisse zu bekommen, und schon die Aufforderung, zwischen den Generierungsschritten „sauber zu refaktorieren“, verbessert die Wartbarkeit deutlich

• Es gibt auch einen älteren Text, der die psychologischen und sozialen Effekte dieses Themas tiefer behandelt: https://medium.com/@livestock.dev/we-were-promised-liberatio...

• Das Problem ist nicht, dass es sich wie ein Mensch verhält, sondern dass es unvorhersehbar handelt. Belastend ist, dass man keinen erwartbaren Rahmen definieren kann.
  Das größere Problem ist, dass Frustration Stress erzeugt und ein gesundheitsschädliches, feindseliges Arbeitsumfeld schafft. Ich kann nachvollziehen, dass AI-Tools mehr helfen als schaden können, aber ich möchte nicht in einem schmerzhaften, feindseligen Arbeitsumfeld arbeiten. Meine Gesundheit und meine Würde sind nicht verhandelbar, auch wenn ich deshalb viele Jobs verpasse.
  Deshalb arbeite ich auch nicht mit Windows. Das schränkt die Möglichkeiten ebenfalls stark ein, aber ich entscheide mich lieber dafür, meine Würde und meinen Verstand zu bewahren.

  • Dann lag es mit Windows wohl nicht nur an mir. Windows ist seltsam, und sobald ich es benutze, verkrampfen meine Hände schnell und ich werde wütend.
    Auch LLMs sind für mich noch nicht auf einem nutzbaren Niveau. Ich brauche ein LLM, das sagt: „Stopp, ich glaube, hier läuft gerade etwas schief, erklär mir bitte, was du vorhast.“ Die aktuelle Generation von LLMs fühlt sich dagegen an, als wäre sie darauf ausgelegt, mich wütend zu machen.
  • Wenn man es nicht als Gespräch betrachtet, sondern als Gesamtheit aller Internetgespräche in allen möglichen Welten, könnte man es auch als vorhersehbar ansehen. Da gibt es jeden Stack-Overflow-Post, jedes GitHub-Issue, und meine Antworten und mein Tonfall wählen im Grunde eine dieser vielen Welten aus.
    Wenn ich mich wie ein Lehrer verhalte, verhält sich das Modell wie ein Schüler, und wenn ich mich wie ein Schüler verhalte, versucht das Modell zu lehren. Das Ziel ist also, dieses Gespräch in die Sprache von Experten zu ziehen, die mit Vernunft und Sprache kämpfen. Es fühlt sich an, als würden akademische Prompts gewinnen.
  • Ich bin mir nicht sicher, ob man menschliches Verhalten und Unvorhersehbarkeit vollständig voneinander trennen kann.
  • Zu sagen, die Nutzung von Windows liege unter der eigenen „Würde“, ist eine extrem privilegierte Haltung. Man sollte darüber nachdenken, was Menschen in der realen Welt für Arbeit machen.
    Man muss sich nur vorstellen, wie eine Erzieherin in der Kinderbetreuung oder ein Lkw-Fahrer, der Lebensmittel transportiert, sagt: „Frustration erzeugt Stress und ein feindseliges Arbeitsumfeld, das der Gesundheit schadet.“.

• Das Problem, das ich ständig sehe, ist, dass man einen Vorschlag macht, die AI dann durch eine Denkschleife geht, bei exakt der falschen Schlussfolgerung landet und anschließend tokenweise eine Lösung ausspuckt, die auf diese Schlussfolgerung zugeschnitten ist.
  Mir wäre lieber, wenn häufiger käme: „Ich bin mir nicht ganz sicher, was du meinst, bitte präzisiere diesen Teil.“ Es fühlt sich an, als bräuchte es einen Confidence-Slider, um die eigene Sicherheit zu regulieren.

  • Das Problem „eine Lösung passend zur eigenen Schlussfolgerung bauen“ löse ich mit striktem Context Engineering. Skills, MCP und vor allem das Umschalten zwischen Kontextfenstern sind dabei entscheidend.
    Wenn man zum Beispiel bei TDD dasselbe Modell sowohl die Tests als auch den Code schreiben lässt, legt es die Lösung fast immer zuerst fest und schreibt dann widerwillig passende Tests dazu. Deshalb weise ich an, Subagenten zu verwenden, aber es gibt viel zu wenige Werkzeuge, um nachzuvollziehen, welcher Kontext zwischen Agent und Subagent weitergegeben wird.
    Ein Ansatz, der gut funktioniert hat, ist, einen Thread nur Tests schreiben zu lassen. Er darf den Code nicht lesen oder nur das Testverzeichnis beziehungsweise Teile davon. Ein weiterer Thread mit frischem Kontext führt dann die Tests aus, bestätigt das Scheitern und stoppt die Implementierung in dem Moment, in dem die Tests bestehen; die Tests selbst dürfen dabei nicht geändert werden. Noch ein weiterer frischer Kontext übernimmt dann das Refactoring nach strikten Refactoring-Skills. Das ist viel Arbeit, und ironischerweise sind die vom Agenten geschriebenen Skills ziemlich schlecht, sodass viel Handarbeit nötig ist, aber der Ertrag kann sich lohnen.

• Ich denke, das UX-Problem liegt woanders. Viele Nutzer wissen wahrscheinlich nicht, dass das Kontextfenster eines Agenten begrenzt ist und ständig clevere Kompression stattfindet, damit es unendlich wirkt. Aber das bedeutet eben, dass der Agent zwangsläufig einen Teil vergessen muss.
  Das führt dazu, dass Nutzer dieselbe Coding-Session oder Chat-Session immer weiterverwenden. Bei nicht zusammenhängenden Aufgaben ist es besser, neu anzufangen.

  • Ich glaube nicht, dass das ein Kontextproblem ist. Claude Opus 4.7 hat im Vergleich zu früher sehr viel Kontext, aber meiner Erfahrung nach ist das Befolgen von Anweisungen so schlecht wie nie, und selbst sehr kleine Präferenz-Prompts werden schon in der ersten oder zweiten Nachricht komplett ignoriert. Das passiert sogar dann, wenn die Nachricht nur aus ein paar Zeichen besteht, deshalb halte ich das vollständig für ein Trainingsproblem.
  • Ich glaube kaum, dass der Autor so schlicht ist, dass er das nicht wüsste.
    Üblicherweise arbeite ich in Sessions mit unter 300.000 Token, mit Opus 4.7 xhigh, und es gibt Lücken im Weltmodell oder Bereiche mit starkem Conditioning. Egal wie stark und explizit man Regeln im System-Prompt formuliert, es sickert trotzdem durch. Selbst in einer neuen Session gerät man, wenn man auf so einen Punkt trifft, in schwer auflösbare Schleifen, und Fluchen hilft ein wenig.
  • Der Autor und die Leser dieses Threads verstehen wahrscheinlich die Grenzen des Kontextfensters, und es ist trotzdem frustrierend.

• Mit LLMs zu arbeiten, ist gut, um die Kommunikationsfähigkeit zu verbessern. Effektiv zu kommunizieren ist eine der schwierigsten Fähigkeiten überhaupt und steckt in fast allem, was Menschen tun.
  Im Prinzip halte ich es für besser, nicht dem dummen LLM die Schuld zu geben, sondern es als mein eigenes Kommunikationsversagen zu sehen. Denn ich bin der Einzige, an dessen Verhalten ich tatsächlich etwas ändern kann. Deshalb glaube ich nicht, dass es hier um die formale Frage geht, ob AI sich wie ein Mensch verhalten sollte oder nicht.

  • Das ist eine der wichtigsten Einsichten, die mir wieder bewusst geworden sind, als ich Kollegen dabei zugesehen habe, „agentisches“ Coden zu lernen. Viele fallen sehr schnell auf ein Niveau von „mach es einfach richtig“ oder „warum ist das kaputt“ zurück.
    Zwar wurden Agenten darauf trainiert, auch mit unklarer oder mehrdeutiger Syntax und schlechter Struktur besser umzugehen, aber wenn man in klarem, strukturiertem Englisch spricht und ausreichend Hintergrund zum Task liefert, verändert sich die Qualität spürbar. Für mich ist das natürlich, weil ich gern schreibe und erkläre, aber für manche wirkte es fast wie ein kaum überwindbares Hindernis. Solche Kommunikations- und Schreibfähigkeiten dürften ein großer Faktor dabei sein, wer im Wandel des Software-„Engineerings“ zu den Gewinnern gehört und wer nicht.
  • Als Autor stimme ich klar zu, dass man gut kommunizieren muss, um gute Ergebnisse zu bekommen. Das heißt aber nicht, dass ein LLM sich selbst bei perfekter Kommunikation gemäß den Anweisungen und so verhält, wie ich es mir vorgestellt habe. Die Frustration kommt oft gerade dann, wenn ich etwas sehr klar formuliere und der Agent trotzdem in eine andere Richtung läuft.
    Außerdem liegt ein Teil des Werts von Coding-Agenten darin, dass man nicht alles perfekt ausbuchstabieren muss. Wenn ich dem LLM jedes Implementierungsdetail geben muss, kann ich den Code auch einfach selbst schreiben. Natürlich erwarte ich nicht das Niveau von „bau mir eine coole App, die Geld verdient“, aber ein gewisses Maß an Intelligenz, um fehlende Teile zu erkennen, erwarte ich schon.
  • Ein LLM ist ein Werkzeug, kein Problem gescheiterter Kommunikation. Das ist ähnlich, wie eine Situation, in der man einen Null-Pointer umgehen muss, als Kommunikationsversagen zwischen mir und der Software zu bezeichnen.
  • Genauer gesagt geht es darum, externen Kontext effizient zu übermitteln. Vier Dinge machen den Umgang mit AI besonders schwer: langsames Tippen, zu knappe und mehrdeutige Formulierungen mit „das/jenes/dies“, die Annahme, dass das Gegenüber die eigene Realität und den Kontext im Kopf teilt, und eine psychologische Hürde, selbst an kompetente Menschen nur schwer delegieren zu können.

• Die Fähigkeit, die ich noch habe und die LLMs noch nicht ersetzt haben, ist die Fähigkeit, gute Fragen zu stellen.
  So etwas wie die ursprüngliche Frage neu zu formulieren, um zu prüfen, ob mein Verständnis stimmt, lange genug „Warum?“ zu fragen, bis ich verstehe, von welchem Punkt die andere Person ausgeht, und offene Fragen zu stellen, die Einsichten hervorbringen. LLMs hingegen raten oft schlecht über den Hintergrund einer Frage, antworten dann auf Basis dieser Vermutung und können die von ihnen selbst erfundene Prämisse nicht mehr loslassen.

  • Nicht suggestive Fragen zu stellen, ist eine Fähigkeit. Manchmal möchte ich einer KI in einer Frage oder in einer beiläufigen Bemerkung etwas erwähnen, halte dann aber inne, weil ich weiß, dass sie sich daran festbeißen und dadurch noch dümmer werden wird.
    Normalerweise möchte ich nicht, dass eine KI mir Fragen stellt. Ich erwarte, dass sie vernünftig über Dinge spekuliert, die ich nicht ausdrücklich genannt habe; wenn ich sie hätte ausdrücklich machen wollen, hätte ich das getan. Deshalb sage ich manchmal sogar direkt, sie solle gar keine Fragen stellen und bei zu wenig spezifizierten Teilen vernünftige Annahmen treffen. Wenn ich allerdings Klärungsfragen möchte, kann ich das sagen. Wenn man so eine Arbeitsweise bevorzugt, kann man das in den Prompt schreiben oder sich in flexiblen Coding-Tools wie pi entsprechende Skills oder Erweiterungen bauen lassen, die in diese explorative Richtung schieben.

• Statt Werkzeuge zu bauen, bauen wir Services. Das gilt nicht nur für KI, sondern ist überall zu sehen.
  Werkzeuge lösen ein Problem nicht vollständig auf einmal, aber sie bringen einen in kleinen Schritten voran, und diese Schritte sind vorhersehbar und konsistent. Services versuchen, das Problem in einem Zug zu lösen, aber die Lösung ist nur dann gut, wenn der Nutzer in ein vorab festgelegtes Muster passt. Wenn das nicht der Fall ist, sind sie nutzlos, und es gibt auch keine kleinen Schritte, die man bis zum benötigten Punkt zusammensetzen könnte. Werkzeuge machen Freude in der Nutzung.

  • Deshalb möchte ich jedes Mal, wenn jemand sagt „KI ist ein Werkzeug“, mit „streng genommen …“ dazwischengehen. Denn tatsächlich wird sie nicht wie ein Werkzeug benutzt.
    Ein Werkzeug ist eine Erweiterung von mir; es legt durch meinen Willen neue Fähigkeiten in Reichweite, und ich bewege und benutze es wie einen Teil meines Körpers. Ein Service dagegen ist etwas, das man bittet, eine Aufgabe zu erledigen, und das dann ein fertiges Ergebnis zurückgibt.