Skip to content

AI as Thought Partner

Estimated time to read: 104 minutes

Choose Your Path

  • Path A: Learning Flutter (Recommended for Semester 3)

    For you if:

    • This is your first mobile development project
    • You're still building programming foundations
    • You want to deeply understand Flutter

    Your approach:

    • Write all code yourself
    • Use AI only for: explaining docs, understanding errors, reviewing IDE suggestions
    • Every line you commit must be explainable by you

  • Path B: AI-Assisted Development (Senior Developer)

    For you if:

    • You have more than solid programming experience
    • You're comfortable with OOP, design patterns, you have experience with complex architectures
    • You want to work at a high abstraction level

    Your responsibilities:

    • Mandatory: Implement proper architecture (MVVM, Repository, Command Pattern)
    • Mandatory: Document AI usage transparently
    • Every line you commit must be explainable by you

Academic Integrity

Path A students using AI for code generation = Plagiarism

  • 5.0 grade + entry in student record
  • The responsibility for proving non‑plagiarism does not lie with me; you must demonstrate that the work is entirely your own.

Path B students must:

  • Declare AI usage in documentation
  • Expect higher evaluation standards
  • Explain every line in Fachgespräch 2

Universal rule: You own every line you commit.

AI as Learning Assistant (Path A)

As a Path A student, you write all code yourself—but that doesn't mean you can't use AI to learn faster!

AI is allowed and encouraged for:

  • 📖 Explaining Flutter documentation or code examples
  • 🐛 Understanding error messages and their causes
  • 🔍 Reviewing and explaining IDE auto-complete suggestions
  • 🎯 Clarifying concepts (e.g., "What is a StatefulWidget?")
  • 🧪 Asking "What does this code do?" for code you read
  • 🔬 "Act as a critical reviewer: compare my work with the attached theory, identify strengths and weaknesses, and suggest improvements — no generated text"
  • ✏️ "Improve the phrasing of the following text without changing its content"

AI is NOT allowed for:

  • ❌ "Write a login screen for me"
  • ❌ "Generate a ViewModel for workout tracking"
  • ❌ "Create this feature"
  • ❌ "Here are my notes and the task — write my user research documentation"

Smart AI Usage for Learning

For detailed strategies on using AI effectively as a learning tool—including how to prompt for understanding rather than solutions, and how to verify your learning—see:

Kluge KI-Nutzung

The Golden Rule: If you can't explain every line you commit in Fachgespräch 2, you've used AI wrong—regardless of your path.

AI as Senior Pair Programmer -- everything below here addresses Path B Only!

conductor
Dalia Stasevska, now BBC Symphony Orchestra's principal guest conductor, makes her UK debut with the Orchestra of Opera North. Photo: Justin Slee

You are the conductor:

  • You know the composition (architecture)
  • You hear when something is off
  • You stop, rehearse, correct
  • You control timing and interaction

AI is the orchestra section:

  • Fast, capable, skilled
  • Does not understand the whole piece
  • Needs your direction

Without conductor: Even excellent musicians → noise
With conductor: Music

Before You Start with AI

To step into the role of the conductor, you need solid craftsmanship.

  1. Complete the codelab.
  2. Study and understand the recommended architecture, its case study, and the accompanying code — including its structure, responsibilities, and data flow. Download the app, run it, and actively debug the code.
  3. Extend the Compass App (without AI): Implement a new feature in the existing compass app (lab 3).
    • Example: Trip Packing List
      • Users should be able to create packing lists for their trips.
      • Define the domain model, repository, and local implementation (no remote/server part needed)
      • Similar to other local repositories: use dummy data without persistence
      • Implement the view model and screen
      • Add navigation from trip details to packing list
    • Alternative Feature Ideas: Trip notes, expense tracker

These fundamentals give you orientation and confidence. Without them, AI doesn't speed you up—it turns development into frustration instead of flow.

Not Every Trail Is for the Motorbike

bike AI-assisted coding is powerful on open roads — clear requirements, known patterns, repetitive structure. But some trails are better navigated on foot or by bicycle:

  • 🐛 Debugging complex state → step through it yourself
  • 🏗️ Architectural decisions → think first, then discuss with AI
  • 📚 Learning a new concept or API → read the docs, experiment manually
  • 🔀 Untangling spaghetti code → AI makes it worse, not better

The motorbike gets you far — but knowing when to park it is part of mastering the terrain.

Path B: Staying in Control of Your Flow

When generating code with AI, you can enter a highly productive flow state – features emerge quickly, momentum builds, and things just work. But in that flow, it's easy to lose track of what the generated code actually does.

You have a few options to stay on top of it:

Option 1 – Flow first, understand later:
Ride the flow, then circle back. After a session, go through the generated code with AI assistance – understand every part, spot improvements, and refactor as you go. This turns review into a second learning moment.

Option 2 – Deliberate checkpoints:
After every feature (or every ~30 minutes), pause intentionally. Before moving on, make sure you can explain what was just generated and why it works.

Option 3 – Understand inline:
Ask the AI to explain each significant block before you accept it. Slower, but keeps understanding and generation in sync.

Try all three and reflect on which works best for you — the right approach may also depend on the situation. Whichever you choose: understanding always comes before committing.

Setup

Required: CLI Tools

Why CLI over Web Interface?

  • CLI has access to entire codebase
  • Supports multi-file, multi-step tasks
  • Reads your architecture.md automatically

Web interfaces (ChatGPT, Claude web) only see what you paste.

Choose one:

Additional Tools:

There are many community‑built extensions – essentially ready‑made shortcuts that wrap "battle‑tested" prompts with convenient parameters.

Configuration Files (Your Source of Truth)

These files define your project's architecture and scope. AI reads them to understand your rules and domain model.

  • architecture.md --- Defines HOW you build Patterns, layer structure, error handling, testing strategy Download Template
  • project_context.md --- Defines WHAT you build Features, domain model, user flows, data storage Download Template

How to Use These Templates

  1. Download both templates using the buttons above. Rename them to .md files.
  2. Read them carefully to understand the structure (1)
  3. Adapt to your project:
    • Replace [Project Name] with your actual project name
    • Modify domain models to match your entities
    • Update features list to match your MVP scope
    • Adjust dependencies to your tech stack
  4. Place in your app folder: 
    app/
├── architecture.md       ← AI reads this
├── project_context.md    ← AI reads this
├── lib/
└── pubspec.yaml
  5. Start your AI session with context:

# Files are referenced inline with @
claude "Build the workout logging feature. 
See @architecture.md and @project_context.md."
💡 Alternatively, rename your context to CLAUDE.md — Claude Code reads it automatically. → Claude Code Docs

# Use @ to attach files to your prompt
gemini "Build the workout logging feature. 
See @architecture.md and @project_context.md."
→ Gemini CLI on GitHub

# Pass files via --context flag or inline
codex --context architecture.md \
      --context project_context.md \
      "Build the workout logging feature."
→ Codex CLI on GitHub

  1. These are NOT just documentation—AI uses them as instructions for every code generation task!

Start Simple, Evolve Later

Don't try to perfect these files on day one. Start with the templates, use them for your first feature, then refine based on what works.

Keeping Files Useful Over Time

Without context files, AI invents scope: 

You: "Build workout logging feature"
AI:  "I'll add GPS, heart rate monitoring, and social sharing!"
You: "No! MVP is manual entry only! 😤"
With them, it stays aligned — but only if you keep them updated:

Trigger What to Update
New feature project_context.md → Features, domain model
Architecture change architecture.md → Layer structure, rules
New dependency Both → Dependencies section
Code review feedback architecture.md → Add learned patterns

15-Minute Milestone Habit

After each completed feature, review and update both files. They grow more valuable over time as they capture real decisions, not just theory.

Design-to-Code Workflow

Critical: Design Before Code

Never skip these steps:

  1. Create a digital prototype first (Figma plain, Stitch, or Figma Make)
  2. Extract your design system (colors, typography, spacing)
  3. Build theme files BEFORE any widgets
  4. Never hardcode colors, fonts, or spacing values

Why? Hardcoded values create technical debt from day one. Changing colors later means hunting through hundreds of widgets instead of updating 4 theme files.

