Genkit Dart: apps agénticas full-stack con un solo lenguaje (y cuándo no conviene)
Genkit Dart es un framework open-source, anunciado por el equipo de Dart en marzo de 2026, para construir aplicaciones con IA de principio a fin usando el mismo lenguaje en cliente y servidor. En la práctica significa que puedes escribir la lógica de IA una vez —llamadas a modelos, tool calling, salidas estructuradas— y ejecutarla dentro de tu app Flutter o en un backend Dart, compartiendo los mismos tipos entre ambos.
Está en preview temprana. Eso condiciona bastante cuándo tiene sentido adoptarlo hoy, así que lo dejamos claro desde el principio: es una apuesta interesante para equipos que ya viven en Dart, no una recomendación universal.
Qué es Genkit Dart, en concreto
Genkit ya existía para TypeScript, Go y Python. La novedad de 2026 es la versión Dart, que se apoya en dos rasgos del lenguaje: su sistema de tipos fuerte y el hecho de que Dart corre tanto en el frontend (Flutter) como en el backend.
Sus piezas centrales son:
- Flows: funciones que envuelven tu lógica de IA y son testables, observables y desplegables. Es la unidad de trabajo del framework.
- Tool calling: el modelo puede invocar funciones que tú defines para traer datos en vivo (una consulta a tu base de datos, una llamada a una API interna).
- Structured output: generación con salidas tipadas mediante esquemas, en lugar de parsear texto a mano.
- API model-agnostic: soporte de fábrica para modelos de Google, Anthropic, OpenAI y compatibles con la API de OpenAI. El diseño busca explícitamente evitar el vendor lock-in.
- UI de desarrollo local: una web en localhost, vía la CLI de Genkit, para probar prompts, ver traces y depurar flows.
Por qué el "un solo lenguaje" no es marketing
El argumento fuerte de Genkit Dart no es "otra librería de IA", sino la continuidad de tipos entre cliente y servidor. Si defines un esquema de entrada/salida para un flow, ese mismo esquema vale en tu backend Dart y en tu app Flutter. Cuando el flow cambia, el compilador te avisa en ambos lados. Es el mismo beneficio que ya discutimos en Dart full-stack en 2026 frente a un backend en Go, aplicado ahora al terreno de la IA.
Los tres modelos de despliegue
Genkit Dart admite tres formas de repartir la lógica, y elegir bien es la decisión de arquitectura más importante:
| Modelo | Dónde corre la lógica | Cuándo tiene sentido | Riesgo principal |
|---|---|---|---|
| Todo en Flutter | En el dispositivo | Prototipos, o apps donde el usuario aporta su propia API key | Nunca embebas tu clave en el binario |
| Flow en backend + remote action | En tu servidor Dart, invocado desde la app | Prompts sensibles, lógica compleja, esquemas compartidos | Necesitas operar un backend |
| Backend como proxy de modelos | Servidor Dart mínimo que reenvía peticiones con tu autorización | Quieres control de acceso y cuotas sin mover toda la lógica | Latencia y coste del salto extra |
El patrón de remote action es el que más valor aporta en producto real: la app Flutter llama a un flow que vive en el servidor como si fuera local, y ambos comparten el esquema. La clave del modelo —literalmente— no viaja al cliente.
Un flow mínimo
La forma de pensar en Genkit es "envuelvo mi lógica en un flow y lo despliego". Un esbozo conceptual de un flow con salida estructurada y una herramienta:
// Definimos una herramienta que el modelo puede invocar
final buscarPedido = ai.defineTool(
name: 'buscarPedido',
description: 'Devuelve el estado de un pedido por su ID',
(String pedidoId) async => await repo.estadoDe(pedidoId),
);
// El flow envuelve la lógica: entrada tipada, salida tipada
final asistentePedidos = ai.defineFlow(
name: 'asistentePedidos',
(ConsultaCliente consulta) async {
final res = await ai.generate(
prompt: consulta.texto,
tools: [buscarPedido],
output: RespuestaPedido, // esquema tipado, no texto libre
);
return res.output;
},
);
El mismo RespuestaPedido que tipa la salida del flow en el servidor es el que tu app Flutter espera al consumirlo. Esa es la propuesta.
Cuándo NO usar Genkit Dart
Aquí es donde toca ser honestos:
- Si buscas estabilidad de producción hoy. Está en preview. La API puede cambiar y el ecosistema de plugins es joven frente a las versiones de Python o TypeScript. Para una carga crítica que no puede permitirse breaking changes, espera o aísla bien la dependencia.
- Si tu caso es una integración de IA sencilla en Firebase. Para "llamar a un modelo desde la app y poco más", Firebase AI Logic puede resolverte con menos piezas. Genkit brilla cuando hay flows con varios pasos, herramientas y necesidad de observabilidad.
- Si tu backend ya es un Go o Python maduro. No reescribas un backend que funciona solo por unificar lenguaje. Genkit existe también en Go y Python; usa la versión que respete tu inversión actual. Cuándo elegir Go sigue siendo un debate válido, y lo tratamos en por qué elegimos Go para proyectos de alto rendimiento.
- Si el equipo no es Dart-first. La ventaja del lenguaje único desaparece si tu backend lo mantiene gente que no escribe Dart.
Y un guardarraíl que Genkit repite y conviene subrayar: nunca publiques una app con la API key embebida en el código fuente; se puede extraer del binario. Si el prompt o la clave son sensibles, van al backend.
Cómo encaja en un stack real
Para producto serio, la combinación razonable es: flows en un backend Dart desplegado como servicio (por ejemplo sobre Cloud Run), invocados desde Flutter vía remote actions, con las claves y la lógica sensible del lado servidor y observabilidad activada desde el primer día. Esa disciplina de medir el comportamiento del agente en vez de fiarte de la demo la desarrollamos en evaluar agentes de IA en producción con evals, no con vibes.
Conclusión
Genkit Dart resuelve un dolor concreto y real: la fricción de tipos y contexto entre la app Flutter y el backend cuando metes IA en medio. Su modelo-agnosticismo y el patrón de remote actions son argumentos sólidos. Pero está en preview: adóptalo como apuesta consciente en equipos Dart-first, con la lógica sensible en servidor, y no como reemplazo de un backend que ya funciona.
Si estás valorando meter capacidades de IA en tu app Flutter y no tienes claro dónde debe vivir la lógica —cliente, backend o un modelo híbrido—, en Dribba llevamos desde 2011 tomando exactamente ese tipo de decisiones de arquitectura con equipo senior in-house. Hablamos.
