Deine KI-Agenten haben eine Rules-Datei. Ein Modell deines Systems haben sie nicht.

Öffne die CLAUDE.md, AGENTS.md oder .cursor/rules im Wurzelverzeichnis deines Repositories und lies sie so, wie sie bei einem Agenten ankommt: als einen Block Text, in dem nichts markiert, welche Zeilen noch stimmen.

Das meiste, was du findest, sind Konventionen. Nutze Tabs. Kein any. Früh returnen. Fehler mit %w wrappen. Diese Zeilen sind haltbar, weil sie beschreiben, wie man eine Zeile Code schreibt, und der Agent wendet sie auf den Code an, der vor ihm liegt.

Dann gibt es die andere Sorte Zeile. Die, die dein System beschreibt: welche Services existieren, welches Package wofür zuständig ist, wie die Schichten miteinander reden dürfen. Wegen dieser Zeilen lohnt sich die Datei überhaupt, und genau sie verrotten.

Ich weiß das, weil unsere es getan hat.

Was bei uns veraltet ist

Im Wurzelverzeichnis von Archyls Repository liegt eine CLAUDE.md. Nach den Maßstäben des Genres ist sie eine gute: 422 Zeilen, ein Architekturbaum, die Config-Variablen, die Verdrahtung der Dependency Injection, eine Beschreibung der Discovery-Pipeline. Jeder Agent, der diese Codebase anfasst, liest sie, bevor er irgendetwas anderes tut.

Das hier stand an dem Morgen darin, an dem ich diesen Text geschrieben habe, dem 5. August 2026. Zeile 392:

No test suite: The codebase currently has no Go test files or frontend tests.

Kein Test-Setup: Die Codebase hat aktuell keine Go-Testdateien und keine Frontend-Tests.

Es gibt 146 _test.go-Dateien unter backend/ und 31 Testdateien unter frontend/src/.

Zeile 140 sagt:

AI Provider Abstraction: Supports both OpenAI and Ollama via ai.Provider interface.

KI-Provider-Abstraktion: Unterstützt sowohl OpenAI als auch Ollama über das ai.Provider-Interface.

backend/internal/adapter/ai/resolver.go routet zu OpenAI, Anthropic, Gemini, Bedrock und jedem OpenAI-kompatiblen Endpunkt, zusätzlich zum plattformverwalteten OpenAI- und Ollama-Pfad. Fünf Provider-Typen in einem einzigen Switch-Statement. Die Datei nennt zwei.

Und der Architekturbaum listet in den Zeilen 74 bis 87 elf Packages unter internal/domain/ auf: c4, project, user, team, adr, projectdoc, flow, insight, subscription, dependency, history. Heute liegen einundvierzig Verzeichnisse in internal/domain/. Unter den dreißig, die sie nicht nennt: conformance, drift, apicontract, marketplace, reality, managedagent, mcpsession. Also so ziemlich alles, was das Produkt geworden ist, seit die Datei geschrieben wurde.

Jede dieser Zeilen war an dem Tag wahr, an dem sie getippt wurde. Keine wurde danach korrigiert, denn zum Korrigieren muss ein Mensch es bemerken, und niemand hat hingeschaut.

Das hier ist eine Firma, die Architekturdokumentation verkauft. Wenn Disziplin die Lösung wäre, hätte sie hier funktioniert.

Die beiden Hälften dieser Datei haben nichts gemeinsam

Die Konventionshälfte ist durchsetzbar. „Kein fmt.Println in Go" ist ein Grep. „Go-Dateien müssen snake_case sein" ist ein Skript. Verletzt ein Agent eine davon, sagt ein Linter es in der CI. Ändert sich die Konvention selbst, fängt der Linter an zu failen und jemand aktualisiert die Datei. Es gibt eine Feedback-Schleife, und sie ist kurz genug, um zu funktionieren.

Für die System-Hälfte gibt es kein Gegenstück. Es gibt kein go vet für „der Payment-Service ist für direkte Datenbankzugriffe tabu". Niemand parst diesen Satz, nichts vergleicht ihn mit dem Repository, nichts schlägt fehl, wenn er nicht mehr passt. Es ist Prosa in einer Markdown-Datei, und Prosa hat keinen Fehlermodus.

Eine Rules-Datei sind also zwei Dokumente, die sich einen Dateinamen teilen. Das eine wird laufend verifiziert, das andere nie, und nichts in der Datei unterscheidet sie. „Fehler mit %w wrappen" und „die Codebase hat keine Tests" stehen in derselben Liste, im selben Ton. Das eine ist eine Regel über den Code, der vor dem Agenten liegt. Das andere ist eine Behauptung über 146 Dateien, die er sich nicht ansieht.

