KI-Coding-Agenten schreiben schnell Code. Ohne Leitplanken driften sie genauso schnell ab. Heute starten wir Agent Hub — ein neuer Bereich in Archyl, mit dem Sie Konformitätsregeln definieren, einen Katalog von 96 vorgefertigten Leitplanken durchsuchen und KI-Agenten den architektonischen Kontext geben können, den sie brauchen, bevor sie eine einzige Zeile Code schreiben.

Agent Hub: Architektur-Leitplanken für autonome KI-Agenten

Etwas Grundlegendes hat sich in der Art und Weise verändert, wie Software geschrieben wird.

Vor sechs Monaten verbrachte ein Entwickler zwei Tage damit, einen neuen Service aufzubauen. Er prüfte die ADRs, fragte einen Kollegen, welche Datenbank zu verwenden sei, folgte den Namenskonventionen, die er über Monate verinnerlicht hatte, und pushte Code, der zur Architektur passte, weil er die Architektur verstand.

Heute erledigt ein KI-Agent das in zwanzig Minuten. Der Code kompiliert. Die Tests bestehen. Aber der Agent hat MongoDB verwendet, obwohl das Team sich auf PostgreSQL standardisiert hatte. Er hat fmt.Println-Aufrufe verstreut, statt strukturiertes Logging zu verwenden. Er hat eine Datenbankabfrage direkt in einen HTTP-Handler gesetzt und dabei die Service-Schicht umgangen, die drei Sprints gebraucht hat, um sie aufzubauen.

Der Agent ist schneller. Aber er weiß nicht, was er nicht weiß.

Die wahren Kosten von Geschwindigkeit ohne Governance

Wir treten in eine Ära ein, in der die Code-Geschwindigkeit im Wesentlichen unbegrenzt ist. Claude Code, Cursor, Copilot Workspace, Devin — diese Tools können komplette Services in Minuten produzieren. Teams, die wöchentlich geliefert haben, liefern jetzt täglich. Der Engpass hat sich verschoben von „wie schnell können wir Code schreiben" zu „wie schnell kann architektonische Entropie unser System zerstören".

Stellen Sie sich vor, was passiert, wenn fünf KI-Agenten gleichzeitig an derselben Codebasis arbeiten:

Agent A fügt einen neuen REST-Endpoint mit Express-Patterns hinzu. Agent B fügt einen weiteren mit Fiber-Patterns hinzu. Jetzt haben Sie zwei API-Frameworks im selben Service.
Agent C erstellt ein Zahlungsmodul, das direkt die Datenbank abfragt. Agent D erstellt ein Bestellmodul, das über die Repository-Schicht geht. Jetzt haben Sie zwei Datenzugriffs-Patterns.
Agent E greift auf eine Bibliothek zurück, die von Ihrem Tech Radar vor sechs Monaten als deprecated markiert wurde. Sie funktioniert einwandfrei. Sie ist auch eine tickende Zeitbombe.

Keiner dieser Fälle ist ein Bug. Alle bestehen die CI. Alle funktionieren isoliert. Aber zusammen verwandeln sie Ihre Codebasis stillschweigend in einen Flickenteppich widersprüchlicher Patterns, dessen Entwirren Sie Monate kosten wird.

Das ist das Problem, für das wir Agent Hub gebaut haben.

Architektur-Leitplanken: Der Linter für Ihre Architektur

Konformitätsregeln sind deterministische Prüfungen — keine KI beteiligt — die Code-Änderungen gegen Ihre architektonischen Entscheidungen validieren. Denken Sie an sie wie ESLint für die Architektur: Sie kümmern sich nicht um Syntax, sie kümmern sich um Struktur.

Sieben Regeltypen decken die Governance-Anforderungen ab, die wir bei Hunderten von Teams beobachtet haben:

Required Pattern — Die einfachste und mächtigste. Definieren Sie Patterns, die in Ihrem Code existieren müssen oder nicht existieren dürfen. Verbieten Sie fmt.Println in Go, console.log in TypeScript, eval() überall. Verlangen Sie set -euo pipefail in jedem Shell-Skript. Verbannen Sie SELECT * aus SQL-Abfragen.

Naming Convention — Erzwingen Sie Namensregeln für Dateien, Typen und Funktionen. Go-Dateien müssen snake_case sein. React-Komponenten müssen PascalCase sein. Python-Module müssen PEP 8 folgen. Wenn ein Agent Code generiert, folgt er den Konventionen Ihres Teams, nicht seinen eigenen Standardwerten.

