Der Unterschied zwischen dem „Hype“ um autonome Agenten und AI-Agenten, die in der echten Produktion funktionieren

• Entgegen der Erwartung, dass der AI-Agenten-Boom 2025 groß durchstarten werde, gibt es in realen Produktionsumgebungen praktische Grenzen
• Wegen Fehlerakkumulation und Token-Kostenproblemen ist eine vollständige Automatisierung mehrstufiger Workflows derzeit unmöglich
• Die meisten erfolgreichen Agentensysteme erfordern eine streng begrenzte Domäne sowie menschliche Freigabe oder Verifizierungsprozesse
• Die eigentliche Schwierigkeit liegt nicht in der AI-Leistung selbst, sondern im Design von Tools und Feedback-Systemen, die Agenten gut nutzen können
• Für Startups/Unternehmen, die 2025 vollautonome Agenten in den Vordergrund stellen, sind bei realer Einführung und Skalierung große Hürden zu erwarten

---

Warum ich darauf wette, dass AI-Agenten 2025 nicht kommen werden (obwohl ich selbst AI-Agenten entwickle)

• Der Hype, dass 2025 das Jahr der AI-Agenten werde, ist allgegenwärtig
• Der Autor hat im vergangenen Jahr selbst verschiedene AI-Agentensysteme gebaut, die in realen Produktionsumgebungen laufen
• Aus direkter Praxiserfahrung heraus steht er der marktweiten „Agentenrevolution“ skeptisch gegenüber

Erfahrung beim Aufbau verschiedener Agentensysteme

• Entwicklungsagenten: Erzeugung von React-Komponenten aus natürlicher Sprache, Refactoring von Legacy-Code, automatische Pflege von API-Dokumentation, spezifikationsbasierte Funktionsgenerierung usw.
• Daten- & Infrastruktur-Agenten: Verarbeitung komplexer Abfragen und Migrationen, Multi-Cloud-DevOps-Automatisierung
• Qualitäts- & Prozess-Agenten: automatisches Beheben von Lint-Problemen, Generierung von Testcode, Automatisierung von Code-Reviews und detaillierten Pull Requests
• Diese Systeme liefern echten Mehrwert und sparen Zeit, aber genau diese Erfahrung ist auch der Hintergrund für den kritischen Blick auf den Hype

Kernzusammenfassung: Drei nüchterne Wahrheiten über AI-Agenten

1. Kumulierte Fehlerquote: Mit jeder zusätzlichen Stufe sinkt die Erfolgsrate exponentiell. Produktionsstandards (99,9 % oder mehr) sind schwer zu erreichen
2. Context Window und Kosten: Je länger die Unterhaltung dauert, desto stärker steigen die Token-Kosten quadratisch, wodurch die Wirtschaftlichkeit zusammenbricht
3. Schwieriges Tool- und Feedback-Design: Nicht technische Grundgrenzen, sondern das Design von Tools und Feedback-Systemen, die Agenten sinnvoll nutzen können, ist die größte Herausforderung

Die mathematische Realität der Fehlerakkumulation

• Mehrstufige autonome Workflows sind wegen kumulativer Fehler im realen Betriebsmaßstab nicht umsetzbar
• Selbst wenn jede Stufe 95 % Zuverlässigkeit hätte, läge die endgültige Erfolgsrate bei 20 Stufen nur bei 36 % (Anforderung in der Produktion: 99,9 % oder mehr)
• Selbst bei angenommener hoher Zuverlässigkeit steigt mit jeder zusätzlichen Stufe die Ausfallwahrscheinlichkeit stark an
• In der Praxis werden Prozesse daher nicht vollständig automatisiert, sondern mit unabhängigen Verifikations- und Rollback-Punkten sowie menschlicher Kontrolle entworfen
• Muster erfolgreicher Agentensysteme: klar begrenzter Kontext, verifizierbare Aufgaben und menschliche Entscheidungen an kritischen Punkten

Token-Kostenstruktur und wirtschaftliche Grenzen

• Die Token-Kosten für das Aufrechterhalten des Context Window und laufender Gespräche werden bei der Skalierung des Systems zu einer unwirtschaftlichen Realität
• Gesprächsbasierte Agenten müssen jedes Mal den gesamten Gesprächsverlauf verarbeiten, weshalb die Kosten mit jeder weiteren Runde quadratisch steigen
• Eine Unterhaltung über 100 Runden verursacht allein an Token-Kosten 50–100 US-Dollar; bei vielen Nutzern bricht die Wirtschaftlichkeit zusammen
• Dagegen sind zustandslose Single-Slot-Agenten zur Funktionsgenerierung ohne Kontextbedarf bei Kosten und Skalierbarkeit im Vorteil
• Die erfolgreichsten Produktionsagenten ähneln eher „smarten Tools mit klarem Zweck“ als „dialogorientierten Agenten“