Choose Your Path

You have three options, ordered by design control and iteration speed:

Figma Direct (Recommended for Serious Projects)

  • Introduction see Figma
  • Full design control in Figma
  • Define design system with variables
  • Create reusable components
  • AI extracts everything via MCP
  • Best for: Complex apps, evolving designs, team collaboration

Stitch

  • Iterate design in browser
  • Export HTML with Tailwind CSS
  • AI extracts theme from Tailwind config
  • Best for: Quick prototypes, learning workflows, simple designs

Figma Make

  • Design components in Figma Make
  • Export React + shadcn/ui
  • AI translates to Flutter
  • Best for: Component-heavy designs; React-to-Flutter translation works well in practice

Try Multiple Tools

Not sure which fits your workflow? Spend 30 minutes with each tool building the same simple screen (e.g., a list with cards). Pick the one that feels most natural.

Path I: Stitch

Step 1: Generate & Download

  1. Iterate your design in Stitch until you are satisfied.
  2. Download the project and save the files organized: reference-ui/screens/home.html, list.html, etc.

Step 2: Extract Theme

Prompt: 

Read architecture.md and reference-ui/screens/*.html.

Extract design system from Tailwind config and classes:

Create lib/ui/core/theme/:
1. app_colors.dart - ColorScheme from tailwind.config colors + bg-*/text-* classes
2. app_text_styles.dart - TextTheme from font config + text-*/font-* classes
3. app_spacing.dart - Constants from p-*/m-*/gap-* classes + border radius
4. app_theme.dart - Combine into Material 3 ThemeData (light + dark)

Map Tailwind → Flutter Material 3 naming.

STOP after theme files. I will test.

Step 3: Create Widgets

Identify patterns: Cards, buttons, list items repeating across HTML files.

Prompt template (repeat for each pattern): 

Read architecture.md and reference-ui/screens/[SCREEN].html lines [X-Y].

Create Flutter widget lib/ui/core/widgets/[name].dart:

1. Analyze HTML structure and Tailwind classes
2. Translate to Flutter (Column, Row, Container, etc.)
3. Use theme (AppColors, AppSpacing, AppTextStyles)
4. Add dummy data as defaults
5. Make customizable (title, subtitle, onTap, etc.)
6. Add Semantics labels
7. Match HTML appearance exactly

STOP. I will test with dummy data.

Build the widgets: Button, Card, TextField, domain cards (WorkoutCard, etc.). Continue with the screens.

All Components Screen

Put all components into one screen and review them.

Step 4: Create Screens

Prompt template (repeat for each screen): 

Read architecture.md and reference-ui/screens/[SCREEN].html.

Create screen lib/ui/[feature]/[screen]_screen.dart:

1. Analyze screen structure:
   - Top-level layout (header, body, navigation)
   - Sections and their arrangement
   - Which existing widgets to use

2. Translate to Flutter:
   - Scaffold with AppBar
   - Body layout (ListView, Column, GridView, etc.)
   - Compose existing widgets (ActionButton, WorkoutCard, etc.)
   - Use AppSpacing for screen-level margins/padding
   - Add ScrollView if needed

Match HTML screen structure exactly.

STOP. I will test navigation and layout.

Path II: Figma Make

Step 1: Generate & Download

  1. Iterate your design in Figma Make until you are satisfied.

  2. Download the project and save the files to the folder reference-ui/. You get:

    • globals.css (with CSS variables)
    • React components (.jsx files)
    • shadcn/ui imports (not all available in Flutter!)

Step 2: Extract Theme from CSS

Prompt: 

Read architecture.md and reference-ui/globals.css.

Extract design system from CSS variables (--primary, --background, etc.):

Create lib/ui/core/theme/:
1. app_colors.dart - Map CSS variables to ColorScheme
2. app_text_styles.dart - Extract from CSS font rules
3. app_spacing.dart - Extract from CSS spacing/radius variables
4. app_theme.dart - Combine into ThemeData

Note: shadcn/ui doesn't exist in Flutter. We'll recreate the style.

STOP after theme files.

Step 3: Translate React Components

Break Down Large Components

React components from Make are often too coarse-grained. Split into smaller, reusable Flutter widgets.

Prompt template: 

Read architecture.md and reference-ui/components/[Component].jsx.

This is REACT code. Translate to Flutter:

1. Analyze component structure (JSX hierarchy, props, styling)
2. Identify if this should be ONE widget or MULTIPLE smaller widgets
3. For each Flutter widget:
   - Create in lib/ui/core/widgets/
   - Use theme (not CSS variables!)
   - Add dummy data from React component
   - Make props customizable
   - Add Semantics

Break large components into:
- Layout widgets (containers, spacing)
- Interactive widgets (buttons, inputs)
- Display widgets (text, icons, images)

Example: WorkoutCard.jsx might become:
- workout_card.dart (container)
- workout_stats_row.dart (reusable stats display)
- tag_chip.dart (reusable tag)

STOP after creating widgets. I will test composition.

Key difference from Stitch: - Stitch → Direct HTML-to-Flutter mapping - Make → React-to-Flutter translation + decomposition

Path III: Figma Direct (with MCP)

Model Context Protocol (MCP) enables LLM CLI to directly access external data sources like Figma files. Instead of exporting HTML or React code, the LLM CLI can read your Figma design system, components, and screens directly through a Figma MCP server.

Benefits: - No manual export/download step - Real-time access to design changes - Structured extraction of styles, components, and screens - More accurate theme mapping (native Figma variables → Flutter)

Setup: Enable the Figma MCP server in VS Code.

Step 1: Connect & Analyze

Prompt: 

Connect to Figma file [FILE_URL].

Analyze the design system:
1. List all color styles (variables + applied colors)
2. List all text styles (font families, weights, sizes)
3. Identify spacing patterns (padding, gaps, margins)
4. Note border radius values
5. List reusable components (buttons, cards, inputs)

Report findings. STOP before creating files.

Review: Check if Claude/Gemini correctly identified your design tokens.

Step 2: Extract Theme from Figma

Prompt: 

Read architecture.md.
Access Figma file [FILE_URL].

Extract design system from Figma variables and styles:

Create lib/ui/core/theme/:
1. app_colors.dart
   - Map Figma color variables → ColorScheme
   - Use semantic naming (primary, surface, error, etc.)
   - Support light + dark mode if defined in Figma

2. app_text_styles.dart
   - Map Figma text styles → TextTheme
   - Preserve font families, weights, sizes, letter spacing

3. app_spacing.dart
   - Extract common spacing values from components
   - Create constants for padding, gaps, margins
   - Extract border radius values

4. app_theme.dart
   - Combine into Material 3 ThemeData
   - Set elevation, shape themes
   - Configure button, input field styles

Map Figma semantic names → Flutter Material 3 equivalents.

STOP after theme files. I will verify against Figma.

Step 3: Create Widgets from Components

Identify components: Use Figma's component structure as blueprint.

Prompt template (for each component): 

Read architecture.md.
Access Figma file [FILE_URL], component [COMPONENT_NAME].

Create Flutter widget lib/ui/core/widgets/[name].dart:

1. Analyze component structure:
   - Frame hierarchy (container → row/column → children)
   - Applied styles (colors, text styles, spacing)
   - Auto-layout properties (direction, padding, gap, alignment)
   - Interactive properties (hover, pressed states if defined)

2. Translate to Flutter:
   - Auto-layout horizontal → Row
   - Auto-layout vertical → Column
   - Fixed size → SizedBox
   - Constraints → ConstrainedBox

3. Implementation:
   - Use theme constants (AppColors.primary, not Color(0xFF...))
   - Use AppSpacing for padding/margins
   - Use AppTextStyles for text
   - Add component variants as constructors (if defined in Figma)
   - Make properties customizable (text, onTap, icon, etc.)
   - Add Semantics labels

4. Match Figma appearance:
   - Exact spacing (use Figma inspector values)
   - Exact colors (use theme mapping)
   - Exact typography (use text style mapping)

STOP. I will compare with Figma component.

Example flow: 

Step 1: "Extract ActionButton component from Figma"
→ Creates action_button.dart with primary/secondary variants

Step 2: "Extract WorkoutCard component"
→ Creates workout_card.dart + identifies nested Tag component

Step 3: "Extract Tag component (used in WorkoutCard)"
→ Creates tag_chip.dart (reusable)

Step 4: "Update WorkoutCard to use TagChip widget"
→ Refactors for composition

Iterate Component by Component

Don't ask for "all components at once". Build them one by one, test each, then move to the next. This matches how you'd build them manually.

Step 4: Extract Screen Layouts

After core widgets exist:

Prompt: 

Read architecture.md.
Access Figma screen [SCREEN_NAME] in file [FILE_URL].

Create screen lib/ui/[feature]/[screen]_screen.dart:

1. Analyze screen structure:
   - Top-level layout (AppBar, body, bottom nav)
   - Body sections (headers, lists, grids)
   - Used components (map to existing widgets)

2. Translate to Flutter:
   - Scaffold with AppBar
   - Body layout (Column, ListView, GridView, etc.)
   - Compose existing widgets (ActionButton, WorkoutCard, etc.)
   - Use theme spacing for screen-level layout
   - Add ScrollView if content may overflow

Match Figma screen structure exactly.

STOP. I will test with dummy data.

Implementation Order (All Paths)

graph LR
    A[Design Tool] --> B[Extract Theme]
    B --> C[Create Core Widgets]
    C --> D[Test with Dummy Data]
    D --> E[Create Screens]
    E --> F[Initial Setup]


    A1[Stitch / Figma Make] -.->|export| A
    A2[Figma MCP] -.->|direct access| A

Common Mistakes Across All Paths

  • ❌ Hardcoding colors/spacing in widgets
  • ❌ Creating one giant widget per screen
  • ❌ Skipping theme extraction ("I'll add it later")
  • ✅ Theme first, widgets second, composition third
  • ✅ Small, reusable widgets
  • ✅ Test each piece before moving to next

The AI Workflow (Step-by-Step)

Two Types of Workflows

  • Initial Setup (Do Once)

    When: Start of project

    What: Foundation before features

    • Theme & Design System
    • Domain Models
    • Repository Interfaces
    • Core Utilities

    Setup Workflow

  • Feature Development (Iterative)

    When: After setup complete

    What: Build actual features

    • User Stories → Features
    • Following established patterns
    • Incremental testing

    Feature Workflow

Initial Setup Workflow

Do This BEFORE Building Features

You cannot build features without foundation. Setup first, features second.

Phase 1: Planning the Foundation

Your Prompt: 

Read architecture.md and project_context.md carefully.

I'm starting a new Flutter project and need to set up the foundation.

**If anything is unclear about the project, ASK ME before planning.**

I created the theme and some components already, use it. 

Based on project_context.md, create a file called SETUP_PLAN.md with:

1. **Domain Models** 
   - All entity classes from project_context.md
   - Enums needed

2. **Repository Interfaces**
   - One interface per entity
   - Method signatures (all return Future<Result<T>>)

3. **Core Utilities**
   - Logger configuration
   - Error types (AppError hierarchy)
   - Result<T> type
   - Command base class: use https://github.com/flutter/samples/blob/main/compass_app/app/lib/utils/command.dart

4. **Dependencies**
   - Packages to add to pubspec.yaml
   - Use latest version were possible

5. **Implementation Order**
   - Step-by-step sequence (what depends on what)

STOP after creating SETUP_PLAN.md. Do NOT write code yet.
Wait for my review.

Phase 2: Review Setup Plan

Open SETUP_PLAN.md and verify: 

## Setup Review Checklist

### Domain Models
- [ ] All entities from project_context.md present
- [ ] Field types correct (DateTime not String, etc.)
- [ ] Enums defined for constrained fields
- [ ] Validation rules documented

### Repositories
- [ ] One interface per entity
- [ ] All methods return Future<Result<T>>
- [ ] CRUD operations covered

### Error Handling
- [ ] Error hierarchy covers all cases
- [ ] Each error has userMessage (UI) and message (logs)