Abwesenheit ist die schwierigere Hälfte

Veralten ist das Versagen, das sich jeder vorstellen kann. Das leisere wiegt schwerer: Eine Rules-Datei enthält nur das, woran jemand beim Aufschreiben gedacht hat, und nichts darin unterscheidet „das existiert nicht" von „das hat niemand erwähnt".

Unsere erwähnt internal/adapter/marketplace/ nie. In diesem Package liegen ein Provider-Interface und acht Adapter: GitHub, GitLab, Argo CD, Datadog, Prometheus, Sentry, SonarQube, PagerDuty. Die Adapter-Liste in CLAUDE.md endet bei git, ai, stripe, email, osv und registry. Nichts, was die Datei über den Marketplace sagt, ist falsch. Die Datei hat keinen.

Ich habe das Experiment nicht gemacht, einen Agenten um eine neunte Integration zu bitten, und ich werde dir nicht erzählen, was dabei herauskäme, denn ich würde mir das Ergebnis ausdenken. Was ich dir sagen kann: Auf der Karte ist kein Marketplace eingezeichnet, und das ist der Normalzustand jeder Rules-Datei, die ich gelesen habe, die eingeschlossen, die ich selbst geschrieben habe.

Ein Modell hat diese Eigenschaft nicht. Du kannst ein Modell fragen, was existiert, und bekommst eine Antwort, die etwas bedeutet, weil die Antwort eine Abfrage über eine Menge ist und keine Suche durch Prosa. „Was redet mit dem Payment-Service" ist eine Frage, die ein Graph beantworten kann und ein Absatz nicht.

Die zwei naheliegenden Antworten, und warum keine trägt

Schreib eine bessere Rules-Datei. Länger, sorgfältiger, mit einer Checkbox im PR-Template. Teams machen das, und ein paar Wochen lang funktioniert es. Es hält nicht, aus einem Grund, der mit Disziplin nichts zu tun hat: Jede Zeile, die das System beschreibt, ist eine gecachte Kopie von etwas, das woanders lebt, und Caches brauchen Invalidierung. Hier ist die Invalidierung ein Mensch, der etwas bemerkt. Das ist der ganze Mechanismus, und es ist derselbe, der in den letzten zwanzig Jahren Architekturdiagramme korrekt halten sollte. Wir wissen, wie das ausgegangen ist; der Leitfaden zur Drift-Detection ist die lange Fassung dieses Arguments.

Lass den Agenten das Repository lesen. Er kann das, und bei einer Frage zu einer einzelnen Datei sollte er es auch. Aber den Code zu lesen sagt dir nicht, welche Grenzen absichtlich gezogen wurden. Das Interface vor einem Service sieht identisch aus, egal ob es da ist, weil vor zwei Jahren nach einem Incident so entschieden wurde, oder weil jemand Interfaces mag. Absicht lässt sich aus dem Artefakt, das aus ihr entstanden ist, nicht zurückgewinnen. Genau deswegen gibt es die Rules-Datei überhaupt, und genau deswegen ist Löschen auch keine Antwort.

Jemand außerhalb dieser Firma hat dasselbe bemerkt

Thoughtworks hat „Architecture drift reduction with LLMs" in den Assess-Ring des Technology Radar Vol. 34 gesetzt, veröffentlicht im April 2026. Ihr Einstieg:

Increased use of AI coding agents can accelerate drift from the intended codebase and architecture designs. Left unchecked, this drift compounds as agents and humans replicate existing patterns, including degraded ones, creating a feedback loop where poor code begets poorer code.

Der zunehmende Einsatz von KI-Coding-Agenten kann die Abweichung von der beabsichtigten Codebase und den Architekturentwürfen beschleunigen. Bleibt dieser Drift unkontrolliert, verstärkt er sich, während Agenten und Menschen bestehende Muster replizieren, auch degradierte, und erzeugt so eine Feedback-Schleife, in der schlechter Code noch schlechteren Code hervorbringt.

Assess bedeutet in der Definition des Radars selbst „worth exploring with the goal of understanding how it will affect your enterprise" — einen Blick wert, mit dem Ziel zu verstehen, wie es dein Unternehmen betreffen wird. Das ist keine Empfehlung für irgendetwas, und schon gar nicht für uns. Es ist die Notiz, dass einige ihrer Teams das ausprobieren und dass es früh ist.

Nützlich ist die Form, die sie beschreiben: deterministische Analysewerkzeuge (sie nennen Spectral, ArchUnit und Spring Modulith) kombiniert mit LLM-Bewertung, weil Struktur von einem Programm prüfbar ist und Absicht nicht. Auch ihre berichtete Lektion lohnt sich zu klauen: Der erste Scan fördert mehr Verstöße zutage, als irgendjemand triagieren will.

