- Início
- The Thinking Wire
- O Número Medido Foi US$ 12 Mil. O Resto Era Uma Linha de Base Que Ninguém Rodou.
O Número Medido Foi US$ 12 Mil. O Resto Era Uma Linha de Base Que Ninguém Rodou.
A OpenAI publicou um case declarando US$ 5,9 milhões de economia na migração da Asana do Enzyme para a React Testing Library. Gergely Orosz foi atrás da parte medida desse número e encontrou cerca de US$ 12 mil, gastos ao longo de aproximadamente duas semanas (The Pulse: we need to talk about migrations with AI, agosto de 2026).
Os dois números podem ser verdadeiros ao mesmo tempo. Os US$ 12 mil são um custo que foi incorrido e deixou comprovante. Os US$ 5,9 milhões são uma subtração, e aquilo de que se subtrai é um projeto que nunca foi executado.
Todo número de economia tem uma metade medida e uma metade imaginada
A metade medida é o que o trabalho custou: tokens, horas de engenheiro, tempo de calendário. Alguém pode ir lá conferir.
A metade imaginada é o contrafactual. É quanto o mesmo trabalho teria custado sob uma abordagem que ninguém executou. Ela não deixa artefato, nem apontamento de horas, nem histórico de commits. Um contrafactual é inauditável por construção, e nenhuma dose de diligência muda isso, porque do outro lado da diligência falta o que encontrar.
Nada disso está escondido. A palavra economia é comparativa e pressupõe uma alternativa. A pressuposição fica sem exame porque um valor em dólar é lido como medição, venha de onde vier.
No caso da Asana, a metade medida são US$ 12 mil contra uma manchete de US$ 5,9 milhões. Isso dá algo em torno de 0,2% do número que o leitor leva embora. Os 99,8% restantes são a estimativa de um projeto que não existe.
De onde saíram os US$ 6 milhões
Segundo Orosz, a linha de base era de cinco anos e US$ 6 milhões, construída a partir de quatro engenheiros a aproximadamente US$ 300 mil por ano. A aritmética se sustenta. Quatro engenheiros a US$ 300 mil por ano ao longo de cinco anos dá algo próximo de US$ 6 milhões, então nada está sendo forçado dentro do modelo.
A premissa embaixo do modelo é que carrega todo o peso. A leitura de Orosz sobre a estimativa é que ela provavelmente assumiu que “um engenheiro em tempo integral conseguiria migrar no máximo X testes por dia, com X entre 5 e 10”. Essa é a inferência dele sobre a produtividade implícita. Ninguém mediu essa taxa. Mexa nessa premissa e a manchete inteira se move junto. Assuma o dobro de produtividade e cerca de metade da economia declarada evapora, sem que um único fato sobre a migração real tenha mudado.
Um auditor consegue verificar a multiplicação. A premissa escapa dele, porque carece de referente no mundo.
O cliente voltou atrás na linha de base
Dan Ubilla, da Asana, confirmou depois ao The Pragmatic Engineer que os US$ 6 milhões eram “uma estimativa de guardanapo”. Ela assumia uma migração totalmente manual, sem ganhos de eficiência e sem uso de LLM na conta, e ele a classificou como “provavelmente uma superestimativa”.
Essa correção é o que torna o caso digno de guardar. Alguém do lado do cliente, sem nada a ganhar com o número menor, disse que a linha de base era grande demais. Normalmente ninguém está posicionado para dizer isso. O número foi publicado pelo fornecedor e classificado pelo cliente como estimativa de guardanapo, e nenhum dos dois lados tem artefato que resolva a questão. O cliente, por sua vez, carece de motivo para revisitá-la depois que o case é publicado. Então o número viaja, sem correção, para dentro de apresentações e conversas de conselho, onde é tratado como medição.
Essa é uma falha diferente da que aparece em o viés do fornecedor nas métricas de produtividade de IA. Lá, o instrumento era calibrado por uma parte interessada na leitura. Aqui o instrumento está correto e o ponto de referência é ficcional. As duas situações produzem um número que não sobrevive a auditoria, por razões sem relação entre si.
O que a metade medida sustenta de verdade
US$ 12 mil e duas semanas já é um número com qualidade de decisão. Ele diz ao comprador quanto custa tentar a mesma classe de trabalho, qual a ordem de grandeza do compromisso e por quanto tempo o time fica exposto antes de descobrir se a abordagem se sustenta. Um CTO consegue orçar contra isso. Se a abordagem estiver errada, a falha aparece dentro dessas mesmas duas semanas.
Os US$ 5,9 milhões ficam de fora de qualquer decisão. Como orçamento, falham: ninguém vai pagar esse custo. Como comparação entre fornecedores, falham: cada fornecedor escolhe a própria linha de base. Como justificativa para um plano de quadro de pessoal, falham: os quatro engenheiros daquele modelo nunca foram contratados. Funcionam como sinal de grandeza numa manchete e param aí.
Vale sentar com essa assimetria. O número pequeno é o que tem evidência atrás. O número grande é o que viaja, e o número grande é o que termina no slide.
As migrações em si são reais
Nada disso torna o trabalho pouco impressionante. Orosz argumenta o contrário: a IA de fato viabiliza migrações que antes eram impraticáveis, e reduz o peso de sustentar sistemas legados enquanto uma transição está em curso. Isso é uma mudança concreta na economia da engenharia, e ela não depende de os US$ 5,9 milhões estarem certos.
Os outros dois casos que ele cita têm o mesmo formato. O Airbnb migrou 3.500 arquivos de teste em seis semanas, em 2025, contra uma estimativa de 1,5 ano-engenheiro de esforço manual. A Uber migrou 600 mil testes unitários em 15 milhões de linhas de código em quatro meses com dois engenheiros, modificando 1,25 milhão de linhas no processo.
A divisão aparece em cada um deles. Contagem de arquivos, de testes, de linhas, de engenheiros, meses decorridos: medidos. O 1,5 ano-engenheiro contra o qual o Airbnb comparava: estimativa de algo que ninguém fez. A metade medida diz ao comprador que o trabalho é alcançável naquela escala, e esse é o sinal útil. A metade imaginada diz ao comprador o que alguém quer que ele acredite sobre o caminho não percorrido.
Faça isto agora
Na próxima vez que um número de economia chegar à sua mesa, venha ele de um fornecedor, de uma consultoria ou do seu próprio time, faça uma pergunta antes de qualquer outra:
Qual metade deste número foi medida, e qual metade é uma linha de base que ninguém rodou?
Depois, as duas perguntas que tornam a resposta utilizável. Quanto o trabalho custou de verdade, em tokens, horas e tempo de calendário? E quem produziu a linha de base, assumindo qual produtividade?
Se a resposta à primeira pergunta for um custo medido pequeno e um custo imaginado grande, o número não está errado. Ele é a colagem de dois tipos distintos de afirmação sob um único cifrão, e só um deles tem evidência atrás. Cite a metade medida. Trate o contrafactual como opinião de quem o escreveu, e pergunte a essa pessoa qual taxa ela assumiu.
Organizações que pulam esse passo acabam tomando decisões reais contra linhas de base imaginadas. É assim que uma alegação de produtividade vira um corte de pessoal que ninguém auditou, e é assim que uma narrativa de substituição falha na própria auditoria quando alguém finalmente confere. O caso da Asana é a única correção desse tipo que vi publicada, vinda do cliente e registrada. Na maior parte das vezes a pergunta precisa partir do comprador.
Fontes
- The Pragmatic Engineer (Gergely Orosz). “The Pulse: we need to talk about migrations with AI.” Agosto de 2026.
A Victorino ajuda conselhos e CTOs a separar a metade medida de uma alegação de ROI de IA da metade contrafactual: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa