🤖 AI

Five Fatal Assumptions: Why T-Shirt Sizing Systematically Fails for AI Projects

Este artigo demonstra que o método de estimativa por tamanhos de camiseta falha sistematicamente em projetos de IA devido a cinco pressupostos inadequados e propõe a "Medição por Marcos" (Checkpoint Sizing) como uma abordagem iterativa e baseada em aprendizado para gerenciar a incerteza inerente ao desenvolvimento de inteligência artificial.

Autores originais: Raja Soundaramourty, Ozkan Kilic, Ramu Chenchaiah

Publicado 2026-02-23

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Raja Soundaramourty, Ozkan Kilic, Ramu Chenchaiah

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um gerente de projetos tentando estimar quanto tempo levará para construir algo novo. No mundo do software tradicional, usamos um método chamado "Tamanhos de Camiseta" (Pequeno, Médio, Grande, Extra-Grande). É como pedir uma roupa: se você já fez uma camiseta "Média" antes, sabe que a próxima "Média" vai demorar mais ou menos o mesmo tempo e usar a mesma quantidade de tecido.

Este artigo, escrito por especialistas da Cisco, diz que essa lógica funciona perfeitamente para construir casas ou pontes, mas falha miseravelmente quando tentamos usá-la para criar Inteligência Artificial (IA).

Aqui está a explicação simples, usando analogias do dia a dia:

O Problema: O Mapa do Mundo Antigo vs. O Território Selvagem da IA

A IA (especialmente os modelos de linguagem como o que você está usando agora) não segue as regras de construção tradicionais. O artigo diz que existem 5 "Assunções Fatais" (crenças erradas) que nos levam a errar feio nos prazos e orçamentos de projetos de IA.

Vamos ver cada uma delas:

1. A Ilusão da Escada Reta (Escalonamento Linear)

A Crença: "Se eu dobrar o tamanho do projeto, o trabalho dobra." (Como construir duas casas iguais).
A Realidade da IA: A IA é como tentar subir uma montanha onde, quanto mais alto você chega, mais íngreme a subida fica.
- Analogia: Se você quer melhorar a precisão de um GPS de 85% para 95%, não é apenas um "pequeno ajuste". Pode exigir o dobro de dados, o triplo de computadores e meses de testes. O último 1% de perfeição custa mais do que os primeiros 90%. Na IA, o "último quilômetro" é na verdade uma maratona.

2. A Armadilha da Memória (Repetibilidade)

A Crença: "Já fizemos um chatbot de RH, então sabemos quanto tempo leva para fazer um de Suporte Técnico."
A Realidade da IA: Cada conjunto de dados é um universo novo e desconhecido.
- Analogia: É como se você fosse um cozinheiro. Você sabe cozinhar um bife perfeitamente. Mas isso não significa que você sabe cozinhar um peixe raro do fundo do mar sem nunca ter visto um. Na IA, os dados (o "ingrediente") podem estar sujos, enviesados ou cheios de erros que só aparecem quando você começa a "cozinhar" (treinar o modelo). Você nunca sabe o que vai encontrar até abrir a geladeira.

3. A Falsa Troca de Tempo e Pessoas (Fungibilidade)

A Crença: "Se o projeto vai levar 8 semanas com 1 pessoa, vai levar 4 semanas com 2 pessoas."
A Realidade da IA: Algumas etapas da IA são como uma fila única em um banco; você não pode colocar 10 pessoas na frente do caixa para atender o cliente mais rápido.
- Analogia: Imagine que você precisa esperar a massa do bolo assar. Não importa se você coloca 10 padeiros na cozinha; o forno ainda leva 40 minutos. Na IA, treinar o modelo e esperar os dados serem processados são "tempos mínimos" que não encolhem só porque você contratou mais gente.

4. O Efeito Dominó (Decomposição de Tarefas)

A Crença: "Podemos dividir o projeto em partes: um time faz a interface, outro o banco de dados, outro o modelo. No final, juntamos tudo."
A Realidade da IA: Tudo na IA está "colado" com supercola. Mudar uma coisa pequena em um lugar quebra tudo em outro.
- Analogia: Em um software normal, trocar a cor do botão é fácil. Na IA, mudar a cor do botão pode exigir que você reescreva a lógica do cérebro do robô, que por sua vez exige novos dados, que exigem nova limpeza. É como tentar trocar uma peça em um relógio suíço sem desmontar o resto: tudo está conectado de forma invisível.

5. O Alvo que Foge (Critérios de Conclusão)