Die Hürde von Tool-Design und Feedback-Systemen

• Die eigentliche Schwierigkeit bei der Entwicklung produktiver Agenten ist die von bestehenden Teams oft unterschätzte Fähigkeit zum Tool-Design
• Die Genauigkeit von Tool Calls ist zwar gestiegen, aber entscheidend ist das Design, um komplexe Zustände und Ergebnisse wirksam zusammenzufassen und dem Agenten als Feedback zu geben
• Beispiele:
  • Wenn eine Aufgabe nur teilweise erfolgreich war, muss entschieden werden, wie viele Informationen und welche Art von Zusammenfassung nötig sind
  • Wenn ein Query-Ergebnis etwa 10.000 Treffer liefert, braucht es eine Abstraktion zur Zustandserfassung wie „Erfolg, 10.000 Einträge, nur die ersten 5 anzeigen“
  • Bei Tool-Fehlern muss die Menge an Wiederherstellungsinformationen gesteuert und eine Verunreinigung des Kontexts vermieden werden
• Der Kern tatsächlich erfolgreicher Datenbank-Agenten: strukturierte Feedbacks bereitzustellen, mit denen der Agent real Entscheidungen treffen kann
• In der Realität übernimmt AI nur etwa 30 % der Arbeit; die restlichen 70 % entfallen auf klassische Engineering-Kompetenzen wie Tool-Feedback, Recovery und Kontextmanagement

Grenzen der Integration in reale Systeme

• Selbst wenn Zuverlässigkeit und Kosten gelöst wären, wirkt die Integration mit der realen Welt als weitere Hürde
• Reale Unternehmenssysteme bieten keine konsistente API; sie enthalten unvorhersehbare Komplexität wie Legacy-Eigenschaften, Sonderfehler, wechselnde Authentifizierung, variable Limits und Compliance-Vorgaben
• Ein echter Datenbank-Agent benötigt zwingend klassisches Programmieren für Connection-Pool-Management, Transaction-Rollback, den respektvollen Umgang mit Read-Only-Replikaten, Query-Timeouts, Logging usw.
• Das Versprechen, „AI integriere den gesamten Stack vollkommen autonom“, stößt beim tatsächlichen Aufbau an harte Realitätsgrenzen

Muster dafür, was in der Praxis wirklich gut funktioniert

• Gemeinsame Prinzipien erfolgreicher Agentensysteme
  1. UI-Generierungsagenten: Das Nutzererlebnis wird am Ende von Menschen geprüft (AI übernimmt nur die Komplexität der Umwandlung von natürlicher Sprache in React)
  2. Datenbank-Agenten: Destruktive Aktionen werden immer von Menschen bestätigt (AI übernimmt nur die SQL-Umwandlung, Menschen behalten die Kontrolle über die Datensicherheit)
  3. Funktionsgenerierungsagenten: Arbeiten nur innerhalb klarer Spezifikationen (keine Zustände, Nebenwirkungen oder komplexen Integrationen)
  4. DevOps-Automatisierung: AI erzeugt den Infrastruktur-Code, Deployment, Versionsverwaltung und Recovery bleiben in bestehenden Pipelines
  5. CI/CD-Agenten: Jede Stufe wird mit klaren Erfolgskriterien und Rollback-Mechanismen entworfen
• Zusammenfassung des Musters: AI verarbeitet Komplexität, Menschen behalten die Kontrolle, und klassische Engineering-Praxis sorgt für Zuverlässigkeit

Marktausblick und Prognose

• Venture-Startups, die vollautonome Agenten in den Vordergrund stellen, werden zuerst auf Rentabilitätsprobleme stoßen
• Bei einem 5-stufigen Workflow mag die Demo glänzen, doch reale Unternehmen verlangen 20 oder mehr Stufen und stoßen damit an mathematische Grenzen
• Unternehmen, die ihrer bestehenden Software einfach AI-Agenten hinzufügen, riskieren wegen mangelnder realer Integration eine stagnierende Akzeptanz
• Die wirklichen Gewinner werden Teams sein, die in klar abgegrenzten Domänen AI nur auf schwierige Aufgaben anwenden und bei wichtigen Entscheidungen Menschen und Randbedingungen einbeziehen
• Der Markt wird den Unterschied zwischen „AI, die in Demos funktioniert“ und „wirklich zuverlässiger AI“ voraussichtlich durch teure Erfahrungen lernen