Technology Constraint — Sperren Sie den Technologie-Stack pro Container. Backend muss nur Go sein. Frontend muss TypeScript sein, nicht JavaScript. Kein lodash (natives JS verwenden). Kein moment.js (date-fns verwenden). Der Agent kann nicht versehentlich eine Abhängigkeit einführen, gegen die sich Ihr Team bereits entschieden hat.

Layer Boundary — Hier wird es mächtig. Definieren Sie Ihre Architekturschichten und welche Schichten von welchen importieren dürfen. Domain darf nicht von Adapter importieren. Service nur von Domain. Handler müssen über Services gehen, niemals direkt auf Repositories zugreifen. Clean Architecture, hexagonale Architektur, DDD — automatisch durchgesetzt, bei jeder Änderung, unabhängig davon, wer (oder was) den Code geschrieben hat.

Contract Compliance — Validieren Sie, dass Code-Endpoints mit Ihren API-Verträgen übereinstimmen. Wenn Sie eine OpenAPI-Spec in Archyl haben, prüft die Konformitäts-Engine, ob Ihre Handler sie tatsächlich implementieren. Keine Phantom-Endpoints, keine fehlenden Routen.

Dependency Rule — Jeder Import im Code muss eine entsprechende Beziehung im C4-Modell haben. Wenn Service A plötzlich anfängt, Service B aufzurufen, aber es keine „uses"-Beziehung in der Architektur gibt, erkennt die Regel das. Architektur-Drift wird sofort sichtbar.

Event Channel Compliance — Wenn Ihr System Kafka, NATS oder einen anderen Message Broker verwendet, validiert diese Regel, dass Produzenten und Konsumenten im Code mit den in Ihrer Architektur deklarierten Event-Kanälen übereinstimmen. Keine unkontrollierten Topics, keine nicht deklarierten Konsumenten.

96 Regeln, null Konfiguration

Regex-Patterns zu schreiben ist mühsam. Deshalb haben wir einen Katalog von 96 vorgefertigten Regeln für 21 Technologien gebaut, die mit einem Klick einsatzbereit sind.

Der Katalog ist nach Kategorien organisiert:

Security (11 Regeln) — Keine hartcodierten Passwörter, API-Schlüssel oder Secrets. Kein eval(). Keine SQL-String-Konkatenation. Keine deaktivierte TLS-Verifizierung. Keine CORS-Wildcard-Origins. Kein MD5 oder SHA1 zum Hashen. Das sind keine Vorschläge — in einer agentischen Welt sind sie nicht verhandelbar. Ein KI-Agent wird bedenkenlos ein Datenbankpasswort in einer Konfigurationsdatei hartcodieren, wenn ihm niemand sagt, dass er das nicht tun soll.

Infrastructure (22 Regeln) — Kein :latest-Tag in Dockerfiles. Ressourcenlimits in Kubernetes-Manifesten erforderlich. Keine privilegierten Container. Kein hostNetwork. Health Checks erforderlich. GitHub-Actions-Versionen an Commit-SHAs pinnen. Keine hartcodierten Credentials in Terraform. Keine Wildcard-IAM-Policies. Wenn Agenten Infrastructure-as-Code generieren, stellen diese Regeln sicher, dass das Ergebnis produktionsreif ist, nicht demo-reif.

Code Quality (18 Regeln für 10 Sprachen) — Go: kein panic(), kein init(), kein globaler mutierbarer Zustand. TypeScript: kein any-Typ, keine var-Deklarationen. Python: kein nacktes except:, keine mutierbaren Standard-Argumente, kein import *. Java: kein System.out.println, keine leeren Catch-Blöcke. Rust: kein unwrap(), kein unsafe. Jede Regel existiert, weil KI-Agenten diese Fehler konsequent machen, wenn ihnen Kontext fehlt.

Architecture (5 Regeln) — Clean Architecture, hexagonale Architektur, geschichtetes DDD, MVC-Trennung, Handler-Service-Repository-Durchsetzung. Das sind die strukturellen Leitplanken, die die teuerste Art von Drift verhindern — die Art, bei der Ihre Architektur langsam zu etwas mutiert, das niemand entworfen hat.

Testing (3 Regeln) — Keine übersprungenen Tests committed. Kein .only() in Test-Suites vergessen. Kein TODO/FIXME im Produktionscode. Kleine Regeln, die die Art von schlampigen Commits verhindern, die KI-Agenten generieren, wenn sie auf „es funktioniert" statt „es ist bereit" optimieren.

Agent-Kontext: Ein Aufruf, volles Wissen

Regeln sagen Agenten, was sie nicht tun dürfen. Kontext sagt ihnen, was sie tun sollten.

