Claude Code anlernen: So bringst du der KI deinen Coding Style bei

KI kann heute erstaunlich guten Code erzeugen. Das eigentliche Problem ist aber ein anderes:

Sie schreibt nicht automatisch so, wie ich selbst entwickeln würde.

Gerade bei professioneller App-Entwicklung reicht es nicht, dass Code nur funktioniert. Er soll zur bestehenden Architektur passen, dieselben Patterns verwenden, vorhandene Komponenten wiederverwenden und sich an Coding Standards halten.

Genau deshalb habe ich mir für meinen KI-gestützten App-Workflow eine Frage gestellt:

Wie bringe ich Claude Code dazu, nicht irgendeinen guten Code zu schreiben, sondern Code, der möglichst meinem eigenen Entwicklungsstil entspricht?

Die kurze Antwort lautet:

Nicht mit einem einzelnen Prompt.

Stattdessen braucht die KI ein dauerhaftes, projektbezogenes Regelwerk.

Der wichtigste Gedanke
Die KI soll sich an mein Projekt anpassen – nicht mein Projekt an die KI.

Warum „Schreib Clean Code“ nicht reicht

Man könnte natürlich bei jeder Aufgabe schreiben:

Verwende MVVM. Nutze StateFlow. Halte dich an Clean Architecture. Schreibe guten Compose-Code.

Das funktioniert oberflächlich.

Aber diese Begriffe sind viel zu unscharf.

Was bedeutet beispielsweise „Clean Architecture“ konkret?

  • Gibt es immer Use Cases?
  • Braucht jedes Repository ein Interface?
  • Werden ViewModels zwischen Android und iOS geteilt?
  • Wie sieht State Handling aus?
  • Wie werden Side Effects modelliert?
  • Welche DI-Lösung wird verwendet?
  • Welche Libraries sind erlaubt?
  • Welche Abstraktionen sind unerwünscht?

Zwei erfahrene Entwickler können dieselben Begriffe verwenden und trotzdem völlig unterschiedlichen Code schreiben.

Eine KI hat genau dasselbe Problem.

Deshalb reicht es nicht, nur Technologien zu nennen.

Man muss die Entwicklungsphilosophie dahinter beschreiben.

Zwei Wege, Claude Code anzulernen

Grundsätzlich gibt es zwei sinnvolle Ansätze.

Möglichkeit 1: Bestehenden Code analysieren lassen

Der ideale Fall ist ein bestehendes Projekt, das bereits ziemlich genau dem eigenen Stil entspricht.

Dann kann Claude das Repository analysieren und daraus Muster ableiten.

Zum Beispiel:

  • Package-Struktur
  • Naming
  • ViewModel-Aufbau
  • State Handling
  • Coroutine-Nutzung
  • Dependency Injection
  • Repository-Struktur
  • Compose-Komponenten
  • SwiftUI Views
  • Tests
  • Accessibility
  • Fehlerbehandlung

Ein möglicher Prompt wäre:

Analysiere den vorhandenen Code und leite daraus meinen Coding Style ab.

Untersuche insbesondere:

- Architektur
- Naming
- State Management
- ViewModels
- Dependency Injection
- Networking
- UI-Struktur
- Testing
- Accessibility
- Fehlerbehandlung

Erstelle anschließend einen Vorschlag für verbindliche Projektregeln.

Wichtig:
Bestehende Projektkonventionen haben Vorrang vor allgemeinen Best Practices.

Das ist wahrscheinlich die beste Methode, wenn man ein gutes Referenzprojekt besitzt.

Was tun, wenn kein sauberes Referenzprojekt existiert?

Genau das war bei mir das Problem.

Viele meiner älteren Projekte sind über Jahre gewachsen, verwenden unterschiedliche Architekturen oder spiegeln schlicht nicht mehr wider, wie ich heute entwickeln möchte.

Ein aktuelles Kundenprojekt wollte ich wiederum aus Datenschutz- und Vertraulichkeitsgründen nicht einfach vollständig einem KI-Agenten zur Analyse geben.

Also habe ich den zweiten Weg gewählt:

Ich habe meinen gewünschten Entwicklungsstil explizit definiert.

Das ist etwas mehr Arbeit – hat aber einen großen Vorteil:

Man beschreibt nicht, wie man früher entwickelt hat, sondern wie man künftig entwickeln möchte.

🔍

Bestehenden Code analysieren

Sinnvoll, wenn bereits ein sauberes Referenzprojekt existiert, das den heutigen Coding Style repräsentiert.

📐

Regeln bewusst definieren

