Besitze den äußeren Loop

• Auch wenn ein Agent die innere Ausführungsschleife übernimmt, in der er Recherche, Implementierung und Validierung wiederholt, muss der Engineer den äußeren Loop besitzen: entscheiden, ob ausgeliefert wird, und Verantwortung für das Ergebnis tragen
• Agentensysteme werden auf Grundlage von Qualität (Quality) als Vorabprüfungen, Urteil (Verdict) als Entscheidung über den Einsatz in Production und Erklärungsverantwortung (Answerability) betrieben, die es ermöglicht, die Gründe für Entscheidungen darzulegen
• In Sonars Studie von 2026 zeigte sich, dass 42 % des committeten Codes KI-generiert oder erheblich KI-unterstützt waren; da die Erzeugungsgeschwindigkeit die Kontrollgeschwindigkeit überholt, werden Review, Validierung, Verständnis und Wartung zu knappen Ressourcen
• Der Einsatz von KI bringt kognitive Kapitulation mit sich, also das ungeprüfte Übernehmen falscher Antworten, außerdem kognitive Schuld, die das Codeverständnis schwächt, sowie Orchestrierungskosten, weil mehrere Agenten mit begrenzter menschlicher Aufmerksamkeit gesteuert werden müssen
• Eine skalierbare Software Factory entsteht nicht durch maximale Autonomie für Agenten, sondern durch unterbrechbare, steuerbare und überprüfbare Autonomie – und dadurch, dass Menschen Einschränkungen, Stichproben-Reviews, Audits, Ownership und das Endergebnis verantworten

---

Der äußere Loop des agentischen Engineerings

• Die Diskussion über agentisches Engineering verlagert sich auf Agent-Harnesses, Loops, Flotten und Software Factories
• Je leistungsfähiger Modelle wie Fable und GPT-5.6 werden, desto mehr müssen Engineers den äußeren Loop selbst besitzen, der Verantwortung für das System bedeutet
• Der hohe Hebel von Agenten erzeugt entsprechende Pflichten
  • Man muss genau erklären können, was sich geändert hat
  • Man muss erklären, warum diese Änderung sicher war
  • Man muss wissen, was passiert, wenn die Einschätzung falsch war
• Werden diese Bedingungen nicht erfüllt, lassen sich die Handlungen eines Agenten nicht rechtfertigen, und auch Organisationen können solche Systeme nur schwer einsetzen

Qualität, Urteil und Erklärungsverantwortung

• Qualität (Quality) bezeichnet alle Prüfungen, die eingerichtet werden, bevor man das System loslässt; die daraus gewonnenen Belege bilden die Grundlage für das Urteil
• Urteil (Verdict) ist die abschließende Production-Entscheidung, die ein Mensch trifft, bevor Arbeit in abhängige Systeme gelangt
  • Auch wenn das Modell den Code schreibt, trägt die Person, die die Arbeit unter ihrem Namen ausliefert, die Verantwortung für das Urteil
  • Sie entscheidet zwischen Deployen, Blockieren, Umleiten, Einschränken des Antwortumfangs, Hinzufügen von Guardrails oder vollständiger Ablehnung
• Erklärungsverantwortung (Answerability) ist die Zusicherung, diese Entscheidung erklären zu können, wenn jemand nach den Gründen fragt
• Ein Modell kann eine Zeile Code schreiben, aber es übernimmt nicht die Verantwortung dafür, zu entscheiden, ob sie an abhängige Systeme weitergegeben wird

Modell, Harness, Loop und Factory

• Ein Agent ist nicht nur ein einzelnes Modell, sondern umfasst auch den Harness, der Dateien, Tools, Memory, Skills, Sandbox, Berechtigungen, Observability und Recovery-Funktionen kombiniert
• Wenn das Modell der Motor ist, entspricht der Harness dem Auto, das um den Motor herum gebaut wurde, damit die reale Arbeit sicher ausgeführt werden kann
  • Tools und Memory stellen Arbeitsfähigkeit bereit
  • Berechtigungen und Sandbox begrenzen den Ausführungsbereich
  • Tests und Observability ermöglichen die Überprüfung der Arbeitsergebnisse
• Der Ausführungs-Loop eines Agenten besteht aus Recherche → Implementierung → Validierung → Iteration
  • Ein wiederholbarer Zyklus verwandelt einen einmaligen Erfolg wieder in einen verlässlichen Prozess
  • Ob eine Aufgabe abgeschlossen ist, sollte nicht durch das Urteil des Modells selbst, sondern durch unabhängige Prüfungen entschieden werden
• Wenn mehrere Loops gleichzeitig betrieben werden, entsteht eine Software Factory
  • Im Inneren erzeugen Agenten Arbeitsergebnisse
  • An der Grenze besitzen Menschen die Production-Entscheidungen

Die Grenze zwischen Innen und Außen des Systems

• Im Zentrum einer Software Factory steht die Grenze zwischen Innen und Außen des Systems
• Das interne System sammelt als Eingaben die Absichten des Produktteams, Wissen über frühere Deployments, jüngste Incidents und konkretes Nutzerfeedback
• Agenten-Loops untersuchen die Aufgabe, implementieren den Plan und validieren anschließend das Ergebnis
• Wenn die durch Validierung erzeugten Belege die Systemgrenze überschreiten, entscheidet der Mensch, der das abhängige System besitzt, ob es weitergeht
• Früher führten Agenten nur Teile des Ausführungsprozesses aus; heute übernehmen sie den gesamten inneren Ausführungs-Loop, während Engineers den äußeren Loop verantworten
• Was Agenten innerhalb der Grenze bereitstellen, ist Fähigkeit (capability)
  • Aufgaben untersuchen
  • Pläne implementieren
  • Ergebnisse testen
  • Ergebnisse berichten
• Was Menschen außerhalb der Grenze ausüben, ist Handlungsmacht (agency)
  • Entscheiden
  • Validieren
  • Freigeben
  • Besitzen

Die Vertrauens- und Validierungslücke durch KI-Code

• Der Anteil von KI-Code ist längst nicht mehr nur randständig
• Laut Sonars State of Code Report 2026 waren 42 % des committeten Codes KI-generiert oder erheblich KI-unterstützt, und die Befragten erwarten, dass dieser Anteil nicht stagniert, sondern weiter wächst
• Wenn die Kosten der Codeerzeugung sinken, werden Review, Validierung, Verständnis und Wartung zu noch knapperen Ressourcen
• Da die Erzeugungsgeschwindigkeit schneller zunimmt als die Kontrollgeschwindigkeit, entsteht eine Vertrauens- und Validierungslücke
  • Viele Menschen äußern Misstrauen gegenüber KI-Code
  • Weniger setzen dieses Misstrauen in konsistente Validierungsprozesse um
• Es braucht billigere und klarere Wege, die Zuverlässigkeit von KI-Code zu überprüfen

Grenzen nachgelagerter Governance

• Laut GitLabs AI-Responsibility-Studie vom Juni 2026 liegt der aktuelle Engpass beim KI-Einsatz bei Review und Validierung
• Governance greift hauptsächlich, nachdem Code bereits erzeugt wurde
  • Zu diesem Zeitpunkt hat die Organisation das Risiko bereits akzeptiert
  • Auch die Kontrolle über die Ownership der Arbeit ist dann bereits geschwächt
• KI-Governance muss über einfache Systemkontrolle hinaus festlegen:
  • Welche Einschränkungen dem System auferlegt werden
  • Mit welchen Belegen Arbeit geprüft wird
  • Wie Teams zur Verantwortung gezogen werden
  • Wer welchen Teil des KI-Lebenszyklus besitzt

Back Pressure, die Qualität erzeugt