Wünschenswerte Prinzipien für den Aufbau von Agentensystemen

• Klare Grenzziehung: Die Rolle des Agenten und die Übergabepunkte an Menschen/bestehende Systeme klar definieren
• Für Fehler entwerfen: Bei AI-Fehlern sind Rollback- und Recovery-Strukturen unverzichtbar
• Wirtschaftlichkeit prüfen: Die Struktur auf Kosten pro Interaktion und Skalierung auslegen (zustandslos ist wirtschaftlicher als zustandsbehaftet)
• Zuverlässigkeit vor Autonomie: Ein konsistent funktionierendes System gewinnt mehr Vertrauen als eines, das nur gelegentlich Magie zeigt
• Auf robuster Grundlage bauen: Nur die schwierigen Teile (Intent-Erkennung, Generierung usw.) an AI delegieren, den Rest (Ausführung, Fehlerbehandlung usw.) klassischer Software überlassen

Die wirkliche Lehre aus der Praxis

• Zwischen „funktioniert in der Demo“ und „funktioniert im realen Betrieb in großem Maßstab“ besteht eine sehr große Lücke
• Agenten-Zuverlässigkeit, Kostenoptimierung und Integrationskomplexität sind branchenweit weiterhin ungelöste Kernprobleme
• Echte Umsetzungserfahrung und ehrlicher Erfahrungsaustausch sind entscheidend für den Fortschritt der Branche
• Je mehr Praktiker über vernünftige Methoden und realistische Fehlschläge diskutieren, desto höher sind die Erfolgschancen insgesamt

[GN⁺]

Hacker-News-Kommentar

• Ich habe einmal mit einem AI-Production-Engineer bei Amazon gesprochen; laut dieser Person gibt es derzeit kein Unternehmen, das generative AI allein dort einsetzt, wo direkt mit Kunden gesprochen wird. Alle automatischen Antworten würden mit älterer, nicht-generativer „klassischer“ Technik laufen, weil die Zuverlässigkeitsprobleme generativer AI zu groß seien, um den Ruf eines Unternehmens davon abhängig zu machen.

  • Früher habe ich mich sehr für Agenten interessiert, die „klassische AI“, also symbolische Verfahren, mit traditionellem Machine Learning kombinieren, aber am Ende habe ich meist mit neuronalen Netzen aus der Vor-Transformer-Ära gearbeitet. Letztlich baut man immer zuerst ein System mit menschlichem Eingriff und sammelt damit Evaluations- und Trainingsdaten. Danach übernimmt das System einen Teil der Arbeit und verbessert damit auch die Qualität des verbleibenden Teils. Gerade bei „subjektiven“ Aufgaben muss man symbolische Systeme unbedingt mitbewerten. Wenn man ein System trainieren will, kommt man um Evaluation ohnehin nicht herum.

  • Tatsächlich führen viele Tech-Unternehmen generative AI bereits im Live-Chatbot-Kundensupport ein. Ich kenne etwa Sonder und Wealthsimple. Wenn das LLM eine Anfrage nicht beantworten kann, wird das Gespräch sofort an einen menschlichen Support-Mitarbeiter übergeben.

• Ein Punkt, der noch nicht diskutiert wurde, ist das Context Window. Menschen können in ihrem Fachgebiet effektiv mit einem „fast unendlichen“ Kontext umgehen. Modelle können diese Grenze mit größeren und vielfältigeren Trainingsdaten teilweise überwinden, aber ich halte das nicht für eine echte Lösung. Derzeit müssen Menschen ihren eigenen Kontext komprimiert in Prompts unterbringen, und in flexiblen Sprachen wie Englisch fühlt sich das eher wie Zaubersprüche aufsagen oder Raten an als wie Engineering. Im Vergleich zu deterministischen Verfahren fühlt es sich an, als ginge dabei ein großer Teil der Daten verloren.

  • Beim Menschen sind „Kontext“ und „Gewichte“ nicht fest und getrennt voneinander abgegrenzt. Erfahrungen und Ergebnisse verändern mit der Zeit meine eigenen „Gewichte“ ständig, aber bei LLMs sind die Gewichte architektonisch schreibgeschützt, daher ist das dort nicht möglich.

  • Ich bin skeptisch, ob Menschen wirklich so ein riesiges Kontextfenster haben. Bei der Lösung komplexer Probleme stoße ich oft an die Grenzen meines spezifisch menschlichen „Kontextfensters“. Ich würde gern wissen, ob es dafür tatsächlich Beispiele gibt.

