DEV Community: Sayed Ali Alkamel

LLM Token Counting Explained: The 30-Year-Old Algorithm Quietly Running Your AI Bill

Sayed Ali Alkamel — Mon, 15 Jun 2026 16:41:00 +0000

TLDR: A token is a subword chunk, typically 3 to 4 characters in English. The algorithm splitting your text into those chunks started as a file compression trick in 1994, was adapted for neural machine translation in 2016, and is now the billing unit for every major AI API. Each provider uses a different tokenizer. The same prompt can produce meaningfully different token counts across GPT, Claude, Gemini, and Llama. Understanding this is not optional if you are building production AI systems.

Where Tokens Actually Came From

Most developers learn about tokens through an API bill. That is the wrong starting point.

The algorithm behind modern LLM tokenization is called Byte Pair Encoding (BPE). Philip Gage introduced it in 1994 in a paper titled “A New Algorithm for Data Compression,” published in The C Users Journal. The idea was simple: scan a binary file for the most frequent pair of adjacent bytes, replace that pair with a single unused byte, repeat until the file is as small as possible.

That is it. A compression trick. Nothing to do with language models.

In 2016, Rico Sennrich, Barry Haddow, and Alexandra Birch published “Neural Machine Translation of Rare Words with Subword Units.” Their core insight was that the same iterative merge logic that compressed bytes could compress characters into subwords for machine translation. Instead of shrinking a file, you were shrinking a vocabulary, and you could represent rare words without an “unknown token” fallback.

That paper became the foundation of how every major LLM today handles text.

How BPE Tokenization Actually Works

Start with individual characters. Find the most frequent pair. Merge them into one token. Repeat until you hit your target vocabulary size.

The interactive animation below walks through this on a real example. Open it in any browser:

Here is the same process as a static diagram for reference:

The key insight: common sequences earn their own token slot through frequency alone. No linguistic rules, no hand-crafted vocabulary. Just counting and merging, over and over.

When GPT-2 shipped, OpenAI extended this to byte-level BPE: the base vocabulary is all 256 possible bytes, which means no text is ever truly “unknown.” Any Unicode input can be represented as a sequence of existing tokens. That was a meaningful leap.

The result is that common English words become single tokens. Rare words, code identifiers, and non-Latin scripts split into multiple tokens. The word “tokenization” is two tokens in OpenAI’s cl100k encoding. The Turkish word for “hello” (merhaba) is three.

Why Token Became the Unit of AI Economics

Language models process text as a flat sequence of integers, one per token. The transformer’s attention mechanism scales quadratically with sequence length, which means longer sequences are exponentially more expensive to compute. Pricing in tokens is not arbitrary: it maps directly to compute cost.

Context windows have grown from 512 tokens in early GPT-1 to 10 million tokens in models like Llama 4 Scout today. That is a 20,000x increase in working memory. But bigger windows are not free. A 1 million token context at Claude’s pricing costs more per call than most developers expect the first time they hit it.

There is also a performance ceiling. A 2023 paper by Liu et al. established what practitioners now call the “lost in the middle” problem: LLMs attend best to content at the start and end of a prompt. Information buried in the center of a long context is processed less reliably, even when it technically fits within the window. Context count is not the same as context quality.

Why Different Providers Count Differently

Every major provider maintains its own tokenizer, trained on its own corpus, with its own vocabulary size and merge rules. The same sentence produces different token counts depending on where you send it.

Provider	Tokenizer	Vocab Size	Offline?
OpenAI (GPT-4o)	tiktoken (o200k_base)	200,000	Yes
OpenAI (GPT-4)	tiktoken (cl100k_base)	100,256	Yes
Meta (Llama 3)	tiktoken-compatible	128,000	Yes
Google (Gemini)	SentencePiece	~256,000	API only
Anthropic (Claude 3+)	Proprietary BPE	Undisclosed	API only
Mistral	SentencePiece	32,000	Yes

The critical column is the last one. Anthropic does not ship a local tokenizer for Claude 3 and later models. The only way to get a ground-truth token count for Claude is through the count_tokens API endpoint, which is free but requires a network call. When that is not suitable, tiktoken works as a close approximation with roughly 5 to 10 percent variance.

The Rules That Actually Matter in Production

Rule 1: 1 token is roughly 4 English characters or 0.75 words.
This is the universal approximation. Divide your word count by 0.75 to estimate tokens quickly.

Rule 2: Non-English text multiplies your token budget.
Non-Latin scripts, especially Arabic, Chinese, and Thai, can produce 2 to 3x more tokens per word compared to English. If your product handles Arabic input and you priced it against English benchmarks, your cost model is wrong.

Rule 3: Code tokenizes differently than prose.
Code identifiers, whitespace, and symbols split unpredictably. A 200-line Python file is not the same token budget as a 200-word paragraph.

Rule 4: Count the full message, not just the user prompt.
System prompts, tool schemas, function signatures, and conversation history all count against your context window and your bill. Developers who only count user input are usually undercounting by 20 to 40 percent.

Rule 5: Fit matters more than size.
A 1 million token window does not mean you should use 900,000 of it. Attention degrades at scale, latency grows, and cost grows linearly. The right context is the minimum that gives the model what it needs.

Counting Tokens in Code

For OpenAI-compatible models, tiktoken is the fastest option and works fully offline:

import tiktoken

enc = tiktoken.get_encoding("cl100k_base")  # GPT-4 and Claude approximation
text = "Your prompt goes here"
token_count = len(enc.encode(text))
print(f"{token_count} tokens")

For Claude’s exact count (requires a network call, but it is free):

import anthropic

client = anthropic.Anthropic()
response = client.messages.count_tokens(
    model="claude-opus-4-6",
    system="You are a helpful assistant.",
    messages=[{"role": "user", "content": "Your prompt goes here"}]
)
print(f"{response.input_tokens} tokens")

For a zero-dependency approximation that works in any language:

def estimate_tokens(text: str) -> int:
    # 4 characters per token is the standard English rule of thumb
    return max(1, len(text) // 4)

What This Means for How You Build

Tokens are not a detail. They are the constraint that determines whether your RAG pipeline fits in a request, whether your agent loop runs for 5 turns or 50, and whether your API bill is $200 or $2,000 at scale.

The 1994 compression algorithm that became BPE was designed to do one thing: make redundant patterns smaller. That is still exactly what it does inside every LLM. Text in, integer sequence out, attention over that sequence, text back out.

Knowing the shape of that pipeline does not make you a researcher. It makes you a builder who does not get surprised by a $4,000 invoice.

Key references:

Gage, P. (1994). “A New Algorithm for Data Compression.” The C Users Journal.
Sennrich, R., Haddow, B., & Birch, A. (2016). “Neural Machine Translation of Rare Words with Subword Units.” ACL 2016.
Liu, N., et al. (2023). “Lost in the Middle: How Language Models Use Long Contexts.” arXiv:2307.03172.
OpenAI tiktoken: github.com/openai/tiktoken
Anthropic Token Counting API: docs.anthropic.com/en/docs/build-with-claude/token-counting

Antigravity 2.0 for Flutter Developers: CLI, SDK & Agentic Workflows That Actually Matter

Sayed Ali Alkamel — Sun, 14 Jun 2026 17:44:43 +0000

TL;DR: Antigravity 2.0 replaces Gemini CLI with a faster Go-based CLI (agy), adds an SDK for custom agent workflows, and ships a Dart & Flutter MCP server that gives agents live context of your running app. The migration deadline is June 18, 2026. The three things that matter most for Flutter devs: AGENTS.md, Agentic Hot Reload, and the Stitch → MCP → Flutter pipeline.

Gemini CLI is being retired on June 18, 2026. If you're a Flutter developer who uses it, you're not just upgrading a tool; you're migrating to a different model of how AI fits into your workflow. Antigravity 2.0, announced at Google I/O 2026 alongside Flutter 3.44, is not a rename. It's four distinct surfaces where one VS Code fork used to be:

Antigravity Desktop: IDE-style editor with an integrated agent panel
Antigravity CLI (agy): terminal-first agent built in Go, fast and scriptable
Antigravity SDK: programmatic API for custom agent workflows
Managed Agents: cloud-isolated Linux environments spun up with a single API call

This article focuses on the three things that give Flutter developers a real, practical edge, not the marketing overview.

1. `AGENTS.md`: Your Project's AI Constitution

What is AGENTS.md? It's a Markdown file you place at the root of your Flutter project. Antigravity reads it at the start of every agent session and uses it as a standing instruction set for the entire project. It replaces the habit of copy-pasting your architecture rules into every prompt.

# Project Agent Rules

- Architecture: Clean Architecture, feature-based folder structure
- State management: Riverpod (prefer AsyncNotifier over FutureProvider)
- Never hardcode colors, always use ThemeData tokens
- Run `flutter analyze` before suggesting any code change
- Target Flutter 3.44+, Dart 3.4+
- Localization: use flutter_localizations, never raw strings in widgets

Drop this in version control. Every developer on your team, and every agent session, starts with the same context. Onboarding a new agent is now the same as onboarding a new developer.

The file is also backward compatible: GEMINI.md is still read, but AGENTS.md takes priority when both exist.

2. Install the Antigravity CLI and Migrate Today

What is agy? It's the Antigravity CLI, a terminal-based agent built in Go that replaces gemini. It's faster, ships with a proper TUI, and shares the same underlying model and plugin system as the desktop app.

# macOS / Linux
curl -fsSL https://antigravity.google/install.sh | bash

# Windows (PowerShell)
irm https://antigravity.google/install.ps1 | iex

# Verify
agy --version  # agy version 2.0.0

If you have existing Gemini CLI config, migration is either automatic on first run (it detects and prompts) or manual:

agy plugin import gemini

Your Agent Skills, Hooks, Subagents, and Extensions (now called Antigravity Plugins) carry over. Global config lives in ~/.antigravity/ going forward.

3. Enable the Dart & Flutter MCP Server

What is the Flutter MCP server? MCP (Model Context Protocol) is a standard for giving an agent live, structured access to your development environment. The Dart & Flutter MCP server lets Antigravity read your widget tree, active routes, Dart analysis output, and running app state, without you pasting code into the chat.

Install it inside Antigravity IDE:

Open the Agent panel with Cmd/Ctrl + L
Search for Dart & Flutter MCP server
Install and restart

Once enabled, the agent can see what's in your running emulator and act on it. This is what makes Agentic Hot Reload work.

4. Agentic Hot Reload: Prompt-to-Emulator in Seconds

What is Agentic Hot Reload? When Antigravity's agent modifies a Flutter file, it triggers Flutter's hot reload automatically. No manual r. No switching windows. You describe a UI change in the Agent panel, the Dart file updates, and the emulator reflects it in place.

Enable it by switching to Agent-driven mode in Antigravity settings. In this mode the agent runs commands (including hot reload) without asking for per-step approval. For production projects, use Review-driven mode instead, with the same capability but the agent pauses and asks before executing commands like flutter pub add or file deletions.

5. The Stitch → Antigravity → Flutter Pipeline

How do you go from a design to a running Flutter app with Antigravity? The workflow the Flutter community has been building around uses three tools in sequence.

Step 1: Design in Stitch

Describe your screen with full context: platform (Android/iOS), design system (Material 3), accessibility requirements, screens, components. Stitch outputs a structured design artifact.

Step 2: Connect via MCP

Export the Stitch output through MCP connectors. This passes the design as structured context into Antigravity's agent, not as a screenshot but as typed design tokens and layout data.

Step 3: Prompt the agent with your architecture

In the Antigravity Agent tab:

Build the habit tracker screen from the Stitch export.
Follow Clean Architecture. Use Riverpod, Material 3 tokens, 
support light and dark mode. No hardcoded strings.

In 10–12 minutes you have runnable Flutter + Dart code. Then flutter run.

What to review manually: Complex async state, platform channels, native plugin integrations, and anything touching sensitive permissions. The agent handles scaffolding well; business logic edge cases still need a human pass.

6. Antigravity SDK: Automate Your Flutter Agent Workflows

What is the Antigravity SDK for? It gives you programmatic access to the same agent harness that powers the desktop and CLI, optimized for Gemini 3.5 Flash (currently the default model, 4x faster than the previous generation, higher benchmark scores). Use it to:

Run a Flutter lint-and-fix agent as a CI step before PR merge
Build a custom agent that understands your design system tokens and enforces them across generated code
Automate multi-step workflows: generate → test → fix → commit, with Managed Agents providing the isolated Linux environment for each run

Managed Agents spin up a full isolated environment with a single API call and maintain persistent state across multi-turn sessions, useful for long-running tasks like migrating a large Flutter codebase to a new API.

Pricing Reference

Plan	Monthly	Usage limit
Free (Individual)	$0	Deprecating June 18, 2026
Google AI Pro	~$20	Standard
AI Ultra	$100	5x Pro limits + Managed Agents

Deadline: Free Gemini Code Assist for individuals stops serving requests on June 18, 2026. You need a plan or the CLI migration before that date.

What This Changes in Practice

Antigravity 2.0 doesn't change what good Flutter code looks like. Clean Architecture is still Clean Architecture. Riverpod still behaves the same way. What changes is how much of the scaffolding and boilerplate you write yourself.

The developers getting the most out of it treat AGENTS.md seriously, use Review-driven mode on anything that touches production, and keep human review on complex state logic and native integrations. The agent is fast at the right things. Know what those things are, and you get the speed without the rework.

Sources: Flutter docs — Antigravity · Flutter docs — Antigravity CLI · Google Developers Blog — Gemini CLI to Antigravity CLI transition · TechCrunch — Google I/O 2026 coverage · MarkTechPost — Antigravity 2.0 full breakdown

I Pointed a Skill Linter at a 52k-Star Repo. Here Is What 84/100 Looks Like.

Sayed Ali Alkamel — Sat, 13 Jun 2026 12:54:57 +0000

Every AI agent skill you write burns context on every turn.

Not just when the skill is running. On every turn. The agent keeps each skill's name and description loaded permanently so it knows when to invoke them. A vague description is not just a documentation problem. It is a tax you pay per message, forever.

That is the problem I built skillscore to catch.

When addyosmani/agent-skills hit 52,000 stars and went to #1 trending on GitHub, I had my benchmark. 24 production-grade skills written by people who clearly know what they are doing. If a static linter has anything useful to say at this level, this is where to find out.

So I ran it.

One command. 24 skills. Two seconds.

This is what skillscore 0.2.0 can do now:

skillscore /path/to/agent-skills/

One command scores everything in the tree. Here is the output:

Three skills from addyosmani/agent-skills scored in one command, then a drill-down into the lowest scorer.

The full results

Skill	Score	Grade
spec-driven-development	91	A
browser-testing-with-devtools	91	A
deprecation-and-migration	91	A
frontend-ui-engineering	91	A
test-driven-development	88	B
code-review-and-quality	88	B
interview-me	86	B
ci-cd-and-automation	85	B
code-simplification	85	B
context-engineering	85	B
documentation-and-adrs	85	B
incremental-implementation	85	B
security-and-hardening	85	B
shipping-and-launch	85	B
source-driven-development	85	B
using-agent-skills	85	B
doubt-driven-development	80	B
observability-and-instrumentation	80	B
planning-and-task-breakdown	80	B
api-and-interface-design	78	C
debugging-and-error-recovery	77	C
git-workflow-and-versioning	77	C
idea-refine	77	C
performance-optimization	77	C

Average: 84/100 (B)

To be clear: 84 across 24 production skills is excellent. No failures. No D grades. Most skill libraries I have tested do not get close to this. The instruction content inside these skills is genuinely good. What the linter found is at the edges, not in the core.

Two gaps. Five skills. Every single C.

I drilled into all five C-grade skills. The same two findings came up in every one of them.

The description does not say when to stop

Every C-grade description says what the skill does. None says when not to use it.

This matters because an agent with no stop condition will stretch a skill to cover loosely related requests. It invokes when it should not. It does not know where the boundary is because you never told it.

The fix is one sentence at the end of the description:

"Do not use when the codebase already has an established pattern for this."

That is it. One sentence. The skill immediately becomes less likely to activate on the wrong request.

Terminal commands with no Safety section

Several of the C-grade skills ship step-by-step terminal commands in the body. None of them has a ## Safety section.

The Antigravity authoring guide requires any skill that runs commands to document what those commands touch, and what the agent must never run unattended. Without that section, the linter applies up to an 8-point penalty. The reason is practical: an agent executing undocumented commands has no signal about blast radius.

Here is what a Safety section looks like:

## Safety

- Never run `git push --force` unattended. Confirm with the user first.
- All destructive commands require explicit confirmation before execution.
- Scripts in scripts/ are reviewed before running, never piped directly to sh.

Five lines. Eight points back.

Add both of those things and every C-grade skill in this dataset moves to B or A territory. The instruction quality is already there. The metadata layer just needed these two signals.

Running it yourself

# Install
dart pub global activate skillscore

# Score your skills
skillscore path/to/your-skills/

# Gate CI (fail if any skill drops below 80)
skillscore skills/ --min-score 80 --format sarif

--format sarif pipes findings into GitHub code scanning so they appear as inline annotations on pull requests. No more "I forgot to check the skill before merging."

If a finding is unclear, skillscore explain <rule-id> prints the full rationale and the guide it came from. Every output line includes the rule ID for exactly this reason.

Fully offline. No API key. Deterministic. The same input always produces the same score, which is the only way to use something in a CI gate.

What this experiment actually proves

The gaps in the C-grade skills are invisible in normal review. If you read performance-optimization cold you would probably call it good, because the instructions are good. A human reviewer is not going to flag the absence of a boundary clause or notice that the Safety section is missing. They are going to read the content and nod.

A linter does not read. It checks. And what it found here is that the most common quality gap in real-world agent skills is not bad instructions. It is the two or three structural signals the agent uses to decide when and whether to invoke the skill at all.

That is a solvable problem. Now you have a number for it.

Try it:

pub.dev/packages/skillscore
github.com/sayed3li97/skillscore
addyosmani/agent-skills — the library used in this post

Official authoring guides

These are the primary sources skillscore's rules are drawn from. Each finding in the tool output cites one of them. Worth reading once if you author skills regularly.

Anthropic — Agent Skills: Best Practices
The canonical guide for Claude Code skills. Covers description quality (action verbs, when-clauses), conciseness (500-line body limit), progressive disclosure patterns, script documentation, and the overall structure of an effective SKILL.md.
platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices

Google Antigravity — Authoring Antigravity Skills (Google Codelabs)
The official hands-on guide for Google Antigravity skills. Covers the Safety section requirement for skills that run commands, the boundary clause ("do not use when..."), and four levels of skill complexity from basic routing to procedural script execution.
codelabs.developers.google.com/getting-started-with-antigravity-skills

Agent Skills Open Standard — Specification
The format specification that all agents implement: Claude Code, Codex, Antigravity, Gemini CLI, Cursor. Defines frontmatter fields, directory structure, optional folders, and progressive disclosure principles.
agentskills.io/specification

skillscore: a CLI that scores your AI agent's SKILL.md 0–100

Sayed Ali Alkamel — Fri, 12 Jun 2026 23:27:22 +0000

A vague AI agent skill is worse than no skill at all — because the agent pays for it in context budget on every single turn, whether it uses it or not. Yet most of us write SKILL.md files by feel and ship them with zero feedback.

So I built skillscore: a command-line tool that statically analyzes any SKILL.md and gives it a 0–100 quality score, a letter grade, and a list of fix-it findings — each one citing the official authoring guide it comes from.

skillscore is an open-source Dart CLI that lints and scores AI agent skills (SKILL.md files) against the Claude, Codex, and Antigravity authoring guides. It runs fully offline, is deterministic, and exits with CI-friendly status codes.

TL;DR

🎯 Scores any SKILL.md 0–100 with a letter grade and actionable findings across 7 categories.
📚 Rules are drawn from the official Anthropic (Claude), OpenAI (Codex), Google (Antigravity), and Flutter skill-authoring guides — and every finding cites its source.
🔌 Offline, deterministic, zero network calls. Same input → same score, every time.
🚦 Built for CI: --min-score 80, JSON output, and SARIF 2.1.0 that annotates pull requests.
⚡ Install: dart pub global activate skillscore → pub.dev/packages/skillscore

Why I built this

AI agent skills are quietly becoming a standard. A skill is just a folder with a SKILL.md — YAML frontmatter (a name and a description) plus a Markdown body of instructions — and optional references/, examples/, scripts/, and assets/ subfolders. Claude Code, Codex, Antigravity, Gemini CLI, and Cursor all read the same format.

Here's the catch that most people miss: an agent keeps every skill's name and description in its context window permanently, so it can decide when to reach for one. A skill with a fuzzy description doesn't just fail to get used — it taxes every prompt and occasionally fires on the wrong request.

The vendors all published authoring guides telling you how to avoid this: front-load triggers, write in the third person, state when not to use the skill, keep the body short, document your scripts. Good advice — scattered across four different documents, none of them enforceable. There was no eslint for skills. So I wrote one.

What is skillscore?

skillscore is a skill linter and SKILL.md validator that turns those authoring guides into 24 concrete, checkable rules. Point it at a file, a skill folder, or a whole monorepo, and it produces a score per skill:

# Install (it's on pub.dev)
dart pub global activate skillscore

# Score a single skill — any name, any location
skillscore path/to/SKILL.md

# Score every skill in a tree
skillscore path/to/skills/

The rules live in 7 weighted categories:

Category	What it checks
A — Frontmatter validity	`---` delimiters, `name` format, `description` present
B — Description quality	states what + when, third person, front-loaded triggers, boundary clause
C — Conciseness	body length, no explainer bloat, no endless "or" chains
D — Structure	progressive disclosure, links one level deep, TOCs on long references
E — Instruction quality	anti-patterns, workflow checklist, feedback loop, code examples
F — Content hygiene	no rotting date references, forward-slash paths, consistent terms
G — Safety & scripts	a penalty (up to −15) when bundled scripts lack docs or a Safety section

100 points are distributed across A–F; category G only bites if your skill ships scripts or terminal commands. Profiles that exclude a vendor-specific rule are normalized back to 0–100, so a score means the same thing on every target.

Does it actually work? Let's score a real one

Here's skillscore run against a genuine skill from the Flutter team's public repo — flutter-add-widget-test/SKILL.md:

flutter-add-widget-test  (SKILL.md)
  Score: 90/100  Grade: A

  A  Frontmatter validity                     15/15  ██████████
  B  Description quality                      21/25  ████████░░
  C  Conciseness & token economy              15/15  ██████████
  D  Structure & progressive disclosure       15/15  ██████████
  E  Instruction quality                      14/20  ███████░░░
  F  Content hygiene                          10/10  ██████████
  G  Safety & scripts                    no penalty

  WARNING E1_anti_patterns  line 8
          Body contains no explicit anti-patterns (no "do not", "never", or "avoid").
          fix: Add explicit prohibitions, e.g. "Never share a WidgetTester across tests."

  INFO    B5_boundary_clause  line 3
          Description has no boundary clause saying when NOT to use the skill.
          fix: Append a boundary, e.g. "Do not use for multi-screen integration tests."

A genuinely good skill, and skillscore says so — but it also pinpoints the two things keeping it off a perfect score: it never tells the model what not to do, and its description doesn't state where the skill stops. Both are real, both are fixable in one line, and both come straight from the published guides.

Want the rationale behind any finding? Ask:

skillscore explain E1_anti_patterns

It prints why the rule exists, the exact fix, and the source guide it's from.

Built for CI

A score you have to eyeball isn't a gate. skillscore is designed to live in a pipeline:

# .github/workflows/skills.yml
- name: Lint agent skills
  run: |
    dart pub global activate skillscore
    skillscore skills/ --min-score 80 --no-color

--min-score 80 → the job exits non-zero if any skill dips below the bar.
--format json → structured output for dashboards.
--format sarif → valid SARIF 2.1.0 that uploads to GitHub code scanning, so findings annotate the exact lines in a pull request.

Exit codes are pipeline-grade: 0 everything passed, 1 a gate failed, 2 a usage error. No flaky LLM in the loop, no network — the same skill always scores the same.

How is this different from just asking an LLM to review my skill?

	skillscore	Vendor schema check	Markdown linter	"Ask an LLM"
Validates frontmatter	✅	✅	❌	⚠️
Scores quality (discoverability, structure, instructions)	✅	❌	❌	✅
Cites a source guide per finding	✅	❌	❌	❌
Deterministic / reproducible	✅	✅	✅	❌
Safe for a CI gate	✅	✅	✅	❌
Offline	✅	✅	✅	❌

An LLM review is great for nuance but non-deterministic — you can't gate a build on it. A schema check tells you the file is valid, not whether it's any good. skillscore fills the gap in the middle, and it pairs nicely with the other two.

It's a library too

The CLI is a thin wrapper over a public Dart API, so you can embed scoring in your own tooling:

import 'package:skillscore/skillscore.dart';

void main() {
  final doc = SkillParser().parseFile('my-skill/SKILL.md');
  final result = Scorer(RuleRegistry()).score(doc, Target.universal);
  print('${result.score}/100 ${result.grade}');
}

FAQ

What is an AI agent skill?
A folder with a SKILL.md manifest (YAML frontmatter + Markdown instructions) that teaches an AI agent a repeatable task. Optional subfolders hold references, examples, scripts, and assets. The format is shared across Claude Code, Codex, Antigravity, Gemini CLI, and Cursor.

Which agents does skillscore support?
All of them — the SKILL.md format is shared. Score against one vendor with --target claude|codex|antigravity, or use the default universal profile, which a portable skill should pass everywhere.

Is it really offline?
Completely. No network calls at runtime, local files only, fully deterministic — the same input always produces the same score and the same finding order.

Does my skill have to be named a particular way?
No. skillscore is name-agnostic: the frontmatter name, the folder name, and the file name are independent, and even non-ASCII folder names work. Rule A2 will still tell you if the name field breaks the official format.

What happens with malformed frontmatter?
No crash. The relevant frontmatter errors are reported, every other rule that can still run does, and you always get a score.

What's next

v0.1.0 is live and the rubric is stable, but it's early. The roadmap: more vendor targets as new guides land, an autofix mode for the mechanical findings (forward slashes, missing TOCs), and a GitHub Action wrapper so CI setup is one line. The rule engine is deliberately simple — a new rule is one class plus one registration — so contributions are welcome, and every rule must cite the published guide it enforces.

Try it

dart pub global activate skillscore
skillscore your-skill/

📦 pub.dev: pub.dev/packages/skillscore
💻 GitHub: github.com/sayed3li97/skillscore

sayed3li97 / skillscore

Lint and score any AI agent SKILL.md against the official Claude, Codex, and Antigravity authoring guides — offline Dart CLI.

skillscore — lint and score AI agent skills (SKILL.md)

skillscore statically analyzes any AI agent skill — a SKILL.md manifest and its folder — and produces a 0–100 quality score, a letter grade and a list of actionable findings, scored against the official skill authoring guides from Anthropic (Claude), Google (Antigravity), and OpenAI (Codex). Offline, deterministic, CI-friendly.

What is skillscore?

skillscore is a skill linter / SKILL.md validator / agent-skill quality checker / AI skill scorer. Agent skills are an open standard — a folder with a SKILL.md (YAML frontmatter + Markdown body) plus optional references/, examples/, scripts/, and assets/ — used by Claude Code Codex, Antigravity, Gemini CLI, and Cursor. Because an agent keeps every skill's name and description in its context budget permanently, a vague or malformed skill is worse than no skill. skillscore catches exactly those…

View on GitHub

If you maintain skills, run it against your SKILL.md and tell me what score you get — and what it got wrong. I want the rules to reflect how people actually author skills, so findings you disagree with are the most useful feedback I can get. And if it saves you a context-budget headache, a ⭐ helps it reach other people building agents.

DiffusionGemma: How Google's New Open LLM Hits 1,000 Tokens/sec and Changes Inference Economics

Sayed Ali Alkamel — Fri, 12 Jun 2026 18:30:19 +0000

TL;DR: Google released DiffusionGemma, an open Apache 2.0 diffusion-based LLM that generates text up to 4x faster than autoregressive models, hitting 1,000+ tokens/sec on a single H100 and fitting in 18 GB VRAM. It trades some accuracy for speed. Here is what that means in practice.

What DiffusionGemma Actually Is

Google DeepMind released DiffusionGemma, the first production-grade open-weight model that applies discrete diffusion to text generation. The same family of techniques behind image generators like Stable Diffusion, now applied to language.

Instead of predicting one token at a time left-to-right, DiffusionGemma fills a 256-token block with noise and iteratively refines the entire block across multiple denoising passes until confidence thresholds are met. It commits roughly 15-20 tokens per forward pass on average, not one.

This is a fundamentally different compute pattern from everything shipping in production today.

The Numbers

Metric	Value
Tokens/sec (H100, FP8, low batch)	1,100+
Tokens/sec (RTX 5090)	700+
Total parameters	25.2B (marketed as 26B)
Active parameters at inference	3.8B
MoE expert config	8 active / 128 total
VRAM required (quantized)	18 GB
Canvas (block) size	256 tokens
Tokens committed per forward pass	~15-20
Max denoising steps	48
Context window	256K tokens
License	Apache 2.0

For context: comparable autoregressive models on the same H100 generate roughly 200-250 tokens/sec. DiffusionGemma is up to 4x faster on throughput. The jump comes from shifting the decode bottleneck from memory bandwidth to compute.

Why the Architecture Matters

DiffusionGemma is a 26B Mixture of Experts (MoE) model built on the Gemma 4 backbone, but it replaces the autoregressive decoder with a diffusion head.

How a single generation works:

The model initializes a 256-token block with random placeholder tokens
It runs up to 48 denoising steps, refining all tokens simultaneously with bidirectional attention (every token attends to every other token in the block)
Tokens that cross an entropy confidence threshold get committed to the KV cache early via adaptive stopping
For sequences longer than 256 tokens, committed blocks are cached and the next block begins

The key difference from GPT-style models: token N can see tokens N+1 through N+256 during generation. This enables genuine self-correction across the block. Autoregressive models structurally cannot do this.

Where It Wins and Where It Does Not

Structural advantages

Code infilling: It sees the code on both sides of the gap before generating the fill, not just the left side
Inline document editing: Revising a paragraph in context of surrounding paragraphs
Real-time latency-sensitive apps: 1,100 tokens/sec on H100 vs ~230 tokens/sec from a comparable autoregressive model
Single-GPU efficiency: 3.8B active parameters means 18 GB VRAM at quantized precision, which fits on an RTX 4090 or 5090

Benchmark trade-offs vs Gemma 4 26B (autoregressive)

Benchmark	DiffusionGemma	Gemma 4 26B
MMLU Pro	77.6%	82.6%
AIME 2026	69.1%	88.3%
GPQA Diamond	73.2%	82.3%
MMMU Pro (Vision)	54.3%	73.8%

Google describes it as experimental. For reasoning-heavy workloads (complex math, multi-step logic, vision understanding) the autoregressive Gemma 4 is still ahead. DiffusionGemma is the right tool when latency and throughput matter more than peak accuracy.

Multi-modal capabilities

The model processes interleaved text, images (5 resolution tiers up to 1120 tokens), and video (up to 60 seconds at 1 fps). It supports OCR, chart comprehension, screen understanding, and handwriting recognition across 35+ languages, with training data covering 140+ languages.

Deploy It in 5 Minutes with vLLM

pip install vllm

vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}' \
  --diffusion-config '{"canvas_length": 256}' \
  --enable-chunked-prefill

The endpoint is OpenAI-compatible. Point your existing client at http://localhost:8000 with no other code changes needed.

Supported inference runtimes: vLLM, Hugging Face Transformers, SGLang, MLX (Apple Silicon), NVIDIA NIM containers, Google Cloud Vertex AI Model Garden.

Fine-Tuning

The ecosystem arrived fast for a day-1 release:

Hackable Diffusion: Google's JAX-based modular research toolbox
Hugging Face Transformers: standard PEFT/LoRA workflows
Unsloth: memory-efficient fine-tuning
NVIDIA NeMo: enterprise training pipelines

A published case study fine-tuned DiffusionGemma on a Sudoku dataset and improved success rate from approximately 0% to 80%. Fine-tuning can also teach the model to stop denoising early when confidence is already high, reducing inference steps further. Autoregressive models have no equivalent lever.

What to Evaluate Right Now

This week:

[ ] Spin up the model on an H100 or RTX 4090 (18 GB VRAM quantized)
[ ] Benchmark it on your actual latency-sensitive workload, not synthetic tasks
[ ] Compare serving cost ($/1M tokens) against your current stack

Next sprint:

[ ] Test code infilling quality in IDE tooling, its structural sweet spot due to bidirectional attention
[ ] If you run real-time chat or inline editing, measure UX metrics, not just accuracy scores
[ ] Follow Unsloth + LoRA support for DiffusionGemma, it is maturing fast

Architecture signal:
This model is built on the same Gemini Diffusion research that will likely inform future proprietary Gemini releases. If diffusion inference stabilizes at this quality level, it rewrites autoregressive serving assumptions at scale.

The Bottom Line

DiffusionGemma is not a production replacement for your current LLM stack today. Accuracy trade-offs are real and Google is transparent about the experimental status.

But the throughput numbers are genuine, the hardware requirements are accessible, and the license is Apache 2.0.

1,100 tokens per second. 18 GB VRAM. Open weights. From Google.

That combination is worth benchmarking on your actual workload this week.

Resources:

Found this useful? Follow for more signal-over-noise breakdowns of AI releases that matter.

How to Write a Flutter Agent Skill That Actually Works: The 2026 Recipe

Sayed Ali Alkamel — Fri, 12 Jun 2026 18:13:04 +0000

TL;DR A great agent skill is not a pile of documentation. It is a tightly scoped SKILL.md with a description engineered for discovery, ruthless conciseness, anti-patterns stated up front, a checklist workflow, and a feedback loop. The format is an open standard that works across Claude Code, OpenAI Codex, Google Antigravity, Gemini CLI, and Cursor. This post synthesizes the official authoring guidance from Flutter, Anthropic, Google, and OpenAI into one recipe, hands you a complete copy-pasteable Flutter skill, and shows you how to actually evaluate it instead of guessing.

In my last article, I wrote about the official Dart and Flutter Agent Skills and why they stop your AI from writing 2022 Flutter. The most common reply I got was some version of the same question:

"Cool. How do I write my own?"

So I went and read the actual playbooks. Not the hot takes, the primary sources: Flutter's skill docs and eval framework, Anthropic's skill authoring best practices, Google's Antigravity skill docs, and OpenAI's Codex skill guide. The good news is they agree on almost everything. The better news is that the gap between a skill that works and a skill that gets silently ignored comes down to a handful of decisions, and most people get them wrong.

Here is the recipe, Flutter-flavored.

Why a bad skill is worse than no skill
The anatomy you need before the recipe
One format, every agent
The recipe: 9 ingredients of a skill that works
A complete Flutter skill you can steal
How to actually evaluate your skill
The security caveat nobody mentions
The honest take from the community
The ship-it checklist
FAQ
Wrapping up

Why a bad skill is worse than no skill

AI agents are generalists. They average across years of Flutter code, much of it deprecated, and hand you the most statistically common answer instead of the currently correct one. The Flutter team named this the knowledge gap: the framework ships features faster than language models can update their training data. Skills exist to close that gap by handing the agent a task-specific, expert workflow.

But here is what nobody tells you. A poorly written skill does not just fail to help. It actively costs you. Every skill's metadata sits in the agent's context budget at all times. A vague skill that never triggers is dead weight. A skill with a fuzzy description that triggers on the wrong tasks is worse, because now your agent is following the wrong playbook with full confidence.

The bar is not "wrote some Markdown." The bar is "the agent reliably finds it, trusts it, and follows it." Everything below is in service of that bar.

The anatomy you need before the recipe

A skill is the simplest possible thing: a folder with one required file.

building-riverpod-async-screens/
├── SKILL.md          # Required: metadata + instructions
├── references/       # Optional: deep-dive docs loaded on demand
├── examples/         # Optional: reference implementations
├── scripts/          # Optional: scripts the agent runs, not reads
└── assets/           # Optional: templates, images

The SKILL.md itself is YAML frontmatter plus a Markdown body:

---
name: building-riverpod-async-screens
description: "Build a Flutter screen that loads async data with Riverpod..."
---

# Building Riverpod Async Screens

[instructions go here]

The magic that makes this scale is progressive disclosure. At startup the agent loads only the lightweight metadata (name, description, path) of every skill. It reads the full SKILL.md only when a task matches, and it reads anything in references/ or examples/ only when the body points it there. If you write Flutter, you already know this pattern: it is deferred loading for the context window. OpenAI, Anthropic, and Google all describe the exact same mechanism.

One format, every agent

This is the part that makes writing a skill worth your time. SKILL.md is an open standard (published at agentskills.io, originated at Anthropic, since adopted across the ecosystem). One skill works almost everywhere:

Tool	Vendor	Where skills live
Claude Code	Anthropic	`.claude/skills/` (project), `~/.claude/skills/` (personal)
OpenAI Codex	OpenAI	`.codex/skills/` (project), `~/.codex/skills/` or `~/.agents/skills/`
Antigravity	Google	`.agents/skills/` (workspace), `~/.gemini/antigravity/skills/` (global)
Gemini CLI	Google	`SKILL.md` standard locations
Cursor / Copilot	Various	supported with manual placement

The Flutter team's installer targets the cross-tool location directly:

npx skills add flutter/skills --skill '*' --agent universal

The --agent universal flag drops everything into .agents/skills, the folder compatible agents auto-discover. Write a skill once, and your whole team gets the same expertise regardless of which agent they prefer. Codex adds a distribution layer on top (it calls the authoring format a "skill" and the installable package a "plugin"), but the core file is identical.

The recipe: 9 ingredients of a skill that works

Every official source converges on these. I have ordered them by how much they matter in practice.

1. The description is 80% of the battle

If your skill does not trigger, it is almost never the instructions. It is the description. This is the single most important line in the entire file, because it is the only part the agent reads when deciding whether to load your skill at all, often choosing from 100+ candidates.

Three rules from the official guidance:

Write in third person. The description is injected into the system prompt. "I can help you build screens" and "You can use this to..." both cause discovery problems. Write "Builds Flutter screens that...".
State what it does AND when to use it. Include concrete trigger words a developer would actually type.
Front-load the key use case. Codex's guide is explicit: put the trigger terms first so matching still works if the description gets truncated. Antigravity recommends adding a "Do not use" clause to stop over-activation.

Compare:

# Weak: vague, no triggers, will rarely fire correctly
description: Helps with Flutter screens.

# Strong: what + when + triggers + boundary
description: Build a Flutter screen that loads async data with Riverpod,
  handling loading, error, and data states with AsyncValue. Use when
  fetching from a repository or API and rendering spinners, retry UI, and
  lists. Do not use for purely static screens with no async data.

2. Be ruthlessly concise

Anthropic puts it perfectly: the context window is a public good. Your skill shares it with the system prompt, the conversation, every other skill's metadata, and the user's actual request. The default assumption must be that the agent is already very smart.

Do not explain what Flutter is. Do not explain what a widget is. Do not define JSON. Challenge every sentence: does the agent really not know this? Keep the SKILL.md body under 500 lines. If it grows past that, split it into references/ files.

<!-- Bad: wastes tokens on what the model already knows -->
Flutter is Google's UI toolkit. A widget is a building block of the UI.
To make a network call, you first need an HTTP client, which is a piece
of software that...

<!-- Good: assumes competence, gets to the point -->
Use the `http` package for REST calls. Wrap responses in a typed model.

3. Match the degrees of freedom to the task

This framing from Anthropic is the one most people miss. Think of the agent as a robot walking a path:

Narrow bridge with cliffs (low freedom): one correct sequence, high cost of failure. Give exact, rigid instructions. Example: "Run exactly dart run build_runner build --delete-conflicting-outputs. Do not modify the flags."
Open field (high freedom): many valid routes, context decides. Give direction and trust the agent. Example: "Structure the feature using the layered approach; choose folder names that fit the existing project."

Fragile, deterministic Flutter operations (code generation, migrations, platform config) want low freedom. Architectural and design decisions want high freedom. Most skills need a mix.

4. Lead with anti-patterns, not just patterns

This is what makes the official Flutter skills so effective, and it is the ingredient that separates a senior skill from a junior one. Do not only say what to do. Ban the wrong instinct explicitly.

The official flutter-build-responsive-layout skill does exactly this. It does not just say "be responsive." It says: do NOT switch layouts on MediaQuery.orientationOf, do NOT check for "phone" vs "tablet", do NOT lock orientation. Those negative rules are what stop the model from reaching for the plausible-but-wrong pattern it learned from a thousand old tutorials.

## Rules

- Use `AsyncValue.when` to render data/loading/error. Never assume data is present.
- Do NOT use `FutureBuilder` for server state. It re-runs on every rebuild
  and causes duplicate network calls.
- Do NOT swallow exceptions or show an infinite spinner on failure.

5. Turn the task into a checklist workflow

For any multi-step task, give the agent a checklist it can copy into its response and tick off. This prevents skipped steps, which is the most common failure mode on complex work. Both Anthropic and Flutter's own skills use this pattern.

## Workflow

Copy this checklist and track progress:

- [ ] Define the immutable data model.
- [ ] Add the repository method returning `Future<Model>`.
- [ ] Create the provider that calls the repository.
- [ ] Build the screen with `ref.watch` + `AsyncValue.when`.
- [ ] Implement the error branch with a retry action.
- [ ] Run `dart analyze` and fix everything. Repeat until clean.

6. Add a feedback loop

The highest-leverage pattern in the entire playbook: run validator, fix errors, repeat. Give the agent an objective check it can run and a rule to keep going until it passes. In Flutter, you have world-class validators for free.

After generating code, run `dart analyze`. If it reports issues, fix them
and run it again. Only present the result when analysis is clean and
`flutter test` passes.

This single habit improves output quality more than almost anything else, because it converts "looks right" into "provably compiles and lints clean."

7. Use progressive disclosure deliberately

Keep the main SKILL.md as a lean overview and push depth into linked files. Three patterns, named by the Antigravity docs:

Router pattern: SKILL.md only. For focused, single-purpose skills.
Reference pattern: SKILL.md + references/. For skills with deep API detail.
Few-shot pattern: SKILL.md + examples/. For skills where output quality depends on seeing worked examples.

Two rules when you split: keep references one level deep from SKILL.md (the agent may only partially read nested files), and add a table of contents to any reference file longer than 100 lines so the agent can see the full scope even on a partial read.

8. Kill time-sensitive information

Never write "before August 2025, use the old API." It rots. Instead, put deprecated guidance in a collapsed "old patterns" section so the current path stays clean while history stays available.

## Old patterns

<details>
<summary>Why not FutureBuilder? (legacy)</summary>

`FutureBuilder` re-runs its future on every rebuild unless cached, causing
duplicate calls. Providers cache and dedupe by default. Prefer providers.
</details>

9. One canonical example beats ten adjectives

If output quality depends on style, show a complete input/output example rather than describing it. The model matches patterns far better than it follows prose. One correct, runnable Dart snippet anchors the entire skill.

A complete Flutter skill you can steal

Here is a full, working skill that bundles every ingredient above. It targets a spot where AI agents reliably write outdated Flutter: loading async data. Drop this into .agents/skills/building-riverpod-async-screens/SKILL.md and it works in Claude Code, Codex, and Antigravity.

---
name: building-riverpod-async-screens
description: Build a Flutter screen that loads async data with Riverpod,
  handling loading, error, and data states with AsyncValue. Use when
  fetching from a repository, API, or database and rendering spinners,
  retry UI, and lists. Do not use for static screens with no async data.
---

# Building Riverpod Async Screens

Wire an async data screen the way a senior Flutter dev would: a typed
provider, `AsyncValue` state handling, and explicit loading/error/data
branches. No raw `FutureBuilder`, no manual `setState` for server state,
no swallowed errors.

## Rules

- Use a `FutureProvider` for read-only data, or an `AsyncNotifier` when the
  screen also mutates state. Do NOT use `StatefulWidget` + `setState` for
  server state.
- Watch with `ref.watch` inside `build`. Use `ref.read` only inside callbacks.
- Render all three states with `AsyncValue.when`. Never assume data exists.
- Always give the error branch a retry path. Do NOT swallow exceptions or
  show an infinite spinner on failure.
- Keep shared providers in their own file: one feature, one providers file.

## Workflow

Copy this checklist and track progress:

- [ ] Define the immutable data model.
- [ ] Add the repository method returning `Future<Model>`.
- [ ] Create a `FutureProvider` (or `AsyncNotifier`) that calls the repository.
- [ ] Build the screen: `ref.watch` the provider, render with `AsyncValue.when`.
- [ ] Implement the error branch with a retry that invalidates the provider.
- [ ] Run `dart analyze` and fix all issues. Repeat until clean.

## Example

// product_providers.dart
final productProvider = FutureProvider.autoDispose<List<Product>>((ref) async {
  final repo = ref.watch(productRepositoryProvider);
  return repo.fetchProducts();
});

// product_screen.dart
class ProductScreen extends ConsumerWidget {
  const ProductScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final products = ref.watch(productProvider);
    return Scaffold(
      appBar: AppBar(title: const Text('Products')),
      body: products.when(
        data: (items) => ListView.builder(
          itemCount: items.length,
          itemBuilder: (_, i) => ListTile(title: Text(items[i].name)),
        ),
        loading: () => const Center(child: CircularProgressIndicator()),
        error: (err, _) => ErrorRetry(
          message: 'Could not load products',
          onRetry: () => ref.invalidate(productProvider),
        ),
      ),
    );
  }
}

Old patterns

Why not FutureBuilder? (legacy)

FutureBuilder re-runs its future on every rebuild unless cached, causing
duplicate network calls. Providers cache and dedupe by default. Prefer
providers for any server state.


Notice how much work the description does, how the rules ban wrong instincts before listing right ones, how the workflow ends in a validator loop, and how the example is complete enough to copy. That is the whole recipe in one file.

## How to actually evaluate your skill

This is the step almost everyone skips, and it is the one that separates a skill that feels good from one that is good. Both Anthropic and the Flutter team are emphatic: do not trust vibes. Measure.

### Build the evaluation first

Anthropic calls this evaluation-driven development, and the order matters:

1. **Find the gap.** Run the agent on a real task with no skill. Document exactly where it fails or writes outdated code.
2. **Write three eval scenarios** that target those failures.
3. **Establish a baseline.** Measure performance without the skill.
4. **Write the minimum instructions** needed to pass.
5. **Iterate.** Re-run, compare to baseline, refine.

This guarantees you are solving a real problem instead of documenting an imaginary one. A simple eval is just structured expectations:

{
  "skills": ["building-riverpod-async-screens"],
  "query": "Build a screen that loads the user's order history from OrderRepository and shows it in a list",
  "expected_behavior": [
    "Creates a FutureProvider or AsyncNotifier that calls OrderRepository, not a StatefulWidget with setState",
    "Renders loading, error, and data states using AsyncValue.when",
    "Includes a retry action in the error branch that invalidates the provider",
    "Generated code passes `dart analyze` with no errors"
  ]
}

Grade it the way Flutter does

The Dart and Flutter teams run an experimental evals framework (open-sourced at the flutter/evals repository) built around critical user journeys: realistic developer tasks rather than toy prompts. They score on two axes, which is a great rubric to copy for your own skills:

Deterministic correctness: does it compile, pass dart analyze, and pass the tests? Objective, machine-checkable.
Qualitative performance: is the reasoning sound, the output concise, the approach safe? Graded by an automated model judge and by expert humans.

For your own skill, that translates to a dead-simple loop: run the task with and without the skill, then ask "did the deterministic checks pass, and is the code meaningfully better?" If the skill does not move either axis, it is not earning its context budget.

Use two agents: author with one, test with the other

Anthropic's most practical tip: develop the skill with one instance (call it the author) and test it with a fresh instance that has no memory of the conversation (the tester). The author helps you write and tighten the SKILL.md. The tester reveals what the instructions actually communicate to a cold agent. When the tester stumbles, bring the specific failure back to the author and refine. Repeat. This observe-refine-test loop is how the official skills were hardened, and it works because the model understands both how to write agent instructions and what an agent needs to receive.

The security caveat nobody mentions

Skills can include scripts and reference external resources. That means an untrusted skill can introduce vulnerabilities or quietly exfiltrate data. Before you install a community skill, read it, the same way you would read a dependency before adding it to pubspec.yaml. For any skill that runs terminal commands or touches infrastructure, add an explicit "Safety" section documenting exactly what it does. Treat skills as code, because they are.

The honest take from the community

When the official skills dropped, the Flutter corner of X and Reddit reacted the way it always does: screenshots, threads, and declarations that AI coding just changed again. I want to be straight, because the skeptics have a point worth hearing.

More than one experienced Flutter dev read the actual skill files and came away underwhelmed, noting the initial set is fairly thin and covers ground a competent dev already knows. That is fair. And it is also the wrong frame.

A skill is not a magic file that makes your agent brilliant. It is a discipline. The value is not in any single skill the Flutter team shipped. It is in the workflow the format unlocks: codify a pattern once, evaluate it, refine it on a loop, and every future session inherits it. The teams that win with AI in 2026 are not the ones with the best model. They are the ones who got good at writing down what they already know, then testing that the agent actually follows it.

That is the real reason to learn this recipe. Not to consume the official skills, but to write the ones your team actually needs.

The ship-it checklist

Before you commit a Flutter skill, verify:

[ ] Description is third person, states what AND when, and front-loads trigger words.
[ ] Description has a "Do not use" boundary to prevent over-activation.
[ ] SKILL.md body is under 500 lines; depth is in references/ or examples/.
[ ] No content explaining things the model already knows.
[ ] Anti-patterns are stated explicitly, not just the happy path.
[ ] Multi-step work is a copyable checklist.
[ ] There is a validator loop (dart analyze / flutter test).
[ ] No time-sensitive info outside a collapsed "old patterns" section.
[ ] At least one complete, runnable example.
[ ] References are one level deep; long ones have a table of contents.
[ ] At least three eval scenarios exist and the skill beats the no-skill baseline.
[ ] Any scripts are audited and documented for safety.

FAQ

What is a Flutter agent skill?
A folder containing a SKILL.md file that gives an AI coding agent task-specific, expert instructions for a Flutter or Dart workflow. It loads on demand via progressive disclosure, so it adds expertise without permanently bloating the context window.

What makes an agent skill good?
A precise, trigger-rich description (the single biggest factor), ruthless conciseness, explicitly stated anti-patterns, a checklist workflow, a validator feedback loop, and at least one complete example, all verified against evaluations rather than vibes.

How do I write the description so the skill actually triggers?
Third person, state both what the skill does and when to use it, front-load the trigger words a developer would type, and add a "Do not use" clause to prevent it firing on the wrong tasks.

How do I evaluate a skill?
Build evals before writing docs. Run the task without the skill to establish a baseline, write three scenarios with expected behaviors, then measure deterministic correctness (compiles, passes dart analyze and tests) and qualitative quality against that baseline.

Does a skill I write for Claude Code work in Codex and Antigravity?
Yes. SKILL.md is an open standard. Skills that stick to the core format (frontmatter plus Markdown instructions) work across Claude Code, Codex, Antigravity, Gemini CLI, and Cursor. Only advanced, tool-specific features need adjustment.

How is a skill different from a rules file or AGENTS.md?
Rules and AGENTS.md are always-on, repository-wide instructions (setup commands, standards). A skill is loaded only when its description matches the current task. Use always-on files for global rules and short if/then triggers, and skills for specific, repeatable workflows.

How long should a SKILL.md be?
Keep the body under 500 lines. If it grows past that, move depth into one-level-deep references/ files and keep the main file as a lean overview.

Wrapping up

The official Dart and Flutter skills are a starting point, not the destination. The real unlock is the recipe behind them: a discovery-optimized description, concise expert instructions, anti-patterns stated out loud, a checklist, a validator loop, and an evaluation that proves it works. Get those right and you can encode your team's hardest-won Flutter patterns into something every agent on the team follows automatically.

Write one skill this week. Pick the task where your AI agent annoys you most, encode the correct pattern, and evaluate it against the no-skill baseline. Then tell me what you built. I read every comment, and I want to know which Flutter pattern you taught your agent first. 🥊

Sources: Flutter docs: Agent skills and AI Evaluations, flutter/skills, Anthropic: Skill authoring best practices, Google Antigravity skills docs, and OpenAI Codex: Agent skills.

Flutter Agent Skills: How to Make Your AI Agent Actually Good at Flutter

Sayed Ali Alkamel — Fri, 12 Jun 2026 15:58:16 +0000

TL;DR: Your AI coding assistant is a generalist. It writes Flutter that looks right but quietly reaches for 2022 patterns. Agent Skills are a new, official way (from the Dart and Flutter teams) to hand your agent task-specific, battle-tested workflows it loads on demand. Two repos, flutter/skills and dart-lang/skills, ship ready-to-use skills for responsive layouts, routing, testing, localization, static analysis, and more. Install in one command:
npx skills add flutter/skills --skill '*' --agent universal
npx skills add dart-lang/skills --skill '*' --agent universal
This post breaks down what they are, how they differ from rules files and MCP, the full catalog, what a real skill looks like under the hood, and whether they actually move the needle. (Spoiler: mostly yes, with one honest caveat.)

Let me tell you about a fight I have almost every day.

I ask my AI agent to make a screen adapt to tablets. It confidently hands me code that switches layout based on MediaQuery.orientationOf(context). It looks clean. It compiles. It even runs. And it's wrong, because device orientation has nothing to do with how much window space your app actually has on a foldable, in split-screen, or in a resizable desktop window.

The model isn't dumb. It's a generalist trained on a giant pile of Flutter code, much of it old. And here's the uncomfortable truth the Flutter team said out loud when they launched this feature: Flutter and Dart ship new features faster than LLMs can update their training data. That lag has a name, the knowledge gap, and it's why your agent keeps writing rookie Flutter with a straight face.

Agent Skills are the Flutter team's answer to that gap. I've been running them on real projects, and they're one of the few "AI workflow" things in 2026 that earned the hype instead of borrowing it. Let's get into it.

The real problem: your AI is a generalist
What are Agent Skills, exactly?
Skills vs Rules vs MCP: who does what
The full catalog: every official Flutter and Dart skill
Anatomy of a skill: what's actually inside that file
Get it running in two minutes
The honest take: hype or substance?
Write your own skill
FAQ
Wrapping up

The real problem: your AI is a generalist

AI agents can write Flutter and Dart. That's not in question anymore. The problem is which Flutter they write.

A generalist model has seen a million Stack Overflow answers, half of them deprecated. So when you ask for something specific, it averages across years of patterns and hands you the most statistically common answer, not the currently correct one. You get:

Layouts keyed off device type ("phone" vs "tablet") instead of available space.
Locked orientations that letterbox your app on foldables.
Hand-rolled fromJson that drifts from your actual model.
Routing glued together imperatively when your app needed deep links and browser history.
Hallucinated APIs that were never real, delivered with total confidence.

You already know this dance. You ask, it answers, you spend ten minutes correcting it back to what a senior Flutter dev would have written in the first place. Multiply that across a week and the "productivity tool" is quietly taxing you.

Agent Skills attack this at the source: instead of hoping the model remembers the right pattern, you give it the right pattern as a repeatable workflow.

What are Agent Skills, exactly?

An Agent Skill is a folder of plain-Markdown instructions, a SKILL.md file plus any supporting resources, that teaches an AI agent how to do one specific job the way a professional would.

Think of it as a task-oriented blueprint. Not "here's everything about Flutter," but "here is the exact, correct, step-by-step way to build an adaptive layout, including the traps to avoid and a checklist to verify you're done."

The mechanism that makes this practical is something the Flutter team calls progressive disclosure, and if you write Flutter you already understand it intuitively: it's deferred loading for your context window.

Here's the idea. Your agent doesn't slurp every instruction from every skill into its context up front. That would torch your token budget and bury the signal. Instead:

The agent reads only the lightweight metadata of each skill first (a name and a short description of when to use it).
When a task actually matches (say, you ask for a responsive layout), it pulls in the full instructions for that one skill, on demand.

Lazy-loaded expertise. The agent stays lean until the moment it needs to be an expert, then loads exactly the right playbook. That's the whole trick, and it's why this scales to dozens of skills without drowning the model.

Skills vs Rules vs MCP: who does what

This is where most people get confused, because Flutter now gives you three ways to steer an AI agent. They're not competitors; they're layers. Here's the mental model I use:

Layer	What it is	What it controls	Analogy
Rules files	Persistent project-wide config (e.g. an AI rules file)	The agent's general behavior across every task	The house style guide that's always in effect
Agent Skills	Task-specific `SKILL.md` workflows, loaded on demand	The step-by-step know-how for one specific job	The expert playbook you open for a specific task
MCP (Dart & Flutter MCP server)	A server exposing real tools to the agent	The machinery: hot reload, runtime errors, analysis	The power tools in the workshop

The cleanest way to say it: MCP gives the agent the tools. A Skill teaches the agent how to use those tools correctly for a specific task. Rules set the tone for everything.

In practice they stack beautifully. The MCP server lets the agent connect to your running app and hot reload after a change. A skill tells it when and why to do that as part of, say, fixing a layout overflow. Rules keep the whole thing consistent with your project's conventions. Together, that's an agent that behaves less like an intern and more like a teammate who's read your codebase's standards.

The full catalog: every official Flutter and Dart skill

Both repos are maintained by the actual Dart and Flutter teams and licensed BSD-3-Clause, so this isn't some random community dump; it's first-party guidance. Here's what shipped.

Flutter skills (`flutter/skills`)

Skill	What it does
`flutter-build-responsive-layout`	Build layouts that adapt to window space using `LayoutBuilder`, `MediaQuery`, `Expanded`/`Flexible`
`flutter-fix-layout-issues`	Diagnose and fix overflows and unbounded-constraint errors ("RenderFlex overflowed", etc.)
`flutter-apply-architecture-best-practices`	Structure the app in the recommended layered approach (UI, Logic, Data)
`flutter-setup-declarative-routing`	Wire up `MaterialApp.router` with `go_router` for deep linking and browser history
`flutter-implement-json-serialization`	Generate `fromJson`/`toJson` model classes correctly
`flutter-use-http-package`	Make GET/POST/PUT/DELETE calls to REST APIs with the `http` package
`flutter-setup-localization`	Add `flutter_localizations` + `intl`, configure `l10n.yaml`, scaffold translations
`flutter-add-widget-test`	Write component tests with `WidgetTester` for rendering and interactions
`flutter-add-widget-preview`	Add interactive widget previews via the `previews.dart` system
`flutter-add-integration-test`	Configure Flutter Driver and turn agent UI actions into permanent integration tests

Dart skills (`dart-lang/skills`)

Skill	What it does
`dart-run-static-analysis`	Run `dart analyze` and auto-apply mechanical fixes with `dart fix --apply`
`dart-fix-static-analysis-errors`	A workflow for hunting down and fixing analyzer errors after edits
`dart-fix-runtime-errors`	Pull an active stack trace, locate the failing line, fix it, verify via hot reload
`dart-add-unit-test`	Write and organize unit tests with `package:test`
`dart-generate-test-mocks`	Generate mocks with `package:mockito` + `build_runner`
`dart-collect-coverage`	Collect coverage with the `coverage` package and emit an LCOV report
`dart-resolve-package-conflicts`	Fix `pub get` version conflicts
`dart-build-cli-app`	Build CLI utilities: entrypoint structure, exit codes, cross-platform scripts
`dart-use-pattern-matching`	Apply switch expressions and pattern matching where they belong
`dart-migrate-to-checks-package`	Migrate assertions from `package:matcher` to `package:checks`

Look at that list as a Flutter dev and the value clicks immediately: these are exactly the tasks where a generalist model fumbles the current best practice. Adaptive layout. Routing. Localization. Serialization. The unglamorous, easy-to-get-subtly-wrong stuff.

Anatomy of a skill: what's actually inside that file

"A Markdown file" sounds underwhelming until you open one. Let me show you the flutter-build-responsive-layout skill, because it's the perfect rebuttal to that orientation bug I opened with.

A skill is structured guidance: rules, anti-patterns, workflows-as-checklists, and runnable examples. Here's the core of what this one teaches the agent:

The non-negotiable rules:

Use MediaQuery.sizeOf(context) to measure the app window, not the physical device.
Use LayoutBuilder and branch on constraints.maxWidth.
Do not use MediaQuery.orientationOf or OrientationBuilder near the top of the tree to swap layouts; orientation doesn't reflect available window space.
Do not check hardware type ("phone" vs "tablet"). Flutter runs in resizable windows, split-screen, and picture-in-picture.
Internalize the core rule: Constraints go down. Sizes go up. Parent sets position.
Don't lock orientation. It letterboxes your app on foldables and large-screen Android tiers.

That's a senior Flutter dev's hard-won instinct, written down where the model can't ignore it.

A workflow as an explicit checklist (the agent literally walks this):

[ ] Identify the widget that needs adaptive behavior.
[ ] Wrap the tree in a LayoutBuilder.
[ ] Extract constraints.maxWidth from the builder callback.
[ ] Define a breakpoint (e.g. largeScreenMinWidth = 600).
[ ] If maxWidth > breakpoint: return the large-screen layout (Row + sidebar).
[ ] Else: return the small-screen layout (Column / standard nav).
[ ] Run validator -> resize the window -> review transitions -> fix overflows.

And a runnable reference example:

import 'package:flutter/material.dart';

const double largeScreenMinWidth = 600.0;

class AdaptiveLayout extends StatelessWidget {
  const AdaptiveLayout({super.key});

  @override
  Widget build(BuildContext context) {
    return LayoutBuilder(
      builder: (context, constraints) {
        if (constraints.maxWidth > largeScreenMinWidth) {
          return _buildLargeScreenLayout();
        } else {
          return _buildSmallScreenLayout();
        }
      },
    );
  }

  Widget _buildLargeScreenLayout() {
    return Row(
      children: [
        const SizedBox(width: 250, child: Placeholder(color: Colors.blue)),
        const VerticalDivider(width: 1),
        Expanded(child: const Placeholder(color: Colors.green)),
      ],
    );
  }

  Widget _buildSmallScreenLayout() => const Placeholder(color: Colors.green);
}

See what happened? The skill doesn't just say "be responsive." It bans the exact wrong instinct (orientation), prescribes the right one (constraints.maxWidth), hands over a verification loop, and gives a canonical example. The agent stops guessing and starts executing a known-good plan. That's the difference between "AI that writes Flutter" and "AI that writes your team's Flutter."

Get it running in two minutes

The skills are distributed through an npx CLI, so you'll need Node.js installed. From your project root:

# All Flutter skills
npx skills add flutter/skills --skill '*' --agent universal

# All Dart skills
npx skills add dart-lang/skills --skill '*' --agent universal

A couple of things worth knowing:

The --agent universal flag drops everything into the standard .agents/skills directory, the folder that compatible agents auto-discover. Commit it, and your whole team (and CI) inherits the same expertise.
Want a subset instead of '*'? Swap in a specific skill name, e.g. --skill flutter-build-responsive-layout.
Update later with npx skills update.

Once they're installed, my favorite first move is to just ask the agent what it's now capable of:

"Review my .agents/skills directory. Which installed skills can help with making this dashboard work on tablet and desktop?"

It'll surface flutter-build-responsive-layout, explain the plan, and you're off; no guessing which incantation to type.

The honest take: hype or substance?

When these dropped, the Flutter corner of X and Reddit did what it always does: screenshots, "AI coding just changed again," the works. I want to be straight with you, because hype helps no one.

The substance is real. This isn't a vibe. It's first-party, task-scoped guidance that demonstrably stops common, current mistakes, and because of progressive disclosure it does so while lowering token usage and raising accuracy. For the unglamorous 80% of app work (layouts, routing, serialization, localization, tests), it's a genuine upgrade. I've shipped cleaner first drafts because of it.

Here's the caveat. Skills are guardrails, not a brain transplant. They make your agent reliably correct on known tasks; they don't make it inventive on novel architecture, and they won't save a vague prompt. The initial set is deliberately scoped to "the most common hurdles"; the Flutter team has been explicit that this is a starting point, not a finished product, and they're openly asking the community to file issues and contribute more.

So the right framing isn't "AI can now build my app." It's: your agent just stopped failing the easy stuff, so you can spend your judgment on the hard stuff. That's a trade I'll take every single day.

If you're already using Cursor, Claude Code, Antigravity, or any agent that reads .agents/skills, there's basically no reason not to try this on your next task.

Write your own skill

Once you feel the difference, you'll want to encode your team's patterns: your state management choice, your folder conventions, your API client. Because a skill is just a Markdown folder, that's very doable. The shape that works:

Create the folder under .agents/skills/your-skill-name/ with a SKILL.md inside.
Write tight metadata. A name and a one-line "use this when…" description. This is the part the agent reads first, so make the trigger condition unambiguous.
State the rules and anti-patterns. Don't just say what to do; say what not to do. The "don't use orientation" line is what makes the responsive skill bulletproof.
Add a workflow checklist. Spell out the steps as a literal task list the agent can march through and self-verify.
Include a runnable example. One canonical, correct snippet is worth a thousand adjectives.

Then evaluate it like code: try it, watch where the agent still drifts, tighten the wording, repeat. Treat skill-writing as a loop (create, test, refine), not a one-and-done config file. The teams that win with AI in 2026 aren't the ones with the best model; they're the ones with the best-encoded knowledge.

FAQ

What are Flutter Agent Skills?
They're folders of Markdown instructions (SKILL.md files) that give an AI coding agent task-specific, expert Flutter and Dart workflows. They're maintained officially by the Dart and Flutter teams in the flutter/skills and dart-lang/skills repositories.

How are Agent Skills different from a rules file?
Rules configure the agent's general behavior across all tasks. A skill gives step-by-step instructions for one specific job, and is loaded only when that job comes up.

How do skills relate to the Dart & Flutter MCP server?
MCP provides the tools (hot reload, runtime errors, analysis). Skills provide the know-how to use those tools correctly. They're complementary layers, not alternatives.

Where do skills get installed?
Into the .agents/skills directory in your project, which compatible agents discover automatically. Use npx skills add ... --agent universal to target that standard location.

Do I need anything special to install them?
Just Node.js, since the skills CLI runs via npx.

Does this only work with one specific AI tool?
No. The .agents/skills convention is designed to be picked up by compatible agents broadly, which is the point of the universal flag.

Will skills make my AI write perfect apps?
No, and that's the honest part. They make it reliably correct on common, well-defined tasks. Novel architecture and vague prompts are still on you.

Wrapping up

The story of AI-assisted Flutter in 2026 isn't "the model got smarter." It's "we got better at telling the model what we already know." Agent Skills are the cleanest expression of that shift I've seen: take the hard-won patterns a senior Flutter dev carries in their head, write them down once, and hand them to your agent exactly when they're needed.

Install the official sets, ask your agent which skills apply to your current task, and watch the rookie mistakes quietly disappear. Then start encoding your own. That's where the real leverage is.

If you try this, I want to hear how it goes, especially which skill saved you the most correcting. Drop it in the comments, and if this was useful, follow me for more on Flutter, Dart, and building with AI agents without losing the plot. 🥊

Sources: Flutter docs: Agent skills, flutter/skills, dart-lang/skills, and the official Dart & Flutter team launch announcement (May 2026).

[Boost]

Sayed Ali Alkamel — Thu, 11 Jun 2026 11:12:45 +0000

Sayed Ali Alkamel

Jun 11

Agentic Flutter Development: Your AI Agent Just Got Hot Reload 🔥

#flutter #ai #dart #mcp

10 min read

Agentic Flutter Development: Your AI Agent Just Got Hot Reload 🔥

Sayed Ali Alkamel — Thu, 11 Jun 2026 11:12:22 +0000

Fellow denizens of the digital age: your Flutter app has spent its entire life as a sealed aquarium.

You could watch the fish swim. Your tools could watch. But the AI "assistant" next to you was functionally blind. It wrote code about your app without ever seeing it run. It suggested a fix, you copy-pasted, hot-reloaded, squinted at the simulator, described what broke, and repeated.

You weren't pair programming. You were a courier.

Agentic Flutter development is what happens when someone hands the AI a key to the aquarium. And in 2026, Google didn't just hand over the key. They shipped it in the SDK.

TL;DR

Agentic Flutter development means AI agents that analyze, edit, run, observe, and fix Flutter apps in a closed feedback loop, not just generate code snippets.
The official Dart and Flutter MCP server (Dart 3.9+ / Flutter 3.35+) exposes the analyzer, hot reload, widget inspection, screenshots, tests, and pub.dev search to any MCP-compatible agent.
Flutter 3.44, released at Google I/O 2026, introduced Agentic Hot Reload: agents auto-discover your running app and reload it after every edit.
The Flutter team's April 2026 strategy post reports that 79% of Flutter developers already use AI assistants, while a 46% trust gap remains around AI accuracy.
The Flutter Extension for Gemini CLI (launched October 2025) bundles the MCP server with commands like /create-app, /modify, and /commit.
It works with Claude Code, Cursor, Antigravity, Gemini CLI, and any client speaking MCP over stdio.

What Is Agentic Flutter Development?

Agentic Flutter development is a workflow where AI agents use the Model Context Protocol (MCP) to directly operate Flutter's developer tools: running the analyzer, editing code, triggering hot reload, inspecting widgets, and reading runtime errors. The agent completes tasks autonomously in a closed feedback loop instead of merely suggesting code for a human to apply.

That's the citable definition. Now the planetarium version.

For a decade, hot reload was Flutter's superpower. For humans. Sub-second feedback made us faster than everyone else at the UI game.

Agentic development asks a deliciously simple question: what if the agent gets the superpower too?

The answer arrived in stages. First, the Dart team shipped an experimental MCP server exposing the full toolchain. Then Flutter 3.44 landed at Google I/O on May 19, 2026, and the Dart Tooling Daemon started automatically advertising your running app's connection to the MCP server. Now an agent edits your code, the app reloads itself, the agent looks at the result, and iterates.

The aquarium is open.

How Does Agentic Flutter Development Actually Work?

The MCP server is the agent's nervous system

One sentence first: the Dart and Flutter MCP server translates between "agent speak" (MCP tool calls) and Flutter's actual developer tooling.

MCP is often described as USB-C for AI. One standard port, any agent can plug in. Through it, agents can analyze and fix errors, resolve symbols, hot reload, capture screenshots, inspect the selected widget, manage pubspec.yaml, run tests, and search pub.dev.

Pause on that last one. Community doc servers cover over 50,000 packages on pub.dev. If you spent just ten minutes evaluating each package, that's 500,000 minutes. Roughly 347 days of non-stop, no-sleep package review. Nearly a year of your life.

The agent queries it in seconds.

The closed loop, step by step

Here's the anatomy of an agentic fix, in order:

You say: "The checkout screen overflows on small phones. Fix it."
The agent calls the MCP server to fetch runtime errors from your running app.
It inspects the widget tree, takes a screenshot, and reads the actual RenderFlex overflow.
It edits the code and triggers hot reload through the Dart Tooling Daemon. No human courier.
It re-screenshots, verifies the fix visually, then runs the analyzer and your tests.
It reports back, ideally with the smugness disabled.

Think of the MCP server as a hospital intercom. The agent doesn't wander the halls; it pages exactly the instrument it needs. Technically, what's happening is JSON-RPC tool invocations over stdio, with the tooling daemon brokering access to the VM service of your live app.

Setting it up takes one config block

It works with Claude Code, Cursor, Windsurf, and friends. For Claude Code, drop this into your project's .mcp.json (requires Dart 3.9+ on your PATH):

{
  "mcpServers": {
    "dart": {
      "command": "dart",
      "args": ["mcp-server"]
    }
  }
}

For Gemini CLI, one command installs the Flutter extension and auto-configures the MCP server:

# Requires Gemini CLI installed; extension is experimental (alpha)
gemini extensions install https://github.com/gemini-cli-extensions/flutter

Now, I know what you're thinking: "Sayed, isn't this just vibe coding with extra steps?"

Fair question. Here's where it gets interesting. Vibe coding is open-loop: the model guesses and you pray. Agentic development is closed-loop: every change gets checked against the analyzer, the test suite, and the actual rendered pixels of a running app. It's the difference between throwing darts blindfolded and throwing darts while watching the board.

Which Agentic Flutter Tools Should You Use?

As of June 2026, here's the honest landscape:

Tool	Maintainer	Requirements	Standout capability	Status
Dart & Flutter MCP server	Google (Dart/Flutter teams)	Dart 3.9+ / Flutter 3.35+	Full first-party toolchain: analyzer, hot reload, widget inspection, tests	Experimental, official
Flutter Extension for Gemini CLI	Google	Gemini CLI; auto-configures MCP server	`/create-app`, `/modify`, `/commit` workflow commands	Alpha (launched Oct 2025)
Agentic Hot Reload	Google (Flutter 3.44)	Flutter 3.44 (May 19, 2026)	Auto-discovers running app, zero-config reload after agent edits	Stable in 3.44
`mcp_flutter` (Arenukvern)	Community	Flutter app + package	27 tools incl. semantic snapshots, tapping widgets, typing into forms	Active, community
`flutter-mcp` (adamsmaka)	Community	Any MCP client	Version-accurate docs for 50,000+ pub.dev packages (kills hallucinated APIs)	Active, community

Notice the pattern: the official server controls your tools, while the strongest community servers let agents control your app itself or ground them in accurate documentation. They stack beautifully.

Why Should Flutter Developers Care About Agentic Development?

The numbers say you mostly already do. The Flutter team reports 79% of Flutter developers use AI assistants. In a ten-person standup, that's eight of you. The question is no longer adoption. It's depth.

Imagine a design-system migration where the agent doesn't just rewrite 200 widget files. It hot-reloads after each batch, screenshots golden screens, and flags the three that visually regressed. Overnight. While you sleep, it works the backlog.

Imagine onboarding a junior developer whose "senior pair" answers "why is this screen janky?" by actually attaching to the running app and reading the raster stats, instead of pasting a generic performance checklist.

Imagine killing the manual tax you pay today. An agent iterating 40 times on a tricky UI costs you roughly 90 seconds of copy-paste-reload-describe per round. That's 3,600 seconds. A full hour of being a courier, eliminated per feature. Meanwhile, on a 120Hz display, every time you blink (about 300ms), Impeller has already drawn 36 frames. The machines were never the bottleneck. The ferrying was.

And the direction of travel is explicit. Mariam Hasnany of the Flutter team laid out the 2026 strategy around three personas (traditional, AI-assisted, and AI-first developers), anchored by principles like "Humans first" and "Add, don't replace": Dart stays readable for people even when agents write it. The team is also collaborating on guidance for Flutter with Antigravity and the "Vibe once, deploy everywhere" concept introduced at Google I/O 2025.

The official account has been beating this drum publicly too:

// Detect dark theme var iframe = document.getElementById('tweet-1979230928820908084-856'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1979230928820908084&theme=dark" }

Limitations and Honest Caveats

1. Almost everything here is labeled experimental or alpha. The official MCP server is explicitly experimental and evolving quickly; the Gemini CLI extension is alpha. APIs will shift under you. Pin versions. Read changelogs.

2. The trust gap is real and measured. The same Flutter team post that celebrates 79% adoption reports a 46% trust gap around AI accuracy. Agents confidently invoke deprecated APIs. That's precisely why doc-grounding servers exist.

3. Closed loops amplify both quality and mistakes. An agent that can edit, reload, and "verify" can also convince itself a wrong fix worked because the screenshot looked fine. Visual confirmation is not semantic correctness. Your test suite is now load-bearing infrastructure for your AI teammates. Write it accordingly.

4. Cost and security. Agents that think before every tool call burn tokens. And an agent with shell access plus a live VM service connection deserves the same scrutiny you'd give a new hire with prod credentials.

And the humility beat, because you've earned it. Honestly? Nobody knows where the reliability ceiling for these agents lands. Not Google, not the MCP authors, not me. That 46% trust gap isn't a marketing problem to message away; it's an open research question we're all living inside. And that should excite you, because the people figuring it out in public are the ones writing the next decade's best practices.

How to Get Started With Agentic Flutter Development

Time to first agentic hot reload: about 15 minutes.

Upgrade: flutter upgrade. You want Flutter 3.44+ for Agentic Hot Reload (minimum Dart 3.9 / Flutter 3.35 for the MCP server).
Pick a client: Claude Code, Cursor, Gemini CLI, or Antigravity.
Wire the server: add the .mcp.json block above, or run gemini extensions install https://github.com/gemini-cli-extensions/flutter.
Run your app with flutter run. On 3.44 the tooling daemon exposes the connection automatically.
Give it a real task: "Find and fix the overflow on the settings screen, verify with a screenshot, then run the tests." Watch the loop close.
Add guardrails: a strong analysis_options.yaml, meaningful tests, and an AGENTS.md or CLAUDE.md describing your conventions.

FAQ

Does the Dart and Flutter MCP server work with Claude Code and Cursor?

Yes. The server speaks MCP over standard I/O, so it works with any compliant client, including Claude Code, Cursor, Windsurf, Gemini CLI, and Antigravity. Clients that support Tools, Resources, and Roots get the full feature set. If your client mishandles roots, launch the server with the --force-roots-fallback flag.

Do I need Flutter 3.44 for agentic development?

No, but you want it. The MCP server itself requires only Dart 3.9 / Flutter 3.35. Flutter 3.44 (Google I/O, May 2026) adds Agentic Hot Reload, where the tooling daemon auto-exposes your running app so agents reload it with zero configuration. It's the single biggest quality-of-life jump in the whole workflow.

Is agentic Flutter development free?

The tooling is. The Dart and Flutter MCP server ships with the SDK as part of the open-source ecosystem, and the Gemini CLI Flutter extension is free to install. Your real cost is model inference: agentic loops make many tool calls per task, so token usage runs meaningfully higher than chat-style assistance. Budget accordingly.

Will AI agents replace Flutter developers?

The evidence points to role transformation, not replacement. The Flutter team's own strategy is explicitly "Humans first" and "Add, don't replace": Dart stays optimized for human readability even when agents generate it. The skill being devalued is fast widget-tree transcription. The skills appreciating are system design, review judgment, and writing the guardrails agents operate inside.

What is Agentic Hot Reload in Flutter 3.44?

It's the mechanism, shipped May 19, 2026, by which the Dart Tooling Daemon automatically shares your running app's connection details with the MCP server. After an agent edits code, the app hot-reloads itself and the agent observes the result. An edit-verify cycle that previously needed a human collapses from minutes to seconds.

The Zoom-Out

Step back far enough and this isn't a story about Flutter, or even about AI. Every leap in software history has been a leap in feedback speed: punch cards to terminals, compile cycles to REPLs, restart to hot reload. Each one didn't just make programmers faster. It changed who got to be a programmer at all.

Agentic Flutter development is the next compression. The loop that once ran through your fingers now runs through a protocol, and your job migrates up the stack: from typing the change to defining what "correct" means. From Muscat to Mountain View, the developers who thrive won't be the ones who fear the agent in the aquarium. They'll be the ones who learned to be excellent aquarium architects.

The future of Flutter isn't humans or agents writing code. It's humans deciding what's worth building, with agents who finally got hot reload.

Enjoyed the ride? Hit the ❤️ and 🦄, drop a comment with your take, I read every one. Follow me here on Dev.to and on X @Sayed3li97 for more deep dives where tech meets wonder.

References

Hasnany, M. "How Dart and Flutter are thinking about AI in 2026," Flutter Blog (Apr 2026). https://blog.flutter.dev/how-dart-and-flutter-are-thinking-about-ai-in-2026-e2fd64e1fdd0 (accessed Jun 10, 2026)
"Dart and Flutter MCP server," Flutter Docs. https://docs.flutter.dev/ai/mcp-server (accessed Jun 10, 2026)
"Flutter extension for Gemini CLI," Flutter Docs. https://docs.flutter.dev/ai/gemini-cli-extension (accessed Jun 10, 2026)
Ryan, J. "Meet the Flutter Extension for Gemini CLI," Flutter Blog (Oct 2025). https://blog.flutter.dev/meet-the-flutter-extension-for-gemini-cli-f8be3643eaad (accessed Jun 10, 2026)
"Flutter 3.44 at Google I/O 2026," Very Good Ventures Blog (May 2026). https://verygood.ventures/blog/google-io-2026/ (accessed Jun 10, 2026)
"Flutter 3.44: Agentic Hot Reload and SwiftPM Default," byteiota (May 2026). https://byteiota.com/flutter-344-agentic-hot-reload-swiftpm-default/ (accessed Jun 10, 2026)
"7 MCP Servers Every Dart and Flutter Developer Should Know," Very Good Ventures (Feb 2026). https://verygood.ventures/blog/7-mcp-servers-every-dart-and-flutter-developer-should-know/ (accessed Jun 10, 2026)
Arenukvern. mcp_flutter, GitHub. https://github.com/Arenukvern/mcp_flutter (accessed Jun 10, 2026)
adamsmaka. flutter-mcp, GitHub. https://github.com/adamsmaka/flutter-mcp (accessed Jun 10, 2026)
@FlutterDev on X. MCP server auto-configuration announcement. https://x.com/FlutterDev/status/1979230928820908084 (accessed Jun 10, 2026)
"Create with AI," Flutter Docs (GenUI SDK, Genkit Dart, Antigravity). https://docs.flutter.dev/ai/create-with-ai (accessed Jun 10, 2026)

[Boost]

Sayed Ali Alkamel — Sun, 15 Mar 2026 12:20:17 +0000

Vibe Coding Flutter: The Senior Dev's Honest Take

Sayed Ali Alkamel ・ Mar 13

#flutter #dart #ai #vibecoding

Vibe Coding Flutter: The Senior Dev's Honest Take

Sayed Ali Alkamel — Fri, 13 Mar 2026 12:46:50 +0000

I'm a Google Developer Expert in Dart & Flutter. This is my honest, research-backed take on vibe coding — with real tweets, real code, and a real workflow you can use Monday morning.

⚡ TL;DR — The Five Things You Need to Know

Vibe coding is AI-assisted dev where intent replaces syntax — coined by Andrej Karpathy in Feb 2025, now a legitimate workflow
Flutter is one of the best frameworks for vibe coding because Dart is strongly-typed, widget trees are predictable, and hot-reload is unbeatable
It genuinely crushes boilerplate, scaffolding, tests, and Figma-to-widget conversion
It breaks badly on state management, platform channels, and performance tuning — you still need to read the code
The power move: pair AGENTS.md + MCP servers + a clear PRD, and treat AI as your most productive junior dev

Where It Started: A Throwaway Tweet That Changed Everything

On February 2, 2025, Andrej Karpathy — OpenAI co-founder, former Tesla AI Senior Director — posted something that wasn't supposed to be a manifesto. It was a shower thought about his weekend hobby.

It got million of views.

// Detect dark theme var iframe = document.getElementById('tweet-1886192184808149383-570'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1886192184808149383&theme=dark" }

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs are getting too good. I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I accept all, I don't read the diffs anymore. I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

— @karpathy, Feb 2, 2025 · x.com/karpathy/status/1886192184808149383

Exactly one year later, Karpathy revisited the post. The word "vibe coding" had earned a Merriam-Webster entry (March 2025) and was named the Collins English Dictionary Word of the Year 2025 and spawned university courses. But his preferred term had quietly evolved:

"Today, programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny. My current favorite term is 'agentic engineering' — agentic because you're orchestrating agents who write the code, engineering because there's an art & science to it. It's something you can learn and become better at."

— @karpathy, Feb 2026 retrospective · x.com/karpathy/status/2019137879310836075

This evolution matters. What started as a "forget the code exists" attitude has matured into deliberate orchestration with oversight. And that nuance is exactly what Flutter developers need to internalize.

What the Flutter Community Is Actually Saying on X

Twitter / X has been the real-time laboratory for Flutter vibe coding opinions. Here's an honest cross-section — hype, skepticism, and people actually shipping things.

The Enthusiasts: "It Unlocks Everything"

// Detect dark theme var iframe = document.getElementById('tweet-1906004591570825422-677'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1906004591570825422&theme=dark" }

"Vibe coding with #Flutter basically lets anyone build whatever niche app they want in a couple of hours."

— @FlutterCarl · x.com/FlutterCarl/status/1906004591570825422

// Detect dark theme var iframe = document.getElementById('tweet-1900578339770843172-196'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1900578339770843172&theme=dark" }

"Preparing a complete Vibe coding with Flutter video... Stay tuned 👀"

— @mcflyDev (Gautier 💙) · x.com/mcflyDev/status/1900578339770843172

"Can't wait to try Vibe coding Flutter apps in the Vide!" — reacting to Norbert Kozsir's Flutter AI-IDE that runs and tests widgets it creates, implements pixel-perfect widgets from screenshots, and writes code exactly the way you want.

— @csells (Chris Sells) · x.com/csells/status/1903182124141908165

"🔴 LIVE Vibe Coding with @norbertkozsir @devangelslondon and @esratech! #VibeCoding #Flutter #Dart #FlutterCommunity" — 2,729 Views on the live session.

— @FlutterComm · x.com/FlutterComm/status/1914001730355814887

The Pragmatists: "It's a Multiplier, Not a Magic Wand"

Andrea Bizzotto (codewithandrea.com), who maintains one of the most respected Flutter newsletters (22k+ subscribers), captured the nuanced position that most senior Flutter developers share:

"AI is a multiplier that amplifies both your skills and your mistakes. So learn to use it well, and don't feel like you need to go all-in. Sometimes the old-fashioned way of writing code manually is still the right call. The decision matrix is simple: compare prompting effort vs coding effort."

— Andrea Bizzotto · codewithandrea.com/newsletter/november-2025

The Skeptics: "Don't Actually Forget the Code Exists"

Andrew Chen from a16z pointed out the macro trajectory that makes seasoned engineers uncomfortable:

"Random thoughts/predictions on where vibe coding might go: most code will be written by the time-rich. Thus, most code will be written by kids/students rather than software engineers. This is the same trend as video, photos, and other social media — we are in the early innings..."

— @andrewchen · March 9, 2025

And the Dart language team itself signaled where things are heading — not pure vibe coding, but structured, type-safe AI tooling for Dart specifically:

// Detect dark theme var iframe = document.getElementById('tweet-2031499569096528324-155'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2031499569096528324&theme=dark" }

"AI apps just got a lot easier to build 🏗️ Genkit Dart (Preview) is officially out, bringing type-safety and a model-agnostic API to the Dart side. Support for Gemini, Claude, OpenAI. Type-safe AI flows. Dev UI for AI testing and traces. #Genkit #Dart #Flutter"

— @dart_lang · x.com/dart_lang/status/2031499569096528324

Why Flutter Is Unusually Well-Suited for Vibe Coding

Most vibe coding discussion centers on web (React, Next.js) or Python backends. But Flutter has structural properties that make it arguably better suited for AI-assisted development than most frameworks. Here's why.

1. Dart's Strong Typing Catches AI Mistakes Early

When an LLM generates incorrect Flutter code, Dart's type system screams immediately. You don't get mysterious runtime crashes at 2 AM — the compiler tells you exactly where the AI hallucinated a method that doesn't exist.

// ❌ AI hallucinated this parameter — Dart catches it at compile time
Widget buildCard(BuildContext context) {
  return Card(
    roundedCorners: 12, // Error: "The named parameter 'roundedCorners' isn't defined"
    child: ListTile(...),
  );
}

// ✅ What it should be — and you know immediately
Widget buildCard(BuildContext context) {
  return Card(
    shape: RoundedRectangleBorder(
      borderRadius: BorderRadius.circular(12),
    ),
    child: ListTile(...),
  );
}

2. Widget Trees Are Declarative — Perfect for AI Reasoning

Flutter's declarative UI model maps almost 1:1 with how LLMs "think" about layout. When you say "add a gradient background to this container with rounded corners and a shadow," there's a direct, unambiguous translation to a DecoratedBox with a BoxDecoration. The AI doesn't have to guess about lifecycle methods or imperative DOM manipulation.

3. Hot Reload Is the Tightest Feedback Loop in Mobile Dev

Vibe coding thrives on fast iteration: prompt → generate → verify → adjust. Flutter's hot reload (now including Flutter Web hot reload (stable since 3.35)) makes the verify step nearly instantaneous. You see AI output materialise on your device in under a second.

4. Dart Is Expressive but Readable

Unlike Java or Kotlin, Dart is concise enough that AI-generated code stays readable. Unlike TypeScript in a React codebase, there's no JSX/CSS-in-JS impedance mismatch. A Flutter file generated by AI tends to look like Flutter code a human would write — which makes review dramatically faster.

The Truth Matrix: When to Vibe, When to Think

Task	Approach	Why
Generate 10 model classes from API spec	✅ Use AI	Pure mechanical translation, zero judgment needed
Build a multi-step onboarding flow UI	✅ Use AI	Declarative widgets, verify visually with hot reload
Write 40 widget tests for existing screens	✅ Use AI	Pattern-heavy, AI is exceptionally good at this
Fix a 2px pixel misalignment	✋ Code it	Low coding effort, high prompt effort — just fix it
Architect a real-time sync feature	✋ Code it	Requires domain knowledge of your specific constraints
Implement fingerprint auth with fallback	🔍 AI draft + review	AI can scaffold, but you must audit every security line
Optimise a ListView with 10,000 items	🔍 AI draft + review	AI knows the patterns, you need to profile the output

Rule of thumb from Andrea Bizzotto: If the prompting effort is lower than the coding effort → use AI. If manually fixing it is faster than explaining it → just fix it manually.

What AI crushes ✅

Scaffold generation (routes, services, models)
Figma design → Flutter widget conversion
Boilerplate (copyWith, fromJson, toJson, Freezed classes)
Responsive layout skeletons
Animation scaffolding (implicit animations)
Simple CRUD screens with Firebase
README and documentation generation

Where to tread carefully ⚠️

Complex Riverpod / BLoC state logic
Platform channel implementations
Performance tuning (jank, Impeller issues)
Custom painters and shaders
Security-sensitive code (auth, storage, network)
Deep navigation flows with guards
Accessibility semantics

The Production-Grade Vibe Coding Workflow for Flutter

Based on real-world patterns from Viktor Lidholt (Serverpod), the Globe.dev team, and senior Flutter practitioners — here's the workflow that actually holds up.

Step 1: Write a PRD Before You Touch the AI

A Product Requirements Document doesn't have to be formal — a Markdown file describing the feature, expected behavior, and constraints is enough. AI with context is an entirely different animal from AI without it.

Context is everything. It's like assigning a task to a junior engineer without any context — poor delivery is almost guaranteed. — globe.dev/blog/beyond-vibe-coding-production-flutter-dart-ai

Step 2: Create an `AGENTS.md` in Your Repo Root

This file tells every AI agent about your architecture, state management choice, folder structure, code style, and package preferences. It's the single highest-leverage action you can take. Without it, agents default to whatever they were trained on — which probably isn't your codebase.

# AGENTS.md — Flutter App Agent Instructions

## Architecture
- State management: Riverpod (hooks_riverpod 2.x)
- Navigation: go_router 13.x with nested routes
- Data layer: Repository pattern, Freezed models
- Network: Dio with interceptors, no direct http package

## Folder Structure
lib/
  features/          # One folder per feature
    auth/
      data/          # Repositories, DTOs
      domain/        # Models, use cases
      presentation/  # Widgets, controllers
  core/              # Shared utils, theme, routing

## Rules
- NEVER use setState in feature widgets, always Riverpod
- ALL models must be Freezed + json_serializable
- Widget tests are REQUIRED for all new screens
- Use const constructors wherever possible
- Follow existing theme tokens in core/theme/

## MCP Servers in Use
- Figma MCP: for any UI implementation task
- Dart MCP: for pub.dev package lookups

Step 3: Connect the Right MCP Servers

The Dart MCP server, Figma MCP server, and Firebase Studio dramatically improve output quality. They give agents access to your actual APIs, your actual design specs — instead of making plausible-sounding things up.

Very Good Ventures published a great resource: 7 MCP Servers Every Dart and Flutter Developer Should Know.

Step 4: Plan Mode First, Then Execute

Use Cursor's or Claude Code's planning mode to generate a plan before any code gets written. Review it. Catch architectural misalignments before they become 300-line mistakes. This one habit catches 80% of problems.

Step 5: Hot Reload, Inspect, Iterate

Run the generated code immediately. Flutter's hot reload plus DevTools makes verifying AI output faster than reading it line-by-line — for simple UI changes. But always read state and logic code before accepting it.

Step 6: Audit. Don't Just Accept All.

Karpathy's original "Accept All, don't read the diffs" was fine for his personal weekend projects. For anything that ships to users, AI-generated code is your technical debt. Read it. If it's messy, ask the AI to clean it up before accepting.

Real Vibe Coding Scenarios That Actually Work in Flutter

Scenario 1: Weekend Proof of Concept — Liquid Glass iOS Effect

Viktor Lidholt from the Serverpod team vibe-coded a Flutter proof-of-concept for Apple's Liquid Glass effect (introduced in iOS 26) over a weekend.

"Obviously not production-level code, but it shows the viability of the approach." — Viktor Lidholt, serverpod.dev/blog/vibe-coding-flutter

Perfect use case: time-boxed, exploratory, visual feedback. Ship the vibe, then decide if it's worth productionising.

Scenario 2: Figma → Flutter with the Figma MCP Server

Using the Figma MCP server + Claude Code, developers are mapping complete design files to Flutter widget trees. The MCP reliably captures dimensional requirements — sizes, spacing, font scales — so the AI output is close enough that human refinement takes minutes, not hours.

// Prompt: "Implement the ProductCard from the Figma design"
// Figma MCP provides exact sizes, spacing, colors from the design file

class ProductCard extends StatelessWidget {
  const ProductCard({super.key, required this.product});

  final Product product;

  @override
  Widget build(BuildContext context) {
    return Container(
      width: 160,  // from Figma
      decoration: BoxDecoration(
        color: Theme.of(context).colorScheme.surface,
        borderRadius: BorderRadius.circular(16),  // from Figma
        boxShadow: [AppShadows.card],
      ),
      child: Column(
        crossAxisAlignment: CrossAxisAlignment.start,
        children: [
          ClipRRect(
            borderRadius: const BorderRadius.vertical(
              top: Radius.circular(16),
            ),
            child: CachedNetworkImage(
              imageUrl: product.imageUrl,
              height: 120,  // from Figma
              fit: BoxFit.cover,
            ),
          ),
          Padding(
            padding: const EdgeInsets.all(12),  // from Figma
            child: Column(/* title, price, rating */),
          ),
        ],
      ),
    );
  }
}

Scenario 3: Full Test Suite from Existing Screens

Prompt: "Write widget tests for every screen in the lib/features/ folder, following the existing patterns in test/."

The AI finds your patterns, replicates them, and generates a scaffold for 20–40 tests in a single pass. Review them, run them, patch the failures. What would take a full day takes two hours.

The Anti-Patterns That Will Burn You

"If you let too much bad code into your project, the models will perform worse over time, and your ability to keep the project clean will suffer." — Viktor Lidholt, Serverpod

❌ No AGENTS.md — Without explicit instructions, the AI defaults to its training data. It might use BLoC when your project uses Riverpod, old go_router patterns, or target the wrong platform entirely.

❌ Accepting security-sensitive code without audit — Documented cases exist of apps deployed with hardcoded secrets, missing authentication checks, and insecure data storage — all AI-generated, none reviewed. Rule: any code that touches auth, storage, or network gets a human eyeball every time, no exceptions.

❌ Vibe coding your state management — Riverpod, BLoC, and Provider have subtleties around lifecycle, disposal, and async state that LLMs frequently get wrong in non-trivial cases. The AI will generate code that looks correct, compiles cleanly, but leaks memory or produces incorrect state transitions. Tests often don't catch this.

❌ No stopping condition on agentic loops — Autonomous agents can spiral. Give them bounded tasks with clear acceptance criteria. "Implement the login screen per the Figma design and the PRD" is a good prompt. "Build the entire app" is a recipe for a mess you'll spend three days untangling.

The Flutter Vibe Coding Stack in 2026

Claude Code — Karpathy's own 2025 year-in-review called it "the first convincing demonstration of what an LLM Agent looks like." It runs in your environment with your private context, making it the most Flutter-codebase-aware option when paired with AGENTS.md.

Cursor — The dominant AI IDE with excellent multi-file operations and planning mode. Pairs well with the Dart MCP server.

Gemini CLI + Flutter Extension — Google's own answer. The Flutter Extension for Gemini CLI combines the Dart and Flutter MCP Server with additional context and commands — natural choice for Firebase-heavy Flutter projects.

Firebase Studio / DreamFlow — Higher-level "vibey" tools where you interact only with the generated app, not the code. Best for non-engineers or pure prototyping, not for production Flutter development.

Dart MCP Server — Not a standalone tool but the connective tissue. Every AI agent for Flutter becomes measurably better with it. Add it to your setup before anything else.

The Key Insight from Karpathy's 1-Year Retrospective

Karpathy's 2026 anniversary post is the most important document in this space right now. He named what skilled developers are actually doing — and it's not "vibe coding" in the throwaway sense:

"Agentic engineering: agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do, and acting as oversight. Engineering to emphasize that there is an art & science and expertise to it."

— @karpathy, Feb 2026 · x.com/karpathy/status/2019137879310836075

This reframe is everything for Flutter developers. You're not abdicating engineering judgment — you're operating at a higher level of abstraction. Your expertise shifts from "how do I write this AnimationController" to "what is the right interaction model and how do I verify the AI implemented it correctly."

The Bottom Line

Vibe coding is real, it's here, and dismissing it is as silly as dismissing hot reload in 2018. But the breathless "just describe your app and it builds itself" narrative sets up a failure mode that is very real for production Flutter development.

Flutter's architecture gives you a genuine edge. The widget tree is predictable, Dart's type system is loud about mistakes, and hot reload gives you the tightest feedback loop in mobile development. These properties mean you can move fast and maintain visibility into what the AI is generating.

Karpathy evolved from "forget the code exists" to "agentic engineering with oversight." That's the right frame. You're the architect, the QA engineer, the tech lead. The AI is your most productive junior developer — high throughput, close review, clear instructions, and never unsupervised in your security code.

"Use vibe coding wisely: accelerate where it helps, but don't let it erode your developer skills."

— Viktor Lidholt, Serverpod · serverpod.dev/blog/vibe-coding-flutter

The Flutter developers who learn to orchestrate agents well — not just prompt and accept — are the ones who will ship extraordinarily fast without accruing the technical debt that kills velocity later.

Have you been vibe coding in Flutter? What's your workflow? Drop it in the comments — I'm genuinely curious what the community has converged on.

If this was useful, follow me here on dev.to and on X [@YourHandle] for more Flutter content.

Tags: #flutter #dart #ai #vibecoding #productivity

I Built an AI Boardroom App in 8 Hours with Flutter & AI 🚀 (Open Source)

Sayed Ali Alkamel — Mon, 05 Jan 2026 18:43:02 +0000

"What if you could have a board of directors made up of the world's smartest AI models, debating your problems in real-time?"

That was the question. The result? LLM Council.

And the craziest part? I built the entire mobile app between lunch and late dinner.

As a Google Developer Expert in Flutter, I've built hundreds of apps, but the speed at which we can now ship software using AI tools like Antigravity is frankly mind-blowing.

Here’s the story of how I took inspiration from an AI legend, fired up my IDE, and shipped a premium cross-platform app in a single day. 👇

💡 The Inspiration

It started when I saw Andrej Karpathy (founding member of OpenAI, former Director of AI at Tesla) tweet about his project: llm-council.

He built a web interface where you can ask a question, and multiple LLMs (GPT-4, Claude, etc.) answer it. Then, they "read" each other's answers and a "Chairman" model synthesizes the best advice.

I loved the concept. But I wanted it in my pocket.

I wanted a premium, executive-tier mobile experience. Something that felt like walking into a boardroom. Dark mode, gold accents, smooth animations.

So I challenged myself: Can I build this before dinner?

🛠️ The Tech Stack

To move fast without breaking things, I stuck to a battle-tested stack:

Flutter 3.6+: For that silky smooth 60fps UI on iOS and Android.
Bloc & Clean Architecture: Because "fast" shouldn't mean "messy code".
OpenRouter API: To access all models (Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro) with one key.
Antigravity: The AI coding assistant that acted as my pair programmer on steroids.

⚡ The "Lunch to Late Dinner" Sprint (1:00 PM - 9:00 PM)

1:00 PM - The Setup 🏗️

I didn't waste time on boilerplate. I initialized the Flutter project and set up the domain layer.
User -> Question -> Council -> Deliberation -> Synthesis.

2:30 PM - The "Antigravity" Boost 🚀

This is where things got wild. Instead of manually typing out every model class and repository, I used Antigravity.

Me: "Generate a repository that hits OpenRouter. It needs to handle streaming responses from 4 different models simultaneously."

Antigravity: Done.

It didn't just write code; it wrote good code. It handled the Dio interceptors, the error parsing, and the concurrent Future.wait calls for the council members.

4:30 PM - The UI Polish ✨

A "Council" implies prestige. A standard Material Design look wouldn't cut it.
I went for a "Succession-style" aesthetic:

Deep Navy Backgrounds (#0F172A)
Gold Accents for the active speaker.
Anonymized Peer Reviews: Models rank each other blindly (Model A doesn't know Model B wrote the answer).

I implemented flutter_animate to make the messages slide in. It felt alive.

6:30 PM - The Synthesis Logic 🧠

The magic of this app is the Chairman.
The app aggregates all the answers, strips the names, and feeds them back to the Chairman model with the prompt:
"Review these perspectives and provide a synthesized, executive summary."

The result? Answers that are significantly more balanced and nuanced than any single model could provide.

8:00 PM - Final Optimizations & Testing 🏁

The last hour was spent on:

Adding local persistence with sqflite so conversations are saved.
Securing the API key storage.
Ensuring the "Chairman" animation was buttery smooth.
9:00 PM: Commit, Push, Done. Dinner time.

🧑‍💻 The Code (Open Source)

I’m making the whole thing open source. You can clone it, put in your own keys, and have your personal AI board of directors.

Check out the repo here:
👉 github.com/sayed3li97/llm_council_app

(Note: If the link is 404, I'm just polishing the README! Check back in 5 mins)

Here is a snippet of how we handle the parallel consultation using Dart's concurrency:

Future<CouncilSession> consult(String query) async {
  // 1. Fire off requests to all members in parallel
  final responses = await Future.wait(
    members.map((model) => _api.ask(model, query))
  );

  // 2. Anonymize and Request Peer Reviews
  final reviews = await _conductPeerReviews(responses);

  // 3. Synthesis by Chairman
  return _chairman.synthesize(responses, reviews);
}

🚀 Why This Matters

We are entering a new era of development. It's not about typing speed anymore; it's about architectural vision and tool leverage.

As a GDE, my advice to developers in 2026 is simple: Embrace the tools.
by using an AI agent like Antigravity, I focused on the product experience the animations, the flow, the value while the AI handled the plumbing.

I built a production-ready app in 8 hours.
What will you build?

If you enjoyed this, drop a star on the repo and follow me for more Flutter & AI experiments!

DEV Community: Sayed Ali Alkamel

LLM Token Counting Explained: The 30-Year-Old Algorithm Quietly Running Your AI Bill

Where Tokens Actually Came From

How BPE Tokenization Actually Works

Why Token Became the Unit of AI Economics

Why Different Providers Count Differently

The Rules That Actually Matter in Production

Counting Tokens in Code

What This Means for How You Build

Antigravity 2.0 for Flutter Developers: CLI, SDK & Agentic Workflows That Actually Matter

1. AGENTS.md: Your Project's AI Constitution

2. Install the Antigravity CLI and Migrate Today

3. Enable the Dart & Flutter MCP Server

4. Agentic Hot Reload: Prompt-to-Emulator in Seconds

5. The Stitch → Antigravity → Flutter Pipeline

6. Antigravity SDK: Automate Your Flutter Agent Workflows

Pricing Reference

What This Changes in Practice

I Pointed a Skill Linter at a 52k-Star Repo. Here Is What 84/100 Looks Like.

One command. 24 skills. Two seconds.

The full results

Two gaps. Five skills. Every single C.

The description does not say when to stop

Terminal commands with no Safety section

Running it yourself

What this experiment actually proves

Official authoring guides

skillscore: a CLI that scores your AI agent's SKILL.md 0–100

TL;DR

Why I built this

What is skillscore?

Does it actually work? Let's score a real one

Built for CI

How is this different from just asking an LLM to review my skill?

It's a library too

FAQ

What's next

Try it

sayed3li97 / skillscore

Lint and score any AI agent SKILL.md against the official Claude, Codex, and Antigravity authoring guides — offline Dart CLI.

skillscore — lint and score AI agent skills (SKILL.md)

What is skillscore?

DiffusionGemma: How Google's New Open LLM Hits 1,000 Tokens/sec and Changes Inference Economics

What DiffusionGemma Actually Is

The Numbers

Why the Architecture Matters

Where It Wins and Where It Does Not

Structural advantages

Benchmark trade-offs vs Gemma 4 26B (autoregressive)

Multi-modal capabilities

Deploy It in 5 Minutes with vLLM

Fine-Tuning

What to Evaluate Right Now

The Bottom Line

How to Write a Flutter Agent Skill That Actually Works: The 2026 Recipe

Table of Contents

Why a bad skill is worse than no skill

The anatomy you need before the recipe

One format, every agent

The recipe: 9 ingredients of a skill that works

1. The description is 80% of the battle

2. Be ruthlessly concise

3. Match the degrees of freedom to the task

4. Lead with anti-patterns, not just patterns

5. Turn the task into a checklist workflow

6. Add a feedback loop

7. Use progressive disclosure deliberately

8. Kill time-sensitive information

9. One canonical example beats ten adjectives

A complete Flutter skill you can steal

Old patterns

Grade it the way Flutter does

Use two agents: author with one, test with the other

The security caveat nobody mentions

The honest take from the community

The ship-it checklist

FAQ

Wrapping up

Flutter Agent Skills: How to Make Your AI Agent Actually Good at Flutter

Table of Contents

1. `AGENTS.md`: Your Project's AI Constitution

Flutter skills (`flutter/skills`)

Dart skills (`dart-lang/skills`)

Step 2: Create an `AGENTS.md` in Your Repo Root