Warum weniger mehr ist: KI-Config-Dateien im Software-Engineering

Mit dem Einzug KI-gestützter Entwicklungs-Tools wie Claude Code, Cursor oder GitHub Copilot hat sich der Programmieralltag grundlegend verändert. Ein zentrales Element in diesem neuen Workflow sind sogenannte KI-Konfigurationsdateien. Doch wie funktionieren sie genau, wie setzt man sie im komplexen ÖPNV-Umfeld richtig ein und warum ist weniger oft deutlich mehr?

Funktionsweise: Wie funktionieren KI-Config-Dateien?

Das Kernprinzip von KI-Konfigurationsdateien basiert auf der automatischen System-Prompt-Injektion. Es handelt sich dabei um einfache Markdown-Dateien im Repository (meist direkt im Root-Verzeichnis). Sobald ein Entwicklungs-Tool oder CLI-Agent wie Claude Code, Cursor oder Windsurf gestartet wird, liest die KI diese Dateien automatisch aus und stellt sie als Kontext vor jede Benutzereingabe.

Man kann sich diese Dateien wie ein kompaktes Onboarding-Dokument für ein neues Teammitglied vorstellen, wenn es sich in einem MENTZ-Repository orientieren muss. Der Ablauf im Hintergrund ist denkbar simpel:

• Initialisierung: Das KI-Tool startet im Projektordner und sucht nach vordefinierten Dateinamen wie CLAUDE.md, .cursorrules oder AGENTS.md.
• Prompt-Injektion: Der Inhalt wird als sogenannter „Top-Level Context“ direkt in den System-Prompt injiziert.
• Verhaltensanweisung: Das Sprachmodell verarbeitet diese Vorgaben als fundamentale Verhaltensanweisungen noch bevor die erste Zeile Code generiert oder angepasst wird.

Marktübersicht: Welches File für welches Tool?

In den letzten Jahren hat sich eine Vielzahl werkzeugspezifischer Formate etabliert, auch wenn das Grundprinzip stets identisch bleibt:

• Anthropic / Claude Code: Verwendet bevorzugt CLAUDE.md im Projekt-Root für lokales Kontextwissen sowie ~/.claude/CLAUDE.md für globale Nutzereinstellungen.
• GitHub Copilot: Arbeitet standardmäßig mit .github/copilot-instructions.md.
• Cursor IDE: Nutzt traditionell .cursorrules auf Projektebene oder das neuere, modularere Format unter .cursor/rules/*.mdc.
• Open-Source & Agenten-Standard: Mit AGENTS.md setzt sich zunehmend ein herstellerübergreifender Standard für autonome Entwicklungsagenten wie Goose, Cline oder OpenHands durch.

Zielsetzung im MENTZ-Kontext: Welchen Zweck erfüllen sie?

In der Anwendungsentwicklung bei MENTZ erfüllen KI-Config-Dateien vor allem die Aufgabe, KI-Agenten zielsicher durch unsere spezifische Fachdomäne und Systemarchitektur zu steuern:

• WHY (Fachdomäne): Vermittlung des fachlichen Fokus auf verteilte Echtzeit-Systeme für ÖPNV/ÖPFV, Fahrplanauskunft, E-Ticketing und Dispositionssoftware.
• WHAT (Stack): Orientierung im Technologiestack bestehend aus C# / .NET Core Services, hochperformanten C++ Komponenten für Routing-Algorithmen, Angular Frontends und GIS-Geodatenverarbeitung.
• HOW (Workflow): Exakte Definition, wie im MENTZ-Ökosystem gebaut, getestet und deployed wird.

Darüber hinaus helfen diese Konfigurationen, Fehlentscheidungen der KI frühzeitig zu verhindern. Beispiele hierfür sind:

• Exakte Befehle bereitstellen: Klare Vorgaben für Build- und Testläufe (z. B. dotnet test, ng test, cmake --build).
• Architektur-Leitplanken setzen: Verhindern, dass die KI systemfremde Frameworks einführt. Da MENTZ in vielen Produkten auf Angular setzt, soll die KI beispielsweise keine React-Komponenten vorschlagen oder für Geodaten-Transformationen MENTZ-interne GIS-Module bevorzugen.
• Anti-Patterns vermeiden: Spezifische Performance- und Legacy-Einschränkungen aufzeigen – wie etwa strikte Regeln zur Speicherverwaltung bei C++ Routing-Kernen.

Expertenmeinungen & Research

Obwohl Konfigurationsdateien extrem nützlich sind, neigen viele Entwicklungsteams zu Beginn dazu, sie zu überfrachten. Führende KI-Experten und Forschungsarbeiten warnen eindringlich vor dieser Falle.

A. Boris Cherny (Creator & Lead von Claude Code bei Anthropic)

Boris Cherny empfiehlt einen radikalen Schritt: Das regelmäßige Löschen aller Config-Dateien. Seiner Erfahrung nach sollten Konfigurationsdateien und benutzerdefinierte KI-Skills nicht als dauerhafte Artefakte behandelt werden, sondern alle paar Monate von Grund auf neu aufgebaut werden.

Der Grund liegt in der rasanten Evolution der Modelle. Der Leistungssprung von älteren KI-Generationen zu modernen Reasoning-Modellen macht unzählige Mikromanagement-Regeln und alte Workarounds obsolet. Veraltete CLAUDE.md-Dateien schränken intelligentere Modelle heute eher ein, als dass sie ihnen helfen.

B. Anthropic Dokumentation

In der offiziellen Dokumentation zu Claude Code gilt das klare Motto „Less is More“. Das Ziel ist eine knappe Datei unter 200 Zeilen:

„Keep each file under about 200 lines and ask of every line: ‚Would removing this cause Claude to make a mistake?‘ If not, cut it. A bloated CLAUDE.md is worse than a short one, because the important rules get lost in the noise.“

— Quelle: Anthropic Claude Code Official Documentation / Best Practices Analysis

C. HumanLayer & Speakeasy Research

Untersuchungen von HumanLayer zeigen das Phänomen des „Instruction Decay“ (Aufmerksamkeitsverlust bei großen Kontexten):

„Frontier thinking LLMs can follow ~150-200 instructions with reasonable consistency … As instruction count increases, instruction-following quality decreases uniformly across all instructions, not just the later ones.“

— Quelle: HumanLayer Engineering Blog (Writing a good CLAUDE.md)

Warum man sie nicht mehr exzessiv nutzen sollte

Das Kernproblem vieler KI-Konfigurationsdateien ist Over-Engineering. Früher versuchte man, KI-Modellen detaillierte Prozessregeln Schritt für Schritt vorzuschreiben. Moderne LLMs verstehen jedoch dank fortschrittlicher Reasoning-Fähigkeiten eigenständig, wie ein C#-Projekt aufgebaut ist oder wie ein Angular-Service eingebunden wird.

Es entsteht ein Kontext-Paradoxon: Je mehr Text in der Konfigurationsdatei steht, desto höher ist die Wahrscheinlichkeit, dass die KI kritische Systemanweisungen oder MENTZ-spezifische Richtlinien schlicht ignoriert. Zudem entsteht ein massiver Wartungsoverhead. Zu lange Dateien verhalten sich wie veraltete Software-Dokumentation: Sie führen die KI auf eine falsche Fährte.

Praxistransfer: Damals vs. Heute

Blickt man ein paar Jahre zurück, sah die Praxis völlig anders aus. In Prompt-Dateien wurden langwierige Abläufe definiert: „Schritt 1: Plane die Schritte. Schritt 2: Erstelle Unit-Tests mit xUnit. Schritt 3: Implementiere den Service…“

Aus heutiger Sicht ist dieses Vorgehen reine Zeitverschwendung. Moderne Agenten arbeiten nativ in spezialisierten Plan-Modi und verifizieren ihren generierten Code selbstständig. Die wichtigste Lektion lautet daher: Verschwende keine Zeit mit werkzeugspezifischen Syntax-Tricks und Überoptimierungen. Statt sich in Details einzelner Tools zu verfangen, lohnt es sich vielmehr, das generelle Funktionsprinzip von Sprachmodellen, Kontextfenstern und Prompt-Strukturen zu verstehen. Dieses Grundlagenwissen bleibt auch bei zukünftigen Modellgenerationen gültig.

Best Practices (Stand: August 2026)

Basierend auf unseren Erfahrungen im MENTZ-Entwickleralltag lassen sich folgende Best Practices zusammenfassen (wobei zu beachten ist, dass sich diese Empfehlungen mit dem schnellen Fortschritt der KI-Technologie weiterentwickeln werden):

1. Kurz halten (< 200 Zeilen): Halte die Stamm-Datei strikt unter 200 Zeilen. Nutze die kürzeste Datei, mit der das Modell fehlerfrei arbeitet.
2. Keine Linter- oder Formatierungsregeln: Code-Styles (Einrückung, Semikolons, Klammerung) gehören in Tools wie Roslyn Analyzers / EditorConfig (.NET), Clang-Format (C++) oder ESLint/Prettier (Angular) – nicht in die KI-Config. Lass die KI stattdessen dotnet format oder npm run lint ausführen.
3. Auf das Wesentliche beschränken: Schreib nur rein, was die KI wirklich wissen muss: die exakten Befehle für Build und Test, die wichtigsten Architektur-Regeln (wie .NET mit Angular) und kritische Tabus (z. B. dass große Daten nicht ohne Ablaufdatum im Speicher landen dürfen).
4. Regelmäßiger Hard Reset: Hinterfrage alle paar Monate sämtliche CLAUDE.md-Dateien und KI-Skills oder lösche sie komplett (die Boris-Cherny-Regel). Prüfe, ob das neu erschienene Modell die Aufgaben nicht bereits ohne händische Instruktionen löst.
5. Progressive Disclosure nutzen: Lagere detaillierte Architekturdokumentation in Unterordner aus (z. B. docs/architecture/routing.md) und verlinke sie nur in der Hauptdatei. Der Agent liest sie dann gezielt bei Bedarf.

Am Ende zeigt sich: KI-Tools sind mächtige Assistenten im Software-Engineering für den öffentlichen Verkehr. Wer ihnen klare, schlanke und fokussierte Rahmenbedingungen mitgibt, erzielt die besten Ergebnisse – ganz ohne Ballast.