O gargalo nunca foi a IA gerar código, foi decidir o que pedir a ela

Em seis meses, sozinho, sem equipe e sem dinheiro de fora, coloquei mais de 25 sistemas em produção. Não protótipos e não demonstrações: sistemas que continuam rodando sem ninguém segurando a mão deles.

A pergunta que isso levanta é justa e é sempre a mesma — como, mecanicamente, uma pessoa faz isso sem que vire trabalho malfeito em série? O número agregado não responde nada. Três sistemas que dá para abrir e conferir respondem melhor.

A pergunta que mais recebo é "como", e a resposta não é um prompt

Quase toda conversa sobre isso termina numa suspeita de atalho: algum prompt secreto, alguma ferramenta que os outros ainda não descobriram, ou a versão pior, "você trocou gente por IA". Nenhuma das três explica o resultado, e prefiro derrubar as três antes de seguir.

O que o método resolve é uma assimetria simples. IA sem disciplina produz lixo rápido — código que roda na demonstração e desmonta na segunda semana de uso real. Disciplina sem IA produz qualidade devagar, que é como sempre foi. A combinação das duas muda a ordem de grandeza, e só funciona nessa ordem, com a disciplina vindo antes.

Três sistemas que dá para conferir, com número e stack

O PublicPolicyDB coleta documentos públicos, extrai o texto de PDFs e de páginas, classifica cada peça por área de política pública e devolve busca e análise em cima disso. São 8.629 documentos processados, 5.685 PDFs extraídos e 2.944 textos estruturados. A stack é modesta de propósito: Flask, Postgres, Selenium, PyMuPDF.

O Alpha Signal ingere preços de fechamento de ações dos EUA, do Brasil e de cripto e calcula um score composto diário por ativo. São quatro serviços sob Docker — banco, ETL, API e dashboard — e um agendador que dispara doze tarefas por conta própria, todo dia útil. O volume passa de 8 milhões de linhas processadas por dia. Python, Postgres, SQLAlchemy, Docker e Next.js.

O Mt-service é um pipeline de tradução multi-passe integrado ao SDL Trados: extração de segmentos, terminologia setorial, tradução, revisão editorial, QA automatizado e checkpoint humano. Roda 15× mais rápido e 95% mais barato que o processo anterior, com dois passes de QA e relatório em 100% dos jobs. FastAPI, spaCy, WeasyPrint.

Os três têm em comum uma coisa que não aparece em nenhuma stack: alguém escreveu o que eles fariam antes de qualquer um deles existir.

O método tem três peças, e nenhuma delas é ferramenta

A primeira é a spec. Antes de qualquer código, um documento define o que o sistema faz, para quem, com quais critérios de sucesso e sob quais restrições. Parece óbvio e quase ninguém faz. Sem spec, você constrói rápido e refaz ainda mais rápido. Com spec, constrói uma vez.

A segunda é o plano de execução. Cada spec vira uma lista de passos concretos, com dependências mapeadas e um critério de verificação por passo. Não "fazer o frontend", mas o que precisa estar de pé para o passo seguinte começar — e como saber que aquele passo funcionou. É o plano que muda o que a IA consegue fazer por você. Sem ele, o modelo devolve código genérico plausível. Com ele, devolve a peça específica que falta.

A terceira é o registro. Cada decisão, cada mudança de rumo e cada lição fica escrita, e esse acervo é o que faz o próximo sistema custar menos que o anterior. O sistema mais recente do lote saiu numa fração do tempo do primeiro, e não foi porque ficou mais fácil. Foi porque metade das decisões já estava tomada em outro documento.

Pular a spec para ir mais rápido é o jeito mais caro de ir devagar

Testei o atalho mais de uma vez. A tentação é sempre igual: o sistema é pequeno, o escopo parece claro na cabeça, escrever a spec parece cerimônia de quem tem tempo sobrando. O retrabalho cobra a conta com juro, e cobra na pior hora — depois que o sistema está de pé e alguém já depende dele.

Isso não condena o vibe coding, que é gerar código conversando com a IA, sem plano escrito. Para protótipo de uso único e exploração, funciona muito bem: a pergunta ali é se a ideia se sustenta, e você não vai manter aquilo. O problema aparece quando a coisa precisa continuar rodando sem supervisão. Aí a falta de spec e de plano vira dívida técnica, e dívida técnica em sistema que ninguém está olhando cobra juro alto.

O custo do método é tempo antes de existir código

O custo aqui não é financeiro. É tempo gasto escrevendo spec e plano enquanto nada roda, e essa é a parte que parece desperdício de fora — e às vezes para quem está escrevendo também. Recomendo mesmo assim, com uma condição declarada: spec e plano só se pagam quando o sistema precisa durar ou se repetir. Para responder uma pergunta uma única vez, o investimento não volta, e o certo é abrir o editor e conversar com o modelo até chegar na resposta.

Uma pessoa só sustentar vários sistemas em produção ao mesmo tempo depende exatamente dessa aritmética. O custo de cada sistema novo cai porque o acervo de decisões escritas já responde metade das perguntas antes de alguém fazê-las. Sem esse acervo, o quinto sistema custa o mesmo que o primeiro, e é aí que uma pessoa só trava.

Eu teria começado a registrar decisão desde o primeiro sistema

O registro sistemático entrou tarde no lote. Os primeiros sistemas nasceram com spec e com plano, mas sem a anotação do porquê de cada escolha. Reconstruir esse porquê meses depois é trabalho que não produz nada visível para ninguém.

O gargalo nunca foi a IA gerar código. Foi decidir o que pedir a ela. Demorei a enxergar isso com clareza. É a única coisa que eu adiantaria se recomeçasse: tratar o documento de decisões com o mesmo peso do código, desde o primeiro dia.

Método e IA se multiplicam. Sozinhos, nenhum dos dois sustenta o ritmo — IA sem método produz volume que não dura, método sem IA produz qualidade na velocidade de sempre. Quem quer construir algo que continue de pé depois que a novidade passar não começa por tutorial de prompt. Começa por uma página dizendo exatamente o que está sendo resolvido, para quem, e como você vai saber que funcionou.