Achte darauf, was in diesem Rezept nicht vorkommt. Niemandes Antwort auf agentenbeschleunigten Drift ist eine längere Markdown-Datei.

Was das Artefakt leisten müsste

Zwei Eigenschaften. Keine davon ist exotisch.

Es muss aufzählen können. Du solltest fragen können, was existiert, und die Menge bekommen, nicht die Erinnerung von jemandem daran. Das heißt: ein Artefakt, das du abfragst statt liest, und der Unterschied zeigt sich am härtesten bei den Fragen, die niemand aufgeschrieben hat.

Es muss falsifizierbar sein. Irgendetwas muss es mit dem Code vergleichen und melden, welche Teile nicht mehr stimmen, nach einem Takt, der nicht „wenn ein Mensch es bemerkt" heißt. ArchUnit macht das für Java-Schichtregeln. dependency-cruiser macht es für JavaScript-Imports. Beide sind bewusst eng, und beide machen den Punkt: Das Artefakt, das etwas taugt, ist eines, dem ein Programm widersprechen kann.

Eine Rules-Datei fällt bei beidem durch. Sie zählt nicht auf, und nichts kann ihr widersprechen.

Wo wir stehen, und was ich dir nicht sagen kann

Archyl pflegt ein C4-Modell deines Systems: Systeme, Container, Components, Beziehungen, aus dem Repository erzeugt von der KI-Discovery und von einem Menschen freigegeben statt von einem gezeichnet. Dieses Modell ist die aufzählbare Hälfte, und Agenten erreichen es über MCP, im Umfang von 181 Tools, sodass ein Agent fragt, was existiert, statt zu hoffen, dass es jemand aufgeschrieben hat. Die Konventionshälfte ist ein Conformance-Katalog: 169 Regeln über 23 benannte Technologien hinweg plus ein sprachunabhängiges Set, deterministische Checks statt Prosa. Und das Modell wird gegen den Code neu geprüft und bewertet, was die Falsifizierbarkeits-Eigenschaft ist.

Einen MCP-Server zu haben ist nicht der interessante Teil, und wer dir einen als Alleinstellungsmerkmal verkauft, verkauft dir eine Steckdose. Structurizr liefert einen und IcePanels ist in offener Beta. Die Frage, über die zu streiten sich lohnt, ist, ob das Ding hinter der Steckdose gepflegt wird, denn ein Endpunkt, der ein Modell ausliefert, das im März veraltet ist, ist nur ein schnellerer Weg, falsch zu liegen.

Ich glaube, das ist der Unterschied, auf den es ankommt. Beweisen kann ich es nicht. Niemand hat gemessen, ob ein Agent, der von einem gepflegten Modell aus arbeitet, besser geformten Code schreibt als ein Agent, der von einer sorgfältigen Rules-Datei aus arbeitet, und bis das jemand tut, ist dieser Satz eine Behauptung über einen Mechanismus, kein Ergebnis. Halt ihn so, und widersprich jedem, der ihn flacher formuliert als ich es gerade getan habe.

Es gibt hier auch einen ehrlichen Haken. Archyl generiert eine Rules-Datei. Das MCP-Tool get_agent_context gibt die Architektur als Markdown-Briefing zurück, das du in dein Repository committen kannst — eine Rules-Datei unter anderem Namen. Die Datei war nie das Problem. Das Problem war, dass nichts hinter ihr stand, also konnte nichts sie neu erzeugen. Eine Rules-Datei, die der Cache eines gepflegten Modells ist, ist in Ordnung. Eine Rules-Datei, die die einzige Kopie ist, ist ein Schnappschuss dessen, was eine Person an einem Nachmittag geglaubt hat.

Die Fünf-Minuten-Variante, die dich nichts kostet

Ignorier alles darüber und mach stattdessen das hier.

Öffne deine Rules-Datei. Geh Zeile für Zeile durch und markier jede entweder als Konvention — sie sagt dem Agenten, wie man Code schreibt — oder als Behauptung — sie sagt dem Agenten etwas über dein System. Dann schreib für jede Behauptung auf, woran du merken würdest, dass sie nicht mehr stimmt.

Meine Vermutung: Du kommst mit einer leeren zweiten Spalte am Ende der Datei an. Das ist die Lücke. Was du dagegen tust, ist eine separate Entscheidung, und um sie zu sehen, musst du nichts kaufen.

Unsere hat ein paar Minuten gedauert und drei falsche Zeilen zutage gefördert. Sie zu reparieren ist ein Commit, und strukturell ändert das nichts: Die nächste Zeile veraltet auf genau dieselbe Weise, und auch bei der schaut niemand hin.