Claude Code in Produktion: KI-gestützte Flutter-Entwicklung

Für CTOs, Tech Leads und Senior Developer, die KI-gestützte Entwicklung in bestehenden Projekten einführen wollen — ohne die Codebase zu ruinieren.

TL;DR: KI Programmierung in Produktionsprojekten funktioniert — aber nicht so, wie die meisten es sich vorstellen. Kein Prompt-und-Hoffen. Ich nutze Claude Code mit einer CLAUDE.md als Projekt-Konfiguration, Custom Skills für unterschiedliche Entwicklungs-Kontexte und Architektur-Guardrails, die verhindern, dass die KI Legacy-Code “verbessert”, wenn ich nur einen Bugfix brauche. Das Ergebnis nach zehn Monaten und 827 Commits in einer Produktions-Flutter-App: circa 30% schnellere Migration, weniger Pattern-Verstöße, null Architektur-Entscheidungen an die KI delegiert.

Vibe Coding vs. AI-Assisted Development

Im aktuellen Diskurs über KI Programmierung werden zwei fundamental verschiedene Ansätze in einen Topf geworfen.

Vibe Coding heißt: Du beschreibst, was du willst, die KI generiert Code, du schaust, ob es funktioniert. Kein Kontext über die bestehende Architektur, keine Konventionen, keine Guardrails. Das funktioniert für Prototypen, Demos, persönliche Projekte. Für Produktionscode in Teams ist es ein Rezept für Chaos.

AI-Assisted Development heißt: Die KI kennt deine Architektur, respektiert deine Konventionen und hat klare Anweisungen, wann sie welche Patterns verwenden soll. Du triffst die Entscheidungen, die KI übernimmt die mechanische Umsetzung.

Der Unterschied ist nicht akademisch. In einer Codebase mit 200+ Dateien, Legacy-Patterns und einer laufenden Clean-Architecture-Migration produziert eine KI ohne Kontext Code, der technisch funktioniert, aber architektonisch inkonsistent ist. Mal StateNotifier, mal AsyncNotifier. Mal Feature-First, mal Layer-First. Mal direkte Repository-Aufrufe, mal Use Cases.

Das Aufräumen dieses inkonsistenten Codes kostet mehr Zeit als manuelles Schreiben.

Die Ausgangslage

Zehn Monate, eine E-Commerce-App für einen Schweizer Online-Händler, 827 Commits. Das Projekt hatte eine gewachsene Codebase mit Legacy-Patterns, eine laufende Migration zu Clean Architecture und ein Team mit klaren Konventionen. Die Migrationsstrategie selbst habe ich separat beschrieben — dieser Beitrag handelt vom AI-Tooling, das sie beschleunigt hat.

Irgendwann stand die Frage im Raum, die sich 2026 jedes Entwicklungsteam stellt: Bringt ein AI Coding Assistant hier etwas? Oder produziert er nur inkonsistenten Code, den jemand hinterher aufräumen muss?

Die ehrliche Antwort: Beides ist möglich. Der Unterschied liegt nicht im Tool, sondern in der Infrastruktur drum herum.

Das Kontext-Problem

Stell dir vor, ein neuer Entwickler startet an Tag eins in deinem Projekt. Ohne Onboarding, ohne Architektur-Dokumente, ohne Code-Reviews. Er ist technisch kompetent, arbeitet schnell und liefert funktionierenden Code. Aber jede Datei sieht anders aus.

Genau so verhält sich ein AI Coding Assistant ohne Projekt-Kontext.

Die Lösung klingt banal: Gib der KI die gleichen Informationen, die du einem neuen Teammitglied geben würdest. Architektur-Entscheidungen. Naming Conventions. Import-Regeln. Migrationsstatus.

In Claude Code heißt dieses Dokument CLAUDE.md.

CLAUDE.md als Single Source of Truth

Die CLAUDE.md ist eine Markdown-Datei im Projekt-Root, die Claude Code bei jedem Start automatisch liest. Sie ist die Projekt-Konfiguration für die KI — vergleichbar mit .editorconfig für Formatierung oder analysis_options.yaml für Linting.