Das MCP-Tool get_agent_context gibt jedem verbundenen Agenten ein vollständiges architektonisches Briefing in einem einzigen Aufruf:

C4 Model — Jedes System, jeden Container, jede Komponente und jede Beziehung im Projekt
Architecture Decision Records — Aktive ADRs mit ihrer Begründung und ihren Entscheidungen
Technology Stack — Welche Technologien in der gesamten Organisation verwendet werden
Active Guardrails — Jede Konformitätsregel, damit der Agent die Grenzen kennt, bevor er Code schreibt
API Contracts — OpenAPI-, gRPC-, GraphQL-Specs, die die API-Oberfläche definieren
Event Channels — Kafka-Topics, NATS-Subjects, Nachrichten-Schemas

Das Tool generiert auch eine Markdown-Version — eine CLAUDE.md-Datei, die Sie in Ihr Repository committen können. Jeder Agent, der sie liest, startet mit perfektem architektonischem Wissen, ohne sich mit dem MCP-Server von Archyl verbinden zu müssen.

Das ist der Unterschied zwischen einem Agenten, der rät, und einem Agenten, der weiß. Zwischen Code, der funktioniert, und Code, der dazugehört.

Warum das jetzt wichtig ist

Die KI-Coding-Landschaft bewegt sich schnell. In sechs Monaten wird die meiste professionelle Entwicklung eine Form von KI-Agenten beinhalten. In einem Jahr werden Multi-Agenten-Workflows üblich sein — verschiedene Agenten, die gleichzeitig an verschiedenen Teilen desselben Systems arbeiten.

Ohne Governance führt das zu Chaos. Nicht die dramatische Art — die langsame, schleichende Art, bei der jeder einzelne Commit vernünftig ist, aber der kumulative Effekt architektonischer Verfall ist. Die Art, bei der Sie sechs Monate später auf Ihre Codebasis schauen und nicht erklären können, warum es drei verschiedene Logging-Bibliotheken, zwei ORM-Patterns und einen Service gibt, der irgendwie von allem abhängt.

Architektur-Leitplanken ändern diese Dynamik grundlegend:

Für Teams, die KI-Agenten einsetzen: Ihre architektonischen Entscheidungen sind nicht mehr Stammeswissen, das verloren geht, wenn ein Agent Code schreibt. Sie sind als Regeln kodiert, die automatisch durchgesetzt werden. Der Agent erhält die gleiche Governance, die ein Senior-Entwickler in einem Code Review bieten würde — aber sofort, bei jeder Änderung, ohne Review-Müdigkeit.

Für Plattform-Teams: Sie können Patterns über Dutzende von Services und Hunderte von KI-generierten Änderungen standardisieren, ohne jede einzelne manuell zu überprüfen. Definieren Sie die Regeln einmal, wenden Sie sie überall an. Wenn ein Team einen neuen Service mit einem KI-Agenten erstellt, folgt er automatisch den Konventionen Ihrer Plattform.

Für regulierte Branchen: Compliance-Anforderungen können als Konformitätsregeln kodiert werden. „Alle Services müssen Health Checks haben." „Keine PII in Logs." „Verschlüsselung im Ruhezustand erforderlich." Diese werden überprüfbar, nicht nur dokumentiert. Audit-Trails zeigen, dass jede KI-generierte Änderung vor dem Mergen gegen die Regeln validiert wurde.

Für Open-Source-Maintainer: Beitragende (menschlich oder KI), die PRs einreichen, erhalten sofortiges Feedback zur architektonischen Konformität. Keine PRs mehr reviewen, die Konventionen verletzen, die der Beitragende nicht kannte. Die Regeln dokumentieren die Erwartungen Ihrer Architektur als ausführbare Einschränkungen.

Die Teams, die in einer agentischen Welt erfolgreich sein werden, sind nicht die mit den besten KI-Agenten. Es sind die mit den klarsten architektonischen Grenzen. Die Agenten sind austauschbar. Die Architektur ist es nicht.

Loslegen

Agent Hub ist ab sofort für alle Archyl-Nutzer verfügbar. Klicken Sie auf das Agent-Symbol in der Seitenleiste. Durchsuchen Sie den Katalog, fügen Sie einige Leitplanken hinzu, und lassen Sie Ihre KI-Agenten innerhalb der von Ihnen definierten Grenzen arbeiten.

Ihre Architekturentscheidungen sollten für KI nicht optional sein. Jetzt sind sie es nicht mehr.

Agent Hub: Architektur-Leitplanken für autonome KI-Agenten - Archyl Blog