Sinnvoll, wenn alte Projekte inkonsistent sind oder aktueller Code aus Datenschutzgründen nicht verwendet werden kann.

Mein Engineering Handbook

Statt alle Regeln in einen einzigen riesigen Prompt zu packen, habe ich sie als Markdown-Dateien direkt im Repository abgelegt.

Die Struktur sieht bei mir aktuell ungefähr so aus:

CLAUDE.md

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

Die Idee dahinter:

Das Repository selbst enthält die Regeln, nach denen die KI arbeiten soll.

Dadurch muss ich Claude nicht bei jeder neuen Aufgabe erneut erklären, wie ich entwickeln möchte.

Die zentrale Datei: CLAUDE.md

Die CLAUDE.md ist der Einstiegspunkt.

Darin stehen nicht alle Details, sondern vor allem:

  • Sprache
  • Rolle von Claude
  • Arbeitsweise
  • Verweise auf weitere Regeln

Zum Beispiel:

# Sprache

Kommuniziere grundsätzlich auf Deutsch.

Code, Klassen, Methoden und Variablennamen bleiben Englisch.

## Rolle

Verhalte dich wie ein erfahrener Senior Mobile Engineer.

Hinterfrage Anforderungen kritisch.
Triff keine Architekturentscheidungen stillschweigend.

## Engineering Contract

Diese Datei ist der Einstiegspunkt für alle Projektregeln.

Vor jeder Implementierung liest du die relevanten Dokumente aus dem docs-Ordner.

Diese Regeln haben Vorrang vor allgemeinen Best Practices.

## Arbeitsweise

Vor größeren Änderungen:

1. Projekt analysieren
2. ähnliche Implementierungen suchen
3. kurzen Implementierungsplan erstellen
4. betroffene Dateien nennen
5. offene Fragen klären
6. implementieren
7. Self-Review durchführen

Der wichtige Punkt dabei ist:

Claude soll nicht sofort losprogrammieren.

Er soll sich zunächst verhalten wie ein Entwickler, der ein bestehendes Projekt übernimmt.

Entwicklungsphilosophie statt nur Regeln

Eine der wertvollsten Dateien ist aus meiner Sicht philosophy.md.

Darin stehen keine Framework-Details.

Sondern Dinge wie:

Lieber einfacher als clever.

Lesbarkeit ist wichtiger als maximale Abstraktion.

Ich bevorzuge:

- kleine verständliche Klassen
- nachvollziehbare Architektur
- expliziten Code
- wenige Dependencies
- native Plattformkonzepte

Ich vermeide:

- Overengineering
- Interface-first-Entwicklung
- generische Frameworks innerhalb der App
- unnötige Abstraktionen

Warum ist das wichtig?

Weil ein Coding-Agent sonst gerne theoretisch elegante Lösungen produziert, die technisch korrekt sind, aber unnötig kompliziert werden.

Mit einer solchen Philosophie bekommt Claude einen Entscheidungsrahmen.

Nicht nur:

Nutze StateFlow.

Sondern:

Nutze StateFlow, aber baue daraus nicht automatisch ein komplettes MVI-Framework.

Architektur explizit festlegen

Im Architektur-Dokument habe ich meine grundlegenden Entscheidungen definiert.

Für mein aktuelles KMP-Projekt zum Beispiel:

Shared KMP:
- Repository
- API
- Ktor
- Domain Models
- Mapper
- Validierung

Android:
- eigenes ViewModel
- Jetpack Compose

iOS:
- eigener Presentation Layer
- SwiftUI

Das ist wichtig, weil KMP viele verschiedene Architekturen erlaubt.

Ohne klare Vorgabe könnte Claude beispielsweise auf die Idee kommen, ViewModels ebenfalls zwischen Android und iOS zu teilen.

Technisch möglich.

Aber nicht zwingend das, was ich möchte.

Beispielarchitektur
KMP Business Logic → Android ViewModel + Compose + iOS Presentation + SwiftUI

Technologien allein reichen nicht

Natürlich habe ich auch konkrete Technologieentscheidungen hinterlegt.

Zum Beispiel:

  • Koin für Dependency Injection
  • Ktor für Networking
  • StateFlow für reaktiven Android-State
  • Jetpack Compose für Android
  • SwiftUI für iOS
  • KMP für gemeinsame Businesslogik

Wichtig ist aber, auch hier die Grenzen zu definieren.

Beispiel:

Reactive State bedeutet NICHT automatisch MVI.

Keine Reducer, Middleware oder generischen State-Machines,
solange sie keinen echten Mehrwert liefern.