Für das Projekt sieht ein Auszug so aus:

## Architecture

This project uses Clean Architecture with feature-first organization.

### Decision Matrix

- Touching existing unmigrated code? → Follow legacy patterns
- Writing a new feature? → Use Clean Architecture
- Migrating an existing feature? → Follow migration checklist

### Import Rules

- Domain layer: NO imports from data or presentation
- Presentation layer: imports domain only
- Data layer: implements domain interfaces

### State Management

- New code: Riverpod with code generation, AsyncNotifier
- Legacy code: DO NOT migrate StateNotifier to AsyncNotifier unless
  explicitly part of a migration task
- Providers: always use @riverpod annotation, never hand-written

### Naming Conventions

- Features: snake_case directories under lib/features/
- Tests: mirror source structure under test/
- Barrel files: one per feature, export public API only

Das ist kein Roman. Es sind die Regeln, die auch in einem Code Review gelten — nur explizit aufgeschrieben, damit die KI sie kennt.

Der entscheidende Teil ist die Decision Matrix. Sie beantwortet die Frage, die in gemischten Codebases am häufigsten falsch beantwortet wird: Soll ich hier das neue oder das alte Pattern verwenden?

Ohne Decision Matrix passiert Folgendes: Du bittest die KI, einen Bug in einer Legacy-Datei zu fixen. Die KI sieht StateNotifier, entscheidet eigenständig, dass AsyncNotifier “besser” ist, refactored die halbe Datei und liefert dir einen PR mit 400 geänderten Zeilen für einen Einzeiler-Fix.

Mit Decision Matrix: Die KI liest “Touching existing unmigrated code? Follow legacy patterns”, fixt den Bug im bestehenden Pattern und lässt den Rest in Ruhe.

Custom Skills: Kontext-abhängiges Verhalten

Eine CLAUDE.md allein reicht für die Grundregeln. Aber unterschiedliche Aufgaben brauchen unterschiedliches Verhalten.

Claude Code unterstützt Custom Skills — vordefinierte Anweisungssets, die per Slash-Command aktiviert werden. Für das Projekt habe ich fünf definiert:

/migration

Der häufigste Anwendungsfall. Eine bestehende Feature-Datei von Legacy-Patterns zu Clean Architecture migrieren.

## /migration

When migrating a feature:

1. Create domain layer first (entities, repository interfaces, use cases)
2. Create data layer (implementations, data sources, DTOs)
3. Create presentation layer (providers, pages, widgets)
4. Write tests for each layer
5. Remove legacy code only after tests pass
6. Update barrel files
7. Verify no remaining imports from legacy paths

Ohne diesen Skill würde die KI bei jeder Migration die Reihenfolge selbst entscheiden. Mal Domain zuerst, mal Presentation zuerst. Mal Tests am Ende, mal gar keine. Der Skill macht den Prozess deterministisch.

/legacy-code

Für Bugfixes und kleine Änderungen in noch nicht migrierten Bereichen.

Die Anweisung ist kurz: Respektiere die bestehenden Patterns. Kein Refactoring. Kein “Verbesserung”. Fix den Bug, schreib einen Test, fertig.

/ui-component

Für neue UI-Elemente. Kennt das Design System, weiß welche bestehenden Widgets zur Verfügung stehen, folgt der Kompositions-Hierarchie.

/riverpod

Für State-Management-Code. Erzwingt Code Generation, @riverpod-Annotations, AsyncNotifier statt StateNotifier, korrekte Provider-Scoping.

/test-workflow

Für Testcode. Kennt die Test-Konventionen: Wo Unit Tests, wo Widget Tests, wo Integration Tests. Welche Mocking-Strategie. Wie Test-Fixtures aufgebaut sind.

Jeder Skill ist eine Markdown-Datei im .claude/-Verzeichnis. Kein komplexes Setup, kein Plugin-System. Klartext-Anweisungen, die Claude Code als Kontext erhält. (Mehr dazu, wie KI-Agenten und Tools wie diese funktionieren, in KI-Agenten, MCP und Tools erklärt.)

