Warum Codier-Agenten wie Claude Code eine Steuerungsebene benötigen, nicht nur bessere Anweisungen.

Klareer Anfragen ergeben tatsächlich bessere Antworten. Sie verringern Missverständnisse, präzisieren Anweisungen und geben einer Sitzung eine klare Richtung – kurzfristig wirkt das so, als würde sich damit die gesamte Arbeitsweise mit KI verbessern. Dieses Gefühl verschwindet jedoch, sobald die KI-Systeme zum Bestandteil der täglichen Arbeit werden. Man fragt nicht mehr nach einer überzeugenden Antwort auf eine isolierte Anfrage, sondern erwartet, dass das System das Projekt kennt, bereits getroffene Entscheidungen respektiert, den richtigen Ablauf wählt, innerhalb seiner Befugnisse bleibt, die richtigen Werkzeuge verwendet und nachvollziehbare Beweise hinterlässt.

Eine Anfrage prägt den Austausch vor Ihnen – sie kann jedoch nicht alles steuern, was diesen Austausch umgibt.

Codex und Claude Code liefern bereits viele nützliche Komponenten. Was fehlt, ist ein vollständiges, portables System, das entscheidet, welche Regeln gelten, welcher Kontext wichtig ist, was ein Programmieragent tun darf, wie Aufgaben verteilt werden und was als Beweis gilt. Jemand muss diese Schicht um die Laufzeitumgebung erstellen. Ein Name dafür ist Kernel: eine von einem selbst kontrollierte Steuerungsschicht, die die Arbeit von der ursprünglichen Absicht des Menschen bis hin zum Beweis führt. Sie enthält kein internes Modell und führt nichts eigenständig aus.

Konkret kann ein solcher Kernel als eine Sammlung portabler, strukturierter Markdown-Dateien beginnen: Regeln, Protokolle, Indexe, anerkannte Entscheidungen, Projektzustände sowie Speicherpolicies. Wenn schriftliche Anweisungen nicht ausreichen, füllen Fähigkeiten, Skripte, Abkürzungen und Hooks die Lücke.

Kontext war nur das Symptom

Das erste sichtbare Problem ist der fehlende Kontext. Eine neue Sitzung kennt oft weder die Architektur noch die jüngsten Änderungen oder die Begründung für eine Aufgabe, weshalb eine weitere Überprüfung durchgeführt werden muss, bevor mit der nützlichen Arbeit weitergegangen werden kann. Diese Wiederholung kostet Zeit, Ressourcen und Geduld.

Mehr Kontext hilft zwar, lässt die tieferliegenden Probleme jedoch unberührt. Ein Agent kann weiterhin den falschen Ablauf befolgen, mit mehr Befugnissen handeln, irrelevante Materialien heranziehen oder ohne Beweise Erfolg melden.

Die offensichtliche Lösung besteht darin, die fehlenden Regeln und Hintergrundinformationen in AGENTS.md, CLAUDE.md oder ein ähnliches Bootstrap-File zu platzieren. Das ist sinnvoll – aber unvollständig. Diese Dateien verbessern tatsächlich die Einarbeitung, doch zu erwarten, dass sie einen gesamten Arbeitsablauf steuern, ist ein Fehler. Ein Bootstrap kann stabile Regeln festlegen und auf zuverlässige Quellen verweisen. Er kann jedoch nicht allein den Projektzustand aktuell halten, den richtigen Kontext pro Aufgabe auswählen, entscheiden, was dem Agenten erlaubt ist, oder das Ergebnis überprüfen.

Ein Prinzip steht dabei im Mittelpunkt: Definieren Sie vor der Ausführung, was „erledigt“ bedeutet, und verlangen Sie anschließend Beweise am Ende.

Das Beseitigen von Wiederholungen war nie das eigentliche Ziel. KI war von einem gelegentlichen Experiment zu einer täglichen Notwendigkeit geworden, und die interessante Frage war, wie viel Wert eine mit gewöhnlichen Software-Entwurfsprinzipien erstellte Umgebung gewinnen konnte. KI war auf einmal durch mehrere Kanäle eingedrungen – in Editoren, in Xcode und VS Code sowie in Tools wie Codex und Claude Code. Jedes dieser Tools machte den Einsatz leistungsfähiger Modelle einfacher, doch ein leichterer Zugang half nicht dabei, das Umfeld um diesen Einsatz zu organisieren.

An guten Tagen kann ein Agent Code überprüfen, ein unbekanntes Framework erklären, eine Architektur vorschlagen oder dabei helfen, eine neue Funktion zu veröffentlichen – und das fühlt sich oft sehr nach der Zusammenarbeit mit einem anderen Entwickler an. Je stärker man darauf setzt, desto wichtiger werden die damit verbundenen Fragen. Wenn zwei Quellen unterschiedlicher Ansicht sind: Welche gewinnt? Welche Regeln gelten für diese Aufgabe? Darf der Agent entscheiden oder nur Empfehlungen aussprechen? Wenn er angibt, die Arbeit sei abgeschlossen, was sollte man dann erwarten?

Der Kontext beantwortet den ersten Teil dieser Fragen, indem er dem Agenten relevante Kenntnisse liefert. Der Rest bezieht sich darauf, wie diese Kenntnisse genutzt werden. „Governance“ ist ein passender Begriff für das Ganze: der praktische Zusammenhang zwischen Absicht, vertrauenswürdigen Kenntnissen, Regeln, Autorität, Ausführung und Nachweis. Er bleibt praktisch, solange die entscheidenden Teile eines Workflows klar genug sind, um sie überprüfen, korrigieren und wiederverwenden zu können.

Für einen Ingenieur, der es liebt, Systeme zu entwerfen, deren Komponenten effizient zusammenarbeiten, erscheint es verschwenderisch, den Workflow rund um Agenten improvisiert zu gestalten. Es wird zu etwas, das entworfen werden muss, anstatt zu einer Reihe von Gesprächen, die überwacht werden müssen. Um dies gut zu machen, ist es notwendig, über einen langen Zeitraum hinweg eigene Gewohnheiten zu beobachten: Was man vor dem Anfassen eines Projekts überprüft, welche Muster man wiederverwendet, wann man langsamer wird und welche Überprüfungen tatsächlich davon überzeugen, dass eine Aufgabe erledigt ist. Das Ziel ist es, diese stillschweigenden Gewohnheiten in Verhaltensweisen umzuwandeln, denen ein Agent folgen und die eine Person überprüfen kann.

Was ein Bootstrap kann und nicht kann

Ein Entwickler, der zu einem etablierten Projekt stößt, braucht mehr als nur Talent. Er muss lernen, wie der Code organisiert ist, welche Entscheidungen getroffen wurden, was sich kürzlich geändert hat und wo die Grenzen liegen. Ohne das verbringt selbst ein hervorragender Neuzugang Tage damit, die Umgebung neu zu entdecken.

Agentensitzungen leiden unter einer komprimierten Form desselben Problems. Man erläutert die Architektur, Ziele, den aktuellen Zustand sowie Einschränkungen, der Agent erbringt gute Arbeit, und in der nächsten Sitzung muss ein Großteil dieses Bildes neu erstellt werden.

Die Unterbringung dieses Materials in einer AGENTS.md- oder CLAUDE.md-Datei macht die Einführung erheblich günstiger. Das Wort „Bootstrap“ markiert lediglich eine Grenze und ist keine Kritik – eine gute Dokumentation legt den Mindestvertragsinhalt fest und weist den Agenten darauf hin, wo zuverlässige Informationen zu finden sind. Codex dokumentiert mehrere AGENTS.md-Dateien, deren Gesamtkapazität begrenzt ist, und Claude Code schlägt kurze Projektanleitungen vor, wobei selten benötigte Verfahren in spezielle Fähigkeiten ausgelagert werden. Beides wird in den Dokumentationen der Anbieter behandelt: die Claude Code Memory-Dokumentation sowie die Codex AGENTS.md-Anleitung. Eine Fähigkeit paketiert ein wiederholbares Verfahren, sodass es zwischen Projekten übertragen werden kann, und Hooks können jedes Mal ein bestimmtes Verhalten erzwingen. Dennoch muss ein weiterer Bestandteil entscheiden, wann jedes dieser Mechanismen angewendet wird und wie ihre Ausgabe überprüft wird.

