When AI writes your Flutter app: what works and what scales

Two talks, one question

At FlutterCon 2026 I sat through two talks that look unrelated at first. One came from an agency that had to rescue an app built entirely by vibe coding. The other came from the Flutter team at Google, explaining why Flutter scales well when AI agents write the code.

Both answer the same question: what happens when AI writes a big chunk of your app?

I work like this every day, so I listened closely.

Part 1: From vibe-coded MVP to production in 90 days

Óscar Martín from Very Good Ventures told the story of taking over Divine, a Flutter reincarnation of Vine. The founder had no Flutter background and built the first version in a few weeks by vibe coding.

It blew up. After a presentation at Web Summit in Lisbon, the 10,000-user TestFlight limit was full within hours.

At the same time, the app was unstable. After a few minutes of scrolling the phone got hot, authentication had issues, and the battery drained.

What vibe coding got right

Martín was clear about the upside:

• A founder with a vision built a working prototype fast.
• Features users asked for on Discord were live the next morning.
• In the end it was proven that people actually wanted the app. A few years ago you'd often spend a year building before finding out nobody cared.

That matches my experience. For validation, quickly built code is gold. I wrote more about this in ship faster instead of perfecting.

What it got wrong

Then Martín looked at the code for the first time. His reaction was a pretty clear "ouch".

• The architecture was all over the place. The video feed existed in six or seven variants, depending on whether you watched videos on your profile or on the home screen.
• The CI/CD pipeline was unreliable. Pull requests deleted tests because nobody trusted them. Many were written only to hit coverage numbers.
• The repository was open source, and the founder sometimes opened more than 10 PRs a day.

According to Martín, agents are very good at extending existing patterns. If the feed was copied once, it gets copied again. Nothing told the agent to reuse the component that already existed.

Architecture matters more than ever

This is the most important point from the first talk for me. Martín says architecture matters more with AI, not less.

His reasoning: even if you don't type the code yourself, your agent does. And it needs a foundation it can replicate. At Very Good Ventures they call this boring code. You open a class and immediately know what it does. The more predictable the structure, the better an agent copies it.

For that they developed an approach called Feature-First Clean Architecture. It mixes classic clean architecture with what they were already doing. The goal is an architecture that works for humans and agents.

I think this is the underrated part. Many people assume AI makes architecture discipline optional. For me it's the opposite. The more code an agent writes, the more clear structure pays off. I covered how I approach this in Flutter in my post on state management in 2026.

No rewrite, just small squads

The obvious question came up: why not rebuild from scratch?

Martín says it was his first thought. But the 10,000 users asked for new features every day. Pausing for a month or two wasn't an option. So they organized differently:

• Small squads of two to three people, for example for accounts, feed, or video player.
• The focus changes weekly. When account bugs are the priority, the video squad uses its time for small refactors and merges two or three feed variants.
• Users don't notice, but the codebase gets cleaner step by step.

He openly says he'd have preferred greenfield. But sometimes the incremental path is the only one you have.

Surviving 30 to 50 PRs a day

With that many pull requests, classic review stops working. In the first week Martín tried to review everything himself and realized he'd do nothing else all day.

So the team changed things:

• Expand CI/CD and lint rules. Anything repeatable belongs in deterministic checks or pre-commit hooks. If you need a refresher: What is CI/CD?
• Agent rules as a second layer. They're not deterministic and sometimes get ignored, but they beat nothing.
• Human reviews focus on architecture. Not "I don't like this line" but: is the feature cut sensibly? Does it fit the structure?
• Agent review via a skill. It costs a lot of tokens, but Martín says it's worth it. His reasoning, roughly: he'd rather spend his time on judgment than on line-level nitpicks.

On top of that came solid contributor docs, because people in the open-source repo worked with their own agents too. Martín estimates that ten humans plus all the agents felt like a hundred participants. Coordination gets more important, not less.

The result: a public release without invite codes in August, a collaboration with Taco Bell, and a stable, growing app. The whole codebase is open source.

Part 2: Why Flutter scales well with AI

The second talk came from Emma Tursky and Carlos Mendoza of the Flutter team. They obviously have a home advantage when it comes to Flutter. I read this as a team defending its own product. Still, a few points stuck with me.

Migration is not scaling

The core line of the talk: AI makes it easy to migrate to a new framework. Flutter makes it easy to scale.

Their argument: an AI rewrite mostly delivers the happy path, meaning layouts, network requests, and boilerplate. A production system holds years of accumulated knowledge, settled debates, and edge cases. If you write it twice, you double that surface.

Then there's drift. Two agents, one for Swift and one for Kotlin, will make slightly different architectural decisions even with identical prompts, according to Tursky. In the end humans have to reconcile that.

Verification is the bottleneck

Generating code is the easy part in 2026. The bottleneck is checking it. An agent needs fast, deterministic feedback.

Tursky compared the two worlds:

• Native: The agent changes Kotlin or Swift and triggers a build. Two to five minutes per cycle. Four debug rounds mean about 20 minutes of waiting. To check the UI, it relies on screenshots and a multimodal model, which is slow and expensive.
• Flutter: Widget tests run headless in milliseconds. Through the Dart VM service and DevTools, the agent can read the actual widget tree instead of guessing from pixels. Hot reload applies changes in under 200 milliseconds and keeps state.

I know this from practice. Hot reload was already why I love Flutter as a human. That the same thing helps agents doesn't surprise me.

Harness over better prompts

Carlos Mendoza stressed that a better prompt doesn't fix the problem. General-purpose coding agents know Flutter only as well as their training data. They reach for deprecated APIs or guess how a package works.

The team's answer is official Dart and Flutter agent plugins with an MCP server and skills that give access to the analyzer and widget inspector. On top of that comes the Skills CLI, which originally came from Serverpod. It lets package authors ship skills directly inside their packages.

That fits what Martín described. His team goes the same way with their own Flutter plugin: best practices as skills so the agent doesn't have to guess.

The Flutter team also measures whether it helps. On a wishlist task, Gemini 3.5 Flash scored 1.4 percentage points higher with the tools, and Gemini 3.1 Pro three points higher. Not a quantum leap, but honestly measured.

Project One Shot

Two Flutter core engineers tested how far agents get on a complex package like Android CameraX. Their lessons:

• Prompting isn't enough. "Be careful with memory leaks" prevents none.
• MCP tools give the model eyes and hands, for example to ask the analyzer whether a class exists.
• Domain skills from package authors prevent misreadings.
• Deterministic guardrails matter: first a failing test, then the minimal change, then tests and linters.

That last principle is identical in both talks. Divine or CameraX, quality comes from the rules around the model, not from the model.

What I take from this

I draw four things from both talks, and this part is my opinion, not the speakers':

1. Vibe coding is a good start and a bad foundation. Great for validating, but plan early for when you clean up. When NoCode or real development fits better is in NoCode vs. real development.
2. Give the agent guardrails. Lint rules, tests, hooks, a clear folder structure. They're not brakes. They're the reason it stays fast.
3. Your job shifts toward judgment. Not "how do I write this" but "should we build this at all". I see this in my own projects too, including as a solo developer.
4. One codebase is an advantage. Especially when agents write code, a single source of truth helps. Whether that has to mean Flutter for every project is another question. I weigh that in native app vs. cross-platform.

Conclusion

AI writes large parts of Flutter apps today, and it works better than many think. But only if you build an environment for it: clean architecture, strict checks, fast feedback.

The Divine story shows that even a chaotic start can be rescued. The Flutter talk shows why the toolchain is a good base for that. Both say the same thing: the model is rarely the problem. The process around it is.

And if you're wondering what AI can sensibly do inside your own app, check my post on AI in app development.

Frequently asked questions (FAQ)

This article was inspired by the talks "Transforming a Flutter App with AI-Generated Code" by Óscar Martín (Very Good Ventures) and "Flutter for Scaling Applications in the AI Era" by Emma Tursky and Carlos Mendoza (Google) at FlutterCon 2026.