A pergunta
O que acontece quando você dá a um desenvolvedor uma ferramenta de AI realmente boa e mede tudo?
Eu queria saber. Não via anedotas (“a AI me poupou horas!”), não por demos de YouTube. Por dados. Com baselines reais, tracking de horas, controle de variáveis. Um experimento de verdade.
O contexto era favorável: sou Tech Lead na Cadastra e tinha um projeto FastStore novo (Herbíssimo), dois devs bons que toparam o desafio, e acesso ao histórico de 13 projetos FastStore anteriores pra usar como comparação. Só faltava a infraestrutura - e essa eu projetei.
O nome veio natural. Montamos o time e eu pensei: somos quase os Avangers… Ou melhor: os AIVengers! A missão? Caçar o Thanos que estala os dedos e metade do orçamento dos projetos desaparece. Os superpoderes? Prompts, tokens e engenharia de contexto.
O que projetei
Um experimento científico não começa com ferramentas - começa com hipótese e método.
Defini três baselines de comparação: a proposta comercial do projeto, a mediana histórica dos 13 projetos anteriores, e a estimativa granular do Jira tarefa a tarefa. Qualquer ganho medido teria que ser ganho contra os três, simultaneamente.
Escolhi Claude Code Max 5x como ferramenta principal - não por fidelidade de marca, mas porque era o único com suporte nativo a Figma MCP e context window de 200K de verdade, sem compressão silenciosa. Isso importava porque minha hipótese dependia do contexto: a AI só é útil se ela “sabe” o que está fazendo. Configurar esse contexto foi o trabalho central.
Escrevi o CLAUDE.md de cada dev com as convenções do projeto, os padrões do design system, as limitações conhecidas do FastStore, e links diretos pra documentação técnica do cadastra-docs. Defini como o Figma MCP seria usado em cada tipo de componente. Criei um script (ai-tokens) pra rastrear consumo de tokens em tempo real - sem isso, qualquer análise de custo seria estimativa. Montei um Google Sheets com Apps Script pra logging diário de horas por tarefa. E documentei o framework metodológico completo antes de começar, não depois.
Foram 17 dias úteis. Dois devs. Um projeto real com cliente real e deadline de verdade. Eu não estava desenvolvendo - estava gerenciando o experimento, fazendo code review, resolvendo impedimentos arquiteturais, e ajustando a engenharia de contexto ao longo do processo quando algo não funcionava como esperado.
O que encontrei
Os devs terminaram o projeto com 53% das horas estimadas. Não foi um dev - foram os dois, com resultados consistentes (50% e 54%). A AI não ajudou mais quem era melhor; ela liberou os dois de formas parecidas.
O que mais me surpreendeu não foi a velocidade. Foi o que a velocidade permitiu. Com mais tempo sobrando, os devs pararam de cortar caminho. Código mais limpo, menos gambiarras, taxa de fix de apenas 10% nos commits. Quando você não está correndo, você faz melhor.
Os componentes visuais foram os que mais ganharam (79-88% de redução). Componentes estruturais, intermediários (30-54%). Páginas complexas com lógica proprietária VTEX, pouco (10-15%). Isso faz sentido: a AI resolve bem o que tem padrão claro, e mal o que exige conhecimento proprietário que não está no seu contexto. Essa variação me confirmou que o contexto que eu havia preparado era o fator determinante - não a ferramenta em si.
O que não funcionou como esperado
Nem tudo foi ganho. Teve task que a AI gerou código errado e o dev perdeu tempo consertando o que ela inventou. Teve momento em que o dev ficava mais ocupado calibrando prompts do que desenvolvendo. E teve o risco real de exposição de credenciais - a AI não distingue um .env de um componente React, e se você não configura os limites certos, ela joga segredo no commit sem pestanejar.
Documentei cinco riscos ao longo do experimento e como cada um foi mitigado. Nenhum era fatal, mas todos exigiam atenção ativa. A AI não se auto-corrige. O trabalho de engenharia de contexto não termina quando o CLAUDE.md está escrito; ele continua durante todo o projeto, ajustando o que a ferramenta sabe e o que ela não deveria tocar.
A variação de resultado por tipo de componente revelou algo que eu suspeitava mas agora tinha dados pra confirmar: o fator determinante não é a ferramenta, é o contexto que alimenta ela. Os componentes com maior redução de tempo eram exatamente os que tinham mais documentação no cadastra-docs: padrões documentados, código-fonte linkado, soluções reutilizáveis. Os que tinham lógica proprietária da VTEX, sem documentação pública acessível, quase não ganharam nada. A infraestrutura de conhecimento que construí antes do experimento foi o que tornou os resultados possíveis. Sem ela, a AI estaria operando no escuro.
O que isso virou
O experimento gerou 28 documentos técnicos que ficaram no cadastra-docs - desde a metodologia e o framework experimental até a análise granular por tipo de componente, comparativo de ferramentas e um plano de expansão pra VTEX IO. Virou o processo padrão de desenvolvimento AI-assistido na Cadastra, com CLAUDE.md por projeto e engenharia de contexto como etapa formal do kickstart.
Mas o que mais importa pra mim é mais simples: eu queria saber se a pergunta tinha resposta. Tem.
Piloto: Herbíssimo (Dana Cosméticos) Infraestrutura: Cadastra Docs