Claude Code anlernen: So bringe ich der KI meinen Coding Style bei

Claude Code kann erstaunlich schnell funktionierenden Code erzeugen.

Aber genau das ist für mich nicht die entscheidende Frage.

In einem professionellen Projekt reicht es nicht, dass Code funktioniert. Er sollte auch so aussehen, als hätte ihn das bestehende Team geschrieben.

Welche Architektur verwenden wir?

Wo liegt der State?

Wie werden Dependencies injiziert?

Wie gehen wir mit Fehlern um?

Welche Abstraktionen wollen wir – und welche ausdrücklich nicht?

Wie strukturieren wir Compose und SwiftUI?

Und was verstehen wir überhaupt unter „gutem Code“?

Ein Coding-Agent kennt diese Entscheidungen zunächst nicht.

Deshalb gehört für mich zu einem KI-gestützten Entwicklungsworkflow ein weiterer wichtiger Schritt:

Die KI bekommt einen Engineering Contract für das Projekt.

Der entscheidende Unterschied
Die KI soll nicht einfach „guten Code“ schreiben. Sie soll Code schreiben, der zu meinem Projekt, meiner Architektur und meinen Entwicklungsentscheidungen passt.

Warum gute Prompts allein nicht reichen

Natürlich kann ich Claude bei jeder Aufgabe einen detaillierten Prompt geben.

Zum Beispiel:

„Verwende ein ViewModel, bilde den Zustand als StateFlow ab, nutze Koin für Dependency Injection, Ktor für den API-Zugriff und halte die Composables möglichst stateless.“

Das funktioniert.

Aber beim nächsten Feature müsste ich dieselben Regeln wiederholen.

Und irgendwann vergesse ich eine davon.

Noch problematischer wird es bei einem größeren Projekt mit mehreren Regeln.

Deshalb gehören solche Informationen für mich nicht in einzelne Prompts, sondern ins Repository.

Claude Code unterstützt dafür Projektanweisungen über eine CLAUDE.md.

Sie wird damit zu einer Art Einstiegspunkt für den Coding-Agenten.

CLAUDE.md als Engineering Contract

In der CLAUDE.md stehen die grundlegenden Anweisungen für Claude.

Ich halte sie allerdings bewusst relativ kompakt.

Denn wenn dort irgendwann hunderte Regeln stehen, entsteht lediglich ein neues unübersichtliches Dokument.

Stattdessen dient sie als Einstiegspunkt in ein kleines Engineering Handbook.

Zum Beispiel:

CLAUDE.md

docs/
├── philosophy.md
├── architecture.md
├── android-style.md
├── ios-style.md
└── review-guidelines.md

Die einzelnen Dateien haben klar definierte Aufgaben.

philosophy.md beschreibt grundlegende Entwicklungsprinzipien.

architecture.md definiert die technische Architektur.

android-style.md enthält Regeln für Kotlin und Jetpack Compose.

ios-style.md beschreibt Swift- und SwiftUI-Konventionen.

review-guidelines.md legt fest, worauf Claude bei Code Reviews achten soll.

Engineering Handbook
CLAUDE.md · Einstiegspunkt und zentrale Regeln
philosophy.md · Entwicklungsprinzipien
architecture.md · Architektur und Verantwortlichkeiten
android-style.md · Kotlin & Compose
ios-style.md · Swift & SwiftUI
review-guidelines.md · Qualitäts- und Review-Regeln

Was steht in diesen Regeln?

Das hängt natürlich vom jeweiligen Projekt ab.

Bei meinem Kotlin-Multiplatform-Beispiel gehören dazu unter anderem Entscheidungen wie:

  • Reactive State statt imperativer UI-Steuerung
  • ViewModels für die Android-Presentation
  • Koin für Dependency Injection
  • Ktor für API-Kommunikation
  • möglichst stateless Compose Components
  • klare Verantwortlichkeiten zwischen UI, Presentation und Domain
  • plattformspezifische UIs mit Compose und SwiftUI
  • gemeinsame Businesslogik nur dort, wo sie sinnvoll ist
  • keine unnötigen Abstraktionen
  • kein Overengineering
  • Fehlerfälle explizit berücksichtigen
  • Accessibility von Anfang an mitdenken
  • bestehende Projektkonventionen respektieren

Das sind keine universellen Wahrheiten.

Und genau das ist der Punkt.

Ein anderes Team kann sich völlig bewusst für Hilt, Compose Multiplatform, andere State-Patterns oder eine andere Modulstruktur entscheiden.

Claude muss nicht wissen, welche Architektur allgemein die beste ist. Claude muss wissen, welche Architektur dieses Projekt verwendet.

Wie bringe ich Claude meinen bestehenden Coding Style bei?

Hier gibt es aus meiner Sicht zwei grundsätzlich unterschiedliche Ausgangssituationen.

Variante 1: Es existiert bereits eine gute Codebasis

Das ist der angenehmste Fall.

Ich kann Claude bestehende, repräsentative Teile des Projekts analysieren lassen.

Wichtig ist dabei, nicht einfach blind das gesamte Repository als Vorbild zu erklären.

Fast jedes länger laufende Projekt enthält:

  • Legacy-Code
  • Übergangslösungen
  • alte Patterns
  • technische Schulden
  • Experimente
  • Ausnahmen

Deshalb würde ich Claude gezielt auf Bereiche verweisen, die tatsächlich dem gewünschten aktuellen Standard entsprechen.

Zum Beispiel:

„Analysiere diese ViewModels, Repositories und Compose-Screens. Leite daraus unsere wiederkehrenden Architektur- und Coding-Konventionen ab. Ändere noch keinen Code.“

Anschließend würde ich die erkannten Regeln gemeinsam mit Claude prüfen.

Erst danach werden sie in das Engineering Handbook übernommen.

Wichtig bei bestehenden Projekten
Nicht jeder vorhandene Code ist automatisch eine Coding Guideline. Ich zeige Claude bewusst die Bereiche, die den gewünschten heutigen Projektstandard repräsentieren.

Variante 2: Ich möchte den Standard bewusst neu definieren

Genau dieser Fall ist ebenfalls interessant.

Vielleicht gibt es noch gar kein geeignetes Referenzprojekt.

Oder die vorhandenen Projekte sind über Jahre gewachsen und enthalten verschiedene Architekturen und Coding Styles.

Dann kann es sogar kontraproduktiv sein, Claude daraus Regeln ableiten zu lassen.

In diesem Fall definiere ich lieber, wie ich heute entwickeln möchte.

Das kann zunächst relativ einfach beginnen:

„Ich möchte Reactive State, ViewModels, Koin als Dependency Injection und Ktor für API-Anbindungen. UI-Komponenten sollen möglichst stateless sein. Vermeide unnötige Abstraktionen und Overengineering.“

Claude kann daraus einen ersten strukturierten Vorschlag für das Engineering Handbook erzeugen.

Diesen lasse ich allerdings nicht einfach ungeprüft übernehmen.

Ich gehe die Regeln durch und entscheide:

Passt das wirklich zu meinem Entwicklungsstil?

Erst danach werden sie Teil des Projekts.

Das ist ein wichtiger Unterschied.

Claude definiert nicht meinen Coding Style. Claude hilft mir, meinen Coding Style explizit zu dokumentieren.

🔍
Bestehender Code

Gute Referenzimplementierungen analysieren lassen und wiederkehrende Regeln daraus ableiten.

✍️
Neuer Standard

Architektur und Entwicklungsphilosophie bewusst definieren und mit Claude in ein strukturiertes Regelwerk überführen.

Projektregeln gehören ins Repository

Das halte ich für einen besonders wichtigen Punkt.

Die Regeln sollten nicht irgendwo ausschließlich in einer Claude-Konversation existieren.

Sie gehören direkt zum Projekt.

Damit werden sie:

  • versionierbar
  • reviewbar
  • veränderbar
  • für das Team sichtbar
  • unabhängig von einer einzelnen Claude-Session

Ändert sich später eine Architekturentscheidung, wird das Engineering Handbook genauso angepasst wie anderer Projektcode.

Beispielsweise könnte sich das Team entscheiden:

Neue Features verwenden ab sofort ein anderes State-Pattern.

Dann wird diese Entscheidung dokumentiert und mit dem Code committed.

Damit weiß auch eine neue Claude-Session, welche Regel aktuell gilt.

Was passiert nach einem Neustart von Claude Code?

Das ist in der täglichen Arbeit wichtig.

Projektregeln in der CLAUDE.md müssen nicht bei jeder neuen Session wieder von Hand erklärt werden.

Claude Code berücksichtigt die Projektanweisungen beim Arbeiten im entsprechenden Projekt.

Damit kann ich nach einem Neustart direkt wieder Aufgaben formulieren wie:

„Implementiere jetzt die Pausenfunktion.“

Ich muss nicht jedes Mal ergänzen:

„Aber bitte Reactive State, Koin, Ktor und unsere ViewModel-Struktur beachten.“

Genau dafür existiert das Engineering Handbook.

Persistenter Projektkontext
Neue Claude-Session.
Gleiches Repository.
Gleiche Engineering-Regeln.

Weniger detaillierte Prompts sind ein guter Test

Sobald die Regeln stehen, wird es interessant.

Ich möchte Claude jetzt nämlich gerade nicht mehr jeden Implementierungsschritt vorschreiben.

Wenn ich sage:

„Erstelle HistoryViewModel, verwende einen StateFlow, lege ein Repository an und injiziere es über Koin …“

dann weiß ich anschließend nicht, ob Claude mein Engineering Handbook verstanden hat.

Ich habe die Architektur schließlich bereits selbst in den Prompt geschrieben.

Deshalb formuliere ich Aufgaben bewusst eher fachlich:

„Implementiere den freigegebenen History-Screen entsprechend unserem Engineering Contract.“

Dann beobachte ich, welche Entscheidungen Claude selbst trifft.

Wenn dabei etwas nicht meinem gewünschten Stil entspricht, gibt es zwei Möglichkeiten:

  1. Claude hat eine vorhandene Regel nicht beachtet.
  2. Die Regel ist im Engineering Handbook noch nicht eindeutig genug beschrieben.

Gerade der zweite Fall ist wertvoll.

Denn dadurch verbessert sich das Regelwerk mit der Zeit.

Das Engineering Handbook entwickelt sich mit dem Projekt

Ich betrachte diese Markdown-Dateien deshalb nicht als einmalige Konfiguration.

Sie entwickeln sich gemeinsam mit dem Projekt.

Wenn bei einem Review beispielsweise immer wieder dasselbe Problem auftaucht, kann daraus eine neue Regel entstehen.

Damit entsteht ein interessanter Kreislauf:

Implementierung → Review → Erkenntnis → neue Regel → bessere nächste Implementierung

Kontinuierliche Verbesserung
Implementierung → Review → Erkenntnis → Handbook verbessern → nächstes Feature

Ein wichtiger Punkt: Datenschutz und bestehende Projekte

Gerade bei Kundenprojekten kann ich natürlich nicht beliebig fremden Quellcode in externe Systeme geben, nur damit ein Coding-Agent meinen Stil analysiert.

Deshalb finde ich den zweiten Ansatz besonders relevant:

Coding Standards lassen sich auch ohne vollständigen Zugriff auf frühere Kundenprojekte definieren.

Dafür reicht zunächst die eigene Erfahrung:

Welche Patterns haben sich bewährt?

Welche Architektur möchte ich verwenden?

Welche Fehler möchte ich künftig vermeiden?

Was soll neuer Code besser machen als historisch gewachsener Legacy-Code?

Damit kann ein neues Projekt von Anfang an einen sauberen Engineering Contract bekommen, ohne dass dafür vertrauliche Altprojekte als Trainingsmaterial dienen müssen.

Die Regeln gelten auch für Code Reviews

Ein weiterer Vorteil zeigt sich beim Review.

Wenn Claude bereits weiß, welche Architektur das Projekt verwenden soll, kann derselbe Agent einen Git-Diff genau gegen diese Regeln prüfen.

Dann lautet die Frage nicht nur:

„Ist dieser Code grundsätzlich okay?“

Sondern:

„Entspricht diese Änderung unseren Projektregeln?“

Das macht Reviews deutlich interessanter.

Genau diesen Workflow habe ich separat ausprobiert und ausführlicher dokumentiert.

Nächster Schritt
Code Review mit Claude Code: KI als zweiter Reviewer
Wie ich Claude Git-Diffs analysieren lasse, Findings priorisiere und die eigenen Engineering-Regeln als Grundlage für Reviews verwende.
Zum ausführlichen Artikel →

Fazit: Nicht Claude muss meinen Code schreiben – Claude muss mein Projekt verstehen

Für mich ist das Engineering Handbook inzwischen einer der wichtigsten Bestandteile des gesamten KI-Workflows.

Denn die Qualität eines Coding-Agenten hängt nicht nur davon ab, wie gut das zugrunde liegende Modell programmieren kann.

Entscheidend ist auch, wie viel Kontext es über das konkrete Projekt besitzt.

Eine allgemeine KI kennt Kotlin.

Sie kennt Compose.

Sie kennt SwiftUI, Ktor, Koin und MVVM.

Aber sie kennt zunächst nicht meine Entscheidungen.

Genau diese Lücke schließt der Engineering Contract.

Damit verändert sich auch die Art, wie ich Claude Aufgaben gebe.

Statt bei jedem Feature wieder Architekturvorgaben in einen riesigen Prompt zu schreiben, kann ich mich stärker auf die eigentliche fachliche Aufgabe konzentrieren.

Und das ist für mich der interessante Punkt:

Je besser der Projektkontext definiert ist, desto weniger muss ich der KI bei jeder einzelnen Aufgabe erklären.

Die KI soll sich dabei nicht meinen Coding Style selbst ausdenken.

Und ich möchte meinen Entwicklungsstil auch nicht einem Sprachmodell überlassen.

Ich definiere die Regeln. Claude arbeitet innerhalb dieser Regeln.