KI-Agenten, die Programmcode schreiben, brauchen eine verlässliche Kenntnis des Systems. Das gilt auch für Banken und Versicherer, die damit ihre Anwendungslandschaft pflegen. André Hoendgen, CTO der MoIn Group, beschreibt in einem Kommentar vom 28. Oktober 2026 drei Bausteine. Erstens eine Codemap: Sie wird bei jedem Build aus dem Code selbst erzeugt und zeigt, was existiert, wo es liegt und wie es zusammenhängt. Dazu gehören auch die Übergänge zwischen Frontend, Backend und Datenbank. Zweitens Annotationen, die den Zweck festhalten. Das Tag @summary beschreibt, was eine Funktion tut. Das Tag @intent hält fest, warum sie es tut, und diese Begründung steht sonst nirgends im Code. Drittens deterministische Prüfungen mit Linter, Compiler und Tests. Eine Regel in einer Anweisungsdatei kann ein Agent überlesen, eine Regel im Linter ist eine Bedingung, an der kein Weg vorbeiführt. Für die Praxis ergibt sich diese Reihenfolge: Neue Funktionen erhalten den Zweck beim Schreiben, angefasste Altfunktionen werden nachgerüstet, und ein Pre-Commit-Hook erzwingt die Annotation. Die Architekturdokumentation, etwa nach arc42, liegt im selben Repository wie der Code. Das Verständnis liegt dann im Repository und überdauert Sitzungsende, Modellwechsel und den Weggang von Kollegen. Für Vorstand, CISO und IT-Leitung ist das ein Steuerungshebel: Die Kontrolle verschiebt sich von jeder einzelnen Zeile zu Regeln, Schnitt und Schichtung. Aus unserer Erfahrung bei Kunden aus Versicherung und Bank lässt sich die Umsetzung daran erkennen, dass Prüfregeln automatisch greifen und Ausnahmen protokolliert werden. Der Autor betont, dass die Karte ein schlecht geschnittenes System nicht heilt und Architektur, Reviews und Tests ihre Bedeutung behalten.