Was passiert ohne Guardrails?

Ein konkretes Beispiel. Aufgabe: Einen neuen API-Endpunkt in ein bestehendes Feature integrieren.

Ohne Guardrails generiert Claude Code etwas wie:

// Kein Use Case, Repository direkt im Widget aufgerufen
class ProductPage extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final products = ref.watch(
      FutureProvider((ref) async {
        final dio = Dio();
        final response = await dio.get('/api/products');
        return (response.data as List)
            .map((e) => Product.fromJson(e))
            .toList();
      }),
    );
    // ...
  }
}

Technisch funktioniert das. Architektonisch ist es eine Katastrophe: Direkter HTTP-Call im Widget, kein Repository, kein Use Case, kein DTO, hand-geschriebener Provider statt Code Generation. Jede Schicht-Grenze verletzt.

Mit CLAUDE.md und dem /riverpod-Skill:

// Domain Layer
abstract class ProductRepository {
  Future<List<Product>> getProducts();
}

// Data Layer
class ProductRepositoryImpl implements ProductRepository {
  final ProductRemoteDataSource _dataSource;

  ProductRepositoryImpl(this._dataSource);

  @override
  Future<List<Product>> getProducts() async {
    final dtos = await _dataSource.fetchProducts();
    return dtos.map((dto) => dto.toDomain()).toList();
  }
}

// Presentation Layer
@riverpod
class ProductList extends _$ProductList {
  @override
  Future<List<Product>> build() async {
    final repository = ref.watch(productRepositoryProvider);
    return repository.getProducts();
  }
}

Gleiche Aufgabe, konsistente Architektur. Nicht weil die KI “schlauer” ist, sondern weil sie weiß, welche Patterns erwartet werden.

Was KI gut kann — und was nicht

Nach zehn Monaten mit Claude Code in diesem Projekt habe ich ein ziemlich klares Bild.

Wo KI Programmierung echten Mehrwert liefert

Boilerplate-Code bei Migrationen. Clean Architecture bedeutet viele Dateien pro Feature: Entity, Repository Interface, Use Case, DTO, Data Source, Provider. Die Struktur ist immer gleich, nur der Inhalt variiert. Das ist ideales KI-Territorium.

Testcode-Scaffolding. Tests folgen Patterns. Arrange-Act-Assert, Mocking-Setup, Edge Cases. Claude Code generiert den Testrahmen, ich ergänze die fachlich relevanten Assertions.

Konsistente Patterns über viele Dateien. Wenn du 15 Features migrieren musst und jedes die gleiche Struktur braucht, hält die KI das Pattern konsistenter als ein Mensch nach Feature Nummer zwölf.

Code Reviews als zweite Meinung. Ich nutze Claude Code regelmäßig, um eigenen Code reviewen zu lassen. Nicht als Ersatz für Team-Reviews, aber als Vorab-Check: Import-Verletzungen, vergessene Error Handling, inkonsistente Naming.

Wo KI versagt

Architektur-Entscheidungen. “Sollen wir hier ein Repository oder einen Service nehmen?” Das kann eine KI nicht sinnvoll beantworten, weil die Antwort von Projekt-Historie, Team-Präferenzen und Zukunftsplänen abhängt.

Business-Kontext. Die KI weiß nicht, warum der Checkout-Flow in einer bestimmten Reihenfolge abläuft. Sie sieht den Code, nicht die Shopify-Limitierungen, die ihn geformt haben.

Subtile Bugs. Race Conditions, Timing-Probleme bei WebView-Bridges, plattformspezifische Quirks. Diese Bugs entstehen aus dem Zusammenspiel von Systemen, die die KI nicht im Ganzen sieht.

Refactoring-Entscheidungen in gewachsenem Code. “Soll ich das jetzt aufräumen oder in Ruhe lassen?” Dafür brauchst du Erfahrung mit der Codebase, Wissen über offene PRs und ein Gefühl für Prioritäten.

Die Grenze lässt sich einfach ziehen: Wenn die Aufgabe ein klares Pattern hat und der Kontext explizit beschreibbar ist, hilft die KI. Wenn Urteilsvermögen gefragt ist, triffst du die Entscheidung.

Messbarer Impact

Harte Metriken für KI-Produktivität sind schwierig. Ich kann nicht sagen “diese Zeile hat Claude geschrieben, diese ich”, weil der Workflow iterativ ist: KI generiert, ich reviewe, korrigiere, generiere neu.

Was ich sagen kann:

Die Clean-Architecture-Migration lief nach meiner Schätzung etwa 30% schneller als ohne KI-Unterstützung. Nicht weil Claude perfekten Code lieferte, sondern weil die mechanischen Teile — Datei-Struktur anlegen, Boilerplate generieren, Tests scaffolden — signifikant schneller gingen. Meine Zeit ging in Architektur-Entscheidungen und Code Review.

Pattern-Verstöße in PRs nahmen ab. Die CLAUDE.md erzwingt Konventionen bei der Generierung, nicht erst im Review. Das ist effizienter als Probleme nachträglich zu finden.

Onboarding neuer Aufgaben wurde schneller. Wenn ich nach zwei Wochen ein Feature wieder anfasse, lese ich die CLAUDE.md und bin sofort im Kontext — die KI und ich arbeiten mit den gleichen Annahmen. Einen ähnlichen Ansatz habe ich auch bei einer Serverless-zu-Monolith-Migration mit vergleichbaren Ergebnissen eingesetzt.

Wenn du eine ähnliche Migration planst oder AI-Tooling in dein Team einführen willst — ich habe das in Produktion gemacht.

Praktischer Setup-Guide

Wenn du AI-Assisted Development in deinem Projekt einführen willst — ob Flutter, Web-App oder Backend, hier die konkreten Schritte. Einen breiteren Überblick über KI in der App-Entwicklung gibt es in App entwickeln mit KI.

Schritt 1: CLAUDE.md erstellen

Starte minimal. Schreib die drei Dinge auf, die ein neuer Entwickler wissen muss: Architektur-Pattern, State-Management-Regeln, Dateistruktur. Erweitere die Datei über Zeit, wenn du merkst, dass die KI wiederholt falsche Annahmen trifft.

Schritt 2: Decision Matrix definieren

Wenn dein Projekt gemischte Patterns hat (und welches Projekt hat das nicht), schreib explizit auf, wann welches Pattern gilt. Das ist der höchste ROI-Punkt: Eine klare Decision Matrix verhindert mehr Probleme als alles andere.

Schritt 3: Custom Skills für wiederkehrende Aufgaben

Identifiziere Aufgaben, die du regelmäßig machst und die einem klaren Ablauf folgen. Migration, Feature-Erstellung, Test-Erstellung. Schreib für jede einen Skill mit Schritt-für-Schritt-Anleitung.

Schritt 4: Iterativ verbessern

Die CLAUDE.md ist ein lebendes Dokument. Wenn die KI etwas falsch macht, frag dich: “Hätte ein neuer Entwickler das gewusst?” Wenn nein, ergänze die Regel.

Schritt 5: Team-Konventionen explizit machen

Der unerwartete Nebeneffekt: Eine CLAUDE.md zwingt dich, implizite Konventionen zu dokumentieren. Das hilft nicht nur der KI, sondern auch dem Team. Und wenn ein Freelancer das Projekt verlässt, bleibt die CLAUDE.md als präzise Architekturbeschreibung im Repo. Kein Wissen geht verloren.

Agentic Coding: Wo die Reise hingeht

Der aktuelle Stand — KI als aufmerksamer Assistent mit klaren Guardrails — ist ein Zwischenschritt. Die nächste Stufe ist Agentic Coding: Die KI führt mehrstufige Aufgaben selbstständig aus, committet Code, erstellt PRs.

