Wie man ein unberechenbares Genie einhegt

• Um wiederkehrende Fehler in AI-Produkten zu verringern, deren Ergebnisse selbst bei derselben Anfrage variieren, sollte man die Kontrolle nicht durch mehr Anweisungen erhöhen, sondern durch deterministischen Code, den das Modell nicht umgehen kann
• Die Kontrollstruktur besteht aus vier Ebenen — Modell, Harness, Dokumente und Hooks — und nur Hooks, die unter bestimmten Bedingungen unabhängig arbeiten, können Regeln wirklich erzwingen
• Aufgaben, deren Korrektheit sich per Code beurteilen lässt, kann man garantieren; bei Aufgaben, die Urteilsvermögen erfordern, etwa subtile Analysefehler, ist man jedoch wieder auf das Modell angewiesen, sodass die Lücke der Verifikation auch mit besseren Modellen nicht verschwindet
• AI-Produkte brauchen Harness Engineering, das trennt, was dem Urteil des Modells überlassen wird und was per Code garantiert werden soll; bei zu wenig Kontrolle entstehen falsche Antworten, bei zu viel daraus teure gewöhnliche Software
• Wenn jeder dasselbe Modell mieten kann, wird die umschließende Schicht (Wrapper) aus produktspezifischen Standards, Code, Daten und Integrationsumgebung zu einem verteidigbaren Wettbewerbsvorteil — das Wachstum von Cursor zeigt das

---

Regeln aus Dokumenten in Code überführen

• Selbst wenn man in einer Datei, die Claude Code in jeder Sitzung liest, ein bestimmtes Verhalten verbietet, kann es vorkommen, dass das System den Inhalt versteht, zustimmt und dasselbe Verhalten trotzdem wiederholt
• Verlegt man die Regel in Code, der den Befehl sofort blockiert, sobald die Bedingung erfüllt ist, stoppt das verbotene Verhalten unabhängig vom Urteil des Modells
• Die in The Verification Tax behandelten Kosten der Überprüfung von AI-Ausgaben lassen sich nicht nur durch mehr nachträgliche Kontrolle, sondern auch durch Engineering weiter oben in der Pipeline senken
• Selbst eine minimale Kontrollstruktur, die eine einzelne Person nur mit persönlichen Tools baut, hat dieselbe Form wie die Probleme, die große AI-Produkte lösen müssen
• Praktische Leitlinien, die Fehlertypen mit Hook-Arten verknüpfen und den messbaren Bereich je Ebene ordnen, finden sich in einem separaten X-Post

Die vier Ebenen der Kontrolle

• Die Kontrollfähigkeit besteht aus vier Ebenen, die von unten nach oben immer stärker werden
  • Modell: Selbst starke Modelle wie Claude Opus 4.8 oder GPT-5.5 können auf dieselbe Anfrage unterschiedliche Antworten geben, und keine Anweisung kann diese Eigenschaft vollständig beseitigen
  • Harness: Systeme wie Claude Code, Codex oder OpenClaw führen das Modell aus und bestimmen, was es sehen kann, können aber nur die grobe Richtung lenken
  • Dokumente: In CLAUDE.md und AGENTS.md lassen sich Präferenzen, Projektkontext, Regeln und aufgelaufene Korrekturen festhalten, doch das Modell kann sie ignorieren, weil es sie zusammen mit anderen Informationen abwägt
  • Hooks: Code, der bestimmte Situationen überwacht und unabhängig arbeitet, blockiert verbotene Befehle unabhängig davon, ob das Modell zustimmt oder nicht
• Von diesen vier Ebenen ist nur die oberste, Hooks, nicht verhandelbar
  • Regeln, die in Hooks verlagert werden, kann das Modell nicht umgehen; dadurch verschwinden wiederkehrende Fehler, und auch der Umfang menschlicher Prüfung sinkt

Der Bereich des Urteilens, den Code nicht garantieren kann

• Die zu kontrollierende Oberfläche lässt sich verkleinern, aber nicht vollständig schließen
  • Ob eine Bedingung wie „Diesen Befehl nicht ausführen“ erfüllt ist, lässt sich per Code prüfen
  • Eine Bedingung wie „Verhindere, dass die Analyse subtil in die falsche Richtung läuft“ erfordert Urteilskraft, und auch ein anderes Modell, das dies beurteilen soll, bleibt wieder unvorhersehbar
• Systeme, die Ausgaben tatsächlich beweisen können, vergleichen von Menschen vorab geschriebene Kriterien und Ergebnisse per Code und funktionieren nur in Bereichen, in denen sich die richtige Antwort exakt definieren lässt
• Auch wenn Modelle aufgerüstet werden, verschwindet das Urteilsproblem nicht; daher bleibt eine Kontrollschicht um das Modell herum nötig