Probleme entstehen, wenn von einer Datei erwartet wird, dass sie den gesamten Arbeitsbereich enthält. Sie kann weder kurz bleiben noch gleichzeitig jede architektonische Entscheidung, den aktuellen Plan, frühere Berichte, Protokolle sowie Aufgabendetails beinhalten. Selbst wenn das Kontextfenster alles aufnehmen könnte, würde das Hineinstopfen aller Inhalte in jede Sitzung zu eigenen Fehlern führen: Die wichtigen Anweisungen würden mit veralteten oder unrelevanten Texten konkurrieren. Das Beheben eines Fehlers erfordert einen anderen Kontext als die Überprüfung einer Architektur. Die Veröffentlichung folgt einem anderen Ablauf als ein frühes Produktgespräch, und eine einfache Frage sollte nicht den Koordinationsaufwand für eine umfangreiche Funktion mit sich bringen.

Deshalb sollte ein Bootstrap einen Einstieg in das System bieten und nicht versuchen, das System selbst zu sein.

Von Bootstrap zu Karte

In diesem Design enthält das Bootstrap einen kleinen Betriebsvertrag und verweist anschließend auf separate Quellen, sobald diese relevant werden. Die angenommenen Entscheidungen bleiben beim Projekt. Protokolle beschreiben wiederkehrende Arbeiten, Fähigkeiten enthalten wiederholbare Verfahren, Abkürzungen komprimieren häufige Anfragen und aktuelle Pläne bewahren den Zustand, den eine weitere Sitzung benötigen könnte.

Im Kernel verbirgt sich nichts Intelligentes. Sein Wert ergibt sich daraus, wie die Dateien über verschiedene Sitzungen und Laufzeiten getrennt, vernetzt, ausgewählt und gepflegt werden.

Die Trennung schützt auch die Bedeutung. Eine angenommene Entscheidung bestimmt, wie sich ein Projekt entwickelt, ein Statusbericht beschreibt einen bestimmten Moment und ein Testergebnis dokumentiert Beweise. Werft alle drei in ein einheitliches, ununterschiedenes Gedächtnis, dann beginnt eine alte Beobachtung wie eine aktuelle Anweisung auszusehen.

Im Laufe der Weiterentwicklung umfasst die Struktur zunehmend Aspekte wie die Speicherrichtlinien, die Komplexität der Aufgaben, die erforderliche Denkleistung sowie welches Modell verwendet werden soll, Abkürzungen, die Kontinuität zwischen Sitzungen, die Validierung sowie die Koordination mehrerer Agenten. Eine vollständige Aufzählung würde die Architektur verbergen. Entscheidend ist, dass der Agent diese Elemente schrittweise entdecken kann, je nach den Anforderungen der Aufgabe. Hinter dieser Struktur stehen vier Verantwortungsbereiche, die zwar nicht jeden Mechanismus beschreiben, aber erklären, warum sie zusammengehören.

Einige Kenntnisse müssen über das Chat-Gespräch hinaus bestehen

Das Chatten funktioniert, während die Aufgabe bearbeitet wird, sollte aber nicht als offizielle Aufzeichnung einer Projektentscheidung dienen. Akzeptierte Architekturen, Einschränkungen sowie Codeentscheidungen müssen in kontrollierten Quellen gespeichert werden, die jede spätere Sitzung lesen kann, und laufende Pläne benötigen ihren eigenen Zustand, der wieder aufgenommen werden kann. Dauerhafte Aufzeichnung der Wahrheit bedeutet nicht, jede Konversation zu archivieren, da der größte Teil davon nur vorübergehendes Hilfsmaterial ist. Fragen Sie stattdessen, was nach Beendigung der Sitzung weiterhin als autoritativ gelten sollte.

Laden Sie nur das, was die Aufgabe benötigt

