Agent-operable Systeme bauen

Image generated by Google Gemini

Wenn ein KI-Agent Ihre App beim Refactoring kaputt gemacht hat, wenn Sie Legacy-Systeme in eine Umgebung umwandeln wollen, in der KI arbeiten kann, wenn Sie die Legacy-Wartungsbudgets der Fortune 500 in Transformationsbudgets umwandeln wollen – dieser Artikel ist die Roadmap.

Gesperrte Erinnerung

In der Dotcom-Blase begannen Unternehmen, digitale Vermoegenswerte anzuhaeufen. Code, Datenbanken, Spezifikationen, Dokumentation, APIs — ueber Jahrzehnte aufgebaute Unternehmensmemory.

Diese Erinnerungen waren gesperrt. Nicht durchsuchbar, nicht verifizierbar, nicht erreichbar (unreachable). Die einzige Methode: Ein Mensch liest, versteht und korrigiert direkt. Deshalb fliessen 60 bis 80 % der IT-Budgets der Fortune 500 in die Wartung dieser gesperrten Erinnerung. Man kann sie nicht oeffnen, also bewacht man sie nur.

Wir befinden uns gerade mitten in dem, was als KI-Blase bezeichnet wird. Die eigentliche Bedeutung dieser Aera ist nicht, dass Modelle intelligenter werden. Sondern dass alte Legacy-Erinnerungen der Unternehmen beginnen, erreichbar (reachable) zu werden.

Aber noch nicht. 2026 schreiben KI-Agenten Code. 68 Minuten, Millionen Tokens verbrannt, das Refactoring ist fertig. Die App ist komplett kaputt. Eine Geschichte, die taeglich auf X erscheint.

Warum wiederholt sich das?

Nicht weil der Agent dumm ist. Sondern weil die Umgebung nicht dafuer gemacht ist, dass ein Agent darin arbeitet. Man stellt keinen Roboter in ein Buero, in dem Menschen arbeiten. Man baut eine Fabrik, in der der Roboter arbeiten kann.

Um die gesperrte Erinnerung zu oeffnen, muss sie zuerst eine Form annehmen, die sich oeffnen laesst. Es geht nicht nur um Code. Datenbanken, Spezifikationen, Dokumentation, APIs — die gesamten digitalen Vermoegenswerte eines Unternehmens sind fuer den Agenten undurchsichtig.

Was Agent-Operable bedeutet

Damit ein Agent autonom arbeiten kann, sind drei Bedingungen noetig:

1. Er muss lesen koennen — ohne Rauschen

In einer 2.000-Zeilen-Datei sind 1.950 Zeilen Rauschen, um eine einzige Funktion zu finden. In einer nicht normalisierten Datenbank muessen drei Tabellen gejoined werden, um Kundeninformationen zu finden. In Excel-Tabellen versteckte Geschaeftsregeln kann ein Agent nicht entdecken.

Lesbar bedeutet nicht lesbar fuer Menschen. Es bedeutet strukturell parsbar fuer Maschinen.

2. Er muss verifizieren koennen — maschinell

Wenn nach einer Aenderung durch den Agenten nicht klar ist, was kaputt ist, geraet man in einen Doom Loop. Code braucht Tests, Datenbanken brauchen Constraints, APIs brauchen Schema-Validierung, Spezifikationen brauchen Kreuzvalidierung.

Einen LLM einen LLM verifizieren lassen ist wie einen betrunkenen Freund zu fragen: “Bin ich betrunken?” go test halluziniert nicht. CHECK-Constraints luegen nicht. JSON Schema driftet nicht.

3. Der Zustand muss persistieren — auch wenn der Agent stirbt

Ein Agent faellt garantiert aus. Token-Limit, Netzwerkfehler, Sitzungsabbruch. Wenn der Fortschritt nicht gespeichert wird, faengt man jedes Mal von vorne an.

Wenn Agent A bis Funktion 200 verarbeitet und stirbt, muss Agent B ab 201 weitermachen. Agenten sind Einwegartikel, aber der Fortschritt muss sich akkumulieren.

Schritt 0: Bugs praeparieren

Die drei Bedingungen sind das Ziel. Der Ausgangspunkt ist ein anderer. Keine Dokumentation, keine Tests, 300 Dateien mit je 2.000 Zeilen — das ist das Legacy, von dem wir starten.

In diesem Zustand dem Agenten “refactore das” zu sagen — was passiert? Er “behebt” einen 10 Jahre alten Bug. Das Problem: Dieser Bug ist kein Bug.

Hyrum’s Law: Jedes beobachtbare Verhalten einer ausreichend alten API hat jemanden, der davon abhaengt. Ein 10 Jahre ignorierter Rundungsfehler ist mit der Zahlungslogik eines VIP-Kunden verknuepft. Ein Datums-Parsing-Bug hat Excel-Makros hervorgebracht, die die gesamte Buchhaltung tragen. Alte Bugs sind implizite Geschaeftsspezifikationen.

Die erste Aufgabe des Agenten ist nicht, Code zu reparieren. Sondern das aktuelle Verhalten zu praeparieren.