Für mich ist das 2026 schon teilweise Realität. Claude Code kann eine Migration autonom durchführen — Dateien anlegen, Code generieren, Tests schreiben, Tests laufen lassen, Fehler korrigieren. Ich reviewe das Ergebnis statt jeden Zwischenschritt.

Aber auch hier gilt: Autonomie ohne Guardrails ist gefährlich. Je mehr Autonomie die KI bekommt, desto wichtiger werden die Architektur-Regeln in der CLAUDE.md. Ohne sie wäre autonomes Arbeiten Vibe Coding mit Extra-Schritten.

Fazit

KI-gestützte Entwicklung in Produktionsprojekten funktioniert. Aber nicht als Plug-and-Play-Lösung.

Das Setup aus CLAUDE.md, Custom Skills und Architektur-Guardrails ist keine einmalige Konfiguration, sondern eine laufende Investition. Genau wie Linting-Regeln, CI-Pipelines oder Code-Review-Prozesse.

Nach zehn Monaten und 827 Commits in einer echten Produktions-Codebase ist mein Fazit nüchtern: Claude Code hat mir bei mechanischen Aufgaben erheblich Zeit gespart. Bei Architektur-Entscheidungen war ich auf mich selbst angewiesen. Und genau so sollte es sein.

Die KI ist kein Ersatz für Engineering-Urteilsvermögen. Sie ist ein Werkzeug, das mechanische Arbeit beschleunigt — wenn du ihr sagst, wie. Wenn dieses Setup zum Standard wird statt zum Experiment, ist KI kein Assistent mehr — sie ist nativer Bestandteil deines Entwicklungsworkflows.

Ich unterstütze Teams bei der Einführung von AI-gestützten Entwicklungsworkflows in bestehende Codebases. Lass uns sprechen.

Häufige Fragen

Was ist der Unterschied zwischen Vibe Coding und AI-Assisted Development?

Vibe Coding heißt: KI generiert Code ohne Projekt-Kontext, du schaust ob es funktioniert. AI-Assisted Development heißt: Die KI kennt deine Architektur, Konventionen und Regeln durch explizite Konfiguration (wie eine CLAUDE.md). Der Unterschied ist vergleichbar mit einem Freelancer ohne Briefing versus einem Freelancer mit ausführlichem Onboarding.

Brauche ich eine CLAUDE.md für jedes Projekt?

Für kleine, saubere Projekte ohne Legacy-Code reicht die KI oft ohne spezielle Konfiguration. Sobald dein Projekt gemischte Patterns, Team-Konventionen oder eine laufende Migration hat, lohnt sich eine CLAUDE.md. Als Faustregel: Wenn du einem neuen Entwickler mehr als fünf Minuten erklären müsstest, wie bestimmte Dinge gemacht werden, schreib es in die CLAUDE.md.

Funktioniert AI-Assisted Development nur mit Claude Code?

Das Prinzip — expliziter Projekt-Kontext statt Prompt-und-Hoffen — gilt für jeden AI Coding Assistant. Die konkreten Mechanismen (CLAUDE.md, Custom Skills) sind Claude-Code-spezifisch, aber die Idee einer Architektur-Konfiguration für KI lässt sich übertragen.

Wie viel Zeit kostet das Setup?

Die initiale CLAUDE.md: ein bis zwei Stunden. Custom Skills: 30 Minuten pro Skill. Laufende Pflege: wenige Minuten pro Woche, wenn dir auffällt, dass die KI etwas falsch macht. Der ROI ist ab dem zweiten Tag positiv, wenn du regelmäßig mit der KI arbeitest.

Kann die KI Architektur-Entscheidungen treffen?

Nein. Und das sollte sie auch nicht. Architektur-Entscheidungen hängen von Projekt-Historie, Business-Kontext, Team-Dynamik und Zukunftsplänen ab — Informationen, die eine KI nicht hat. Die KI kann Entscheidungen umsetzen, die du getroffen hast. Das ist der Kern von AI-Assisted Development: Du entscheidest, die KI implementiert.