Letzte Woche habe ich die Krankheit diagnostiziert: sechs KI-Coding-Tools, sechs proprietäre Config-Formate, null Interoperabilität. CLAUDE.md unsichtbar für Cursor. .cursor/rules bedeutungslos für Copilot. Wochenlang aufgebaute Team-Intelligenz eingesperrt in dem Parser, der sie zufällig lesen kann.
Jede Reaktion auf den Artikel bestätigte: Das Lock-In ist real — und stellte dann dieselbe Frage: 'Und was mache ich jetzt dagegen?" Fair. Eine Geiselnahme diagnostizieren, ohne einen Rettungsplan zu liefern, ist nur Kommentar. Hier ist der Rettungsplan.
Warum 'klug wählen" nicht mehr reicht
Allein in der letzten Woche hat sich die Lage dreimal verschoben. GitHub hat am 20. April alle individuellen Copilot-Anmeldungen eingefroren, weil agentische Compute das Flatrate-Modell gesprengt hat — VP of Product Joe Binder gab zu, dass 'agentic workflows have fundamentally changed Copilot's compute demands." Am 15. April hat Zed parallele Subagents und ein universelles LLM-Gateway ausgeliefert. Am 14. April hat Anthropic Claude Code zur Desktop-App umgebaut — inklusive Cloud-getriggerter Routines. OpenAI hat sein Agents SDK am 15. April aktualisiert — mit sandboxed Execution und MCP-Integrationen. Tools mutieren wöchentlich. Deine Regeln sollten nicht in dem Tool gefangen sein, das du vor sechs Monaten gewählt hast.
Das Problem kennst du. Dieser Guide liefert eine funktionierende Lösung, die du heute committen kannst.
Der Fix: eine kanonische Datei, fünf Vendor-Kopien
Das Konzept ist beleidigend simpel. Halte eine einzige Source-of-Truth-Regeldatei in einem vendor-neutralen Verzeichnis. Synchronisiere sie per Shell-Skript in jedes Vendor-Format. Bearbeite die Vendor-Dateien nie direkt.
Schritt 1: .ai/rules.md anlegen
Wähle einen Verzeichnisnamen, den kein Vendor beansprucht hat. .ai/ funktioniert.
.ai/
├── rules.md # Kanonische Projektregeln
├── architecture.md # System-Design-Kontext
├── patterns.md # Code-Konventionen
└── sync.sh # Das Skript, das dich befreit
Deine rules.md ist pures Markdown:
---
project: my-app
lang: [typescript, python]
updated: 2026-04-21
---
# Project Rules
## Code Style
- Strict TypeScript. No `any`. Ever.
- Python: Black formatter, 88-char lines.
- All functions get docstrings. No exceptions.
## Architecture
- Monorepo: apps/ for services, packages/ for shared libs.
- API routes in `src/routes/`, logic in `src/services/`.
- Never import across apps directly. Use packages.
## Testing
- Unit tests co-located: `foo.ts` → `foo.test.ts`.
- Integration tests in `__tests__/integration/`.
- 80% branch coverage minimum on services/.
## Deployment
- Main branch auto-deploys to staging.
- Production: manual approval + passing E2E.
- Env vars in Vault, never in .env files.
## Gotchas
- Payments service uses legacy Stripe v2 client. Don't refactor — vendor contract.
- GraphQL types generate at build time. Run `make codegen` after schema changes.
Source of Truth. Jedes Tool kann sie lesen. Jeder Mensch kann sie lesen. Keine Vendor-Magie, nur Markdown.
Schritt 2: Das Sync-Skript
#!/usr/bin/env bash
set -euo pipefail
CANONICAL=".ai/rules.md"
[ ! -f "$CANONICAL" ] && echo "No ${CANONICAL} found." && exit 1
HEADER="# Auto-generated from .ai/rules.md — do not edit directly"
BODY=$(printf '%s\n\n%s' "$HEADER" "$(cat "$CANONICAL")")
echo "$BODY" > CLAUDE.md # Claude Code
mkdir -p .cursor && echo "$BODY" > .cursor/rules # Cursor
mkdir -p .github && echo "$BODY" > .github/copilot-instructions.md # GitHub Copilot
echo "$BODY" > GEMINI.md # Gemini
mkdir -p .windsurf && echo "$BODY" > .windsurf/rules # Windsurf
echo "Synced to 5 vendor configs."
Zwanzig Zeilen. Fünf Vendors. Eine Quelle. Nach jeder Änderung ausführen. Das ist der ganze Trick.
Schritt 3: Automatisieren — weil du es sonst vergisst
Du kennst dich. Richte einen Pre-Commit-Hook ein:
#!/usr/bin/env bash
# .git/hooks/pre-commit (oder husky / lefthook)
if git diff --cached --name-only | grep -q "^\.ai/"; then
echo "Changes in .ai/ — syncing vendor configs..."
bash .ai/sync.sh
git add CLAUDE.md .cursor/rules .github/copilot-instructions.md \
GEMINI.md .windsurf/rules
fi
Kanonische Datei bearbeiten, committen, Vendor-Kopien aktualisieren sich von selbst. Der # Auto-generated-Header sagt dem Team: Finger weg von den generierten Dateien.
Schritt 4: Architektur-Kontext
Regeln allein reichen nicht. KI-Tools konsumieren auch Architektur-Docs und Component Maps. Gleiches Muster — alles in .ai/ halten, beim Sync konkatenieren:
<!-- .ai/architecture.md -->
# System Architecture
## Services
- **api-gateway**: Express.js — auth + routing
- **user-service**: Python/FastAPI — owns user data
- **payments**: Node.js — Stripe integration (legacy v2)
- **notifications**: Go — async via SQS
## Data Flow
Requests → api-gateway → service → own DB.
Cross-service: SQS events only. Never direct HTTP.
Erweitere sync.sh, um rules.md + architecture.md + patterns.md zu konkatenieren. Claude Code kann nativ mit mehreren Kontext-Dateien umgehen; für Tools, die das nicht können, funktioniert eine große Datei genauso.
Was sich nicht portabel machen lässt
Hier verdienen sich die Vendors ihr Lock-In — und hier höre ich auf, so zu tun, als würde das alles lösen.
Agent-Runtime-Configs. Claude Codes Routines — Cloud-Agenten, getriggert durch Zeitpläne oder GitHub-Events — haben kein Cursor-Äquivalent. Cursors parallele Agent-Orchestrierung funktioniert völlig anders als Zeds Subagents. Das sind Runtime-Verhalten, kein statischer Kontext. Keine Config-Datei kann sie erfassen, weil es keine Configs sind. Es sind Produktfeatures, die du mietest.
Angesammeltes Gedächtnis. Claude Code baut über die Zeit MEMORY.md auf — ein Protokoll vergangener Entscheidungen, Fehler, gelernter Muster. Wissen, das die KI während der Nutzung generiert, nichts, was du selbst schreibst. Du kannst es nicht synchronisieren, weil es erst existiert, wenn die KI es erstellt. Tool wechseln, Gedächtnis weg. Wie den Therapeuten wechseln und bei Sitzung eins anfangen — nur dass der Therapeut auch deinen Namen vergessen hat.
Modell-optimierte Formulierungen. 'Verwende immer beschreibende Variablennamen" funktioniert überall. Aber wenn du wochenlang Regeln feingetunt hast, die ausnutzen, wie Claude mit Mehrdeutigkeiten umgeht, oder GPTs Tendenz zur Überabstraktion umschiffen — diese Nuancen lassen sich nicht portieren. Verschiedene Modelle, verschiedene Macken, verschiedene Fehlerarten.
Die portable Schicht deckt ungefähr 80% von dem ab, was dein KI-Tool auf deinem Projekt nützlich macht. Die restlichen 20% sind echtes Vendor-Lock-In. Die Grenze zu kennen ist wichtiger, als so zu tun, als gäbe es sie nicht.
CI: Vertrau niemandem, am wenigsten dir selbst
Füge Drift-Erkennung in deine Pipeline ein:
# .github/workflows/ai-rules-check.yml
name: AI Rules Sync Check
on: [pull_request]
jobs:
check-sync:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Verify vendor configs match source
run: |
bash .ai/sync.sh
if ! git diff --quiet; then
echo "Vendor configs drifted from .ai/rules.md"
git diff --stat
exit 1
fi
Jemand bearbeitet CLAUDE.md von Hand? CI killt den PR. Drift weg. Eine Maschine, der deine Gefühle und deine Deadline egal sind, setzt Compliance durch.
Warum kein Vendor das für dich bauen wird
MCP hat uns ein universelles Protokoll für Tool-Verbindungen gegeben. Für Projekt-Kontext hat das niemand gemacht. Kein ai-rules.json-Standard, keine Interoperabilitäts-Spezifikation, keine Arbeitsgruppe. Jeder Vendor profitiert von der Inkompatibilität — versehentliches Lock-In, das nichts in der Wartung kostet und sich in Retention auszahlt.
JetBrains hat im April 2026 über 10.000 Entwickler befragt und festgestellt: Claude Code liegt bei 91% Zufriedenheit mit einem NPS von +54. Beeindruckende Zahlen, die Sunk Costs genauso messen wie Qualität. Teams mit fünfzig CLAUDE.md-Dateien quer durch ihre Repos wechseln nicht. Nicht weil Claude unersetzlich wäre, sondern weil die Migrations-Rechnung brutal genug ist, um das Gespräch zu killen, bevor es anfängt.
Deine .ai/rules.md verwandelt diese Rechnung von 'zwei Wochen manuelles Umschreiben" in 'Skript ausführen, Diff prüfen." Sie portiert nicht alles. Die 20% — das Gedächtnis, die Runtime-Verhalten, das modellspezifische Feintuning — kosten weiterhin echten Aufwand. Aber es ist der Unterschied zwischen Lock-In aus Überzeugung und Lock-In aus Nachlässigkeit.
Die Tools wollen nicht, dass du das baust. Sie verhindern es aber auch nicht. Sie rechnen nur damit, dass du dir die Mühe nicht machst.
Mach dir die Mühe.



