Ein Coding Agent kann in wenigen Minuten erstaunlich viel leisten. Er versteht eine Codebasis, implementiert Funktionen, schreibt Tests, refaktoriert mehrere Dateien und findet Fehler, für die ein Mensch deutlich länger suchen würde. Danach ist der Build grün, die Anwendung startet und alles sieht überzeugend aus.
Damit ist trotzdem noch nicht bewiesen, dass die Änderung korrekt ist.
Eine verspätete Antwort kann einen neueren Zustand überschreiben. Ein Refactoring kann einen selten verwendeten Fehlerfall verändern. Ein zusammengeführter Branch kann noch Arbeit enthalten, die in einem anderen Worktree weitergeführt wird. Eine Dokumentation kann technisch stimmen und trotzdem auf einer inzwischen überholten Entscheidung beruhen.
Das Problem liegt dabei nicht zwingend in der Intelligenz des Modells. Moderne Modelle sind inzwischen bemerkenswert gut. Das Problem entsteht, wenn man von ihnen erwartet, gleichzeitig Codebasis, Projektgeschichte, Prozessregeln, Zuständigkeiten, Risiken und Abnahmekriterien zuverlässig im Kopf zu behalten.
Ich behandle Coding Agents darum weniger wie besonders intelligente Editoren und mehr wie Teilnehmer eines technischen Systems.
Ein Prompt ist noch kein Prozess
Viele Agent-Setups beginnen mit einer langen Instruktionsdatei.
Prüfe deine Arbeit. Schreibe Tests. Verändere kein bestehendes Verhalten. Lies zuerst die Dokumentation. Sei vorsichtig mit Git. Frage bei riskanten Aktionen nach.
Das klingt vernünftig. Es beschreibt allerdings überwiegend Absichten.
«Verändere kein bestehendes Verhalten» beantwortet noch nicht, welches Verhalten als Vertrag gilt. «Teste deine Änderung» sagt nicht, welche Failure Modes geprüft werden müssen. «Sei vorsichtig mit Git» hilft wenig, wenn ein Branch integriert wurde, daneben aber noch ein aktiver Worktree mit nicht gesicherter Arbeit existiert.
Je komplexer ein Projekt wird, desto weniger reicht eine Sammlung guter Ratschläge.
Ich habe daher über längere Zeit wiederkehrende Arbeitsabläufe formalisiert: als Skills mit definierten Prüfschritten, Zuständen, Entscheidungsregeln und Abschlussbedingungen. Ein Agent bekommt damit nicht nur gesagt, was er erreichen soll. Er bekommt ein Verfahren, mit dem er feststellen kann, ob er es erreicht hat.
Ein Teil dieser Verfahren ist inzwischen als Reliable Agent Toolkit öffentlich verfügbar. Das Repository enthält portable Fassungen etablierter Workflows für Softwareanalyse, Planung, Refactoring, Repository-Umbauten, Git-Konsolidierung, Design, SEO, Publikation und projektübergreifende Konsistenz.
Zuverlässigkeit beginnt bei Failure Modes
Der vielleicht deutlichste Fall ist mein Software-Sanity-Check.
Ein klassischer Entwicklungsdurchlauf endet leicht bei drei grünen Signalen: Der Code kompiliert, die vorhandenen Tests bestehen und die Anwendung sieht beim Ausprobieren korrekt aus.
Der Sanity Check stellt andere Fragen. Wo liegt die tatsächliche Source of Truth? Wer besitzt einen Zustand? Welche Übergänge sind erlaubt? Was passiert bei Persistenz? Was geschieht, wenn zwei asynchrone Vorgänge in einer anderen Reihenfolge abgeschlossen werden, als sie gestartet wurden? Welche Annahmen werden durch Code, Typen, Tests oder Runtime-Checks geschützt?
Ein einfaches Beispiel ist eine Suche mit zwei Requests. Request A wird gestartet. Kurz danach startet Request B. B kommt zuerst zurück und zeigt die aktuellen Ergebnisse. Anschliessend trifft die ältere Antwort A ein und überschreibt wieder den Zustand.
Die Anwendung kann bei hundert manuellen Versuchen korrekt wirken. Der Fehler steckt in einer zeitlichen Reihenfolge, die im Normalfall kaum sichtbar wird.
Der Sanity Check verfolgt in einem solchen Fall State Ownership und Ordering. Wird eine ungeschützte Annahme gefunden, soll der Agent nicht bei der Reparatur stehen bleiben. Er ergänzt die kleinste passende dauerhafte Absicherung. Bei diesem Beispiel können das ein Guard gegen veraltete Responses und ein Verhaltenstest sein, der beide Requests absichtlich in der falschen Reihenfolge abschliesst. Dieser Failure Mode ist auch als Beispiel im öffentlichen Toolkit dokumentiert.
Damit entsteht ein Feedback-Loop:
Fehler finden → Ursache verstehen → Invariante bestimmen → Schutz einbauen → Verhalten reproduzierbar prüfen → Absicherung im Projekt behalten.
Die Erkenntnis verschwindet nicht wieder mit dem Kontextfenster des Agents.
Refactoring braucht ein Gedächtnis für Verhalten
Dasselbe Prinzip gilt beim Refactoring.
Ein Modell kann eine grosse Klasse beeindruckend schnell in mehrere kleinere Komponenten zerlegen. Strukturell sieht das Resultat häufig besser aus. Gerade darin steckt eine Gefahr: Eine elegante neue Architektur kann gleichzeitig bestehendes Verhalten verändert haben.
Mein Refactoring-Workflow beginnt daher mit einer Baseline.
Welche öffentlichen APIs existieren? Welche persistierten Formate müssen erhalten bleiben? Welche Fehlerzustände gehören zum Verhalten? Welche Lifecycle-Eigenschaften sind relevant? Welche Verantwortlichkeiten liegen aktuell wo?
Erst danach wird geschnitten.
Das Ziel lautet nicht einfach «weniger Code» oder «schönere Architektur». Der Agent muss unterscheiden, welche Teile Struktur sind und welche Teile Vertrag. Nach dem Umbau folgt eine erneute Completion Review gegen die vorher bestimmten Invarianten. Das öffentliche Toolkit erhält diese mehrstufige Arbeitsweise bewusst vollständig. Es wurde nicht auf eine kurze Liste generischer Refactoring-Tipps reduziert.
Diese Unterscheidung ist für mich zentral: Ein Agent darf viel verändern können. Gleichzeitig muss das System wissen, was er nicht unbemerkt verändern darf.
Git hat mehr Zustand als einen Branch
Ein ähnliches Problem entsteht bei paralleler Agent-Arbeit.
Mehrere Coding Agents können gleichzeitig an unterschiedlichen Aufgaben arbeiten. Git-Branches und Worktrees machen das technisch möglich. Sobald Arbeit integriert und anschliessend aufgeräumt werden soll, reicht ein einfaches «Branch wurde gemerged, also löschen» jedoch nicht mehr.
Ein Branch ist eine Git-Referenz. Ein Workspace ist ein Arbeitszustand.
Ein integrierter Branch kann zu einem Worktree gehören, in dem inzwischen neue Arbeit entstanden ist. Es können lokale Änderungen existieren. Die Ownership kann unklar sein. Ein anderer Agent kann dort noch aktiv arbeiten.
Mein Main-Consolidation-Workflow behandelt daher «integriert» und «gefahrlos entfernbar» als zwei verschiedene Aussagen.
Er klassifiziert Inhalte, überprüft die tatsächliche Integration bis hin zum Remote-SHA-Readback und schützt aktive, veränderte, primäre oder nicht eindeutig zuordenbare Workspaces. Ein erfolgreicher Abschluss darf ausdrücklich darin bestehen, einen Workspace zu behalten.
Das klingt konservativ und soll es auch sein. Automatisierung wird wenig wertvoll, wenn sie zehn Minuten Arbeit spart und einmal im Monat einen halben Tag nicht gesicherte Arbeit vernichtet.
Wissen gehört nicht in das Kontextfenster
Skills lösen allerdings nur einen Teil des Problems.
Meine eigene Umgebung besteht aus wesentlich mehr als dem öffentlichen Repository. Besonders wichtig ist eine Knowledge Base.
Ein Modell kann sehr viel wissen. Es kann aber nicht wissen, welche interne Entscheidung ich vor drei Monaten getroffen habe, welcher Architekturpfad verworfen wurde, welche Regel inzwischen eine ältere ersetzt oder welches Dokument für ein bestimmtes Thema aktuell die kanonische Quelle ist.
Dieses Wissen sollte meiner Ansicht nach auch nicht durch immer grössere Prompt-Dateien in jeden Agent-Kontext geladen werden. Stattdessen braucht Wissen Rollen.
Aktuelle Entscheidungen haben eine kanonische Quelle. Historische Dokumente bleiben als Geschichte erhalten, ohne dadurch weiterhin normative Autorität zu besitzen. Ein Agent lädt nur die Informationen, die für seine aktuelle Aufgabe relevant sind. Änderungen an gemeinsam genutztem Wissen müssen wieder an der richtigen Quelle landen.
Das Toolkit enthält dafür den knowledge-routing-Workflow und eine bewusst einfache Knowledge-Base-Vorlage. Die öffentliche Vorlage benötigt keinen Server und kann in einem Projekt oder einem separaten Dokumentationsrepository liegen. Ihr Validator prüft Struktur und lokale Referenzen, beansprucht aber ausdrücklich nicht, die faktische Wahrheit der Dokumente zu beweisen.
Meine eigene Infrastruktur geht hier weiter. Die öffentliche Version soll keinen Nachbau meiner privaten Umgebung erzwingen. Sie zeigt das Modell dahinter in einer Form, die jemand auch ohne meine Systeme verwenden kann.
Zuständigkeit muss ebenso explizit sein wie Wissen
Bei mehreren Projekten entsteht noch ein zweites Problem. Eine Regel kann an mehreren Stellen verwendet werden, sollte aber nur an einer Stelle einen Eigentümer haben.
Nehmen wir an, mehrere Produkte verwenden denselben Standard für Deployment, Authentisierung oder Dokumentstruktur. Zwei Repositories entwickeln irgendwann unterschiedliche Vorstellungen davon, wie diese Regel aussehen soll. Der naheliegende Agent-Reflex wäre, beide Stellen lokal zu reparieren. Damit entstehen zwei neue Wahrheiten.
Meine Infrastruktur trennt daher Konsumenten von Eigentümern gemeinsamer Regeln. Ein Consistency-Workflow kann eine Abweichung feststellen, die zuständige Quelle bestimmen und die betroffenen Projekte anschliessend mit einer verifizierten Änderung und einer klaren Information zur Fortsetzung versorgen.
Im öffentlichen Repository gibt es davon bewusst nur eine manuelle, infrastrukturarme Vorlage. Die Dokumentation weist ausdrücklich darauf hin, dass dieses «Consistency Department» kein Produktionscontroller ist. Es scannt keine Systeme selbstständig, plant keine Jobs und versendet keine Aufgaben.
Das ist mir bei der Veröffentlichung wichtig: Eine reduzierte Open-Source-Fassung sollte ihre Grenzen offen benennen, statt private Fähigkeiten durch ein paar Hilfsskripte vorzutäuschen.
Die öffentliche Version ist ein Ausschnitt
Das Reliable Agent Toolkit ist daher nicht meine komplette Agent-Infrastruktur. Es ist der Teil, den ich sinnvoll generalisieren und veröffentlichen kann.
Private Pfade, interne Endpunkte, Geräteinventare, Infrastrukturbindungen, Geschäftsquellen und spezifische Koordinationsmechanismen wurden entfernt oder durch explizite Konfiguration ersetzt. Wo meine eigene Umgebung einen Dienst voraussetzt, verwendet die öffentliche Fassung vorhandene Projektquellen oder dokumentierte manuelle Verfahren.
Dabei wollte ich einen Fehler vermeiden, der bei solchen Veröffentlichungen schnell passiert: Man nimmt einen detaillierten internen Workflow, reduziert ihn auf zehn freundliche Bulletpoints und veröffentlicht anschliessend nur noch die Idee des ursprünglichen Systems.
Beim Toolkit war die Portabilisierung bewusst andersherum gedacht. Die privaten Bindungen dürfen verschwinden. Die Entscheidungslogik soll erhalten bleiben.
Beim Refactoring bleiben Baseline und Invarianten. Beim Sanity Check bleiben State- und Lifecycle-Prüfungen. Bei Main Consolidation bleiben Ownership, Content-Klassifikation und die konservativen Cleanup-Regeln. Bei Planung, SEO, Design und Publikation bleiben die jeweiligen Prüfschritte und Grenzen erhalten. Das Repository dokumentiert diese Herkunft und die vorgenommenen Portabilitätsänderungen separat.
Der öffentliche Nutzer braucht meine Infrastruktur nicht. Er soll aber von den Erfahrungen profitieren können, aus denen diese Infrastruktur entstanden ist.
Skripte dort, wo Determinismus möglich ist
Ein weiterer Teil der Architektur ist die Trennung zwischen Modellarbeit und deterministischer Prüfung.
Ein Sprachmodell eignet sich hervorragend dafür, Architektur zu verstehen, semantische Widersprüche zu finden, Risiken einzuordnen oder einen passenden Test zu entwerfen. Für manche Fragen gibt es jedoch keinen guten Grund, ein Sprachmodell raten zu lassen.
Existiert diese Datei? Verweist dieser Pfad auf ein gültiges Ziel? Erfüllt ein Plan eine definierte Struktur? Stimmen bestimmte Metadaten? Ist die Installation vollständig? Welche Remote-SHA wurde tatsächlich gelesen?
Wo eine Aussage deterministisch überprüfbar ist, verwende ich dafür Skripte und Validatoren.
Das Toolkit kombiniert daher Skills mit Hilfsprogrammen und Tests. Die Workflows entscheiden, was geprüft werden muss. Deterministische Werkzeuge übernehmen Teile davon, bei denen Interpretation keinen Mehrwert bringt. Das Repository stellt dafür auch einen lokalen Gesamtvalidator und eigene Test-Suites bereit.
Das Modell bekommt damit weniger Gelegenheit, sich selbst von seinem Ergebnis zu überzeugen.
Ein grünes Ergebnis braucht Evidenz
Diese Denkweise verändert auch den Begriff «fertig». Ein Agent kann sehr überzeugend formulieren, dass eine Aufgabe abgeschlossen sei. Für mich ist diese Formulierung selbst keine Evidenz.
Die relevante Frage lautet: Welche beobachtbare Tatsache rechtfertigt den Abschluss?
Bei einer Codeänderung können das Tests und ein reproduzierbares Verhalten sein. Bei einem Git-Vorgang kann es der Readback des tatsächlich veröffentlichten Commits sein. Bei einem UI-Problem braucht es gegebenenfalls eine gerenderte Prüfung. Bei einem Performance-Problem müssen vorher und nachher vergleichbare Laufzeitdaten vorliegen.
Auch manuelle Prüfung darf Teil des Ergebnisses sein. Sie muss dann allerdings als solche benannt werden.
Das System versucht also nicht, menschliches Urteil vollständig zu entfernen. Es versucht, den Unterschied zwischen Wissen, Annahme und Evidenz sichtbar zu halten.
Mehr Autonomie braucht bessere Grenzen
Auf den ersten Blick wirken solche Regeln wie eine Einschränkung für Agents. Für mich bewirken sie eher das Gegenteil.
Je klarer reversible lokale Arbeit, reine Lesezugriffe, produktive Änderungen und destruktive Eingriffe voneinander getrennt sind, desto mehr kann ein Agent innerhalb seines erlaubten Bereichs selbstständig erledigen.
Das öffentliche Toolkit verwendet dafür ein abgestuftes Berechtigungsmodell. Lokale reversible Arbeit und Lesen können innerhalb des beauftragten Scopes ohne zusätzliche Freigabe erfolgen. Produktive und destruktive Aktionen benötigen die jeweils vorgesehene menschliche Autorisierung.
Autonomie entsteht damit aus klaren Zuständigkeitsgrenzen.
Das Besondere liegt wieder in der Verbindung
Als ich über meine physische Argio-Infrastruktur geschrieben habe, kam ich am Ende zu einem ähnlichen Punkt.
Proxmox ist nicht besonders. ZFS ist nicht besonders. Synology, WireGuard, Monitoring und eine USV kann jeder einzeln installieren. Der eigentliche Wert entsteht durch die Verbindung ihrer Rollen, Zustände und Rückkehrwege.
Bei meiner Agent-Infrastruktur sehe ich inzwischen dasselbe Muster. Ein Skill ist nicht besonders. Eine Knowledge Base ist nicht besonders. Git-Worktrees, Tests, Validatoren, Agent-Instruktionen und Freigaberegeln sind ebenfalls bekannte Bausteine. Interessant wird es dort, wo sie sich gegenseitig Grenzen und Informationen liefern.
Der Agent weiss, welche Quelle Autorität besitzt. Ein Workflow sagt ihm, welche Failure Modes er prüfen muss. Ein deterministischer Validator überprüft das, was sich objektiv überprüfen lässt. Ein gefundener Fehler wird nach Möglichkeit zu einer dauerhaften Regressionsabsicherung. Gemeinsame Regeln haben einen Eigentümer. Parallel laufende Arbeit besitzt einen Zustand. Destruktive Aktionen haben eine Freigabegrenze. Und ein Task gilt erst dann als abgeschlossen, wenn sein Ergebnis durch passende Evidenz gedeckt ist.
Ich versuche damit nicht, das Sprachmodell unfehlbar zu machen. Das wäre die falsche Systemgrenze. Ich baue die Umgebung so, dass das Modell nicht unfehlbar sein muss.
Ein Agent darf etwas übersehen, solange eine spätere Prüfstufe den Fehler findet. Er darf einen Plan ändern, solange die relevanten Invarianten erhalten bleiben. Er darf parallel arbeiten, solange Ownership und Integration nachvollziehbar bleiben. Er darf Wissen aus vielen Quellen verwenden, solange klar bleibt, welche davon für die aktuelle Entscheidung Autorität besitzt.
Das Reliable Agent Toolkit ist die portable, öffentliche Schicht dieses Ansatzes. Es bildet bewusst nicht meine gesamte Umgebung ab. Es enthält jene Workflows, Skripte und Regeln, die sich aus ihrem privaten Kontext lösen lassen, ohne ihren eigentlichen Zweck zu verlieren.
Der Rest bleibt Infrastruktur.
Und wie bei jeder guten Infrastruktur besteht ihr Wert weniger darin, wie beeindruckend sie aussieht, wenn alles funktioniert. Interessant wird sie in dem Moment, in dem etwas schiefgeht und das System trotzdem noch weiss, welcher Zustand gilt, wer zuständig ist und welcher Weg zurückführt.