La pregunta que llega a discovery estos meses no es si usar un agente de IA para tocar Flutter, sino cómo evitar que escriba código que compila, parece correcto y no lo es. En septiembre de 2026 el equipo de Flutter publicó su respuesta oficial: el repositorio flutter/agent-plugins, que empaqueta skills, reglas y un servidor MCP para que los asistentes de código dejen de improvisar sobre tu base de código. Si mantienes una app Flutter en producción, merece la pena configurarlo. Pero el valor no está donde se mira primero, en las skills, sino en el servidor MCP. Esa distinción es casi todo lo que necesitas entender antes de activarlo.

Qué hay dentro de flutter/agent-plugins

Un plugin de agente junta cuatro piezas que resuelven problemas distintos:

  • Agent Skills. Guías de procedimiento que le enseñan al asistente cómo hacer una tarea concreta de Flutter: construir un layout responsive, montar routing declarativo, configurar localización, añadir widget tests, tests de integración o widget previews. Hay alrededor de una decena, mantenidas y versionadas por el propio equipo de Flutter. Funcionan por divulgación progresiva: el agente lee primero solo el nombre y la descripción de cada skill, y solo carga el SKILL.md completo cuando la tarea lo pide. Así diez recetas no te ocupan el contexto desde el primer turno.
  • Reglas (rules). Instrucciones persistentes que entran en el contexto en cada sesión: convenciones del proyecto, restricciones, pequeños automatismos como disparar un hot reload al editar un widget.
  • Servidor MCP de Dart y Flutter. Conecta al asistente con el SDK real por stdio: diagnósticos del analyzer, resolución de símbolos, introspección del estado de la app en ejecución, búsqueda en pub.dev, ejecución de tests y de dart format.
  • Agentes especializados. Personas acotadas para un trabajo concreto. El que ya está disponible en Antigravity es el agente de accesibilidad: audita el árbol de widgets, detecta labels semánticos que faltan, marca touch targets por debajo de 48x48 y propone el arreglo idiomático.

Hay un repositorio hermano, dart-lang/skills, con lo específico del lenguaje: tests unitarios, análisis estático, resolución de dependencias. Y un tercer servidor MCP, el de Developer Knowledge de Google, que da al agente búsqueda sobre la documentación viva de docs.flutter.dev y dart.dev.

El valor está en el bucle, no en las recetas

Casi todo el ruido de las últimas semanas va sobre las skills. Son útiles, pero son la parte menos importante del paquete. Una skill es una receta: le dice al agente los pasos para montar go_router o un LayoutBuilder. Eso ya lo hacía razonablemente bien sin plugin, porque es justo el tipo de patrón que abunda en sus datos de entrenamiento.

Lo que un modelo no puede hacer solo es comprobar si lo que acaba de escribir funciona. Ahí entra el servidor MCP. Con él, el agente lanza el analyzer y ve el error real, ejecuta tu suite de tests y lee el fallo, inspecciona el estado de la app corriendo. Sin MCP, el asistente escribe código plausible y se detiene antes de saber si sirve. Con MCP, se corrige contra diagnósticos reales antes de devolverte nada. Para una base de código en producción, con sus tipos propios y sus restricciones, esa es la diferencia entre un agente que adivina y uno que verifica.

El salto de calidad en nuestros proyectos Flutter no llegó cuando el agente se supo los patrones. Llegó el día en que pudo comprobar por su cuenta si un cambio había roto un test. Un bucle de feedback vale más que diez recetas.

Cómo se instala, según tu agente

La configuración cambia por herramienta, pero el patrón es siempre el mismo: servidor MCP, luego skills, luego reglas.

En Claude Code el flujo es directo:

claude plugin marketplace add flutter/agent-plugins
claude plugin install dart-flutter@dart-flutter

Para el resto de agentes compatibles con MCP (Cursor, GitHub Copilot, Antigravity, Codex, Windsurf, Zed, Cline) configuras el servidor en el archivo MCP de tu editor:

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

Y añades las skills por la vía universal:

npx skills add flutter/agent-plugins --skill '*' --agent universal --yes
npx skills add dart-lang/skills --skill '*' --agent universal --yes

Las reglas van en el archivo de convenciones de cada agente: CLAUDE.md, .cursor/rules/, .github/copilot-instructions.md o .agents/skills/ según el caso. Empieza por el servidor MCP; si solo instalas una cosa, que sea esa.

Cuándo sí

Las tareas procedimentales con respuesta conocida son el caso obvio: layout responsive, routing declarativo, localización, andamiaje de tests. El agente hace el trabajo mecánico y tú revisas, en lugar de teclearlo tú.

Las auditorías acotadas también encajan. El agente de accesibilidad es buen ejemplo: una pasada sobre una pantalla saca los problemas de semántica que se cuelan en cualquier equipo con prisa.

Y el onboarding o las migraciones, donde el MCP de documentación evita que el agente cite APIs que ya no existen, el fallo más caro cuando alguien nuevo entra al proyecto.

Cuándo no

No arregla decisiones de arquitectura. Una skill te monta go_router impecable, pero no te dice si tu feature necesitaba esa complejidad; esa decisión sigue siendo tuya.

No sustituye la revisión senior. El plugin reduce el código que compila y no debería existir, no lo elimina. Si publicas sin leer, acumulas deuda de comprensión: código que nadie de tu equipo entiende del todo.

El contexto se paga. Las skills por divulgación progresiva apenas pesan, pero cada regla persistente viaja en todos los turnos. Un archivo de reglas de 400 líneas es peor ingeniería de contexto que diez líneas afiladas.

Y el MCP abre superficie: un servidor así ejecuta comandos en tu máquina. Antes de darle esa llave a un agente, revisa qué expone y con qué permisos.

Lo que haríamos nosotros

En un equipo senior, la configuración por defecto es corta. Encender el servidor MCP siempre: es lo que convierte al asistente de adivino en herramienta. Activar las skills de forma selectiva (tests, responsive, routing, localización) y dejar fuera las que tapan decisiones de diseño. Reglas mínimas y específicas del proyecto, no un manifiesto genérico de 400 líneas. Y antes de confiar un flujo a un agente, medirlo: un par de evals sobre tareas reales te dicen en una tarde si el plugin ayuda o solo da la sensación de ayudar.

Que la herramienta sea oficial no la hace neutral. Está pensada para que cualquiera arranque rápido, y ese "cualquiera" incluye ajustes que a ti no te convienen. La ventaja de tener un equipo que ya sabe Flutter es poder quedarte con el bucle de verificación y descartar el resto.

Si estás montando o manteniendo una app Flutter y quieres meter agentes en el flujo sin perder el control de lo que entra a producción, en Dribba llevamos desde 2017 en el directorio oficial de partners de Flutter de Google y hemos pasado por esta curva con equipos reales. Escríbenos y lo miramos sobre tu código, no sobre un tutorial.