⏱️ 7 min de leitura
No capítulo anterior, O git foi feito para humanos (capítulo 6), a resposta para os conflitos foi planejar antes. Este capítulo é sobre o outro lado dessa conta. Quase tudo o que aprendi na engenharia de software diz para investir no começo: refinar, prototipar, prever onde fica cada botão. Com agentes trabalhando a noite inteira, comecei a desconfiar disso, e depois testei a desconfiança até ela quebrar.
A manhã de 1º de outubro
A primeira noite inteira da fábrica, contada em Dormi e acordei com o trabalho pronto (capítulo 3), rodou com tudo no modo Automático, inclusive as telas. De manhã, escrevi para a IA:
"Pensando na filosofia ágil, para mim pareceu muito melhor eu ir dormir e acordar com propostas já mergeadas, onde eu posso fazer um refinamento em cima do que já foi feito."
O que eu tinha na frente não era uma descrição de tela. Era a tela. "Não é isso, é assim" é uma frase curta. Descrever "o que é" antes de qualquer coisa existir leva reuniões.
O incremento funcionando é a especificação mais barata que existe.
Essa conta só fecha porque gerar ficou barato: naquela noite, cada entrega custou cerca de três quartos do que custava uma feita de dia, comigo acompanhando. Errar e refazer passa a custar menos do que as horas tentando acertar de primeira.
O refinamento não sumiu. O PO de O dia em que a IA saiu do meu volante (capítulo 2) ainda só aceita no roadmap uma tarefa com 85% ou mais de clareza. O que mudou foi o tamanho: o suficiente para começar, não para prever tudo.
O experimento da cidade
Duas semanas depois, quis levar a ideia mais longe: no meio do dia, com uma tela nova. Era a cidade 3D, um mapa do código em que cada arquivo vira um prédio e cada área do projeto, um bairro. Naquela tarde, em uma sessão à parte, eu tinha feito uma prova de conceito da cidade, a POC: uma versão rápida, fora do sistema, só para ver se a ideia ficava boa. Ficou, e eu aprovei.
Para levar a cidade para dentro do aplicativo, escrevi:
"A etapa da cidade eu não pedi para validar, pedi para desenvolver direto. [...] É mais rápido pedir para entregar do jeito que a IA achar melhor, correr o risco de dar certo e depois corrigir, com um pouco mais de custo, mas sem parar o roadmap. [...] Será que não vale mais a pena pedir para fazer, acordar e validar aquilo que já foi feito, do que ficar refinando e pensando em como fazer?"
O agente decidiria os detalhes e entregaria sem parar em nenhuma aprovação minha, o motor juntaria o código e seguiria para a etapa seguinte, e o que eu achasse testando viraria tarefa na etapa depois. Antes de ver a tela, eu já tinha um palpite: "a cidade não abre em tela cheia, e é bem provável que eu queira isso". É o tipo de detalhe que ninguém escreve em uma tarefa e que salta aos olhos no primeiro clique. Era exatamente o caso a favor de reagir depois.
"Devia ter validado"
O palpite se confirmou, mas foi o menor dos problemas. Testando a cidade e a aba onde ela mora, achei mais de 12:
- Controles brancos: listas de opções e campos de data com fundo branco em um aplicativo escuro.
- Checkbox pequeno: difícil de acertar com o mouse.
- Texto demais: uma tela tão carregada que não parecia feita para uma pessoa ler.
- A cidade: parecia uma pilha de quadrados, não abria em tela cheia e piscava com o mouse por cima.
Escrevi, naquela noite:
"Eu achei que ia ser bom, mas como envolve front-end, foi péssimo. Um monte de coisa errada, tela toda torta. [...] Passar por todo o fluxo para corrigir vai custar mais horas e tokens. Foi uma péssima decisão, devia ter validado."
Foram 6 tarefas de correção na mesma noite. O roadmap não parou, como o experimento previa. Mas cada correção ia passar pelo fluxo inteiro.
E o número que mais me incomodou foi outro. A fábrica tem um agente revisor de interface, que olha as capturas de tela de cada entrega. Nas mesmas telas, ele achou zero problemas. Ele conferia se as cores e espaçamentos seguiam as variáveis do projeto, não se a tela ficava boa; as capturas usavam poucos dados, e uma tela que só quebra com 50 linhas não quebra no teste; e "aprovado, sem achados" não exigia dizer o que tinha sido conferido. Ele ganhou um checklist de legibilidade e checagens de acessibilidade logo depois, mas um revisor filtra o óbvio. Em uma tela nova, quem sabe se ela ficou boa sou eu.
A POC era a especificação
Uma das tarefas de correção pedia, com essas palavras, que a tela do app ficasse parecida com a POC aprovada, em escala real. Ou seja, o bom resultado já existia antes de a etapa começar. O fluxo tratou a POC como inspiração, não como especificação, e o agente reinventou a tela.
A ideia do capítulo continuava de pé, só que em outro lugar. O incremento funcionando era mesmo a especificação mais barata: era a POC. O erro foi não amarrar a etapa a ela. Na noite seguinte, uma execução levou o layout e a geometria da POC para o app, e outra deu à cidade a tela cheia.
Quanto custa descobrir o erro
O experimento mostrou que a pergunta estava mal feita. Não era "refinar antes ou reagir depois". Era quanto custa descobrir o erro, e quem descobre.
No motor, nos testes e nos fluxos de trabalho, os testes acham o erro sozinhos, e o conserto é uma volta curta dentro da mesma execução. Ali, reagir depois ganha fácil. Em uma tela nova, só eu acho o erro, abrindo o app, e cada conserto vira uma tarefa nova com testes, revisão e integração atrás. Interface pede muitas voltas curtas de "olha e ajusta", e o fluxo completo deixa cada uma cara. Na interface, o juiz sou eu.
A regra que ficou:
- 🤖 Tela nova nasce em uma POC: em uma sessão à parte, comigo olhando, até ficar aceitável.
- 🤖 A POC vira a especificação: a tarefa leva a captura de referência e o código da POC, roda em Validated, e a revisão compara lado a lado.
- ⚙️ O Automático fica com o resto: com o que um teste consegue julgar.
Nunca começar sem design system
A outra metade do estrago tinha uma causa mais antiga. O aplicativo nunca teve um design system, o conjunto de componentes prontos e regras visuais que todas as telas usam. Cada lista de opções foi escrita do jeito que o agente da vez achou melhor. Eram 74, espalhadas por 27 arquivos, além de oito campos de data, nenhum com estilo no tema escuro. Uma tela torta não era uma correção. Eram 74.
"Isso vai virar um aprendizado: nunca iniciar um projeto sem um design system, nem que seja um da internet, algum conhecido. Agora o projeto está gigante, vou ter que passar refatorando, e imagina o custo de IA no front-end para buscar todos os selects nos arquivos e ler tudo isso."
O custo talvez nem fosse tão alto. Achar os 74 lugares é trabalho de uma busca de texto, não de uma IA lendo arquivo por arquivo: o agente escreve uma vez a regra da troca, testa em alguns arquivos, e o código aplica o resto. E a IA levantou uma hipótese ainda mais barata: parte do branco vinha de uma única linha que faltava na folha de estilo base, a que avisa o navegador que o app é escuro.
Um design system só vale se alguém conferir; uma regra só escrita foi exatamente o que o revisor aprovou. Dois dias depois do experimento, o app ganhou um componente único de lista de opções, um campo de período com atalhos, checkbox de 18 pixels e uma trava do motor que acusa quando um controle cru volta ao código das telas. Para um projeto novo, ficou uma lista curta:
- Design system no primeiro commit: um conhecido, com o tema escuro definido e as cores e medidas em um arquivo só.
- Trava que acusa: o código das telas não aceita controle cru nem cor fixa fora desse arquivo.
- Acessibilidade nos testes de tela: contraste baixo e alvo de clique pequeno são pegos sem IA.
- A regra escrita para os agentes: no arquivo de instruções que todo agente lê ao começar.
O próximo passo
Este capítulo terminou com regras novas no código. Mas houve um conserto que nenhuma trava previu. Na primeira noite, às 22h23, uma segunda cópia do aplicativo bagunçou o roadmap, e quem consertou foi a própria IA, lendo os arquivos do estado do app.
No próximo capítulo, capítulo 8, Um sistema que a IA lê, a IA conserta, conto esse susto e por que guardar o estado em arquivos que uma IA consegue ler virou uma decisão de arquitetura.