Man pingt die API. Zeichnet die Antwort auf. Fixiert sie als Hurl-Test. Bizarrer Bug oder beabsichtigtes Verhalten — man unterscheidet nicht. Man praepariert es so, wie es ist. Das ist der erste Zahn des Ratchet — er sperrt den Agenten davon ab, eigenmaetig zu “verbessern”.

Aenderungen entscheidet nur, wer die Spezifikation besitzt. Der Agent ist Ausfuehrender. Nicht Entscheider.

Sobald die Praeparation abgeschlossen ist, beginnt der Uebergang zu den drei Bedingungen — Lesen, Verifizieren, Persistieren.

Nicht nur Code

“Agent-operable codebase” ist der Ausgangspunkt. Die digitalen Vermoegenswerte eines Unternehmens bestehen nicht nur aus Code.

Einzeln betrachtet heisst es “man sollte besser aufraumen”. Zusammen betrachtet ist es ein System.

Symbolic Feedback Loop

Eine gemeinsame Struktur ermoeglicht diesen Uebergang.

LLM generiert -> deterministisches Tool urteilt -> Ergebnis geht zurueck an LLM -> Wiederholung

Im Code, in Tests, in Spezifikationen, in Daten — dieselbe Schleife funktioniert:

Code-Struktur:          filefunc validate -> Verstoss-Feedback -> LLM-Korrektur -> wiederholen
Tests:                  go test + coverage -> nicht abgedeckte Zeilen -> LLM-Verstaerkung -> wiederholen
Spezifikations-Konsistenz: yongol check -> Drift-Feedback -> LLM-Korrektur -> wiederholen
Benutzerregeln:         rulecat evaluate -> Verstoss-Feedback -> LLM-Korrektur -> wiederholen

Der LLM ist nur an der “Generierung” beteiligt. Was korrigiert werden soll, ob es besteht, was als Naechstes kommt, ob es fertig ist — alles entscheidet die Maschine. Dem LLM wird keine Entscheidungsbefugnis gegeben.

Das ist keine Erfindung. C. elegans investiert 60 seiner 302 Neuronen (20 %) in die Wahrnehmung. Nicht Generierung — Verifikation. Das ist die Schlussfolgerung von 500 Millionen Jahren Evolution: Die Qualitaet des Feedbacks zu verbessern ist fuer das Ueberleben vorteilhafter als die Anzahl der Neuronen zu erhoehen.

Die Branche macht den Zug (das Modell) schneller. Groessere Modelle, intelligentere Agenten, bessere Prompts. Aber je schneller der Zug wird, desto wichtiger werden die Schienen.

80/20

Im Endzustand teilt sich das System in zwei Schichten.

SSOT (80~90 %)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── Aus Spezifikationen generiert. Drift an der Quelle blockiert. Freie Aenderung durch den Agenten.

Custom (10~20 %)
├── Geschaeftsregeln, Domaenenlogik, rechtliche/politische Berechnungen
└── Strukturiert durch filefunc, Tests gesichert durch tsma. Menschliche Pruefung.

Code, der wirklich menschliche Aufmerksamkeit braucht, wird auf 10-20 % komprimiert. Den Rest generiert der Agent aus Spezifikationen, und die Maschine verifiziert.

Die 60 % der Fortune 500

60 bis 80 % der IT-Budgets der Fortune 500 fliessen in die Legacy-Wartung. 42 % der Entwicklerzeit wird durch technische Schulden verbraucht. 70% der digitalen Transformationsprojekte verfehlen ihre Ziele.

Dieses Budget wird bereits ausgegeben. Man muss kein neues schaffen. Nur die Richtung aendern. Wartungsbudget in Transformationsbudget umwandeln.

Man fuettert das Legacy komplett ein und erhaelt ein agent-operable System. Das ist das Versprechen von Building Agent-Operable Systems.

Warum Big Tech das nicht macht

Anthropic und OpenAI bauen Allzweckmodelle. Ein Modell um 10 % zu verbessern gilt fuer alle Kunden. Aber eine Go-Test-Feedback-Schleife zu bauen gilt nur fuer Go-Entwickler. Ein Python-Coverage-Tool zu bauen gilt nur fuer Python-Projekte.

Symbolische Verifikation ist von Natur aus domaenenspezifisch. Jede Sprache, jedes Framework, jede Spezifikation braucht einen anderen Verifizierer. Keine Allgemeingueltigkeit, also kein ROI fuer Big Tech.

Deshalb ist dieser Platz frei. Wer den Zug baut und wer die Schienen legt, stehen nicht im Wettbewerb — sie ergaenzen sich.

Fragen

Ihr Agent schreibt Code. Aber wer prueft, ob dieser Code korrekt ist?

Ein anderer Agent? Oder go test?

Liest Ihr LLM wirklich alle 100.000 Zeilen?

Oder tut er nur so?

Im Zeitalter der Agenten braucht man keinen intelligenteren Agenten. Man braucht ein System, in dem der Agent arbeiten kann.

Sources

• Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
• Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
• McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
• Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
• Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
• White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
• Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
• METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
• GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
• Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks