DEV Community: Khalit Hartmann

Mobile App Engagement Strategy: How We Fixed a 0.6% Push Notification Open Rate

Khalit Hartmann — Thu, 02 Jul 2026 16:19:58 +0000

Based on my talk at Flutter Berlin (Flutter OctoberFest). Assumes familiarity with mobile development. No ML or data science background needed.

📺 Watch the full talk on YouTube

TL;DR: Campaign push notifications at MediaMarktSaturn had a 0.6% open rate across 2.7 million sends. The problem wasn't the content. It was timing, relevance, and volume. We found a framework called Just-In-Time Adaptive Interventions (JITAI), originally from medical health apps, and designed a system that decides whether, when, and what to send each user. The system was still in discovery when I gave this talk, but the thinking behind it applies to any mobile app engagement strategy.

Most mobile app engagement strategies treat push notifications as a broadcast channel: pick a segment, write copy, blast it out, hope for clicks. This post shows what happens when that stops working at scale, and how a research-backed framework gives you a better way to improve app engagement through push notifications. The examples come from a real e-commerce app with millions of users.

The numbers that started the conversation

At MediaMarktSaturn, I worked on the consumer apps team, one of the larger Flutter teams in Germany. We maintained apps across 13 countries. The quarter before, we'd also shipped a push notification service.

Here's what a bad campaign looked like:

Metric	Number
Push notifications sent	2,700,000
Opened	~17,000 (0.6%)
Converted (from opens)	66 (0.36%)

That's 66 purchases from 2.7 million interruptions. Not 66 thousand. Sixty-six.

This wasn't even our worst campaign. But it made the question impossible to dodge: are we providing value to our users, or are we just making noise?

Why push notifications fail to drive app engagement

We kept coming back to four problems:

Timing. Send a notification while someone is in a meeting or on the train and it's just a disturbance. Every user has different windows of attention throughout the day.

Relevance. A promotion for kitchen appliances is useful to someone furnishing a new apartment. To everyone else, it's clutter. Batch campaigns don't distinguish between the two.

Volume. Send too many and users go numb. Or they revoke notification permissions entirely. Once that happens, the channel is dead.

Competition. The average user has around 50 apps installed. Each one wants a slice of a limited attention budget. If your notification doesn't earn its place, it gets swiped away.

All four come back to the same thing: receptivity, the user's ability and willingness, right now, to receive and act on an interruption.

What receptivity actually means

Receptivity isn't a toggle. It shifts throughout the day based on two kinds of signals:

Internal: mood, cognitive load, what the user is focused on
External: location, time of day, whether they're driving, walking, or sitting still

The idea is simple: if someone isn't in a position to care about your message, sending it does nothing at best and annoys them at worst. Push to a non-receptive user often enough and they'll opt out.

Our bet: if we time notifications better and make them personal, users will see them as useful instead of annoying. Useful notifications get opened. Opened notifications convert.

What is JITAI? A framework from health research

Just-In-Time Adaptive Interventions (JITAI) comes from medical health research, specifically addiction support and weight loss apps. Those systems monitor a user's internal and external state and only step in when two conditions are met:

The user is in a vulnerable state (in a health app: at risk of relapsing; for us: likely to benefit from a product notification)
The user is in a receptive state (able and willing to process the message right now)

The framework has four parts:

1. Decision points

The moment the system decides whether to show a notification. For server-sent push, this is when the server would normally fire. For on-device local notifications, you can set intervals and check every X minutes whether conditions are right.

The important part: the decision isn't just "send." It's "send, delay, or don't send at all."

2. Tailoring variables

The data that feeds the decision. Two sources:

Passive (no user action needed):

Device type (Android and iOS users often have different notification habits)
Location (is the user near a physical store?)
Time patterns (when does this user typically open the app?)
Sensor data (accelerometer, ambient light, with consent)

Active (user tells us directly):

Wishlist items
Search history
Category preferences

The system has to work with whatever the user consents to share. Someone who only grants location access should still get a noticeably better experience than a batch campaign.

3. Intervention options

What the system can actually do:

Action	Example
Information notification	New arrivals, restocks
Promotional notification	Sales, discounts
Location-based notification	Store-specific offers when nearby
Rich push	Image-heavy, interactive notifications
Reschedule	Delay the notification for a better time
No push	Suppress the notification entirely

That last row matters the most. Sometimes the best notification is none.

4. The decision maker

This is the core. It takes the tailoring variables and intervention options and decides which intervention to offer, to whom, and when.

Two approaches:

Algorithmic: Decision trees and rules. Easier to build, test, and explain. Example: if the user is within 500m of a store AND has a wishlist item on sale at that store, send a location-based push.

Machine learning: An on-device reinforcement learning model that learns from each user's interaction patterns. The model improves per-user over time without sharing data across devices. Harder to build and harder to test, but it can pick up patterns that rules miss.

In practice, you'd start with rules and add ML where the rules stop improving.

Push notification examples that improve app engagement

The store walk-by

You're walking through Alexanderplatz. Your Saturn app knows your wishlist, and you've been eyeing a pair of headphones. In the background, the system checks: does the Saturn store at Alexanderplatz have those headphones in stock? Is there a promotion running?

If yes, send a push. You already wanted the product. The store is 200 meters away. The promotion gives you a reason to walk in now.

You find out about a deal on something you already want. The store gets a walk-in. One notification, no spam.

Distal outcome: purchase in store.
Proximal outcome: user becomes aware of the deal. Even if they don't tap the notification, they've absorbed the information.

The abandoned cart

You're at home, browsing the MediaMarkt app. You add three items to your cart. Your partner walks in, you put the phone down, and the cart just sits there.

The system picks up that the cart has been idle for a few hours. One of the items now has a 20% discount that expires soon. You probably forgot about the cart, and you definitely don't know about the price drop.

Send a notification about the discount. You get a useful reminder. The retailer recovers a sale that would have quietly disappeared.

Both examples follow the same logic: only interrupt someone when you're reasonably confident the notification is worth their attention.

The hard parts of this engagement strategy

Privacy and GDPR

We're in Germany. GDPR isn't a formality, it's the operating environment. The system touches sensitive data: location, purchase history, browsing behavior. The deal with users has to be clear: this data improves your notification experience, full stop. It's never sold or shared.

If users don't trust the system, they won't grant the permissions it needs. And then there's nothing to work with.

Testing tailoring variables

Which variables actually predict receptivity? Device type? Time of day? Distance to a store? Some combination? This needs serious A/B testing and careful measurement. The search space is large, and gut feelings about what matters tend to be wrong.

Incomplete data

The system has to work when users only grant some permissions, or none at all. Someone who shares location, wishlist, and browsing history gives the decision maker plenty of signal. Someone who shares nothing gets the batch experience, same as before, no penalties.

That gap in quality is inherent, and it's fine. But it needs to be measured honestly, not papered over in the dashboard.

Where we left off

When I gave this talk at Flutter Berlin, the system was in the discovery phase. We had research, architecture, and a talk, but no production code yet. The academic literature on JITAI is solid, but applying it to e-commerce push at scale, across 13 countries and millions of users, raises problems the papers don't address.

The thing I keep coming back to: the problem with push notifications isn't push notifications. It's sending the wrong message at the wrong time. And honestly, it's not having the discipline to send nothing when you don't have a good reason.

Most mobile app engagement strategies still treat push as a broadcast channel. The bar for standing out is low: just stop yelling at people who didn't ask.

Thanks to Flutter Berlin and MediaMarktSaturn for hosting the event.

If you're building a mobile app that needs smarter notifications — or rethinking the system you already have — that's the kind of architecture work I do.

Key takeaways