Oder bei Use Cases:

Use Cases sind optional.

Keine One-Line-UseCases nur, um ein Architekturpattern zu erfüllen.

Gerade solche Regeln helfen enorm dabei, Overengineering zu verhindern.

Claude soll Regeln kritisch hinterfragen

Nachdem ich die Dateien erstellt hatte, habe ich Claude nicht einfach gesagt:

„Lies das und halte dich daran.“

Stattdessen sollte er die Regeln kritisch analysieren.

Unter anderem mit folgenden Fragen:

  • Gibt es Widersprüche?
  • Sind Entscheidungen unklar?
  • Welche Regeln könnten später problematisch werden?
  • Welche Architekturfragen fehlen?
  • Wo gibt es Interpretationsspielraum?

Das Ergebnis war überraschend hilfreich.

Claude stellte zum Beispiel direkt die Frage, ob ViewModels zwischen Android und iOS geteilt werden sollen oder nicht.

Genau solche Punkte möchte ich vor der eigentlichen Feature-Implementierung klären.

Regeln müssen leben

Das Engineering Handbook ist für mich kein einmal fertig geschriebenes Dokument.

Es soll mit dem Projekt wachsen.

Wenn ich bei einer Implementierung merke:

„So würde ich das selbst niemals schreiben.“

dann ist das möglicherweise keine einmalige Korrektur.

Es könnte eine fehlende Projektregel sein.

Deshalb habe ich Claude angewiesen:

Wenn ich dich bei einer Architektur- oder Coding-Entscheidung korrigiere,
prüfe, ob daraus eine allgemeine Projektregel entstehen sollte.

Ändere das Engineering Handbook nicht automatisch.

Schlage die neue Regel zuerst vor.

Das gefällt mir an diesem Ansatz besonders.

Der eigentliche Lernprozess
Mein Coding Style → Engineering Handbook → Claude implementiert → ich korrigiere → Regeln werden präziser

Warum ich das besser finde als endlose Prompts

Viele KI-Workflows basieren auf immer neuen Prompt-Vorlagen.

Zum Beispiel:

„Du bist Senior Android Developer. Schreibe Clean Code und achte auf SOLID.“

Das kann funktionieren.

Aber bei jeder Session beginnt man praktisch wieder von vorne.

Ein Engineering Handbook hat dagegen einen entscheidenden Vorteil:

Das Projekt besitzt seine eigenen Regeln.

Dadurch werden die Prompts kürzer.

Aus:

Implementiere diese Funktion mit StateFlow, Koin, Repository Pattern, stateless Compose Components, ohne Overengineering…

wird irgendwann einfach:

Implementiere das Check-in-Feature nach unserem Engineering Contract.

Das ist wesentlich näher an echter Zusammenarbeit.

Funktioniert das wirklich?

Mein erster Eindruck: erstaunlich gut.

Natürlich hält sich Claude nicht plötzlich zu 100 Prozent an jede persönliche Präferenz.

Aber der Unterschied ist deutlich sichtbar.

Besonders hilfreich finde ich aktuell:

  • Claude plant größere Änderungen zuerst
  • Architekturfragen werden häufiger erkannt
  • neue Dependencies werden nicht einfach eingeführt
  • bestehende Regeln werden beim Review berücksichtigt
  • Overengineering lässt sich explizit begrenzen
  • Claude kann seine eigenen Änderungen gegen dieselben Regeln reviewen

Der nächste interessante Schritt ist deshalb nicht mehr nur Codegenerierung.

Sondern:

Kann Claude Code auch als zweiter Reviewer innerhalb dieses Regelwerks funktionieren?

Genau das teste ich aktuell ebenfalls.

Mein Fazit

Wer Claude Code professionell einsetzen möchte, sollte meiner Meinung nach nicht versuchen, den perfekten Prompt zu finden.

Viel wichtiger ist ein dauerhaftes, versioniertes Regelwerk im Repository.

Ob diese Regeln aus bestehendem Code abgeleitet oder bewusst neu definiert werden, hängt vom Projekt ab.

Der entscheidende Gedanke bleibt derselbe:

Die KI sollte nicht entscheiden, wie mein Projekt entwickelt wird. Sie sollte lernen, wie ich mein Projekt entwickeln möchte.

Und genau darin liegt für mich aktuell einer der spannendsten Unterschiede zwischen einfachem AI Coding und echter KI-gestützter Softwareentwicklung.

Mein Learning
Nicht der beste Prompt macht den Unterschied. Entscheidend ist, ob die KI die Regeln, Architektur und Philosophie des Projekts kennt.