você não precisa de um modelo mais inteligente, precisa ser mais inteligente

Capítulos

Vou começar confessando um vício meu: durante meses, toda vez que um projeto travava, minha primeira reação era trocar de modelo. O DeepSeek alucinou? Vamos de Gemini Flash. O Flash ficou burro no contexto longo? Testa o GPT 5.5. O 5.5 comeu minha cota? Tem o Luna, tem promoção, tem cota grátis ali e aqui. Eu colecionava LLMs como quem coleciona chave de fenda achando que o problema é a ferramenta — quando na verdade eu estava tentando montar um móvel sem olhar o manual. Que eu mesmo nunca tinha escrito.

Esse texto é um rant, mas é um rant com carinho. Porque eu era exatamente a pessoa para quem ele se aplica.

O sintoma: trocar de modelo

Repara no padrão: o código sai ruim, e a conclusão é “preciso de um modelo mais inteligente”. Quase nunca é “preciso pensar melhor no que estou pedindo”. Um modelo fraco com um projeto bem pensado produz mais que um modelo forte pastando num repositório sem rumo. Eu sei porque testei dos dois jeitos, várias vezes, e o segundo cenário me fez perder mais tempo do que eu gostaria de admitir.

Funciona assim: sem requisitos claros, sem arquitetura, sem contexto, o agente — qualquer agente, do mais barato ao mais caro — vai preencher as lacunas com adivinhação estatística. E adivinhação estatística em cima de um projeto confuso gera código confuso com muita confiança. Aí você troca de modelo e ganha uma versão diferente do código confuso. Parece progresso. Não é.

A pergunta que mudou meu jogo foi simples: e se o gargalo não for a inteligência do modelo, mas a qualidade do que eu entrego para ele mastigar?

Pensar antes de codar

Antes de abrir o editor, eu hoje me obrigo a responder por escrito: o que esse projeto resolve, para quem, o que está fora do escopo, quais são as fronteiras que não podem ser quebradas e qual é o menor experimento que prova a ideia. Parece burocracia. Na prática, é o contrário: é o que me deixa codar rápido depois, porque as decisões difíceis já foram tomadas com a cabeça fria.

Cada projeto meu pagou essa lição de um jeito. No Petunia3D, eu demorei para separar o renderer 3D da interface — e cada semana sem essa fronteira gerava acoplamento que depois custava dias para desfazer. No HummTube, decidir “local-first, sem conta obrigatória” antes do código definiu o banco, o sync (que não existe) e metade da arquitetura de graça. No TidyFlow, os requisitos de “mostrar o que aconteceu, o que está rodando e o que vai rodar” viraram a interface inteira. Nenhuma dessas decisões veio de um modelo mais inteligente. Todas vieram de pensar antes.

Tecnologias entram na mesma conta. Eu comparo a opção óbvia, uma ou duas alternativas e alguma coisa experimental — e escolho a que encaixa nas restrições deste projeto, não a “melhor” em abstrato. Stack não é religião, é resposta a restrições. Quando você sabe quais são as suas restrições, até modelo barato acerta.

Documentação para dois públicos

Aqui vai a parte que mais me empolga: documentação boa não é mais um favor para o “eu do futuro”. Ela alimenta dois públicos ao mesmo tempo — humanos e agentes de código. E o interessante é que o que ajuda um ajuda o outro: fronteiras explícitas, decisões com motivo registrado, exemplos pequenos e completos, contratos claros.

Foi nessa trilha que o Prumo evoluiu. A ideia central — repositório como fonte de verdade, estado canônico em Markdown e Git, adapters por ferramenta — ganhou muito quando eu estudei o ai-memory do Akita. O projeto dele resolve o mesmo tipo de dor por outro ângulo: memória de longo prazo para agentes, handoff entre ferramentas diferentes, wiki em Markdown puro que pode ser lido com grep, sem cerimônia. Ver alguém experiente chegando a conclusões parecidas (fonte de verdade em arquivos comuns, handoff como protocolo e não como convenção) me deu confiança de que eu estava na direção certa — e várias ideias boas para roubar com orgulho e citar a fonte, como estou fazendo agora.

Arquitetura de projeto e arquitetura de documentação, para mim, viraram a mesma disciplina: decidir o que existe, onde mora, quem pode mudar e como se descobre isso sem perguntar para ninguém.

Seis meses de Ori-lang

Nada me ensinou “planejamento estratégico primeiro” como passar seis meses desenhando uma linguagem de programação. Na Ori, cada decisão sintática arrasta consequências para o parser, os tipos, o codegen e o tooling — errar no começo custa meses no fim. Fui obrigado a desenvolver o músculo de pensar antes: especificação aberta, manifesto, cada feature justificada por escrito antes de existir.

O efeito colateral foi ótimo: esse músculo vazou para todos os outros projetos. Hoje eu estranho começar qualquer coisa sem um documento de uma página dizendo o que é, o que não é e como vou saber se funcionou. Seis meses atrás eu achava isso frescura. Hoje eu acho que é o motivo de eu conseguir tocar seis projetos ao mesmo tempo sem enlouquecer — bem, sem enlouquecer muito.

Manual de estratégia de um dev com IA pobre

Vamos ao prático, porque rant sem tática é só desabafo. Eu desenvolvo gastando o mínimo possível, e funciona — desde que o planejamento faça o trabalho pesado. O manual, testado na marra:

Modelo fraco + contexto forte vence modelo forte + contexto fraco. Um DeepSeek Flash ou um Gemini Flash com requisitos claros, exemplos e fronteiras definidas entrega mais que um top de linha adivinhando. Contexto é o multiplicador; o modelo é só a base.

Use cada modelo para o que ele faz de barato. Rascunho e exploração nos baratos e nas cotas grátis; revisão e decisão final onde vale gastar. Eu rodo o grosso no barato e guardo os créditos para os momentos que realmente precisam de força bruta.

Aproveite tudo que é grátis sem culpa. Cotas do OpenCode, freebuff, Antigravity, promoções de planos, tiers gratuitos — tudo isso é orçamento de experimentação. O truque é experimentar barato e decidir caro: testar ideias nos gratuitos, consolidar nos pagos quando (e só quando) a ideia provou valor.

Documentação é economia direta. Cada decisão registrada é uma ida-e-volta a menos com o agente. Cada exemplo canônico é um prompt a menos para escrever. Eu pago minutos escrevendo contexto e economizo horas — e dólares — de geração.

Protótipo descartável antes do caminho oficial. Antes de comprometer a arquitetura, um experimento pequeno e jogável responde mais que dez discussões. Barato de rodar, barato de jogar fora.

Nada disso exige o modelo do momento. Exige pensar antes — que, felizmente, continua de graça.

O Akita já avisou

Se algo aqui soou familiar, é porque o Akita martela essas ideias há anos: aprender a aprender, não terceirizar decisões, sofrer o desconforto em vez de caçar fórmula mágica. O vídeo abaixo é o famoso rant dele sobre o assunto — uma hora de bronca necessária, e uma das inspirações para eu parar de procurar atalhos e começar a construir fundação:

No fim, o rant inteiro cabe numa frase, e ela é o título do texto: você não precisa de um modelo mais inteligente. Precisa chegar para o modelo — qualquer modelo — já sendo mais inteligente sobre o seu próprio projeto. Planeja primeiro, documenta sempre, decide com trade-offs na mesa. O resto é consequência. E se doer um pouco no começo, ótimo: como diria o Akita, se não está doendo, você não está tentando com força o suficiente.