Por que o Flutter levou 25 dias a mais: fechando a fundação de tokens do Harness Design System

O rollout dos tokens do Flutter no app do Prolog foi em 24/09, e a release para quem usa o produto saiu esta semana. O React já estava no ar, então a fundação de tokens do Projeto Harness Design System está fechada nas duas stacks, com harness aplicado e tokens que uma LLM consegue consumir. Chame de agentic ready, de LLM-readiness ou do nome que preferir. A parte mais estrutural do design system está pronta.

Este artigo conta por que o Flutter terminou cerca de 25 dias depois do prazo que estimamos, e o que isso mudou na minha forma de planejar trabalho de design system.

Estimamos o Flutter olhando para o React

No React, fazer e testar foi mais rápido. A estimativa do Flutter nasceu dessa experiência, e esse foi o erro de origem.

O Flutter roda numa engine própria do Google, sobre Dart, e não compartilha nada com JavaScript. O Figma, em Dev Mode, já exporta CSS e TypeScript, e na web os tokens entram pelo Tailwind sem muita cerimônia. No Flutter não existia um caminho equivalente. A infraestrutura que recebe os tokens e os distribui para cada plataforma precisou ser construída com o Flutter em mente, e a migração de componentes e telas foi feita de forma independente da web.

Na prática eram dois projetos com o mesmo nome, e nós estimamos como se fosse um só.

Testar custou mais do que migrar

Na web, a homologação se apoiou numa ferramenta que mostra a tela atual ao lado da tela com os tokens novos. Ela ajudou muito no React e foi adaptada depois para o Flutter, mas o Flutter exigiu bem mais teste em runtime, rodando o aplicativo e olhando o resultado.

O Rodolfo, que conduziu a migração no código, descreveu bem a dificuldade. A aplicação é grande, com muitas páginas e versões antigas e novas convivendo, e isso significa muito contexto para uma IA carregar de uma vez. Ele tentou orquestrar a migração num workflow único e a execução não chegava ao fim. O que funcionou foi dividir em fases.

A revisão teve o mesmo problema de escala. Uma das ferramentas que ele criou listava todos os tokens das duas plataformas, e o volume chegou a cerca de 7 mil. Revisar isso um a um era inviável. O Glauber pivotou o método algumas vezes até decidirmos passar tela por tela no aplicativo, anotando onde o problema visual era maior. Com isso conseguimos separar o que valia migrar naquele momento do que podia passar. Os empty states, por exemplo, já precisavam ser redesenhados de qualquer forma, então não fazia sentido gastar tempo ajustando a versão antiga. O critério que usamos foi deixar a divergência imperceptível para quem usa o app.

Débito técnico que ainda não tínhamos explorado

Cada stack carrega o seu débito técnico, e uma parte dele só aparece quando alguém entra no código para fazer a mudança. A estimativa, por outro lado, é feita antes de entrar. No React essa diferença entre o previsto e o encontrado foi pequena. No Flutter foi grande.

Hoje eu trato esse débito como incerteza declarada na estimativa, e a conta que faço mudou. Antes eu perguntava quanto tempo uma stack leva. Agora pergunto quanto da stack eu já conheci por dentro. Se for pouco, o prazo precisa vir com uma margem explícita, e essa margem precisa ser comunicada para as lideranças no começo.

A dedicação caiu no meio do projeto

O segundo motivo do atraso vem da organização do time. Quem atuava no projeto precisou iniciar novos projetos, e o tempo dedicado ao design system caiu para algo em torno de quatro horas por semana, quando acontecia.

Numa reunião de alinhamento de metas, uma pessoa do time disse que, sem tarefa bem definida, quatro horas semanais não rendiam trabalho. Outra apontou que vínhamos batendo nos prazos porque nenhum deles era realista. Os dois comentários estavam certos.

Trabalhar com IA agrava esse problema. Um experimento com agentes pede que alguém prepare o contexto, dispare a execução, deixe rodar por horas e depois revise. Fatiar isso em blocos de duas horas por semana multiplica o custo de reentrada. Durante a conversa alguém fez a conta: oito horas de trabalho em fatias de duas horas semanais levam um mês, e a mesma coisa cabe em um dia.

Foi o que fizemos. Definimos um dia inteiro dedicado ao Flutter para fechar as lacunas de tokens que restavam, e a release em produção saiu nesta semana. Não tenho um número para comparar esse dia com as semanas anteriores, mas foi ele que destravou a entrega, e é a lição mais clara do período.

Outra proposta que saiu dessa mesma reunião, e que quero experimentar, é medir o custo humano do projeto. A execução da IA é difícil de contar em horas, mas dá para registrar quanto tempo cada pessoa precisou parar o que fazia no squad para resolver questões do design system. Sem esse número, o projeto parece barato e o time paga a diferença.

O que levo disso

A primeira mudança é estimar cada stack separadamente, sem herdar o prazo de outra. A segunda é tratar o que ainda não conhecemos do código como risco declarado no cronograma. A terceira é reservar dias inteiros para o trabalho que depende de contexto longo. E a quarta é contar o custo de quem sai do próprio squad para atuar no projeto, porque esse custo existe mesmo quando ninguém o registra.

A fundação está fechada, e os componentes são o próximo passo

Os tokens entregam a base: um sistema mais consolidado, com mais variantes, tipografia revisada e documentação que a LLM consegue ler. Eles ainda não entregam o resultado que dá nome ao projeto, que é uma IA montando telas com direção. Esse ganho depende dos componentes, e a proposta para essa etapa foi apresentada ao nosso CTO nesta semana. Ele aprovou o plano.

A primeira decisão do plano vem direto da lição do Flutter. Em vez de horas soltas durante a semana, o time vai se reunir presencialmente um dia inteiro por semana, focado só no projeto e sem interrupções, até o fim de outubro. Pensamos em encontros quinzenais, mas isso daria poucos dias de trabalho até lá, pouco para o escopo. Também dobramos as horas que tínhamos previsto antes, e o impacto nas outras demandas das pessoas foi combinado de antemão.

O trabalho corre em duas frentes ao mesmo tempo.

A primeira é uma skill, uma instrução reutilizável que o Claude Code segue, para avaliar telas. Ela compara a tela criada com telas do Prolog que funcionam bem, dá uma nota de 0 a 100% e sugere o que ajustar. Telas com 80% ou mais seguem sem revisão de design. Isso ajuda principalmente nas telas simples, como as que seguem o nosso padrão de tabelas, filtros e navegação com painéis laterais, que hoje as pessoas de desenvolvimento já criam sozinhas com IA.

A segunda é aplicar o harness em cerca de 60 componentes do nosso design system. Existem outros componentes que ainda não estão no repositório correto do design system, e eles ficam para depois. Para esse trabalho vamos adaptar uma ferramenta de linha de comando do Astryx, um projeto externo que já resolveu como preparar um catálogo de componentes para agentes de IA. Decidimos não reescrever os componentes agora. Reescrever obrigaria a testar o funcionamento de cada um, e hoje não temos testes para isso. Esse caminho continua sendo o ideal a médio prazo, mas aumentaria o risco de atraso.

Na apresentação, o CTO fez uma observação que mudou a primeira frente. A nota não pode ser só uma porcentagem, porque alguns erros precisam bloquear a tela. O nosso padrão para mostrar os detalhes de uma linha de tabela é um painel lateral. Se alguém usar uma janela que abre no meio da tela, ela não deve perder 10% e seguir. Deve voltar para ajuste, porque já existe um componente pronto para aquilo. A skill passa a ter, além da nota, uma lista de bloqueios.

Como medir essa porcentagem nos componentes ainda é uma pergunta aberta. Vamos respondê-la no primeiro dia de trabalho, e é por volta do segundo que saberemos se a IA cria telas melhores com o harness. Por enquanto temos escopo, prazo e essa pergunta declarada.