### Dependencies
- [ ] All packages listed
- [ ] Version constraints specified

Phase 3: Execute Setup (Step-by-Step!)

You: "SETUP_PLAN.md approved. 
     Execute Step 1. 
     Then STOP for my review."

AI: [Creates files]

You: [Review in GitHub Desktop]
     [Review, test, commit]

You: "Step 1 approved. Continue to Step 2."

... repeat for each step ...

Why step-by-step?

  • ✅ Catch issues early
  • ✅ Understand each piece
  • ✅ Testable increments
  • ❌ Never: "Just implement everything"

Feature Development Workflow

Prerequisites: Initial setup complete ✅

Phase 1: Planning a Feature

Your Prompt: 

Read architecture.md and project_context.md.

I want to implement: [FEATURE NAME from project_context.md MVP list]

Example: "Manual workout logging" or "Weekly goal setting"

**Context from project_context.md:**
[Copy-paste relevant user flow or feature description]

**If anything about this feature is unclear, ASK ME before planning.**

Then create current_plan.md with:

1. **Files to Create**
   - Paths matching architecture.md structure
   - Purpose of each file

2. **Files to Modify** 
   - Why each modification needed

3. **Implementation Order**
   - Bottom-up: Service → Repository → Command → ViewModel → View

4. **Data Flow**
   - Where data lives (local/remote)
   - How it flows between layers

5. **Potential Issues**
   - Validation rules
   - Offline handling
   - Error cases
   - Edge cases from project_context.md

6. **Testing Strategy**
   - What to test at each layer
   - How to mock dependencies

7. **Acceptance Criteria**
   - How do we know this feature is done?

STOP after creating current_plan.md. Do NOT write code yet.
Wait for my review and approval.

Phase 2: Feature Review

Open current_plan.md and check: 

## Feature Plan Review Checklist

### Scope Alignment
- [ ] Feature matches project_context.md MVP list
- [ ] Respects "Out of Scope" items
- [ ] Follows documented user flows

### Architecture Compliance
- [ ] Files follow architecture.md structure
- [ ] Layers properly separated
- [ ] Error handling follows Result<T> pattern
- [ ] Loading states planned

### Domain Consistency
- [ ] Uses domain models from project_context.md
- [ ] Respects validation rules (e.g., "duration > 0")
- [ ] Follows data storage strategy

### Implementation Quality
- [ ] Bottom-up order (dependencies first)
- [ ] Each step testable
- [ ] Offline handling considered
- [ ] Localization planned
- [ ] Accessibility planned

### Testing Coverage
- [ ] Unit tests for Repository
- [ ] Unit tests for ViewModel
- [ ] Widget tests for Screen
- [ ] Integration test (if critical)

If you find issues: Revise the plan.

Phase 3: Execute Feature

Your Prompt: 

Using the approved current_plan.md:

Execute Step 1 only: [STEP DESCRIPTION]

Requirements:
- Follow architecture.md error handling
- Add logging (Logger.info/severe)
- Return Result<T> from async methods
- Include /// doc comments

After generating, STOP. I will review and test.

After AI generates:

  1. Open GitHub Desktop
  2. Review diff
  3. Run app, test the change
  4. If good: continue to Step 2
  5. If bad: fix [specific issue]

The Three-Strikes Rule

When AI Gets Stuck

If AI fails to fix after 3 attempts → STOP using AI for this task.

Signs AI is stuck:

  • Same error repeats
  • Fix breaks something else
  • Contradictory solutions
  • Apologizes without progress

Example: 

You: "List doesn't update after add. Fix it."
AI: [Solution A] ❌
You: "Still broken."
AI: [Solution B] ❌
You: "Still broken."
AI: [Solution C] ❌

You: "Three strikes. I'll debug manually."

[You find: forgot notifyListeners()]
[You fix it]
[You LEARN the actual problem]

Why?

  • Stops time waste on hallucinations
  • Forces understanding

AI as Your Thought Partner

AI should help you enjoy building.
Poor prompts and shallow understanding turn AI into noise and frustration.
If it kills the fun, slow down, think clearer—or code without AI for a while.

Further Reading