AITM liest nicht nur die Quelldateien — es baut ein strukturiertes, abfragbares Modell dessen auf, was der Code tatsächlich tut, damit die KI nicht mehr rät, sondern prüft.
Wie AITM ein Projekt versteht
Behavioral Contracts
Jedes relevante Feature in der Codebasis lässt sich als Behavioral Contract erfassen: eine maschinenlesbare Spezifikation mit einer ID, dem zugehörigen Modul, einer einzeiligen Verhaltensbeschreibung, den genau betroffenen Dateien, einer Danger-Zone-Warnung und einem Confidence-Wert. Contracts werden pro Projekt in einer lokalen SQLite-Datenbank gespeichert, und die KI fragt sie per GraphQL ab, bevor sie eine einzige Codezeile anfasst. Das ist der wichtigste Grund, warum halluzinierte Dateipfade und erfundene Methoden seltener werden — die KI prüft den Contract, statt zu raten.
Contracts veralten auch nicht: Nach jedem Merge scannt der Docs-Pipeline-Schritt die Änderung automatisch erneut und aktualisiert jeden betroffenen Contract.
Danger Zones
Jeder Contract kann eine Danger Zone tragen — eine Warnung in klarer Sprache zum Wirkungsbereich bei Änderungen an diesem Code (etwa „niemals aufrufen, ohne zuvor das Skip-Flag zu prüfen“). Die KI liest Danger Zones vorab und weiß daher, was NICHT kaputtgehen darf, bevor sie mit dem Bearbeiten beginnt, und nicht erst, nachdem ein Test fehlschlägt.
Der Knowledge Graph
Hinter einem GraphQL-Endpunkt stehen zehn miteinander verknüpfte Wahrheitsquellen zum Projekt:
- Der Variablenbaum (
BL.*-Codes für Business-Logik,UI.*-Codes für die Oberfläche) - Behavioral Contracts
- Die DOM-Elementkarte
- Das Hint Dictionary
- Der Dokumentationsindex
- Die Code-Karte — Imports/Exports, stark gekoppelte „God nodes“ und Modul-Communities
- Die Test-Karte — UI-Element zu Playwright-Locator
- Screenshots
- Bugs
- Modulübergreifende Kanten, die all das miteinander verknüpfen
Eine einzige Abfrage kann zusammengehörigen Kontext aus allen zehn Quellen gleichzeitig holen, statt dass die KI blind das gesamte Repository durchsucht.
Projekt-Onboarding
Beim ersten Import eines Projekts führt AITM einen deterministischen statischen Vorab-Scan durch, bevor eine KI es anfasst: Erkennung von Sprache und Stack, eine vollständige Code-Karte, DOM-Extraktion über data-aitm-Attribute, Variablen-Backfill und Dokumentationsverweise. Erst danach führt AITM optional KI-Durchläufe aus — Architekturerkennung, Git-Historien-Auswertung zur Modulkopplung und einen tiefen Durchlauf pro Modul. Kurz gesagt: Ein Repository importieren, und AITM kartiert es, bevor der erste Task überhaupt läuft.
DOM-Karte + Dev Panel
Echte UI-Elemente der App werden mit data-aitm-Attributen versehen, jeweils mit Kanten für auslösende und ausgelöste Effekte sowie einer Pixel-Rect-Karte, wo das Element auf dem Bildschirm sitzt. Diese Karte speist zuverlässige, selbstheilende E2E-Test-Selektoren anstelle fragiler CSS-Locatoren.
Was das Dev Panel tut
Das Dev Panel ist eine in sich geschlossene, einbindbare JS-Symbolleiste (aitm-dev-panel.js), die jedes von AITM verwaltete Projekt während der Entwicklung laden kann. Es ist eine schwebende, andockbare Symbolleiste, die jedes mit data-aitm markierte Element der laufenden App mit einem Badge überlagert: Ein Hover-Tooltip zeigt Code, Tag, Aktion und Handler des Elements, ein Live-Ereigniszähler läuft mit, über ein kleines Chat-/Brainstorm-Feld lässt sich die AITM-Instanz direkt aus der laufenden App ansprechen, und es gibt Schriftgrößen-Steuerelemente sowie eine Online-/Offline-Anzeige für AITM selbst. Das Panel verfolgt echte Benutzerinteraktionen (click/change/input/mount/unmount) in dem Moment, in dem sie geschehen, und sendet sie alle 2 Sekunden an AITM — so hält AITM seine Karte der Oberfläche aktuell.
Das Panel hat vier Tabs: Elements (die angeklickten oder angehefteten Elemente mit Variablencode, Contracts, Dateien und Danger-Zone-Warnungen; die Schaltflächen Overlay, Pin / One Pin und Clear Pins), Records (die aufgezeichneten UI-Elemente), Errors (erfasste JavaScript- und Konsolenfehler, die in AITM zu Bug-Tasks werden können) und Settings. Die vollständige Dokumentation öffnet sich in AITM über das Header-Menü: Help → AITM Dev Panel.
Läuft AITM auf einem anderen Rechner als diese Website, wird AitmServer:PublicBaseUrl in der Konfiguration gesetzt (z. B. http://192.168.1.50:3333) — die Adresse, von der der Browser aitm-dev-panel.js lädt. Leer bedeutet http://<page host>:<Port>. Die AITM-Adresse kann auch später im Tab Settings des Panels geändert werden.
Guide & Flow — der Business-Logic-Flow eines Elements
In der Zeile eines Elements im Dev Panel lässt sich dessen Detail mit den Tabs Graph, Guide & Flow und App Flow öffnen. Guide & Flow erklärt das ausgewählte Element von oben nach unten in einfachen Schritten — zuerst das UI-Element selbst, dann die Business-Contracts, die sein Verhalten beschreiben (jeweils mit den Variablen, die sie betreffen). Copy as Markdown kopiert die gesamte Erklärung in die Zwischenablage, bereit zum Einfügen in einen Task-Prompt. Mehr dazu unter Contract Explorer & App Flow.
Pro Projekt aktivieren und deaktivieren
Es handelt sich um ein einziges bedingtes <script>-Tag in der gemeinsamen HTML-Hülle des Projekts, das nur außerhalb von Production angezeigt wird und ein Attribut data-project="<your-project-id>" trägt, damit das Panel automatisch das richtige Projekt anspricht.
Blazor Server (.NET 8+)
In App.razor IWebHostEnvironment injizieren und das Script-Tag mit IsProduction() absichern:
@inject IWebHostEnvironment env
@if (!env.IsProduction())
{
<script src="http://localhost:3333/aitm-dev-panel.js" data-project="your-project-id"></script>
}
ASP.NET Core Razor Pages
Dasselbe Muster — @inject IWebHostEnvironment env plus dieselbe IsProduction()-Absicherung — in der gemeinsamen _Layout.cshtml, mit demselben Codeblock wie oben.
Node / Express / TypeScript
Mit process.env.NODE_ENV in dem Template absichern, das die HTML-Hülle rendert:
{process.env.NODE_ENV !== 'production' &&
'<script src="http://localhost:3333/aitm-dev-panel.js" data-project="your-project-id"></script>'}
Zum Deaktivieren wird das bedingte Script-Tag entfernt oder die App einfach in Production betrieben — die Absicherung blendet es automatisch aus, ohne dass das Tag angefasst werden muss.
Tipps
- Scheint die KI eine Datei „schon zu kennen“, die sie in dieser Sitzung nie geöffnet hat, ist das eine Contract-Abfrage bei der Arbeit und kein Zufallstreffer.
- Die Danger Zone eines Contracts lohnt sich auch dann zu lesen, wenn der Code selbst geändert wird — oft ist es der schnellste Weg, eine versteckte Abhängigkeit zu erkennen.
- Ein erneuter Import des Projekts nach größeren Refactorings lässt den Onboarding-Vorab-Scan die neue Struktur nachholen.