Por qué Flutter tardó 25 días más: cerrando la base de tokens del Harness Design System

El rollout de los tokens de Flutter en la app de Prolog fue el 24 de septiembre, y la release para quienes usan el producto salió esta semana. React ya estaba en producción, así que la base de tokens del Proyecto Harness Design System está cerrada en las dos stacks, con harness aplicado y tokens que un LLM puede consumir. Llámalo agentic ready, LLM-readiness o como prefieras. La parte más estructural del design system está lista.

Este artículo cuenta por qué Flutter terminó cerca de 25 días después del plazo que estimamos, y qué cambió eso en mi forma de planificar trabajo de design system.

Estimamos Flutter mirando a React

En React, hacer y probar fue más rápido. La estimación de Flutter nació de esa experiencia, y ese fue el error de origen.

Flutter corre en un engine propio de Google, sobre Dart, y no comparte nada con JavaScript. Figma, en Dev Mode, ya exporta CSS y TypeScript, y en la web los tokens entran por Tailwind sin mucha ceremonia. En Flutter no existía un camino equivalente. La infraestructura que recibe los tokens y los distribuye a cada plataforma tuvo que construirse pensando en Flutter, y la migración de componentes y pantallas se hizo de forma independiente de la web.

En la práctica eran dos proyectos con el mismo nombre, y los estimamos como si fuera uno solo.

Probar costó más que migrar

En la web, la validación se apoyó en una herramienta que muestra la pantalla actual al lado de la pantalla con los tokens nuevos. Ayudó mucho en React y después se adaptó para Flutter, pero Flutter exigió bastante más prueba en runtime, ejecutando la aplicación y mirando el resultado.

Rodolfo, que condujo la migración en el código, describió bien la dificultad. La aplicación es grande, con muchas páginas y versiones antiguas y nuevas conviviendo, y eso significa mucho contexto para que una IA lo cargue de una vez. Intentó orquestar la migración en un único workflow y la ejecución no llegaba al final. Lo que funcionó fue dividirla en fases.

La revisión tuvo el mismo problema de escala. Una de las herramientas que creó listaba todos los tokens de las dos plataformas, y el volumen llegó a cerca de 7.000. Revisar eso uno por uno era inviable. Glauber pivotó el método algunas veces hasta que decidimos pasar pantalla por pantalla en la aplicación, anotando dónde el problema visual era mayor. Con eso pudimos separar lo que valía la pena migrar en ese momento de lo que podía pasar. Los empty states, por ejemplo, ya necesitaban rediseñarse de cualquier forma, así que no tenía sentido gastar tiempo ajustando la versión antigua. El criterio que usamos fue dejar la divergencia imperceptible para quien usa la app.

Deuda técnica que todavía no habíamos explorado

Cada stack carga con su deuda técnica, y una parte solo aparece cuando alguien entra al código a hacer el cambio. La estimación, en cambio, se hace antes de entrar. En React esa diferencia entre lo previsto y lo encontrado fue pequeña. En Flutter fue grande.

Hoy trato esa deuda como incertidumbre declarada en la estimación, y la cuenta que hago cambió. Antes preguntaba cuánto tiempo lleva una stack. Ahora pregunto cuánto de la stack ya conocí por dentro. Si es poco, el plazo tiene que venir con un margen explícito, y ese margen tiene que comunicarse a los líderes al comienzo.

La dedicación cayó en medio del proyecto

El segundo motivo del atraso viene de la organización del equipo. Quienes actuaban en el proyecto tuvieron que iniciar proyectos nuevos, y el tiempo dedicado al design system cayó a algo en torno a cuatro horas por semana, cuando ocurría.

En una reunión de alineación de metas, una persona del equipo dijo que, sin una tarea bien definida, cuatro horas semanales no rendían trabajo. Otra señaló que veníamos incumpliendo los plazos porque ninguno era realista. Los dos comentarios tenían razón.

