Ein Gespräch mit Enrico Papalini über 'Non-Deterministic Loop Engineering'

Als wir vor einem Jahr mit Enrico Papalini über sein erstes Buch sprachen, war das zentrale Thema ein gebrochener stiller Pakt: der zwischen Entwicklern und deterministischen Maschinen, der in dem Moment zerbrach, als der Code aufhörte, immer und unter allen Umständen genau das zu tun, was ihm aufgeschrieben wurde. Papalini, Head of Software Development für Issuances, Custody, Data & UX/UI Solutions bei Euronext Securities, mit einer Vergangenheit bei der London Stock Exchange Group und der Borsa Italiana, erzählte von diesem Übergang mit der Stimme von jemandem, der Systeme verwaltet, in denen Fehler keine vertragliche Option, sondern ein Störfall sind.

Seitdem hat sich das Gespräch weiterentwickelt. Es reicht nicht mehr aus zu fragen, was passiert, wenn ein Modell eine falsche Antwort generiert. Denn die eigentliche Frage lautet, was passiert, wenn dieses Modell stundenlang alleine weiterarbeitet, Entscheidungen trifft, Werkzeuge nutzt, Dateien modifiziert, ohne dass jemand jeden einzelnen Schritt überwacht. Hieraus entsteht sein neues Buch Non-Deterministic Loop Engineering, das sich nicht mehr dem einzelnen Output widmet, sondern dem Loop, der ihn erzeugt, verifiziert und entscheidet, ob er neu gestartet werden soll.

Wir haben den Faden mit ihm wieder aufgenommen und uns dieses Mal auf ein einziges Objekt konzentriert: den Loop, seine Architektur, seine Risiken und die Fragen, die er offen lässt.

Vom Pakt zum Loop

Die ersten beiden Fragen dienen dazu zu verstehen, warum Papalini sich dafür entschieden hat, den Loop als eigenständige Disziplin zu isolieren, und ob es sich wirklich um etwas Neues oder nur um ein Rebranding bereits bekannter Ideen im Softwarebereich handelt.

Ich frage ihn, was ihn nach der Schilderung des Übergangs vom Determinismus zum Nicht-Determinismus dazu bewogen hat, ein ganzes Buch speziell dem Loop zu widmen, und wie er es in einem einzigen Satz jemandem erklären würde, der nicht vom Fach ist.

"Prompt Engineering lehrt uns, mit einem Modell zu sprechen. Loop Engineering entwirft das, was passiert, wenn das Modell weiterarbeitet, selbst nachdem wir aufgehört haben, mit ihm zu sprechen", antwortet Papalini. "Es ist dieser Übergang, der mich dazu bewogen hat, das Buch zu schreiben. Solange wir die KI als Assistenten nutzen, ist der Zyklus einfach: Wir stellen eine Frage, erhalten eine Antwort und bewerten sie. Der Mensch behält bei jedem Schritt die Kontrolle. Wenn wir jedoch einen Agenten einführen, übertragen wir ihm ein umfassenderes Ziel. Das System liest den Zustand der Arbeit, wählt eine Aktion aus, nutzt Werkzeuge, ändert Dateien oder Daten, überprüft das Ergebnis und entscheidet, ob es fortfahren soll. Zu diesem Zeitpunkt ist das Modell nicht mehr das System. Es ist nur noch eine Komponente des Systems. Das eigentliche ingenieurtechnische Objekt wird der Loop, der es umgibt: Wo bewahren wir das Ziel auf, wie stellen wir den Zustand dar, welche Werkzeuge kann es nutzen, wer verifiziert das Ergebnis, wie oft kann es einen Neustart versuchen, wie viel darf es ausgeben und wann muss es die Kontrolle an eine Person zurückgeben. Ich habe den Loop isoliert, weil viele Unternehmen von Copiloten zu Agenten übergehen und diese Veränderung so behandeln, als handele es sich um eine bloße Leistungssteigerung des Modells. Das ist es nicht. Wenn Unternehmen von Copiloten zu Agenten übergehen, ist das ein Wandel in der Kontrollarchitektur."

Die zweite Frage ist die unbequemste, und ich stelle sie ihm ohne Umschweife: Im Buch unterscheidet er vier Ebenen – Prompt, Context, Harness und Loop Engineering –, und dennoch formalisierte ReAct bereits Denk- und Aktionszyklen, während das Maker-Checker-Prinzip schon lange vor der KI existierte. Benennt er hier nicht einfach bereits etablierte Patterns um?

"Das ist eine berechtigte Frage, und die ehrliche Antwort ist, dass fast kein Element des Loop Engineering, einzeln betrachtet, völlig neu ist", gibt er zu. "Der Beobachtungs-Aktions-Zyklus existiert seit Jahrzehnten. Das Maker-Checker-Prinzip ist die Basis von Code Reviews, der Aufgabentrennung und vieler Kontrollsysteme. Retry, Timeout, Circuit Breaker, Arbeitswarteschlangen und menschliche Aufsicht sind keine Erfindungen der generativen KI. Die Neuheit liegt nicht im einzelnen Baustein, sondern darin, dass diese Bausteine um einen nicht-deterministischen Ausführer herum neu zusammengesetzt werden müssen. Es ist ähnlich wie das, was bei DevOps passiert ist. DevOps hat das Deployment, das Monitoring, die Versionierung oder die Automatisierung nicht erfunden. Es hat erkannt, dass diese Mechanismen als ein einziges operatives und organisatorisches System konzipiert werden müssen, um kontinuierlich zuverlässige Software zu produzieren. Loop Engineering versucht, etwas Ähnliches für Agenten zu tun. ReAct beschreibt ein Pattern, bei dem das Modell zwischen Denken und Handeln abwechselt. Es legt nicht zwangsläufig fest, wo die dauerhafte Absicht leben soll, wer die Autorität hat, die Arbeit als abgeschlossen zu erklären, wie die Akzeptanzkriterien geschützt werden müssen oder wie viel der Zyklus kosten darf. Ein Pattern erklärt, wie ein Teil des Verhaltens funktionieren kann. Eine Disziplin muss auch erklären, wie man es einschränkt, beobachtet, verifiziert und unterbricht."

Maker, Checker, Ralph

Hier dringen wir in den technischen Kern der Methode vor, mit zwei operativen Patterns, die das Buch in den Mittelpunkt stellt: der Trennung von Maker und Checker und dem sogenannten Ralph Loop.

Ich frage ihn nach dem offensichtlichsten Risiko: Auch der Checker kann ein probabilistisches Modell sein. Wie geht man also mit der Gefahr einer "hallucinated approval" um – einer Freigabe durch einen Kontrolleur, der eine fehlerhafte Arbeit absegnet, insbesondere wenn Maker und Checker dieselben blinden Flecken teilen?

"Maker und Checker zu trennen, ist notwendig, aber nicht ausreichend", erklärt Papalini. "Wenn ich ein Modell bitte, ein Ergebnis zu erzeugen, und dann dasselbe Modell, vielleicht in derselben Konversation, frage, ob das Ergebnis korrekt ist, habe ich keine wirklich unabhängige Kontrolle aufgebaut. Ich habe lediglich das System gebeten, seine eigene Arbeit zu genehmigen. Das Risiko steigt, wenn Maker und Checker dasselbe Modell, denselben Kontext, dieselben Beispiele und dieselbe implizite Interpretation des Ziels teilen. Sie können zwei unterschiedliche Agenten sein und trotzdem denselben blinden Fleck haben. Deshalb spreche ich im Buch von geschützter Verifikation. Wenn möglich, sollte sich der Checker nicht darauf beschränken, eine sprachliche Meinung zu äußern. Er sollte sich auf externe Signale stützen: Tests, Kompilierung, statische Analyse, Schema-Constraints, Richtlinien, Referenzdaten, Simulationen oder deterministische Kontrollen. Im Softwarebereich ist es beispielsweise viel besser, den Checker anzuweisen, eine Testsuite auszuführen, als ihn zu fragen, ob der Code 'korrekt aussieht'. Wenn eine deterministische Verifizierung nicht möglich ist, können wir das Risiko verringern, indem wir Kontexte trennen, explizite Rubriken verwenden, unterschiedliche Modelle einsetzen oder bei risikoreichen Fällen menschliche Prüfer hinzuziehen. Aber wir müssen ehrlich sein: Ein zweites Modell verwandelt ein probabilistisches Ergebnis nicht auf magische Weise in eine Wahrheit. Der Checker beseitigt die Unsicherheit nicht. Er macht sie sichtbarer und beherrschbarer."

Kommen wir zum Ralph Loop, einem der operativen Patterns, von denen das Buch ausgeht. Ich frage ihn, wie er in der Praxis funktioniert und vor allem, wo er typischerweise scheitert – ob er Fälle beobachtet hat, in denen der Loop kontinuierlich weiterarbeitete, ohne echten Fortschritt zu erzielen.

"Der Ralph Loop basiert auf einer fast schon provokant einfachen Idee: Man gibt einem Agenten ein dauerhaftes Ziel und startet ihn mehrmals mit einem frischen Kontext neu, sodass er bei jeder Iteration den Zustand des Repositories liest und den nächsten Schritt wählt", erzählt er. "Seine Stärke liegt genau in dieser Einfachheit. Er verringert die Abhängigkeit von einer extrem langen Konversation, macht die Arbeit persistent und ermöglicht es dem Agenten, dort anzusetzen, was tatsächlich auf der Festplatte existiert, anstatt sich nur auf das Chat-Gedächtnis zu verlassen. Aber diese Einfachheit verdeutlicht auch die Grenzen. Ein Loop kann wiederholt dieselben Dateien ändern, einen Test reparieren und dabei einen anderen beschädigen, einen Teil als abgeschlossen deklarieren, den er nicht wirklich überprüft hat, oder Iterationen verbrauchen, ohne den Abstand zum Ziel zu verringern. Er kann sehr aktiv sein, ohne wirklich produktiv zu sein. In meinen Experimenten war eines der häufigsten Verhaltensweisen kein spektakulärer Fehlschlag, sondern Stagnation: Das System erzeugt kontinuierlich kleine Variationen um dasselbe Problem herum. Wenn wir nach diesem Muster vorgehen, verhält sich das System wie eine Person, die ihre Schlüssel immer in derselben Schublade sucht, weil sie überzeugt ist, dass sie dort sein müssen. Deshalb ist der Ralph Loop ein guter Ausgangspunkt, aber keine vollständige Architektur. Man muss externe Erfolgskriterien, die Erkennung von fehlendem Fortschritt, Budgets, Grenzen für Änderungen, Checkpoints und Eskalationspfade hinzufügen. Was spezifische Unternehmensbeispiele betrifft, kann ich nicht über interne, nicht öffentliche Verhaltensweisen sprechen. Das Buch unterscheidet bewusst zwischen Experimenten, analytischen Modellen und Systemen, die tatsächlich in der Produktion validiert wurden. Es stünde im Widerspruch zur These des Buches, eine begrenzte Erfahrung als universellen Beweis darzustellen."

Die versteckten Kosten

Hier greift das Buch zwei unabhängige Kritikpunkte auf, den ökonomischen und den architektonischen, und ich konfrontiere ihn mit beiden.

Papalini führt das Konzept der Kosten pro akzeptiertem Ergebnis ein. Ich gebe zu bedenken, dass die Automatisierung es erleichtert, die Modellaufrufe zu multiplizieren. Riskieren wir mit dem Loop Engineering also nicht, den Gesamtverbrauch zu erhöhen, während wir eigentlich versuchen, ihn zu optimieren?

"Ja, das Risiko besteht. Es wäre sogar naiv, das zu leugnen", antwortet er. "Wenn die wahrgenommenen Grenzkosten einer Aktion sinken, neigen wir dazu, sie häufiger zu nutzen. Das ist der Mechanismus hinter dem Jevons-Paradoxon: Eine effizientere Technologie kann den Gesamtverbrauch steigern, weil sie es attraktiv macht, viel mehr Dinge zu tun. Bei der KI passiert das bereits. Wenn ein Agent zehn Implementierungen generieren kann, während wir schlafen, besteht das Risiko, dass wir am Morgen zehn Implementierungen vorfinden, die wir verstehen, verifizieren und vielleicht verwerfen müssen. Deshalb ist die Anzahl der Tokens allein ein schlechter Indikator. Aber auch das Gegenteil ist der Fall: Diejenigen zu belohnen, die weniger Tokens verbrauchen, bedeutet nicht automatisch, diejenigen zu belohnen, die mehr Wert schaffen. Die Kennzahl, die ich vorschlage, sind die Kosten pro akzeptiertem Ergebnis. In diese Berechnung fließen nicht nur die Tokens ein. Es fließen Fehlversuche, Verifikationszeit, Infrastruktur, menschliche Arbeit, Nacharbeit (Rework) und das operationelle Risiko ein. Ein Loop, der 20 Euro kostet und ein verifiziertes Ergebnis liefert, kann günstiger sein als ein einzelner 2-Euro-Aufruf, der einen Fehler verursacht, der erst drei Wochen später entdeckt wird. Umgekehrt ist ein Agent, der stundenlang an einer marginalen Aufgabe arbeitet, einfach eine effiziente Maschine zur Budgetverbrennung. Der Punkt ist nicht, jeden Aufruf zu minimieren. Wenn wir Aufrufe tätigen, müssen wir jede Iteration durch eine messbare Verringerung der Unsicherheit oder des Abstands zum Ziel rechtfertigen."

Der andere Kritikpunkt betrifft den Lock-in-Effekt bei den Anbietern und das, was er im Buch als konzeptionelle Schuld bezeichnet. Ich frage ihn, was von einem heute gebauten System wirklich übrig bleibt, wenn das verwendete Modell in einem Jahr bereits veraltet ist.

"Das ist einer der Gründe, warum ich es für sinnvoll halte, den Fokus vom Modell auf den Loop zu verlagern", sagt er. "Wenn ein Unternehmen alles um die proprietären Funktionen eines einzelnen Anbieters herum aufbaut, ist der Lock-in unvermeidlich. Das betrifft nicht nur die APIs. Es betrifft das Format der Werkzeuge, den Speicher, das Caching, die System-Prompts, die Richtlinien, die Evaluierungssysteme und sogar die Gewohnheiten der Mitarbeiter. Der beste Weg, den Lock-in zu verringern, besteht nicht darin, so zu tun, als seien alle Modelle austauschbar. Heute sind sie es nicht. Sie haben unterschiedliche Fähigkeiten, Kosten, Latenzen und Betriebsmodi. Man muss jedoch das, was sich schnell ändert, von dem trennen, was von Dauer sein sollte. Das Modell sollte in einem vernünftigen Rahmen ein austauschbarer Ausführer sein. Die Absicht, der Zustand der Arbeit, die Akzeptanzkriterien, die Berechtigungen, die Nachweise und die Historie der Entscheidungen sollten außerhalb des Modells leben und, soweit wie möglich, außerhalb des Produkts des Anbieters. In einem Jahr ändern wir vielleicht Claude, GPT, Gemini oder ein lokales Modell. Aber der Plan, die Tests, die Regeln, die Daten und die Fähigkeit zu rekonstruieren, warum das System eine Entscheidung getroffen hat, sollten erhalten bleiben. Hinzu kommt die Verständnisschuld. Wenn wir Code oder Dokumente in Batches schneller generieren, als wir sie lesen können, beseitigen wir die Arbeit nicht: Wir verschieben sie mit Zinsen in die Zukunft. Der gefährlichste Lock-in ist nicht immer der technologische. Es ist die Abhängigkeit von Ergebnissen, die niemand im Unternehmen mehr erklären kann."

Die verlorene Lehrzeit

Kommen wir zu den operativen Schwachstellen, die eher die Menschen als die Architektur betreffen.

Ich stelle ihm die Frage, die ich für die heikelste halte: Wenn jüngere Fachkräfte ihre Zeit damit verbringen, Agenten zu beaufsichtigen, anstatt selbst Code zu schreiben, zu analysieren und zu debuggen, wie sollen sie dann die notwendige Erfahrung sammeln, um Senior-Entwickler zu werden? Riskieren wir nicht, Loop-Architekten auszubilden, die nicht wissen, was in ihrem Inneren vorgeht?

"Das ist wahrscheinlich das ernsteste gesellschaftliche Risiko der gesamten Transformation", gibt er ohne Zögern zu. "Man wird nicht zum Experten, indem man nur korrekte Lösungen studiert. Man wird zum Experten, indem man auf Fehler stößt, falsche Annahmen trifft, schwierigen Code liest, einen Bug durch verschiedene Ebenen des Systems verfolgt und lernt, schwache Signale zu erkennen. Wenn wir genau diesen Teil des Weges an die KI delegieren, erhalten wir vielleicht vermeintlich hochproduktive Juniors, denen jedoch die mentalen Modelle fehlen, um zu erkennen, wann das System Fehler macht. Das Paradoxon ist offensichtlich: Wir verlangen von jungen Menschen, Werkzeuge zu beaufsichtigen, die Arbeit auf fast schon Senior-Niveau liefern, aber wir geben ihnen nicht die Zeit, die Erfahrung aufzubauen, mit der sie diese bewerten können. Die Lösung besteht nicht darin, die KI zu verbieten. Das wäre unrealistisch und wahrscheinlich kontraproduktiv. Wenn wir die Ausbildung gestalten, müssen wir ihren Einsatz als Teil des Lernwegs konzipieren. Im Buch greife ich die Idee des Trio Workings auf: Ein Junior, ein Senior und die KI arbeiten am selben Problem. Die KI beschleunigt die Ausführung. Der Junior muss das Ergebnis verstehen, modifizieren und erklären. Der Senior gibt sich nicht mit einer bloßen Freigabe zufrieden, sondern stellt Fragen: Warum wurde diese Struktur gewählt? Welche Hypothese stützt den Code? Was passiert, wenn der externe Dienst nicht antwortet? Welcher Test beweist wirklich, dass die Funktionalität korrekt ist? Die Regel sollte einfach sein: Übertragt einem Agenten keine Aufgabe, die die Fachkraft noch nicht in der Lage ist, zumindest so weit zu verstehen, dass sie sie verifizieren kann. Wenn wir die grundlegende Lehrzeit komplett eliminieren, könnten wir in einigen Jahren feststellen, dass wir keine Menschen mehr haben, die in der Lage sind, die Loops zu entwerfen, die wir zu beaufsichtigen vorgeben."

Die andere Schwachstelle ist technischer Natur und betrifft das, was er als Loop Drift bezeichnet – die Tendenz des Systems, sich nach vielen Iterationen langsam von der ursprünglichen Absicht zu entfernen. Ich frage ihn, wie er das handhabt.

"Die erste Regel lautet, die Identität der Arbeit nicht dem Konversationsgedächtnis des Modells anzuvertrauen", erklärt er. "Eine lange Konversation ist bequem, aber kein zuverlässiges Protokoll. Informationen werden zusammengefasst, verdichtet, neu interpretiert und manchmal vergessen. Nach vielen Iterationen kann das System zwar weiterhin konsistent mit seiner eigenen jüngeren Geschichte sein, aber nicht mehr mit dem ursprünglichen Ziel. Deshalb muss die Absicht in einem externen und dauerhaften Zustand leben: einer Spezifikation, einem versionierten Plan, Akzeptanzkriterien, Constraints und bereits getroffenen Entscheidungen. Bei jeder Iteration sollte der Agent diese Elemente neu lesen und sie nicht frei aus seinem Gedächtnis rekonstruieren. Die zweite Regel besteht darin, zwischen Fakten, Entscheidungen und Zusammenfassungen zu unterscheiden. Ein verifizierter Fakt sollte nicht bei jedem Schritt neu geschrieben werden. Eine Entscheidung sollte eine Begründung haben und, wenn möglich, einen Verweis auf den Nachweis, der sie gestützt hat. Die vom Modell erstellten Zusammenfassungen können nützlich sein, dürfen aber die Quellen nicht ersetzen. Die dritte Regel ist, den Fortschritt anhand externer Signale zu überprüfen. Wenn das Ziel darin besteht, 120 Tests zu bestehen, sollte der Loop nicht entscheiden, dass er 'fast fertig' ist, nur weil der Code besser aussieht. Er muss zeigen, welche Tests bestanden werden, welche fehlschlagen und wie sich diese Situation im Laufe der Zeit verändert. Schließlich braucht man Checkpoints und Resets. Manchmal verschlimmert das Hinzufügen von mehr Kontext das Problem. Es ist gesünder, mit einer frischen Session neu zu starten – mit dem essenziellen Zustand und den realen Nachweisen –, als eine bereits verzerrte Konversation weiterzuschleppen. Sinnvolles Gedächtnis bedeutet nicht, sich an alles zu erinnern. Es bedeutet, das zu bewahren, was man braucht, ohne zuzulassen, dass die Erzählung die Realität ersetzt."

Vom Code zum Kunden

Schließen wir mit dem konkreten Fall ab, den das Buch außerhalb des Software-Bereichs vorstellt, und mit Papalinis Vision über das Schicksal des Begriffs selbst.

Das Buch widmet dem Kundenservice eine Fallstudie, weit entfernt vom Code. Ich frage ihn, wie sich diese Fallstudie während des Schreibens entwickelt hat, was sie beweisen soll und wie hoch ihr tatsächlicher Validierungsgrad ist.

"Ich habe diesen Fall aufgenommen, weil ich nicht wollte, dass Loop Engineering als Synonym für Coding-Agenten verstanden wird", erklärt er. "Software ist das sichtbarste Labor, weil es über Tests, Repositories, Compiler und Werkzeuge verfügt, die es einfacher machen, das Verhalten des Agenten zu beobachten. Aber die Prinzipien des Loops gelten auch dann, wenn das Ergebnis eine Antwort an einen Kunden, ein Bericht, eine Dokumentenprüfung oder ein kommerzielles Angebot ist. In der Fallstudie empfängt das System eine Anfrage, ruft die relevanten Informationen ab, bereitet eine Antwort vor, gleicht sie mit den Richtlinien ab und entscheidet, ob sie gesendet, überarbeitet oder an einen menschlichen Mitarbeiter eskaliert werden soll. Während des Schreibens wurde mir klar, dass der interessanteste Teil nicht die Generierung der Antwort war. Das ist relativ einfach. Das eigentliche Problem bestand darin zu definieren, wer das Recht hat, sie zu senden. Eine Antwort kann sprachlich hervorragend und trotzdem falsch sein: Sie könnte eine nicht autorisierte Rückerstattung versprechen, veraltete Informationen nutzen oder einen unklaren Fall mit übertriebener Sicherheit behandeln. Die Fallstudie dient also dazu zu zeigen, dass die Autonomie im Verhältnis zum Risiko stehen muss. Einfache und gut dokumentierte Anfragen können den Loop automatisch durchlaufen. Unklare, finanziell relevante oder emotional sensible Anfragen müssen eskaliert werden. Es ist wichtig, präzise zu sein: Der im Buch vorgestellte Fall ist ein vollständiges Entwurfsmodell, das entwickelt wurde, um die Methode und ihre Werkzeuge aufzuzeigen. Er wird nicht als ein bereits im großen Maßstab in der Produktion validiertes industrielles System präsentiert. Ihn in einen empirischen Beweis zu verwandeln, würde ein echtes Pilotprojekt, gemessene Daten, den Vergleich mit einer Baseline und eine Fehleranalyse erfordern. Das Buch schlägt die Architektur vor. Es behauptet nicht, dass eine Architektur auf dem Papier automatisch einem Produktionsnachweis entspricht."

Blicken wir zum Abschluss nach vorn: Werden wir in einem Jahr noch über Loop Engineering sprechen, oder wird der Begriff überflüssig werden, so wie es derzeit beim Prompt Engineering der Fall ist? Kann es sich zu einer eigenständigen Disziplin entwickeln, ähnlich wie DevOps, oder wird es von der Systemtechnik absorbiert?

"Ich hoffe, dass ein Teil des Begriffs überflüssig wird", antwortet Papalini. "Wenn eine Praxis wirklich von der Ingenieurwissenschaft absorbiert wird, hören wir auf, sie als etwas Besonderes zu betrachten. Niemand wundert sich heute darüber, dass eine Anwendung Logs, Monitoring, automatisierte Tests und Rollback-Verfahren haben muss. Sie sind zu normalen Elementen des Systems geworden. Das Gleiche könnte mit den Loops passieren. In einigen Jahren könnte es selbstverständlich erscheinen, dass ein Agent einen externen Zustand, ein Budget, Erfolgskriterien, begrenzte Berechtigungen und einen Eskalationsmechanismus haben muss. Aber ich glaube nicht, dass das Problem verschwinden wird. DevOps ist nicht verschwunden, als Pipelines alltäglich wurden. Es hat sich verändert. Es wurde zu einer Reihe von Praktiken, Verantwortlichkeiten und Kompetenzen, die Entwicklung und Betrieb verbinden. Loop Engineering könnte einen ähnlichen Weg einschlagen, aber ich bin nicht davon überzeugt, dass wir sofort neue Berufsbezeichnungen oder Zertifizierungen benötigen. Die Tech-Branche besitzt bereits eine beachtliche Fähigkeit, Rollen zu schaffen, noch bevor die eigentliche Arbeit geklärt ist. Ich denke eher, dass diese Kompetenzen in bestehende Rollen einfließen werden. Die Entwickler werden Verifikationen und persistente Zustände entwerfen müssen. Die Architekten werden über Autorität und Grenzen nachdenken müssen. Die Product Owner werden verifizierbare Ziele formulieren müssen. Die Risikomanager werden Systeme verstehen müssen, die nicht immer denselben Pfad ausführen. Der Name mag sich ändern. Aber das Problem bleibt dasselbe: Wie verwandelt man einen probabilistischen Ausführer in ein zuverlässiges, verifizierbares und steuerbares System."

---

Das Buch Non-Deterministic Loop Engineering von Enrico Papalini vertieft neben den hier besprochenen Themen die praktischen Implementierungsaspekte des Ralph Loops und die Governance-Modelle für die fortschreitende Autonomie von Agenten.