• Qualität lässt sich als Back Pressure verstehen, die auf das System wirkt
• Ziel ist nicht, Agenten die maximal mögliche Autonomie zu geben
• Agenten sollten nur so viel Autonomie erhalten, dass man sie unterbrechen, steuern, ihre Arbeit prüfen und die menschliche Rolle bewahren kann
• In bestehendem Engineering gibt es bereits Signale, die zeigen, ob Arbeit in die richtige Richtung läuft
  • Type Checks
  • Tests
  • Hooks
  • Sandbox-Limits
  • Audit-Logs
  • Monitore
• Wenn Agenten dieselben Signale ausgeben, kann das bestehende Engineering-System angemessene Back Pressure bereitstellen

Vier Loops, in denen Menschen beteiligt sein müssen

• Einem System zu vertrauen bedeutet nicht, Menschen aus dem Loop zu entfernen
• Menschen sollten weniger im inneren Ausführungs-Loop sein, sondern in den folgenden vier äußeren Kontroll-Loops
  • Constraint-Loop: entscheidet, welche Inputs, Architekturen, Anweisungen und Invarianten festgelegt werden
  • Stichproben-Review-Loop: legt fest, welcher Anteil der Outputs herausgegriffen und geprüft wird
  • Audit-Loop: entscheidet, welche Belege aufbewahrt werden und wie die Gültigkeit von Audit-Logs sichergestellt wird
  • Ownership-Loop: klärt, wer welchen Teil der Production-Grenze besitzt
• Agenten können mehr Arbeit erzeugen, als Menschen überprüfen können
• Daher ist die knappe Ressource die zentrale menschliche Urteilskraft, die auf Basis von Qualitätssignalen wie Logs und Tests ausgeübt wird
• In der experimentellen Umgebung, die OpenAIs Studie zu Agenten und der Zukunft der Arbeit behandelt, ist agentische Delegation im Stundenbereich bereits erreichbar
• Ownership-Grenzen müssen etabliert werden, bevor das System mehr Arbeit liefert, als überprüfbar ist

Lang laufende Agenten und Erklärungsverantwortung

• Jede Auswahl, die ein lang laufender Agent über Stunden hinweg trifft, ist eine Entscheidung
• Nicht jede Entscheidung wird protokolliert, und nicht jede lässt sich bis zu den Input-Tokens zurückverfolgen
• Wenn man lediglich glaubt, dass das Ergebnis die richtige Wahl für das Problem ist, kann die Rekonstruktion der Entscheidungskette, die zu diesem Ergebnis führte, Hunderte oder Tausende Stunden menschlicher Arbeit erfordern
• Da solche Entscheidungsketten praktisch schwer zu rekonstruieren sind, muss Erklärungsverantwortung im Zentrum des Systemdesigns stehen

Drei versteckte Kosten der KI-Delegation

• Kognitive Kapitulation

  • Kognitive Kapitulation (cognitive surrender) ist das Phänomen, KI-Ergebnisse blind zu übernehmen
  • Auch wenn man eine Aufgabe an einen Agenten übergibt, bleiben Ergebnis, Reputation und Verantwortung mit der Arbeit des Nutzers verbunden
  • Defekte verbleiben in der Software des Nutzers
  • Auch das, was an den Output angepasst werden muss, ist die Software des Nutzers
  • Die Antwort des Agenten wird letztlich zur Antwort des Nutzers, und die Verantwortung folgt mit
  • In einer Wharton-Studie akzeptierten fast drei Viertel der Teilnehmenden die Antwort der KI selbst dann, wenn sie falsch war, und zeigten mehr Selbstvertrauen als bei einer Entscheidung ohne KI

• Kognitive Schuld

  • Kognitive Schuld (cognitive debt) ist das Phänomen, dass Verständnis und Erinnerung daran, wie Probleme gelöst werden, schwächer werden
  • Wenn man Arbeit an einen Agenten delegiert, wird auch der Denkprozess externalisiert
  • Die Zeit und Energie, die nötig wären, um eine große Codebasis selbst zu verstehen, lassen sich im Lernprozess möglicherweise nur schwer aufbringen
  • Dadurch können die von Agenten erzeugten Ergebnisse ein Niveau erreichen, das mit den aktuellen Fähigkeiten des Nutzers schwer erreichbar wäre
  • Je länger ein Agent plant, desto größer wird die Lücke zwischen erzeugtem Code und menschlichem Verständnis
  • Diese Lücke akkumuliert sich, und die Kosten, die Lernkurve erneut zu erklimmen, steigen nahezu exponentiell
  • In Anthropics randomisierter kontrollierter Studie erzielten Engineers, die Code mit KI schrieben, bei Verständnis-Quizzen 50 %, 17 Prozentpunkte weniger als die 67 % der Gruppe, die selbst schrieb