Push notification open rates are a symptom, not the disease. The real problem is sending the wrong message at the wrong time to the wrong user.
The JITAI framework gives structure to personalization. Decision points, tailoring variables, intervention options, and a decision maker — four components that turn "send smarter notifications" into an engineering problem.
Start with rules, add ML later. Algorithmic decision trees are easier to build, test, and explain. Machine learning picks up patterns rules miss, but only after you understand what "better" looks like.
The best notification is sometimes no notification. Suppressing a low-value push preserves the user's trust and keeps the channel alive for when it matters.

Building Apps with AI: What Actually Works (2026)

Khalit Hartmann — Thu, 02 Jul 2026 16:19:57 +0000

For CTOs, founders, and developers who want to know how AI is actually changing app development. No buzzword bingo — experiences from real projects.

TL;DR: "Build an app with AI" can mean two things: using AI tools to develop faster, or adding AI features to your app. I do both daily. The reality: AI coding tools like Claude Code speed up my work by 20–40%, but they don't replace architecture decisions or testing. No-code AI builders like Bolt or FlutterFlow produce decent prototypes, but not production-ready apps. And AI features in apps (chatbots, image recognition, recommendations) are now affordable — if you know which API to use for which problem.

What "build an app with AI" actually means

When clients mention "AI" in their initial inquiry, they usually mean one of two things.

The first: using AI tools to make development itself faster. Claude Code implements entire features from a description, GitHub Copilot suggests inline completions, Cursor navigates the codebase. This affects me as a developer and changes how I work.

The second: adding AI features to the app itself. A chatbot that answers customer questions. Image recognition that identifies products. Personalized recommendations based on user behavior. This affects the product and its features.

Both meanings matter, but they're fundamentally different. I'll cover both.

AI as a development tool: what works, what doesn't

I've been using AI coding tools in my daily work since 2023. Currently it's exclusively Claude Code — as a coding partner that knows the entire codebase and can implement features end-to-end.

What genuinely goes faster: boilerplate code, test cases, data models, regular expressions, and navigating unfamiliar codebases. When I need a new Flutter widget that follows an existing pattern in the app, Claude Code builds it in seconds instead of minutes. Unit tests for a method? Claude Code generates them in the context of the existing test suite and gets the approach right most of the time.

On a recent project — an e-commerce app with a complex shopping cart — I estimate I spent 30% less time on implementation than I would have without AI tools. The gain isn't in single big moments but in hundreds of small time savings spread across the entire project.

What doesn't work: architecture decisions. "Should we use Riverpod or Bloc for state management?" — AI will give you an answer, but whether it's right for your specific project requires someone who understands the context. (More on framework choices in my Flutter vs React Native comparison.) Same goes for security decisions, performance optimization, and anything where context extends beyond a single file.

One point that rarely gets mentioned: AI-generated code needs the same careful review as human-written code. I've accepted AI suggestions that compiled and passed tests but were logically wrong. That happens when you stop reading the output. AI tools make an experienced developer faster. They don't make an inexperienced developer experienced.

Adding AI features to your app: the practical options

The second meaning — putting AI into the product. A lot has changed here in the last two years.

Chatbots and text processing

For chatbots and text processing, the large language models are the obvious choice. Claude API, OpenAI API, or Google Gemini as the backend. The integration is technically straightforward: API call to the provider, display the response. The challenge is in prompt design (what instructions does the model get?), cost control (API calls charge per token), and making sure the responses actually make sense for your context.

Image recognition and computer vision

For image recognition and computer vision, there are on-device options: TensorFlow Lite, Core ML (iOS), and Google's ML Kit. The advantage: processing happens on the device with no server costs and no latency. A concrete example: for a health app, I built text recognition using Google ML Kit that scans product codes from leaflet inserts. The user points their camera, the app recognizes the code via on-device OCR and unlocks content — no server costs, no latency.

Recommendation systems

Recommendation systems — "products you might like" — can now be built with services like AWS Personalize or Google Recommendations AI without training your own ML model. Costs start low and scale with usage. In practice, I haven't needed to train a custom recommendation algorithm on any project so far — the cloud services cover most use cases.

Speech recognition

Speech recognition runs on native platform APIs from Apple and Google — reliable and without server costs. Once you need intent detection or context across multiple sentences, you're back to the LLM APIs.

What each option costs

What each option costs depends heavily on usage volume. For an MVP with a few hundred users, API costs run 10–50 €/month. With hundreds of thousands of users, it can quickly hit four figures. On-device ML has no ongoing costs — but the initial development is more involved.

No-code AI: building apps without programming

Bolt, Lovable, FlutterFlow with AI assistant — I've tested them all. These tools promise to generate apps from text descriptions.

I've tested several of them. My honest take:

For prototypes and demos, they work surprisingly well. Bolt generates a functional web app from a prompt — with UI, navigation, and basic logic. FlutterFlow creates Flutter UIs from descriptions that actually look decent. For a pitch deck prototype or an internal demo, that saves days.

For production-ready apps, they fall short. The codebase is hard to maintain, performance sits below what an experienced developer produces, and the moment you need something beyond standard patterns, you hit walls. Error handling, edge cases, accessibility, performance optimization — these are the things that separate a good app from a mediocre one, and no builder handles them well.

My recommendation: use no-code AI for validation. Build a prototype, show it to potential users, collect feedback. If validation is positive, invest in a professional implementation. The prototype then provides valuable requirements for the developer. (More on this in my post for founders building their first app.)

Want to know what an MVP with AI features actually costs? Here's my honest breakdown.

What AI means for costs and timelines

The honest answer: AI makes app development cheaper and faster, but not to the degree some people promise.

My experience: AI tools save me 20–40% of development time, depending on the project type. A project that would have taken eight weeks now takes six to seven. With heavy custom UI and little boilerplate, the difference is smaller. With API-heavy backend integrations, it's larger.

What doesn't change: the concept and design phase. Understanding what to build takes just as long as before. Same for testing and QA. AI accelerates implementation, not the entire product development process.

For clients, that means concretely: an MVP that previously cost 20,000 € now comes in around 15,000–17,000 €. (More on this in my post about app costs.) Not a paradigm shift, but a noticeable improvement. The bigger change is that I can deliver more functionality in the same time — not that the same functionality costs dramatically less.

Where AI hits its limits

After two years of daily use, I'm clear on what AI can't do in app development — at least not yet.

Business context is the biggest gap. AI can write code, but it can't judge whether the feature priority is right or whether the architecture will still scale in six months. Every decision that goes beyond a single function needs human judgment.

Then there's the missing long-term memory. AI doesn't know the decision from last sprint about why you chose against Redux, or which technical debt you consciously accepted. Context extends beyond the session, and that's missing.

Hallucinations still happen. Less than a year ago, but they do. Non-existent API methods, outdated syntax, packages that don't exist. If you can't verify the output, you won't notice. That's why AI is a tool for developers, not a replacement.

And then the quality question. AI produces code that "works." But working code and good code aren't the same thing. Error handling, accessibility, performance under load, edge cases with poor network connectivity — these are the things that matter, and they don't appear in any AI-generated MVP.

Still: AI is the best tool that's been added to my career as a developer. Not because it replaces me, but because it handles the boring parts and leaves me more time for the interesting ones. If you're considering local AI alternatives to cloud APIs, here's my experience report.

Planning an app with AI features, or want to know how AI can speed up your project? Book a free intro call — I'll give you a realistic assessment of what's possible and what's worth it. More about my approach on the app development page.

AI-Assisted Flutter Development: Claude Code in Production

Khalit Hartmann — Thu, 02 Jul 2026 15:04:00 +0000

AI-Assisted Flutter Development: Claude Code in Production

For senior developers, tech leads, and CTOs wondering whether AI coding tools actually work in production -- or just generate impressive demos.