Ein Agent benötigt nur das Nötige, um seine Aufgabe zu verstehen, nicht alles, was das System je gespeichert hat. Eine kleine Codeänderung kann die Projektregeln sowie einige Dateien erfordern. Eine komplexe Funktion benötigt möglicherweise außerdem die Produktziele, architektonische Entscheidungen, Expertenmeinungen sowie einen Validierungsplan. Ziel ist ein minimal ausreichender Kontext und nicht ein maximal verfügbarer Kontext. Kontinuität bedeutet, zum richtigen Zeitpunkt das richtige Material finden zu können, anstatt die gesamte Historie bei jeder Aufgabe mitzunehmen.

Etwas finden ist keine Genehmigung

Das Finden einer Datei, einer Nachricht oder einer Empfehlung berechtigt nicht dazu, darauf zu handeln. Das System muss Informationen von Befugnissen trennen – insbesondere bei zerstörerischen Aktionen, endgültiger Validierung, Veröffentlichung sowie bei allem, was die Welt außerhalb des Arbeitsbereichs betrifft. Diese Schicht ist weniger sichtbar als die Modellintelligenz, doch sie ist entscheidend, wenn ein fahrlässiger Fehler teurer ist als eine Pause zur Entscheidungsfindung.

Die Vollendung erfordert Beweise

Fließende Sprachbeherrschung bedeutet nicht automatisch Korrektheit, und plausibel ist noch lange kein Zeichen für Abgeschlossenheit. Deshalb fragt der Kernel, was überprüft werden muss, welche Beweise aufbewahrt werden sollten und wo der bestätigte Zustand festgehalten wird. Wenn ein Agent Code ändert und „erledigt“ meldet, erhält man lediglich eine Angabe – nichts weiter. Die Überprüfung kann darin bestehen, dass Tests erfolgreich sind, eine Kompilierung gelingt, das Verhalten in der laufenden Anwendung sichtbar ist und der Zustand aufgezeichnet wurde. Andere Bereiche erfordern unterschiedliche Nachweise, doch die Regel bleibt dieselbe: Das Ende des Dialogs bedeutet nicht, dass die Arbeit abgeschlossen ist.

Eine Organisation als Analogie

Stellen Sie sich ein Unternehmen vor, das ein Gebäude, Computer und hervorragende Ausrüstung besitzt, aber keine gemeinsame Arbeitsweise hat. Es verfügt über Kapazitäten, ist jedoch nicht kohärent. Die Menschen benötigen weiterhin gemeinsames Wissen, Verfahren, Entscheidungsbefugnisse, klare Aufgaben und Qualitätskontrollen. Der Vergleich ist lose, denn ein Agent ist kein Angestellter und ein Runtime tut mehr als nur Menschen an Schreibtischen unterzubringen. Er zeigt jedoch, wie die Komponenten miteinander verbunden sind: Agenten übernehmen begrenzte Rollen, Tools stellen die Ausrüstung dar und der Runtime ist der Ort, an dem die Aufgaben ausgeführt werden. Der Kern ist die gemeinsame Schicht aus Regeln, Wissen, Methoden und Kontrollen, die eine Zusammenarbeit ermöglicht. Bessere Modelle führen nicht automatisch zu einem besseren System.

Wo sich die Schicht befindet

Der Kernel konkurriert nicht mit Codex, Claude Code, Gemini oder jedem anderen Betriebssystem, das in Zukunft erscheint. Diese bieten die laufende Umgebung: Modelle, Tools, Sitzungen, Einstellungen für das Reasoning sowie eine wachsende Anzahl eigener Subagenten, Hooks und Fähigkeiten. Die Steuerungsschicht arbeitet mit dieser Umgebung zusammen und klärt drei Dinge: Was soll erhalten bleiben, was darf der Agent tun und welche Beweise gelten als erledigt.

Jedes Mal, wenn eine Laufzeitumgebung eine Funktion bereitstellt, die einer bereits manuell erstellten Funktion ähnelt, wird die Trennung zwischen Handarbeit und automatisierter Verarbeitung wertvoller. Jede Laufzeitfunktion neu zu entwickeln, würde Zeit kosten, die besser für die Projekte eingesetzt werden könnte, denen die Agenten dienen. Es ist der nachhaltigere Ansatz, den Laufzeitumgebungen die Ausführung zu überlassen, während die Steuerungsschicht weiterhin portabel bleibt. Die Anbieter unterscheiden sich in Modellen, Tools, Schnittstellen und Ausgabeformaten – durch Portabilität bleiben Ihre Regeln unabhängig von einem bestimmten Anbieter, ohne dass man vorgibt, diese Unterschiede würden verschwinden.

Steuerung garantiert keine Sicherheit

Das Aufschreiben einer Regel garantiert nicht, dass ein Agent sie liest, versteht oder zur richtigen Zeit anwendet. Ein Bootstrap kann auf das richtige Protokoll verweisen und dennoch ignoriert werden. Eine kanonische Entscheidung kann perfekt erhalten bleiben, während ihr Inhalt stillschweigend veraltet. Ein Hook kann eine Regel lange Zeit treu durchsetzen, selbst nachdem die Regel nicht mehr nützlich ist.

Die Erfahrung zeigt, dass dies schnell passiert. Die für Worktrees und Hooks hinzugefügten Regeln beginnen sich zu überschneiden, miteinander zu kollidieren und die Aufgaben zu blockieren, die sie eigentlich schützen sollten, weshalb sie vereinfacht und korrigiert werden müssen. Die Verwaltung erfordert ständige Pflege, und die Kosten hören dort nicht auf: Schnittstellen und Indizes verbrauchen Zeit und Ressourcen und können den neuesten Zustand trotzdem verpassen, Agenten ignorieren Anweisungen, je größer das System wird, und Vertrauen ist schwer wiederherzustellen, wenn ein Workflow Erfolg behauptet, ohne den erwarteten Nachweis zu liefern.

Ein solches System ist niemals fertig oder universell. Es handelt sich um eine persönliche Einrichtung, die über Monate hinweg getestet, beschädigt und korrigiert wird. Es verbessert Ihre Fähigkeit, das Verhalten der Agenten zu beobachten und anzupassen, doch keine Regel, kein Protokoll, keine Abkürzung und kein Speichermechanismus wird perfekt befolgt. Die Verwaltung kann das Beobachten und Beheben von Verhaltensproblemen erleichtern, aber sie kann keinen probabilistischen Agenten deterministisch machen.

Drei Fragen, die man zuerst stellen sollte

Der Verlust des Kontexts ist es, der die Menschen auf diesen Weg bringt. Was sie dort hält, ist eine größere ingenieurtechnische Frage: Wie sollte der Weg um ein leistungsstarkes Modell herum gestaltet werden, ohne dass anderen wichtigen Architekturen weniger Aufmerksamkeit geschenkt wird?

Kann man also nachweisen, dass die Arbeit abgeschlossen ist? Nur dann, wenn „abgeschlossen“ bereits vor der Ausführung definiert wurde und das Ergebnis Beweise liefert, die zur Aufgabe passen. Ohne das bleibt es bei einer Behauptung, und eine Behauptung ist kein Beweis.

Man braucht kein solches System, um so zu denken. Bevor man einen weiteren Prompt oder eine weitere Datei hinzufügt, fragen Sie sich:

1. Welche Quellen dürfen bestimmen, was wahr ist?
2. Welche Entscheidungen und Handlungen erfordern menschliche Autorität?
3. Welche Beweise zeigen, dass die Arbeit abgeschlossen ist?

Diese Fragen verwandeln einzelne KI-Funktionen in Bestandteile eines zuverlässigen Arbeitsablaufs anstelle von Fähigkeiten, die lediglich nebeneinander existieren. Jeder kleine Antrag sollte das gesamte System nicht mitziehen. Die Kontrollmechanismen sollten mit den Konsequenzen skaliern: locker, wenn das Risiko gering ist, strenger, wenn ein Fehler teuer wäre. Die Modelle liefern die Fähigkeiten, und der gesteuerte Weg von der Absicht bis zum Beweis ist das, was man um sie herum aufbaut.