• Meine Erfahrung mit AI-Tools war insgesamt eher positiv. Sie helfen sehr dabei, kleine Aufgaben zu übernehmen, wenn man eine Pause braucht, oder Arbeit zu strukturieren und anzustoßen. Aber Kosten werden schnell zum Problem. Wenn man zum Beispiel Claude Code auf einer großen Codebasis nutzt, kostet das in 1–2 Stunden etwa $25. Mit automatisierter Korrektur steigt das auf bis zu $50/hr. Es gibt einen Trade-off zwischen Geschwindigkeit, Genauigkeit und Kosten. Auch bei den heutigen Agenten ist noch unklar, wo genau sie in diesem Dreieck liegen. Viele Experimente sind spannend, aber ich halte das weiter für riskant.

  • Etwas zynisch betrachtet passt die Struktur, bei der ein LLM sich selbst ständig neu promptet, um Fehler zu korrigieren, und der Ansatz „Kein RAG nötig! Wirf einfach den gesamten Code in ein Kontextfenster mit 1m Tokens“ am Ende perfekt zu einem Geschäftsmodell mit Abrechnung pro Token.

  • Eine Idee, über die ich in letzter Zeit nachdenke, ist eine Struktur, in der AI von Anfang an mehrere Commit-Entwürfe erzeugt und diese Ergebnisse dann von Menschen oder automatisiert gefiltert und manuell verfeinert werden. Je größer die Aufgabe, desto höher die Wahrscheinlichkeit, dass kleine frühe Abweichungen das Gesamtergebnis ruinieren. Deshalb spart es selbst mit dem aktuellen SOTA Zeit für manuelles Refactoring, wenn Agenten mehrere Varianten parallel ausprobieren. Ich habe dazu einmal etwas auf GitHub geschrieben.

  • Ich würde gern fragen, ob das ein Abo-Service ist.

• Menschliche mehrstufige Workflows haben normalerweise Verifikations-Checkpoints, weil auch Menschen nicht zu mehr als 99 % korrekt sind. Zukünftige Agenten werden wohl ebenfalls mit Verifikationsprozessen um ihre Ausgaben herum entworfen und darauf trainiert, diesen Prozess zu bestehen, bevor sie zum nächsten Schritt weitergehen. Man könnte auch vorab eine Risikobewertung machen, etwa nach dem Muster: „Hier brauchen wir auf jeden Fall mehr als 99 % Genauigkeit.“

  • Claude Code hält vor jedem Arbeitsschritt immer wieder an und fragt den Nutzer, ob weitergemacht werden soll, und zeigt die vorgeschlagenen Änderungen vorher an. Das ist wirksam, um Token-Verschwendung und ineffiziente Arbeit zu verhindern.

  • Viele Anwendungen müssen wohl ebenfalls an diese Struktur angepasst und neu entworfen werden. Ich denke, Microservices-Architekturen passen gut zu LLMs und könnten deshalb wieder populär werden.

• Ich stimme der Aussage zu, dass „das eigentliche Problem nicht die Fähigkeiten der AI sind, sondern das Design von Tools und Feedback-Systemen, die Agenten tatsächlich effektiv nutzen können“. Weil ich unsicher war, wie der Markt das aufnehmen würde, habe ich erst nur still mitgelesen und bin dann zu einem sehr kleinen Startup gewechselt, das auf den Bau von Agenten spezialisiert ist. In fünf Monaten bin ich von Skepsis zu Zustimmung und dann zu Überzeugung gelangt. Wenn man den Themenbereich sehr eng fasst und sich auf das Tooling konzentriert, das das Modell zum Arbeiten braucht, erlebt man hohe Erfolgsquoten. Es gibt eine Tendenz, die nichtdeterministische Natur abzulehnen, aber mit exzellentem Tooling und immer engerem Scope ist das in der Praxis ziemlich brauchbar. Das Tooling selbst wirkt schwierig, aber ich glaube, es lässt sich ganz ordentlich lösen. Ich bin optimistisch für die Zukunft.