TL;DR: I used Claude Code across 827 commits in a Flutter e-commerce app for a Swiss retailer. The difference between "vibe coding" and AI-assisted development is not the AI -- it is the infrastructure around it. A CLAUDE.md file defines project context. Custom skills (slash commands) switch the AI between migration mode, legacy mode, and test mode. Architecture guardrails prevent the AI from "improving" code it should not touch. Result: ~30% faster migration timeline. Not because the AI wrote perfect code, but because it handled the mechanical parts while I made the decisions that required judgment.

Vibe Coding vs. AI-Assisted Development

These two terms get used interchangeably in 2026. They should not be.

Vibe coding is prompting and committing. You describe what you want, the AI generates code, you paste it in. Maybe it works. Maybe it compiles. Maybe it follows the same pattern as the rest of your codebase. You don't know until something breaks, and by then three more features are built on top of it.

AI-assisted development is structured collaboration. The AI knows your architecture. It knows which patterns to follow in which parts of the codebase. It knows when to use TaskEither and when to use try/catch. It knows because you told it -- explicitly, in configuration files that it reads before writing a single line.

Both use the same underlying models. The difference is entirely in setup. One produces code that looks right in a PR diff. The other produces code that works in production six months later.

I spent ten months on a project that started as vibe-coded and ended as something far more disciplined.

The Project: 827 Commits, One Codebase

The Customer was a renowned Swiss retailer that had just launched their Mobile E-Commerce App 2 Months prior. I joined their Flutter e-commerce app when it had an 85% crash-free rate -- roughly one in seven sessions ended in a crash. API calls inside widgets, three different error handling styles, state management by tutorial roulette.

Over 22 weeks, I migrated the app to Clean Architecture while shipping features. 827 commits. Crash-free rate past 97%. I have written about the migration strategy itself separately. This post is about the AI tooling that made it possible to move that fast.

My only AI coding tool was Claude Code -- an agentic coding CLI that reads your entire project and executes multi-step development tasks. Not Copilot, not Cursor. The distinction matters because this workflow depends on Claude Code features: CLAUDE.md configuration files and custom skills.

The Context Problem

Here is what happens when you point an AI at a Flutter codebase without project context.

You ask it to fetch product data. It writes a service class with try/catch. You ask it to fetch user data. It writes a repository with TaskEither from fpdart. You ask it to handle cart state. It generates a ChangeNotifier. You already use Riverpod.

Three requests, three different patterns. Each defensible in isolation. Together, a maintenance nightmare.

The AI has no way to know your project uses TaskEither for error handling and AsyncNotifier for state management. It draws from the sum of all Flutter code it has ever seen, and that sum includes every pattern and anti-pattern in existence.

The fix is not a smarter model. The fix is project context.

CLAUDE.md: Your Project's AI Configuration

Claude Code reads a CLAUDE.md file from your project root at the start of every session. Architecture decisions, naming conventions, import rules -- everything the AI needs before it touches your code.

Here is a simplified version from the retailer project:

## 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

### Error Handling

- New code: TaskEither<AppFailure, T> from fpdart
- Legacy code: existing try/catch (do NOT refactor)

### State Management

- New features: Riverpod with code generation
- AsyncNotifier for async state
- Do NOT use ChangeNotifier, StateNotifier, or Bloc

This is not documentation for humans. Humans have context from standups and PR reviews. CLAUDE.md is documentation for the AI -- explicit, unambiguous, with decision trees instead of guidelines.

The decision matrix is the most important part. Without it, the AI defaults to "write the best code possible." During a migration, "best code possible" is context-dependent. A bug fix in unmigrated code should follow legacy patterns. The same logic, written during a migration, should follow Clean Architecture. Same feature, two correct approaches, depending entirely on intent. No model training covers that distinction. It has to be configured per project.

Custom Skills: Different Tasks, Different AI Behavior

A CLAUDE.md sets the baseline context. But different development tasks need the AI to behave differently. That is where custom skills come in.

Custom skills are slash commands in Claude Code. Each one loads a specific set of instructions that override or extend the baseline context. On the retailer project, I used five:

/migration enforces a strict sequence:

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

The AI does not jump ahead to the presentation layer because it is "easier." It starts with the domain, writes the interfaces, and builds outward. Every migrated feature has the same structure.

/legacy-code is the opposite. "Follow existing patterns. Do not introduce Clean Architecture imports. Match the style of surrounding code." This was the hardest skill to get right. The AI's instinct is to improve. It sees a try/catch and wants to refactor it into TaskEither. That instinct is correct in migration mode and catastrophic in legacy mode. A "quick improvement" to a legacy service class can break five widgets that depend on its exact interface.

/ui-component loads design system rules. /riverpod enforces code generation with @riverpod annotation and AsyncNotifier. /test-workflow sets testing conventions -- unit tests for use cases, widget tests for composed components, mock repositories via domain interfaces.

Each skill changes the AI's behavior without changing the AI itself. The model is the same. The context is different. (For more on how AI agents and tool systems like these work, see AI Agents, MCP, and Tools Explained.)

Architecture Guardrails: The Biggest Win

If I had to pick one concept from this entire setup that delivered the most value, it is architecture guardrails.

During a migration, two valid architectural styles coexist for months. Every task requires a decision -- which style applies here? Humans handle this through judgment. AI does not have that judgment. Without explicit guardrails, it sees legacy code and "improves" it. That creates a third style -- half-migrated code that follows neither convention consistently. Worse than legacy code because it is unpredictable.

The decision matrix in CLAUDE.md solved this. Not a suggestion -- a rule. "Touching unmigrated code? Follow legacy patterns." No ambiguity.

Here is what the same task looks like with and without guardrails.

Without guardrails -- fixing a bug in a legacy service:

// AI "improves" the legacy code while fixing the bug
class ProductService {
  TaskEither<AppFailure, Product> getProduct(String id) {
    return TaskEither.tryCatch(
      () => _httpClient.get('/products/$id').then((r) => Product.fromJson(r.data)),
      (error, stack) => AppFailure.unexpected(error.toString()),
    );
  }
}
// Problem: 12 widgets depend on Future<Product>, not TaskEither

With guardrails -- same bug, same service:

// AI fixes the bug using existing patterns
class ProductService {
  Future<Product> getProduct(String id) async {
    try {
      final response = await _httpClient.get('/products/$id');
      return Product.fromJson(response.data);
    } catch (e) {
      if (e is TypeError) throw ProductNotFoundException(id);
      rethrow;
    }
  }
}
// Bug fixed, existing interface preserved

The second version is not "better code" in the abstract. It is the correct code for this context -- context-dependent correctness.

What AI Is Good At (and Where It Falls Short)

After 827 commits using Claude Code, I have a clear picture of where AI pair programming delivers value and where it does not.

Where it excels

Boilerplate is the obvious one. Clean Architecture is verbose by design -- entity classes, repository interfaces, use cases, data sources, DTOs, mappers, provider declarations. The structure is formulaic. Once the AI has seen two migrated features, it generates the scaffolding for the third with minimal correction.

Test generation is close behind. "Write unit tests for this use case" with the project's testing conventions loaded produces usable tests 80% of the time. The remaining 20% need manual adjustment, usually around edge cases the AI cannot infer from the interface alone.

Pattern consistency is something AI handles better than humans. A developer on their fifteenth provider declaration in a week starts taking shortcuts. The AI does not get tired. Every AsyncNotifier follows the same structure. That consistency compounds over months.

Where it falls short

Architectural decisions remain firmly human territory. "Should we introduce a caching layer here?" depends on traffic patterns, backend SLA, and six other factors the AI cannot observe. It will give you a confident answer. That answer may be wrong.

Business context is invisible to the AI. It does not know that the German market has different legal requirements for price display than the Swiss market, or that certain API fields return stale data because the backend redesign is not finished. These are the things that cause real bugs.