• Garantien auf Basis formaler Spezifikationen

  • SEVerA kann garantieren, dass Agenten-Ausgaben formale Verträge erfüllen, doch diese Verträge müssen vorab in formaler Logik beschrieben werden, und das gilt nur für Bereiche, in denen solche Prüfungen möglich sind
  • VeriGuard ergänzt LLM-Agenten um verifizierte Sicherheit, erfordert aber weiterhin manuelle Prüfung durch den Nutzer
  • Schon der Schritt, in dem ein LLM die Absicht des Nutzers in formale Regeln übersetzt, ist selbst unvorhersehbar
  • Praktische Garantien hängen letztlich von festen Prüfungen gegen Spezifikationen ab, die von Menschen geschrieben wurden
  • „Selbstverbessernde Agenten“ bewerten eingetretene Ergebnisse und verbessern daraufhin ihr späteres Verhalten, doch das ist etwas anderes als der Nachweis, dass ein einzelner Output korrekt ist

Einen probabilistischen Motor mit deterministischer Software umhüllen

• Traditionelle Softwaretests haben sich so entwickelt, dass gewünschte Ausgaben und eine einzige richtige Antwort festgelegt und dann vorhersehbarer Code geprüft werden
• AI-native Produkte setzen jedoch einen probabilistischen Motor ins Zentrum, der selbst beim gleichen Prompt unterschiedliche Ergebnisse liefert, wodurch die Annahmen klassischer Tests zerbrechen
• Wie Hamel Husain anmerkt, setzt die über Jahrzehnte aufgebaute Disziplin des Softwaretestens eine einzige richtige Antwort voraus — in AI verschwindet genau diese Antwort
• Mehrere Entwickler konvergieren daher auf einen Ansatz, bei dem der unvorhersehbare Motor bestehen bleibt, aber mit deterministischem Code umhüllt wird, der sich jedes Mal gleich verhält
  • Dex Horthys 12-factor agents definieren einen guten Agenten als ein System, das „größtenteils aus Software besteht“
  • Anthropics building effective agents empfiehlt, Aufgaben über „vordefinierte Codepfade“ auszuführen und „programmatische Prüfungen“ hinzuzufügen
• In Claude Code kann man wählen, wie Bedingungen geprüft werden sollen
  • Wenn Code unabhängig über Erfolg oder Fehler entscheidet, erhält man eine Garantie
  • Wenn das Modell entscheidet, ob die Bedingung erfüllt ist, erhält man nur ein Urteil

• Skills und /goal in Claude Code

  • Skills sind strukturierte Verfahren, die ein Agent aufrufen kann; da aber das Modell entscheidet, ob es sie ausführt, und unterwegs davon abweichen kann, gehören sie zur Dokumentenebene
  • /goal sorgt dafür, dass die Arbeit fortgesetzt wird, bis die angegebenen Bedingungen erfüllt sind, und liegt damit näher an einer erzwingenden Ebene
  • Allerdings beurteilt nach jedem Zug ein kleines, schnelles Modell, ob die Bedingungen erfüllt sind, und kann sich wie andere Modelle irren
  • /goal ist eine Funktion, die einen Stop-Hook umhüllt; in einem selbst geschriebenen Stop-Hook kann statt des Modells ein Skript unabhängig über Erfolg oder Fehler entscheiden
  • Die Claude-Code-Dokumentation unterscheidet entsprechend zwischen Skripten für deterministische Prüfungen und Modellen für Prüfungen, die Urteilskraft erfordern

Wenn persönliche Konfiguration auf Organisationsgröße skaliert

• In einer persönlichen Umgebung kostet es meist nur ein paar Minuten, wenn ein Agent eine einzelne Regel ignoriert, und wichtige Fälle lassen sich mit persönlichen Hooks abfangen
• In einem Unternehmen mit 200 Mitarbeitenden, das denselben Agenten nutzt, hat nicht jede Person eigene Hooks, und Regeln können in einer gemeinsamen Datei liegen
• Wird eine gemeinsame Regel einmal ignoriert, kann dasselbe Problem überall auftreten, wo diese Datei ausgeführt wird, und das Schutzniveau der Organisation hängt von der am lockersten formulierten Regel ab
• Die Kontrollstruktur ist dieselbe wie im persönlichen Setup, aber mit wachsender Größe ändern sich die Kosten von Fehlern

Was garantieren und was offenlassen?

• Everys Leitfaden für agent-native Architekturen definiert Funktionalität nicht als geschriebenen Code, sondern als „beschriebene Ergebnisse, die Agenten in einer Schleife erreichen“
• Dieser Ansatz lässt Modelle improvisieren und entwirft Produkte rund um Ergebnisse, kehrt an den Stellen, die Kontrolle verlangen, aber wieder zu Code zurück
  • Für Hot Paths, die häufig oder wichtig sind, wird empfohlen, sie in Code zu überführen
  • Zugleich wird anerkannt, dass manche Aufgaben Prüfungen brauchen, die nicht dem Urteil eines Agenten überlassen werden dürfen
• Modellzentriertes Produktdesign und kontrollzentriertes Engineering wirken gegensätzlich, behandeln aber dieselbe Architektur von zwei Enden her
• In der Praxis muss entschieden werden, welche Stellen eines Produkts bis zu welchem Grad per Code festgelegt werden
  • Fixiert man zu wenig, urteilt das Modell auch bei Aufgaben mit Garantiebedarf improvisierend und kann Kunden selbstbewusst falsche Antworten liefern
  • Fixiert man zu viel, entsteht gewöhnliche Software, in der jeder Pfad per Code festgeschrieben ist, und das Modell erledigt nur langsam und teuer Arbeit, die bisheriger Code schon leistete
• Das vom OpenAI-Team so genannte Harness Engineering ist die Arbeit, an jedem Punkt eines Produkts bewusst zu entscheiden, welcher Anteil das Urteil des Modells braucht und welcher Anteil Code-Garantien braucht

Die umschließende Schicht, die länger besteht als das Modell

• Modelle kann jeder mieten, und sie verbessern sich für alle Nutzer gleichzeitig nach dem Fahrplan des jeweiligen Modelllabors, weshalb dies die am schwersten zu verteidigende Ebene ist
• Selbst wenn ein Konkurrent das gesamte Code-Repository lesen könnte, erhielte er damit noch nicht die kumulierten Urteile darüber, was in einer bestimmten Arbeit garantiert und was offen gelassen werden soll
• Diese Urteile werden in einer Ebene umgesetzt, die das Modell nicht übergehen kann, und sammeln sich zusammen mit der produktspezifischen Kontrollstruktur weiter an
• Die Summe aus Code, Standards, Daten und Arbeitsintegrationen rund um das Modell bildet einen langfristigen Wettbewerbsvorteil

Die Kontrollschicht, die Cursor aufgebaut hat

• Das AI-Coding-Tool Cursor baut kein eigenes allgemeines Modell, sondern leitet Anfragen zwischen Claude, GPT, Gemini und Grok weiter und behandelt Modelle als mietbare Commodity
• Selbst wenn Anthropics Claude Code früher Zugang zu überlegenen Modellen hat, kann es Cursor nicht ersetzen
• Der Umsatz von Cursor stieg von rund 1 Milliarde US-Dollar im vergangenen November auf etwa 4 Milliarden US-Dollar im Juni
• SpaceX übte vergangene Woche eine im April gesicherte Option aus und einigte sich auf die Übernahme von Cursor für 60 Milliarden US-Dollar — die größte Startup-Übernahme im Venture-Bereich aller Zeiten
• Was Cursor aufgebaut hat, ist kein besseres allgemeines Modell, sondern die Schicht um das Produkt herum
  • Ein Codebase-Index, der das gesamte Repository synchron hält und durchsuchbar macht
  • Ein eigenes Autocomplete-Modell, das aus Hunderten Millionen täglicher Bearbeitungen lernt, welche Vorschläge Entwickler annehmen oder ablehnen
  • Eine Enterprise-Integrationsumgebung, die in den meisten Fortune-500-Unternehmen verankert ist
• Selbst wenn Modellfirmen bessere Modelle besitzen, besitzen sie damit noch nicht den Editor, den Index oder die Nutzungsgewohnheiten der Entwickler

Die Frage, die über die Beständigkeit AI-nativer Produkte entscheidet

• Beispiele wie Cursor, die eine Kontrollschicht aufgebaut haben, sind selten; viele, die AI in ihrer Arbeit nutzen, haben eine solche umschließende Schicht nicht gebaut oder wissen nicht einmal, dass es sie gibt
• Auf Unternehmensebene entscheidet die Frage, wie diese Schicht aufgebaut wird, darüber, ob ein AI-natives Produkt realen Einsatz aushält oder nur eine beeindruckende Demo auf einem Modell bleibt, das jeder mieten kann
• Selbst wenn Basismodelle kostenlos werden, bleibt die Frage, was übrig bleibt, die Trennlinie für den nachhaltigen Vermögenswert eines Produkts