• Orchestrierungskosten

  • Orchestrierungskosten (orchestration tax) entstehen daraus, dass zwar viele Agenten gleichzeitig laufen können, die kognitive Bandbreite von Menschen aber nicht auf dieselbe Weise parallelisiert wird
  • Menschen müssen die folgenden Aufgaben selbst erledigen
    • Agenten so ausrichten, dass sie die schlimmsten Handlungen vermeiden
    • Aus den Ergebnissen diejenigen Aufgaben auswählen, die Aufmerksamkeit erfordern
    • Anweisen, wichtige Aufgaben zuerst zu bearbeiten
    • Vor der Ausführung zentrale Constraints und riskante Annahmen validieren
  • Diese Arbeit lässt sich nicht automatisieren und kann menschliches Urteil nicht ersetzen

Aufmerksamkeit in Brownfield-Systemen schützen

• Brownfield-Systeme sind besonders riskant, weil das zu auditierende Verhalten nicht nur im Code existiert, sondern auch in angesammelten Narben und Geschichte
• Bei Architekturentscheidungen sollte menschliche Aufmerksamkeit priorisiert werden
• Mit Worktree, Scope und Belegen lässt sich die Kopplung zwischen ursprünglichem Plan und während der Ausführung neu sichtbar gewordener Arbeit verringern
• Lösungsversuche für nicht ausführbare Schritte sollten zeitlich begrenzt werden
• Berechtigungen für Softwareänderungen sollten strikt per Opt-in vergeben werden

Alpha, Decay und Taste

• Drei zentrale Muster, die Karrieren und Leistungen über verschiedene Felder hinweg prägen, sind Alpha, Decay und Taste
• Alpha ist der führende Bereich, den die leistungsstärksten Personen im Wettbewerb besetzen, und der Zustand, in dem die wertvollsten Züge gemacht werden
• Decay sind etablierte Muster, die alle durch Wiederholung und Beobachtung gelernt haben; man kann es als eine Art Plateau betrachten
• Taste ist die Urteilskraft, die Veränderungen von Alpha oder Decay erkennt, bevor Belege sichtbar werden
• Paul Grahams Diskussion besagt: Wenn jeder alles bauen kann, wird die Entscheidung, was gebaut werden soll, wichtiger
• In Mitchell Hashimotos Definition ist Taste ein hochwertiges qualitatives Urteil, das gefällt wird, solange es noch keine objektiven Messgrößen gibt
• Alpha verschiebt sich durch Veränderungen im Taste, und Decay verschwindet, wenn Menschen anfangen, andere Dinge zu bevorzugen

Taste zu einer operativ nutzbaren Fähigkeit machen

• Um Taste von einer Intuition in eine bewusste Fähigkeit zu überführen, muss man ihm zuerst einen Namen geben
• Dieses Urteil muss durch Kritik und konkrete Beispiele geübt werden
• Auch die Begründung des Urteils muss explizit ausgedrückt werden
• Um nachhaltige Wettbewerbsvorteile zu erhöhen, muss die Grenze der Rolle immer weiter nach oben verschoben werden
  • Arbeit selbst ausführen
  • Anderen Menschen oder Systemen die Arbeit beibringen
  • Arbeit systematisieren
  • Entscheiden, wann sie ausgeführt werden sollte
  • Das Ergebnis besitzen

Der Unterschied zwischen Developer und Engineer

• Jeder kann Developer sein, aber nicht jeder ist Engineer
• Ein Developer wird zum Engineer, wenn er strengere Arbeitsdisziplin akzeptiert
  • Gründliches und logisch belastbares Schlussfolgern
  • Berücksichtigung von Constraints und Trade-offs
  • Bewusstsein für Risiken und Exposition
  • Tatsächliche Verantwortung
• Wenn Engineering anspruchsvoller wird, verlassen Menschen reine Verwaltungstätigkeiten und trennen Rollen, die zuvor an Handwerk gebunden waren, um ihre jeweiligen Funktionen zu klären
  • Die Person, die Prototypen erstellt
  • Die Person, die baut
  • Die Person, die aufräumt
  • Die Person, die wachsen lässt
  • Die Person, die wartet

Die Systemgrenze, die nur Menschen wahren können

• Menschen erhöhen Alpha auch an der gegenüberliegenden Grenze des Systems
  • Sie wählen aus, was es wert ist, getan zu werden
  • Sie legen fest, innerhalb welcher Constraints es getan wird
  • Sie beurteilen, ob die Belege für ein Fortfahren ausreichen
  • Sie kümmern sich um das Ergebnis
• Ob ein Team oder 100 Teams: Diese Grenze kann nur von Menschen besessen werden
• Aufmerksamkeit, Taste und Verantwortung sind die Kernelemente, die eine Software Factory funktionsfähig machen
• Ohne Verantwortung gibt es keine Regeln, keine Reaktion auf Fragen, keine Trade-offs, keine Risiken und keine Sicherheitsnetze
• Wenn niemand die Folgen einer Entscheidung besitzt, führt hohe Handlungsmacht zu Chaos

Eine Signatur, die länger bleibt als Technologie

• Die Halbwertszeit eines technischen Vorteils kann eine einzige Release sein, die Halbwertszeit der Signatur (signature), die man in seiner Arbeit hinterlässt, erstreckt sich über die gesamte Karriere
• Signatur bedeutet, dass man seinen Namen hinter die ausgelieferten Ergebnisse stellen kann
• Technologie schafft Hebelwirkung, und Verantwortung verwandelt diese Hebelwirkung in Vertrauen
• Nur Menschen wählen und erben die Ergebnisse
• Agenten können innerhalb von Policies auswählen, routen, mergen und eskalieren, aber sie können die Ergebnisse nicht erben

Der Verantwortungsvertrag einer Codebasis

• Jede Codebasis könnte einen Verantwortungsvertrag brauchen, der die Bedingungen festlegt, unter denen Änderungen angenommen werden
  • Eine Checkliste, die beim Freigeben bestätigt, was verstanden wurde
  • Die Belege, die für das Urteil genutzt wurden
  • Die Person, die die Änderung verantwortet
  • Der Systemzustand, nachdem eine Änderung blockiert wurde
• Der Vertrag sollte Zusammenhänge wie Aufmerksamkeit und Taste, Belege, Urteil und Ownership sowie Alpha, Decay und Taste explizit behandeln

Die Leiter hoher Handlungsmacht

• In agentischen Workflows bedeutet hohe Handlungsmacht, zu wissen, wann man delegiert, prüft, unterbricht und Ergebnisse besitzt
• Die Leiter der Handlungsmacht führt von niedrigen zu höheren Stufen
  1. Potenzielle Probleme markieren
  2. Probleme untersuchen
  3. Reaktionsarbeiten ausführen
  4. Ursachen diagnostizieren
  5. Lösungen vorschlagen
  6. Änderungen empfehlen
  7. Probleme beheben
• Zu höheren Stufen gehört auch die Urteilsschärfe, ein Problem zu erkennen, aber zu entscheiden, dass es nicht wert ist, behoben zu werden, und weiterzugehen

Warum Brownfield die Frontlinie der Software Factory ist

• Brownfield ist die Frontlinie, der sich Software Factories stellen müssen, wenn sie skalieren wollen
• Greenfield-Systeme lassen sich vollständig kontrollieren, daher ist es vergleichsweise einfacher, ausreichende Back-Pressure-Mechanismen zu planen und zu implementieren
• Wenn intelligente Agenten zu Legacy-Systemen hinzugefügt werden, muss man auch Komplexität außerhalb des Codes berücksichtigen
  • Gesamtes Production-Verhalten
  • Zukünftige Kundenerwartungen
  • Migrationshistorie
  • Release- und Budgetzyklen
  • Implizite Annahmen
  • Ausnahmefälle
  • Besonderheiten der Daten
  • Runbook-Prozeduren
  • Unverwaltet angesammelte Narben
• Um Brownfield zu pflegen, braucht es nachhaltiges Engineering
  • Implizites Wissen in explizite Constraints verwandeln
  • Wissen über Teams und Generationen hinweg konsistent halten
  • Wissen in Testverfahren und Funktionsspezifikationen formalisieren
  • Dieses Wissen mit objektiven Belegen verbinden
  • Fehlschläge als zusätzliches Lernen ansammeln
• Wenn das bisherige Maß an Pflege abreißt, kann das gesamte System zusammenbrechen

Neue Arbeit, die mit wachsender Skalierung entsteht

• Wenn bestehende Komponenten automatisiert werden, nutzen Menschen Alpha und Taste aus ihrer handwerklichen Erfahrung, um neue Arbeit zu entwerfen
  • Neue Loops entwerfen, die in die Software Factory integriert werden
  • Das in der Factory gewonnene Wissen nutzen, um prinzipientreue Greenfield-Systeme aufzubauen
  • Neue Belegformen schaffen, mit denen neue Systeme validiert werden können
  • Brownfield-Systeme pflegen, die komplex genug geworden sind, um dedizierte Betreuung zu erfordern
  • Neue Back-Pressure-Mechanismen entwerfen und verwalten
  • Neue Agenten entwerfen
  • Neue Systeme der Handlungsmacht aufbauen
• All diese Aktivitäten sind echte Engineering-Arbeit, und je größer der Maßstab wird, desto interessanter werden die Probleme

Der Engpass, den Automatisierung verschiebt

• Automatisierung gibt Kontrolle im industriellen Maßstab und schafft zugleich neue Engpässe
• Wenn der alte Engpass „Können wir das bauen?“ war, verschiebt er sich künftig zu: „Sollte das existieren, und können wir die Folgen erklären und verantworten?“
• Der neue Engpass in Production ist es wert, direkt von Menschen besessen zu werden

Das Betriebsmodell des agentischen Engineerings

• Der innere Loop ist der Ort, an dem die eigentliche Arbeit geschieht, und jeder Loop sollte so unabhängig wie möglich gestaltet werden
• Alle Qualitätssicherung und Validierung sollten in den inneren Loop eingebaut werden
• Nachdem der Loop selbst entworfen und validiert wurde, verleiht man Autonomie, indem man Back-Pressure-Mechanismen installiert, die Ausführungsgeschwindigkeit und Arbeitsumfang kontrollieren
• Menschen sollten nicht in jeden internen Schritt eingreifen, sondern an den richtigen Entscheidungspunkten platziert werden
• Verständnis sollte nicht als einfache Übergabe oder Release-Gate behandelt werden, sondern als Entscheidungspunkt, an dem ein Mensch bereit ist, Einsicht beizutragen
• Jedes Mal, wenn Ergebnisse wieder in Production und zu neuen Teams oder Engineers zurückfließen, sollten bessere Ergebnisse und Belege zurückbleiben als zuvor
• Baue und betreibe eine Software Factory weiter, halte die Arbeit aber in einem Zustand, in dem sie lesbar, überprüfbar und mit einem Owner versehen ist
• Auch wenn Agenten Code schreiben, muss ein Mensch die folgenden Fragen beantworten, bevor er Nutzer erreicht
  • Warum sollte dieser Code existieren
  • Warum ist er sicher genug, um in Production aufgenommen zu werden
  • Was tun wir, wenn er falsch ist
• Dieses Urteil und diese Verantwortung auszuüben, ist der äußere Loop des agentischen Engineerings