Um paper publicado em agosto de 2026 deu nome formal a algo que quem trabalha com desenvolvimento orientado a especificação já percebia na prática sem conseguir medir.
O nome é Ambiguity Tax. A pesquisa, assinada por Vu Hung Nguyen e Thanh Nguyen e publicada no arXiv como SDAD: Spec-Driven Agentic Development for the AI-Native SDLC, formalizou a relação entre clareza de especificação e custo de desenvolvimento com agentes de IA. E o dado que surpreende não é a existência do custo. É a forma que ele tem.
A relação não é linear. É exponencial.
O custo que cresce mais rápido do que parece
A fórmula que o paper introduz para o Ambiguity Tax descreve a probabilidade de alucinação como uma função da clareza da especificação. Quando a clareza cai pela metade, o custo não dobra. Sobe muito mais.
O mecanismo é o seguinte. Um agente que recebe uma spec vaga não para para pedir esclarecimento. Ele infere o caminho mais plausível, sintetiza, e entrega. O humano avalia o que chegou, percebe que não era o que queria, corrige a spec, e o ciclo recomeça. Cada volta desse ciclo tem um nome no paper: é o repair multiplier, representado como φ.
Quando φ se aproxima de 1, o agente sintetizou na primeira passagem. Quando φ sobe para 3, 5, 10, o ciclo de correção multiplicou o custo por esse fator antes de o trabalho ter fim.
O número que muda a conta
O paper apresenta uma fórmula de custo total chamada TCI_agentic. Ela multiplica os tokens consumidos pelo φ e soma o custo do trabalho humano de arquitetura e revisão de gates. Quando φ é baixo, o resultado do cálculo ilustrativo é da ordem de USD 600 por módulo equivalente. O custo do mesmo módulo em desenvolvimento humano-ágil convencional: USD 60.000.
A diferença de 99% não é garantida. É condicional. A condição é exatamente o φ baixo, a spec que permite uma passagem única, sem interrupções, sem clarificações no meio do caminho.
Na minha leitura, o que o paper torna explícito é que essa condição não é técnica no sentido convencional. Não depende do modelo escolhido, nem da ferramenta de orquestração. Depende da qualidade do que chegou ao agente antes de ele começar.
A inversão que parece errada na primeira leitura
Quem tem prática em desenvolvimento ágil vai encontrar no paper uma afirmação que parece equivocada na primeira vez que lê. O paper diz que congelar os requisitos, a prática que o Agile tratou por décadas como sinal de projeto antiquado, não é inércia burocrática. É otimização técnica.
O raciocínio é direto. Um pipeline agêntico funciona melhor como uma passagem única e contínua a partir de uma especificação completa e sem ambiguidade. Interrupções e specs parciais degradam a qualidade do output. No desenvolvimento humano, a capacidade de adaptar durante a execução é uma vantagem porque o programador percebe que o requisito estava incompleto e resolve na hora. O agente não resolve. Ele entrega o que a spec pediu, mesmo que a spec estivesse errada.
Isso não é argumento contra a iteração. É argumento sobre onde ela precisa acontecer. Antes da síntese, não durante ela.
O papel que muda de peso
O paper propõe uma mudança de terminologia que revela a mudança de prioridade. O papel que antes se chamava Engenheiro passa a se chamar Spec Architect. A renomeação não é cosmética. Reflete que o trabalho central migrou da autoria de código para a captura de intenção, a elaboração da especificação formal, e a orquestração do pipeline agêntico.
O DORA ROI of AI-Assisted Software Development, publicado em abril deste ano, oferece contexto para entender por que isso importa na prática. Tarefas simples em código novo (greenfield) entregam 30 a 40% de ganho de produtividade com IA. Tarefas complexas em código existente (brownfield) entregam entre 0 e 10%. A diferença não é capacidade do modelo. É a dificuldade de escrever uma spec precisa para um sistema com anos de história, decisões implícitas, e conhecimento distribuído entre pessoas.
O Ambiguity Tax é mais alto exatamente onde o trabalho é mais valioso. O sistema legado que sustenta o negócio não tem uma spec limpa esperando para ser executada. Ela precisa ser construída antes que o agente possa trabalhar com eficiência.
O que fica depois da fórmula
O paper é formal, com equações e métricas de governança, mas a intuição que carrega é simples. A IA não resolve a ambiguidade. Ela a multiplica.
Quando um humano recebe uma tarefa vaga, ele negocia, questiona e ajusta. Quando um agente recebe uma tarefa vaga, ele escolhe um caminho plausível, percorre até o fim, e entrega. O custo do caminho errado não aparece no token de geração. Aparece no loop de correção que vem depois.
O Ambiguity Tax é o que você paga por ter pulado a etapa de clareza antes de acionar o agente. E como a relação é exponencial, a tendência é subestimar o quanto vai pagar até o primeiro ciclo de retrabalho chegar.
A condição para o ganho de 99% não é um modelo melhor. É φ próximo de 1. E φ próximo de 1 exige uma spec que o agente não precise corrigir.