Subtle bugs are the dangerous category. The AI writes code that compiles, passes the tests it generated, and looks correct in review. But it might use the wrong comparison operator for a currency calculation or handle a timezone edge case incorrectly. AI-generated code needs the same scrutiny as human-written code. Arguably more, because its confidence makes it easier to rubber-stamp.

The AI also lacks the judgment to not write code. Sometimes the correct response is "this duplicates existing functionality." The AI will always produce something.

The Real Impact: ~30% Faster, Not Magic

The migration took 22 weeks. Without AI-assisted development, my estimate is 30-32 weeks. That is roughly six to eight weeks saved -- not the ten-times productivity claim you see in conference talks.

The 30% comes from two sources. The mechanical parts of each migration step were faster -- scaffolding, boilerplate, initial test suites. And pattern consistency reduced the review cycle. Fewer "why does this feature handle errors differently?" conversations.

What AI did not speed up: architectural planning, debugging production issues via Crashlytics traces, and the final QA pass on each step.

The honest math: 70% of the speed gain came from boilerplate reduction. 30% came from consistency enforcement. Zero percent came from the AI making better architectural choices than I would have. I applied a similar Claude Code workflow in a serverless-to-monolith migration with comparable results.

If your team is planning a similar migration or evaluating how AI tooling fits into production workflows, I have done this before.

Setting This Up for Your Project

This works for any project, not just Flutter -- I use the same CLAUDE.md and custom skills approach on web apps, backend services, and infrastructure projects. For a broader perspective on AI in app development, see Building Apps with AI.

Start with CLAUDE.md. Document your architecture in machine-readable terms. Not "we prefer clean code" -- the AI does not know what you mean by that. Instead: "Domain layer classes live in lib/features/{name}/domain/. They must not import from data/ or presentation/. Error handling uses TaskEither<AppFailure, T>." Concrete paths. Concrete types. Concrete rules.

Add a decision matrix. If your codebase has multiple styles (most do), codify which style applies when. Write it as a decision tree, not prose.

Create your first custom skill for whatever task you do most often. Start with one. Add more as you identify repeated patterns in your AI interactions.

Run the AI on low-risk tasks first. A utility function. A test for an existing module. Review the output carefully -- import paths, naming conventions, whether it followed the CLAUDE.md rules. Update CLAUDE.md when the instructions are ambiguous. Expand to feature work once the context is dialed in.

The CLAUDE.md is a living document. Mine changed over fifty times during the retailer project. Over ten months, it became a remarkably precise description of the project's architecture. A side effect: it is also the best onboarding document the project has.

What This Means for Teams

The CLAUDE.md and custom skills are project-level configuration, not personal preference. When the entire team uses them, a junior developer using /migration gets the same structural scaffolding as a senior developer. The architecture decisions are encoded in the tooling, not locked inside one person's head.

This shifts code review from "did you follow the pattern?" to "is the business logic correct?" And it forces the team to articulate rules that previously lived as tribal knowledge. "When you fix a bug in legacy code, follow legacy patterns" is a nuanced rule most teams never write down. The AI forces you to write it down, and the whole team benefits.

There is a handover benefit too: the CLAUDE.md and custom skills stay with the codebase. When a freelancer finishes an engagement, the team inherits a precise, machine-readable description of their own architecture. No knowledge walks out the door.

Agentic Coding: Where This Is Heading

The current setup -- AI as a careful assistant with explicit guardrails -- is an intermediate step. The next stage is agentic coding: the AI executes multi-step tasks autonomously, creates files, runs tests, fixes failures, and commits the result.

For me, this is already partially reality in 2026. Claude Code can run a migration end-to-end -- create the file structure, generate the code, write tests, run them, and correct failures. I review the outcome instead of every intermediate step.

But the same principle holds: autonomy without guardrails is dangerous. The more autonomy the AI gets, the more important the architecture rules in CLAUDE.md become. Without them, autonomous coding is just vibe coding with extra steps.

Conclusion

AI-assisted development in production is not about the AI being smart. It is about the developer being deliberate.

In a production codebase, AI without project context generates code that looks right and behaves wrong. Without guardrails, it "improves" code that should not be touched. The infrastructure matters more than the model -- CLAUDE.md, custom skills, explicit rules about which patterns apply where. That is what separates vibe coding from production-grade AI development. When this setup becomes your default rather than an experiment, AI is no longer assisting your development -- it is native to it.

My results on the retailer project: 827 commits, crash-free rate from 85% to past 97%, ~30% faster migration timeline. Not because the AI was magic. Because the AI had context.

The bar for AI-assisted development in 2026 is not "can the AI write code?" It can. The bar is: "can the AI write code that belongs in your codebase?" That takes work. The work is worth it.

I help teams set up AI-assisted development workflows for production codebases. If that is relevant for your project, let's talk.

Frequently Asked Questions

What is the difference between vibe coding and AI-assisted development?

Vibe coding means prompting an AI and committing the output with minimal review or structural guidance. AI-assisted development means providing the AI with explicit project context -- architecture rules, conventions, decision matrices -- so that its output is consistent with the existing codebase. Same models, different infrastructure.

What is CLAUDE.md?

A configuration file that Claude Code reads from your project root at the start of every session. It contains architecture descriptions, naming conventions, import rules, and decision trees that guide the AI's behavior -- project documentation written for the AI.

Can AI coding assistants handle architecture migrations?

With guardrails, yes. Unguided, an AI will try to "improve" all code it touches, creating pattern chaos during a migration. Custom skills and decision matrices in CLAUDE.md constrain the AI to follow the correct patterns for each context.

How much faster is AI-assisted Flutter development?

Roughly 20-30% faster for implementation work. Boilerplate-heavy work sees the biggest gains. Architectural planning, debugging, and QA are not meaningfully faster.

Does this approach work with tools other than Claude Code?

The concepts -- project context files, task-specific configurations, architecture guardrails -- apply broadly. The specific implementation (CLAUDE.md, custom skills) is Claude Code. Other tools have their own mechanisms. The principle is the same: give the AI explicit, machine-readable project context.

DEV Community: Khalit Hartmann

Mobile App Engagement Strategy: How We Fixed a 0.6% Push Notification Open Rate

The numbers that started the conversation

Why push notifications fail to drive app engagement

What receptivity actually means

What is JITAI? A framework from health research

1. Decision points

2. Tailoring variables

3. Intervention options

4. The decision maker

Push notification examples that improve app engagement

The store walk-by

The abandoned cart

The hard parts of this engagement strategy

Privacy and GDPR

Testing tailoring variables

Incomplete data

Where we left off

Key takeaways

Related reading

Further reading

Building Apps with AI: What Actually Works (2026)

What "build an app with AI" actually means

AI as a development tool: what works, what doesn't

Adding AI features to your app: the practical options

Chatbots and text processing

Image recognition and computer vision

Recommendation systems

Speech recognition

What each option costs

No-code AI: building apps without programming

What AI means for costs and timelines

Where AI hits its limits

AI-Assisted Flutter Development: Claude Code in Production

AI-Assisted Flutter Development: Claude Code in Production

Vibe Coding vs. AI-Assisted Development

The Project: 827 Commits, One Codebase

The Context Problem

CLAUDE.md: Your Project's AI Configuration

Custom Skills: Different Tasks, Different AI Behavior

Architecture Guardrails: The Biggest Win

What AI Is Good At (and Where It Falls Short)

Where it excels

Where it falls short

The Real Impact: ~30% Faster, Not Magic

Setting This Up for Your Project

What This Means for Teams

Agentic Coding: Where This Is Heading

Conclusion

Frequently Asked Questions

What is the difference between vibe coding and AI-assisted development?

What is CLAUDE.md?

Can AI coding assistants handle architecture migrations?

How much faster is AI-assisted Flutter development?

Does this approach work with tools other than Claude Code?