Claude Code is an interactive coding agent you start by running claude in your Flutter project directory. It reads your Dart files, runs Flutter and pub commands, edits code, and iterates with you on widgets, state management, tests, and platform channels. The practical value comes from keeping a tight loop: describe a small task, let the agent change code, run analysis and tests, review the diff, repeat.
Why Claude Code fits a Flutter codebase
Flutter projects have a predictable structure: lib/, test/, pubspec.yaml, a widget tree, lints, and generated files. Claude Code can inspect that structure directly and use the same command line tools you already run: flutter pub get, flutter analyze, flutter test, dart format. That means it can create a feature folder with presentation, application, domain, and data layers instead of piling code into one file. It excels at repeating widget patterns, adding Riverpod providers or Bloc events, writing testWidgets tests, and generating platform channel boilerplate. The agent also reads existing code before editing, so if you follow a consistent architecture it tends to follow that same architecture. For a deeper look at what the agent can do, see Claude Code.
A Flutter-specific CLAUDE.md that keeps the agent on rails
Start by adding a CLAUDE.md at the root of the Flutter project. Claude Code reads this file at the start of a session. A good CLAUDE.md for Flutter is short and specific: the commands the agent should run, folder conventions, state management preference, and rules that prevent common mistakes. Avoid pasting architecture essays; the agent can read the codebase. The example below works for a Riverpod-based app.
# CLAUDE.md
## Commands
- Install dependencies: flutter pub get
- Analyze: flutter analyze
- Run all tests: flutter test
- Run one test: flutter test test/features/cart/cart_test.dart
- Format: dart format lib test
- Generate code: flutter pub run build_runner build --delete-conflicting-outputs
## Project conventions
- Feature folders: lib/features/<feature>/{presentation,application,domain,data}
- State management: Riverpod; providers live in lib/features/<feature>/providers.dart
- Widgets should be const when possible
- Use current stable Flutter APIs
## Rules for the agent
- Run flutter analyze after each file change; fix all warnings and errors before asking for review.
- Never edit generated files (*.g.dart, *.freezed.dart, *.mocks.dart); regenerate them with build_runner.
- Keep MethodChannel names as constants in lib/core/channels.dart.
- Prefer widget tests with testWidgets for UI behavior.
- Do not add new dependencies to pubspec.yaml without asking first.Tune this file to your project. If you use Bloc, replace the Riverpod line with Bloc conventions. If you use very_good_cli, mirror its layer names. The goal is to give the agent the same guardrails a new team member would get. More on writing good instructions: Claude Code best practices.
A tight working loop for Flutter tasks
Treat Claude Code like a pair programmer, not a one-shot code generator. Plan a small change, let the agent implement only that change, run the verification commands, and review the diff before moving on. Use plan mode for larger refactors so it explains the steps first.
- Add a Riverpod
CartNotifierand a cart badge in the app bar. UpdateCartNotifierwhen the user taps add, and write a widget test that verifies the badge count changes. - Refactor the
LoginScreenstate fromsetStateto Bloc. Keep the public API the same. Runflutter analyzeandflutter test test/features/auth/login_bloc_test.dartafter every change. - Create a
BatteryServicewith a MethodChannel to read battery level on Android and iOS. Use a single channel constant and handlePlatformExceptionwith a fallback value. Add unit tests with a mocked MethodChannel. - Find all
Navigator.pushcalls inlib/features/checkoutand replace them with a typed router. Do not change the screens’ constructor signatures without asking. - Add golden tests for the
OnboardingScreenfor light and dark themes. Generate goldens and runflutter test --update-goldensonly after I review the first run.
Keep the loop short. After each prompt, review git diff, then ask for the next step. If the agent churns, stop it, reduce the scope, and point to the exact file or widget.
Where Claude Code shines in Dart and where to check its work
Claude Code handles many Flutter chores reliably, but a few areas need a second look. The table shows tasks and good prompts.
| Task | Good prompt |
|---|---|
| Add a feature screen | Create a profile screen under lib/features/profile with a Riverpod provider that loads user data. Add a widget test for loading and success states. |
| Migrate state management | Replace Provider with Riverpod in this widget tree. Keep the existing widget API and update all tests. |
| Add platform channel | Add a MethodChannel for clipboard copy. Keep the channel name in lib/core/channels.dart and write a unit test with a mocked channel. |
| Fix analyzer warnings | Run flutter analyze, then fix every warning in lib/features/cart without changing public method signatures. |
Watch the agent closely in four Flutter-specific spots. First, generated files: the agent may edit .g.dart or .freezed.dart instead of regenerating them, which creates drift. Second, widget lifecycle: it can move state into a StatefulWidget but forget dispose, causing leaks. Third, platform code: Dart changes often require matching Kotlin/Swift updates, and the agent may only implement one side. Fourth, package changes: adding a dependency is easy but can break flutter analyze or require Android/iOS Gradle changes. If you see a prompt that would pull in a new package, ask for a no-dependency approach first.
Verifying Flutter changes with the agent
Use the agent as your CI runner locally. After any code change, have it execute the full Flutter verification stack: flutter analyze, flutter test, and dart format --output=none --set-exit-if-changed .. For a single area, direct it to a specific test file to reduce noise: flutter test test/features/cart/cart_test.dart. The agent can read stack traces and assertion failures and often fix the Dart side. For platform channels, unit tests should mock the channel with TestDefaultBinaryMessengerBinding.instance.defaultBinaryMessenger.setMockMethodCallHandler; tell the agent to keep the mock in the test file and not change production code. Golden tests are useful for UI regression, but generated images can cause churn across platforms; limit them to stable screens and use --update-goldens only after you inspect the diff. If a test is flaky under flutter test, run it with --concurrency=1 before asking the agent to rewrite it.
Running parallel agents on one Flutter codebase with AgentVera
On a Flutter project with separate workstreams, AgentVera runs command line agents in parallel, each in its own git worktree so widget, state, and platform-channel changes don’t collide. When an agent finishes, a second model reviews the Dart, Kotlin, and Swift changes and links findings to file:line. Checkpoints let you undo a bad refactor in one click. Token budgets keep a long build_runner or test loop from exhausting the account. See how to run multiple Claude Code agents.
Keeping the workflow predictable
Claude Code becomes a reliable Flutter assistant when you give it a focused CLAUDE.md, work in small verified steps, and review every diff. Let it run flutter analyze and flutter test often, and never let it touch generated files. Start with one feature, keep the loop tight, and expand only after the team trusts the workflow.