• Ich halte das alles für lösbare Probleme. Viele Startups konzentrieren sich nur nicht darauf, weil sie im Wettlauf um schnelles ARR stehen. Die Meinung, Agenten seien längst nicht so nützlich wie versprochen, ist nicht völlig falsch, aber in Wirklichkeit ist das ein Engineering-Problem. Mit einem anderen Ansatz wird es meiner Meinung nach funktionieren, ich persönlich setze eher auf RL. Zum Beispiel braucht man gute Verifier. Viele Aufgaben sind leichter zu verifizieren als direkt auszuführen. Schon mit fünf parallel erzeugten Ergebnissen, die jeweils nur 80 % Genauigkeit haben, liegt die Wahrscheinlichkeit bei 99,96 %, dass mindestens eines korrekt ist, und ein Verifier kann dieses auswählen. Auch in Multi-Step-Szenarien wird das mathematisch vorteilhaft. Das ist ein anderer Ansatz als bisher. Im Artikel wird ebenfalls von einem Workflow-Paradigma mit 3 bis 5 Schritten gesprochen, und das passt in der Praxis sehr gut. Wir brauchen künftig mehr solcher Modelle.

  • Ich finde das Argument plausibel, dass Verifikation bei vielen Aufgaben in Wirklichkeit schwieriger ist als die Aufgabe selbst. Gerade im Software-QA-Umfeld wurde mit dieser Logik oft umstrukturiert, und ich habe das Gefühl, dass die Qualität darunter gelitten hat. Verifier werden extrem schwierig, weil die Zahl möglicher Zustände des Systems und der Außenwelt geometrisch wächst. LLMs sind in solchen komplexen Arbeitsumgebungen attraktiv, weil sie repetitive Fleißarbeit übernehmen können, etwa Abhängigkeiten zu mocken oder Daten vorab zu befüllen. Aber damit Verifikationstests sinnvoll sind, gibt es am Ende immer die Forderung, dass sie 100 % korrekt sein müssen, und dadurch braucht man für jede Vorbedingung wieder einen weiteren Verifier. Wenn am Ende jeder Schritt 100 % sein muss, sinkt die kumulative Wahrscheinlichkeit entsprechend. Menschen testen meist vorsichtig für bestimmte Fälle und verifizieren nicht jede Möglichkeit vollständig; Whitebox-Tests sind viel üblicher als Blackbox-Tests. Wenn LLMs viel Code erzeugen, muss der Bearbeiter am Ende dennoch den gesamten Code verstehen, damit Whitebox-Verifikation möglich ist, und dann schrumpft der Zeitgewinn wieder. Im Moment erzeugt das LLM etwas und ich muss alle Fehler selbst beheben, wodurch ich weniger Vertrauen habe und mehr Zeit verliere. In manchen Situationen kann man das lösen, indem man Interfaces an die Erwartungen des LLM anpasst, aber das ist nicht allgemein einsetzbar. Außerhalb von Software ist Verifikation oft ganz unmöglich, etwa bei „Wähle die fünf vielversprechendsten Game-Startups aus“, weil das objektiv nicht verifizierbar ist. Wenn man solche Bereiche blind einer Maschine statt einem Menschen überlässt, lässt sich das hinterher nicht mehr einfangen.

  • Ich frage mich, ob man überhaupt annehmen kann, dass fünf Generierungen voneinander unabhängig sind.

  • Das stimmt. In der Praxis ist es effektiv, mehrere Agenten Dinge ausprobieren zu lassen, mehrfach zu iterieren und verschiedene Lösungen anzuwenden. Ich habe tatsächlich Fälle erlebt, in denen negatives Feedback bei einem Ansatz kam und dann ein anderer Ansatz erfolgreich war.

• Ich finde es überraschend, dass eine einzelne Person oder ein extrem kleines Team mehr als 12 AI-Agenten gebaut hat, die in Entwicklung, DevOps, Data Operations und ähnlichen Bereichen tatsächlich produktiv im Einsatz sind. Wenn man sich die Ausfallrate von Startups ansieht, ist schon „ein“ gutes Produkt schwer genug, deshalb sind 12 besonders bemerkenswert. Wir haben mit Tools wie Definite, also Data-Stack-plus-AI-Agent-Tools, zwei Jahre gebraucht, bis es vor etwa sechs Monaten endlich ganz ordentlich wurde. Definite

  • Gemeint sind in Wirklichkeit keine 12 unabhängigen Produkte, sondern 12 sehr spezifische Tools für den jeweiligen Bedarf im eigenen Job. Wie das Gesamtthema des Artikels zeigt, werden Agenten nur dann nützlich, wenn sie sich auf sehr einfache und klar definierte Zwecke konzentrieren.

  • Dass jemand neben einer Vollzeitstelle über drei Jahre hinweg mehr als 12 davon gebaut haben soll, klingt trotzdem etwas seltsam.

• Es ist auch mein Beruf, Agenten beziehungsweise AI-Automatisierung zu entwickeln. Open-ended Coding Agents sind einfach eine dumme Idee. Menschliche Verifikations-Checkpoints, kleine Suchräume und sehr spezifische Fragen oder Prompts, etwa „Enthält diese E-Mail eine Rechnung, JA/NEIN“, sind realistisch. Ich verstehe den Wunsch nach vollautomatischen Agenten, aber technologisch sind wir noch nicht so weit. Ich fasse keine Content-Erzeugung an, also weder Text, Bilder noch Code, weil einem das am Ende ohnehin um die Ohren fliegt.

  • Auch ich reduziere mein Arbeitspensum mithilfe von Agent-Frameworks und Chat Coding, also kommunikationsbasiertem Coding, um etwa 50 %. Mit GPT habe ich dabei real messbare Effekte erlebt. Aber ungefähr jedes zehnte Mal tritt sicher ein Fehler auf. Ich glaube nicht, dass sich diese Fehlerrate beheben lässt, solange sich die LLM-Architektur nicht grundlegend ändert. Solange der Hype das Vertrauen der Entwickler nicht komplett zerstört, bin ich dennoch überzeugt, dass künftig sehr viel robustere Systeme entstehen werden. Der Produktivitätsgewinn ist so deutlich, dass wir im Team real erheblich weniger Leute einstellen können als früher. Auch die Lernkurve bei vielen Themen ist drastisch gesunken, weil LLMs den Qualitätsverlust der Google-Suche kompensieren. In automatisierten Workflows ist ein Orchestration Framework am wichtigsten, in dem LLMs einen Teil der menschlichen Arbeit übernehmen. Das LLM sollte auch seine eigene Sicherheit mit angeben, und wenn der Confidence-%-Wert niedrig ist, sollte der Fall sofort an einen Menschen übergehen. Wenn Tests, Guardrails und Ähnliches gut aufgesetzt sind, können zumindest nicht-kritische Aufgaben menschliche Arbeit durchaus ersetzen. Es geht nicht darum, Menschen zu ersetzen, sondern durch Automatisierung von Arbeit die Teamgröße zu reduzieren. Als Beispiel bin ich überzeugt, dass LLMs bei großen E-Commerce-Anbietern eines Tages Produktbeschreibungen, Bildprüfung, Tippfehler und Bild-Inkonsistenzen übernehmen werden, also Aufgaben, die heute Menschen machen.

  • Im Großen und Ganzen stimme ich zu, aber mit so einem Ansatz bleibt am Ende vielleicht nur „einfach ein teures Workflow-System“ übrig. Ich frage mich, ob es überhaupt nötig ist, dafür ein LLM zu verwenden, wenn ältere Technologien das ebenfalls könnten.

  • Ich stimme ebenfalls zu. Im Moment sind Agenten ideal für „eng begrenzte, risikoarme, repetitive und langweilige Arbeit“. Als Beispiel habe ich meine Erfahrung mit Agenten für unterstützende Aufgaben rund um Dev-Log-Markdown hier festgehalten.

  • Dass menschliche Verifikation am zuverlässigsten ist, um Checkpoints zu schaffen, stimmt, aber zusätzlich gibt es noch viele andere Ansätze wie Unit-Tests oder ad-hoc-Validierung des Gesamtsystems.

• Ich glaube tatsächlich, dass der Autor bei autonomen Agenten sogar noch optimistischer sein sollte als derzeit. 90 % von dem, was heute gemacht wird, war Anfang 2024 noch unmöglich. Man sollte die Entwicklungskurve nicht unterschätzen.

• Ich sehe das genauso. Dazu gibt es auch diesen Blogbeitrag. Der Kernunterschied ist, dass HITL (Human in the loop) hilft, Fehler zu reduzieren, während HOTL (Human out of the loop) im Gegenteil eher Probleme erzeugt.