A Crença: "O projeto está pronto quando o teste passa e o código é enviado."
A Realidade da IA: O "pronto" é uma ilusão. O que era seguro ontem pode ser perigoso hoje.
- Analogia: Imagine que você construiu um carro. Você acha que está pronto porque ele anda. Mas, no dia seguinte, descobre-se que o carro tem tendência a falar palavrões com crianças ou dirigir sozinho para o lado errado. Na IA, você pode ter um modelo que funciona perfeitamente, mas que falha em testes de segurança ou ética que só surgem depois de meses de uso. O projeto "terminado" de sexta-feira vira um "gigante" (XL) na segunda-feira.

A Solução: O "Sizing por Checkpoints" (Parar e Verificar)

Como resolver isso? Os autores propõem abandonar a ideia de "adivinhar o tempo todo no início" e adotar o Sizing por Checkpoints.

Em vez de dizer "Isso vai levar 3 meses" no dia 1, você trata o projeto como uma expedição de exploração:

Defina Paradas de Segurança (Checkpoints): Em vez de um plano rígido, você cria portões de decisão.
- Portão 1: Os dados estão limpos? Se não, pare e limpe.
- Portão 2: O modelo aprendeu o básico? Se não, ajuste a estratégia.
- Portão 3: O robô está seguro? Se não, pare e corrija.
Reavalie a cada passo: Só depois de passar por um portão e ver os resultados reais é que você estima o tempo para o próximo.
Esteja pronto para desistir ou mudar: Se nos dados você descobrir que o projeto é impossível ou muito caro, você para antes de gastar meses.

Resumo Final

A IA não é como construir um prédio onde você sabe exatamente quantos tijolos precisa. A IA é como tentar domar um animal selvagem. Você não sabe exatamente quanto tempo vai levar, nem quantas pessoas são necessárias, até tentar.

O artigo nos ensina a parar de usar "Tamanhos de Camiseta" (que são estáticos) e começar a usar Bússolas e Paradas de Checagem (que são dinâmicas), reconhecendo que, na IA, o mapa só se desenha enquanto você caminha.

Resumo Técnico: Por que o Dimensionamento por Camisetas Falha Sistematicamente em Projetos de IA

1. O Problema

As técnicas de estimativa ágil tradicionais, especificamente o Dimensionamento por Camisetas (classificação de tarefas em S, M, L, XL), são amplamente utilizadas no desenvolvimento de software devido à sua simplicidade e utilidade no escopo de trabalho. No entanto, a aplicação desses métodos a iniciativas de Inteligência Artificial (IA) — particularmente aquelas envolvendo Modelos de Linguagem de Grande Escala (LLMs) e Sistemas Multi-Agentes — resulta em estimativas sistematicamente enganosas.

O problema central não é a falta de habilidade das equipes, mas a incompatibilidade dos modelos mentais. O dimensionamento por camisetas assume um mundo de software determinístico e linear, enquanto o desenvolvimento de IA é caracterizado por incerteza dependente de dados, comportamentos não lineares e falhas emergentes. Isso leva a:

Projetos que se expandem por meses além do previsto.
"Paredes técnicas" imprevistas (ex: degradação de desempenho em conversas multi-turno).
Subestimação crítica de esforço devido à complexidade de integração e validação.

2. Metodologia

Os autores (Raja Soundaramourty, Ozkan Kilic e Ramu Chenchaiah, da Cisco Systems) utilizaram uma abordagem de síntese estruturada para identificar e validar as falhas das estimativas tradicionais:

Síntese de Métodos de Estimativa: Revisão de práticas ágeis canônicas (pontos de história, poker de planejamento) para extrair premissas implícitas.
Ancoragem em Fluxos de Trabalho de IA: Contraposição dessas premissas com características documentadas de workflows de ML/IA (dependência de dados, iteração experimental, dívida técnica específica de ML).
Ancoragem Empírica: Mapeamento de cada premissa para evidências empíricas recentes na literatura de LLMs e sistemas multi-agentes (incluindo preprints do arXiv e estudos de engenharia de software), focando em modos de falha, comportamento de escalabilidade e não confiabilidade em conversas longas.
Critérios de Avaliação: Cada premissa foi testada contra três critérios: validade no software tradicional, violação sistemática no contexto de IA e impacto material na estimativa.

3. Contribuições Principais

O artigo faz quatro contribuições fundamentais:

Identificação de 5 Premissas Fatais: Enumeração e análise sistemática das cinco suposições fundamentais do dimensionamento por camisetas que colapsam no contexto de IA.
Fundamentação Empírica: Cada falha é sustentada por literatura recente sobre comportamento de sistemas multi-agentes, propriedades de escalabilidade e fluxos de trabalho de desenvolvimento de IA.
Evidência Quantitativa: Apresentação de métricas concretas, como o crescimento de complexidade de interação $N(N-1)$ em sistemas multi-agentes e uma degradação média de desempenho de 39% em conversas multi-turno.
Novo Framework (Checkpoint Sizing): Proposta de uma metodologia alternativa baseada em evidências, desenhada especificamente para a incerteza inerente aos projetos de IA.

4. Análise das 5 Premissas Fatais e Resultados

O núcleo do artigo detalha como cada premissa tradicional falha:

1. Escalonamento Linear de Esforço:
- Tradicional: Dobrar o escopo dobra o trabalho.
- Falha em IA: O esforço segue uma curva exponencial. Melhorar a precisão de 85% para 95% pode exigir 10x mais dados e computação. Em sistemas multi-agentes, adicionar um agente não adiciona complexidade linearmente, mas multiplica os estados de erro e caminhos de roteamento (complexidade combinatória).
2. Repetibilidade da Experiência Anterior:
- Tradicional: Projetos similares exigem esforço similar.
- Falha em IA: Cada conjunto de dados é território inexplorado ("desconhecidos desconhecidos"). A degradação de contexto em conversas longas e a variabilidade de distribuição de dados tornam a analogia com projetos passados irrelevante.
3. Fungibilidade Esforço-Duração:
- Tradicional: Adicionar pessoas reduz o tempo (até certo ponto).
- Falha em IA: Existem dependências sequenciais irreduzíveis (coleta de dados $\to$ limpeza $\to$ treino $\to$ avaliação). Ciclos de computação e latência de inferência não podem ser comprimidos apenas adicionando pessoal.
4. Decomposição de Tarefas:
- Tradicional: Grandes iniciativas podem ser divididas em fluxos de trabalho paralelos.
- Falha em IA: O acoplamento é "apertado" (tight coupling). Mudanças em pipelines de dados afetam prompts e arquitetura do modelo. Um agente "verborrágico" pode esgotar a janela de contexto compartilhada, degradando o desempenho de outros agentes, criando riscos de integração invisíveis à estimativa por componentes.
5. Critérios de Conclusão Determinísticos:
- Tradicional: "Feito" é binário (testes passam, especificação atendida).
- Falha em IA: A conclusão é probabilística. Critérios de aceitação mudam dinamicamente (ex: taxas de alucinação, viés ético, requisitos legais). O "ponto de chegada" é um alvo móvel, e loops infinitos de correção podem consumir orçamentos sem progresso visível.

5. Solução Proposta: Checkpoint Sizing

Como alternativa, os autores propõem o Checkpoint Sizing, que trata a estimativa como um processo iterativo de descoberta, não um exercício de planejamento inicial.

Princípios:
- Portões de Decisão Explícitos: Reavaliação de escopo e viabilidade em marcos naturais (ex: prontidão de dados, convergência do modelo, validação de segurança).
- Reavaliação Baseada em Evidências: As estimativas são atualizadas com base em artefatos empíricos (ex: relatórios de qualidade de dados, harness de avaliação, testes de segurança), não em analogias.
- Opção de Pivotar: Inclusão de pontos de decisão para reduzir escopo, pivotar ou encerrar o projeto com base nos resultados dos checkpoints.
Gates (Portões) Sugeridos:
1. Prontidão de Dados (qualidade, PII, drift).
2. Harness de Avaliação (taxonomia de tarefas, conjunto de ouro, métricas).
3. Segurança e Confiabilidade (políticas de recusa, controle de loops).
4. Orçamento de Custo e Latência (SLOs, custos por tarefa).
5. Operacionalização (monitoramento, planos de canário).

6. Significado e Impacto

Este trabalho é crucial para gerentes de engenharia, líderes técnicos e proprietários de produtos que planejam iniciativas de IA. Ele demonstra que:

Buffers de tempo não são suficientes: Adicionar 20% a uma estimativa não cobre a natureza exponencial e não linear da IA.
O "Feito" é dinâmico: Em IA, a validação de segurança e governança pode transformar um projeto "concluído" em um projeto XL overnight.
Mudança de Paradigma: A indústria precisa abandonar a ilusão de precisão das estimativas iniciais e adotar um modelo de incerteza controlada, onde o escopo é refinado continuamente à medida que o conhecimento empírico é adquirido.

O artigo conclui que o dimensionamento por camisetas foi projetado para um mundo de escalabilidade linear e padrões repetíveis, e sua aplicação contínua em IA sem adaptações levará a falhas sistêmicas de projeto. O Checkpoint Sizing oferece um caminho prático para navegar essa complexidade.