Trabajar con IA agrava este problema. Un experimento con agentes pide que alguien prepare el contexto, dispare la ejecución, la deje correr por horas y después revise. Fragmentar eso en bloques de dos horas por semana multiplica el costo de reentrada. Durante la conversación alguien hizo la cuenta: ocho horas de trabajo en fracciones de dos horas semanales llevan un mes, y lo mismo cabe en un día.

Eso fue lo que hicimos. Definimos un día entero dedicado a Flutter para cerrar las brechas de tokens que quedaban, y la release en producción salió esta semana. No tengo un número para comparar ese día con las semanas anteriores, pero fue lo que destrabó la entrega, y es la lección más clara del período.

Otra propuesta que salió de esa misma reunión, y que quiero probar, es medir el costo humano del proyecto. La ejecución de la IA es difícil de contar en horas, pero se puede registrar cuánto tiempo necesitó cada persona para detener lo que hacía en el squad y resolver asuntos del design system. Sin ese número, el proyecto parece barato y el equipo paga la diferencia.

Lo que me llevo de esto

El primer cambio es estimar cada stack por separado, sin heredar el plazo de otra. El segundo es tratar lo que todavía no conocemos del código como riesgo declarado en el cronograma. El tercero es reservar días enteros para el trabajo que depende de contexto largo. Y el cuarto es contar el costo de quien sale de su propio squad para actuar en el proyecto, porque ese costo existe aunque nadie lo registre.

La base está cerrada, y los componentes son el próximo paso

Los tokens entregan la base: un sistema más consolidado, con más variantes, tipografía revisada y documentación que el LLM puede leer. Todavía no entregan el resultado que da nombre al proyecto, que es una IA armando pantallas con dirección. Esa ganancia depende de los componentes, y la propuesta para esa etapa se presentó a nuestro CTO esta semana. Él aprobó el plan.

La primera decisión del plan viene directo de la lección de Flutter. En lugar de horas sueltas durante la semana, el equipo se va a reunir de forma presencial un día entero por semana, enfocado solo en el proyecto y sin interrupciones, hasta fines de octubre. Pensamos en encuentros quincenales, pero eso daría pocos días de trabajo hasta entonces, poco para el alcance. También duplicamos las horas que habíamos previsto antes, y el impacto en las otras demandas de las personas se acordó de antemano.

El trabajo corre en dos frentes al mismo tiempo.

El primero es una skill, una instrucción reutilizable que Claude Code sigue, para evaluar pantallas. Compara la pantalla creada con pantallas de Prolog que funcionan bien, da un puntaje de 0 a 100% y sugiere qué ajustar. Las pantallas con 80% o más siguen sin revisión de diseño. Esto ayuda sobre todo en las pantallas simples, como las que siguen nuestro patrón de tablas, filtros y navegación con paneles laterales, que hoy las personas de desarrollo ya crean solas con IA.

El segundo es aplicar el harness a cerca de 60 componentes de nuestro design system. Hay otros componentes que todavía no están en el repositorio correcto del design system, y quedan para después. Para este trabajo vamos a adaptar una herramienta de línea de comandos de Astryx, un proyecto externo que ya resolvió cómo preparar un catálogo de componentes para agentes de IA. Decidimos no reescribir los componentes ahora. Reescribir obligaría a probar el funcionamiento de cada uno, y hoy no tenemos pruebas para eso. Ese camino sigue siendo el ideal a mediano plazo, pero aumentaría el riesgo de atraso.

En la presentación, el CTO hizo una observación que cambió el primer frente. El puntaje no puede ser solo un porcentaje, porque algunos errores deben bloquear la pantalla. Nuestro patrón para mostrar los detalles de una fila de tabla es un panel lateral. Si alguien usa una ventana que se abre en medio de la pantalla, no debería perder 10% y seguir. Debería volver para ajuste, porque ya existe un componente listo para eso. La skill pasa a tener, además del puntaje, una lista de bloqueos.

Cómo medir ese porcentaje en los componentes sigue siendo una pregunta abierta. La vamos a responder el primer día de trabajo, y es alrededor del segundo cuando sabremos si la IA crea mejores pantallas con el harness. Por ahora tenemos alcance, plazo y esta pregunta, declarados.