Eu peço uma bicicleta e a IA me traz um foguete

Tem uma coisa que me incomoda quando uso IA para resolver problemas técnicos: os modelos costumam propor uma solução muito mais complexa do que o necessário, logo de cara. Aí eu sempre fico na dúvida se pedi errado ou se o problema era mais difícil do que eu pensava.

Depois de um tempo quebrando a cabeça e pesquisando, entendi que os modelos de linguagem têm um viés para a complexidade em alguns casos.

As três causas para o problema

Os modelos costumam ir na versão mais elaborada quando você pede ajuda técnica: sugerem infraestrutura, abstrações e ferramentas novas, mesmo quando o problema era relativamente simples de resolver.

Entendi três causas pra isso.

Primeira: os modelos puxam para o que é mais comum no treinamento, independente de ser a melhor opção para o seu caso. Um estudo recente mostrou que assistentes de código têm viés para linguagens e ferramentas populares. Uma das bibliotecas mais comuns de análise de dados aparece em até 48% das sugestões, mesmo quando há alternativa mais simples. A solução elaborada que os modelos propõem muitas vezes é só a mais frequente nos dados de treino.

Segunda: quanto mais contexto você despeja no prompt, mais confusa e complicada tende a ser a resposta. Limitar o escopo a poucos exemplos bem definidos melhora a qualidade da sugestão. Mais informação não é mais qualidade.

Terceira: a própria Anthropic reconhece, na documentação dos modelos Claude atuais, que eles têm tendência a criar arquivos extras, abstrações desnecessárias e configurabilidade não solicitada. A recomendação interna é instrução explícita de escopo para conter isso. Sem ela, o modelo adiciona por padrão.

Ninguém faz overengineering de propósito. Costuma ser o oposto: o cuidado de antecipar todo cenário possível, a empolgação de usar a ferramenta certa. O modelo imita o que aprendeu com humanos. E humanos fazem isso o tempo todo.

O problema que você ainda não tem

Overengineering é resolver um problema que você ainda não tem.

Essa definição virou um filtro pra mim. Antes de aceitar qualquer sugestão dos modelos, eu me pergunto: eu realmente tenho esse problema? Se a resposta não for imediata, a solução provavelmente está resolvendo algo que não existe ainda.

O Addy Osmani, ex-engenheiro do Google, tem um enquadramento que ajuda:

“Usar IA bem é como gerenciar um programador júnior muito rápido, mas ingênuo. Quase tudo que torna alguém sênior (como desenhar sistemas, gerenciar complexidade e saber o que vale automatizar versus fazer à mão) é exatamente o que produz os melhores resultados com IA.”

A IA gera o conteúdo, mas o critério de aceitar ou não é seu. Quem não exerce esse critério acaba herdando a complexidade dos modelos como se fosse necessidade real.

O filtro SIMPLES

Para operacionalizar esse critério, uso um filtro antes de aceitar qualquer solução que o modelo propõe:

• Solução mínima primeiro. Sempre o menor caminho que resolve o problema declarado. A pergunta de partida: “qual a solução mais simples possível, sem nada a mais?”

• Impor restrições explícitas. O modelo obedece limite explícito melhor do que adivinha preferência. Diga o que não usar: sem servidor novo, sem ferramentas que você não tem.

• Manutenção como critério. A pergunta que desarma overengineering não é “isso funciona?” mas “o que dá menos trabalho daqui a seis meses?”. Capacidade impressiona na hora, mas é a manutenção que vai custar.

• Por quê obrigatório. “Só proponha algo mais complexo se explicar por que o simples não serve.” Transforma complexidade de default em escolha consciente.

• Lado a lado. Peça duas versões: a mínima e a “ideal”, cada uma com custo de setup e manutenção estimados. Ver lado a lado decide por você.

• Escopo travado. Só o que foi pedido. Sem features extras, sem melhorias não solicitadas. Escopo novo: o modelo pergunta antes de adicionar.

• Subir em camadas. Não peça a solução completa de uma vez. Um pedaço de cada vez: você implementa, testa e avança. Isso impede a torre que nasce de um pedido único e ambicioso demais.

Como aplicar agora

Tem dois modos.

Se quiser testar no próximo pedido, cole isso antes de descrever o problema:

“Antes de propor qualquer solução: me dê a versão mínima que resolve só o que pedi, sem infra ou ferramentas novas. Se algo mais complexo valer a pena, mostre como segunda opção e justifique com o custo de manutenção de cada uma.”

Se quiser como regra permanente, adicione nas instruções do sistema do modelo que você usa:

“Default to the minimal solution for the stated problem. No new infrastructure, abstractions, or scope I didn’t request. Optimize for low maintenance, not capability. If more complexity seems warranted, present it as a labeled second option with a why and a maintenance cost.”

A segunda forma é mais poderosa porque tira de você o esforço de lembrar de perguntar. O filtro passa a ser o padrão.

O que separa quem usa de quem obedece

Toda a conversa sobre prompting gira em torno de extrair mais do modelo: escrever melhor, com mais contexto, com mais detalhe. O maior ganho, em muitos casos, está na direção contrária: filtrar o que o modelo entrega.

A IA é muito boa em produzir. Mas ela é muito menos calibrada para produzir o necessário.

A pergunta que separa quem usa IA bem de quem apenas executa o que o modelo sugere é a mesma do início: eu realmente tenho esse problema, ou estou construindo para um que ainda não existe?

O fluxo elaborado do começo morre nessa pergunta. A maior parte da complexidade que a IA sugere também.

Publicado originalmente na edição #34 da Modo IA.