A IA cobre os 70% fáceis de um projeto em grande velocidade, mas os 30% finais — edge cases, tratamento de erros, arquitetura, robustez — continuam exigindo critério humano e decidem se o software sobrevive em produção. A lição: a IA colapsa o custo de começar, não o de terminar.
Há um momento mágico e traiçoeiro em cada projeto construído com IA: são onze da noite, você pediu um app e, em vinte minutos, tem algo que funciona, parece bonito e até parece pronto. Você sente que ganhou. No dia seguinte, tenta fazê-lo lidar com um usuário que faz algo estranho, um pagamento que falha no meio do caminho, um dado vazio, duas pessoas apertando o mesmo botão, e a mágica vira um pântano. Bem-vindo ao problema dos 70%: o fenômeno mais bem documentado — e menos confessado — da era do código assistido por IA. A IA te presenteia com 70% do caminho a uma velocidade que parece bruxaria e, então, solta a sua mão justo nos 30% que decidem se o seu software é um brinquedo ou um produto.
Quem deu o nome e por que o número importa
O nome não é nosso. Addy Osmani, engenheiro do Google, o batizou de "o problema dos 70%" depois de observar padrão após padrão em gente construindo com IA. Sua tese é incomodamente precisa: a IA cobre com facilidade a parte padronizada e previsível de um projeto — o scaffolding, o CRUD, a tela bonita, o que ela já viu um milhão de vezes no treinamento —, mas os 30% restantes continuam exigindo critério de engenheiro sênior. Esses 30% não são mais código: são outro tipo de trabalho. São os edge cases que ninguém pediu, o tratamento de erros que só importa quando algo quebra, as decisões arquiteturais que não aparecem mas sustentam tudo, a robustez que separa a demo do deploy. E a observação mais afiada de Osmani é sobre quem sobrevive ali: os seniores moldam e limitam a saída da IA como quem poda uma árvore; os iniciantes ficam presos num loop infinito de depuração, pedindo à máquina que conserte um bug que eles não entendem, gerando três bugs novos a cada um que tapam.
O peixe e a vara: por que os 30% são de outra matéria
A melhor forma de entender isso é uma velha imagem virada do avesso. A IA não te ensina a pescar; ela te entrega o peixe já cozido, servido, com a mesa posta. É um banquete instantâneo. O problema é que produção não é um jantar: é uma tempestade em alto-mar. E quando a rede rasga, quando o motor falha, quando entra água por um lado que ninguém previu, você não precisa de mais peixe — você precisa saber pescar. Esse saber são os 30%. Não se gera, se exerce. Por isso o sênior e o iniciante vivem o mesmo momento de formas opostas: para o sênior, os 70% da IA são um rascunho rápido sobre o qual ele aplica seu critério; para o iniciante, esses mesmos 70% são uma caixa-preta que quase funciona, e "quase funciona" em software é o lugar mais perigoso do mundo, porque parece pronto e não está.
Por que a demo brilha e produção tropeça
Aqui isso se conecta com algo que dizemos faz tempo. O vibe coding — construir no puro instinto conversacional com a IA — é espetacular na demo justamente porque a demo vive nos 70%: o caminho feliz, o usuário que faz exatamente o que você esperava, os dados limpos. Produção é o contrário: são os 30% multiplicados por milhares de usuários reais fazendo coisas que você jamais imaginou. Já tínhamos colocado números na distância entre a demo e a realidade no nosso ensaio sobre a matemática dos 27% — o quanto o desempenho despenca entre o laboratório e o mundo —; o problema dos 70% é o outro lado dessa mesma moeda, visto pelo lado da construção em vez do desempenho. Um mede o quanto a IA cai ao sair do laboratório; o outro explica exatamente em que parte do trabalho ela cai. Ambos apontam para o mesmo abismo: a distância entre "funciona na minha tela" e "aguenta no mundo".
O que Osmani de fato propõe (e o que não)
Convém ser honesto com a fonte, porque na internet atribuem a Osmani curas que ele não receitou. Sua resposta ao problema dos 70% não é uma metodologia rígida de especificações adiantadas; é um punhado de hábitos de convivência com a IA. O primeiro, tratar a saída da IA como um "primeiro rascunho", nunca como a versão final. O segundo, a "conversa constante": iterar em diálogo, corrigir o rumo turno a turno em vez de aceitar o primeiro output. E o terceiro, o que resume tudo: "confie, mas verifique". Confie na velocidade dos 70%, mas verifique cada centímetro dos 30%, porque é ali que a IA é mais convincente e mais equivocada ao mesmo tempo. Se você busca uma disciplina mais formal de especificar antes de gerar, ela existe — o Spec Kit e o spec-driven development vão por aí —, mas é outra conversa, não a de Osmani. A lição dele é mais simples e mais portável: a velocidade da IA não te isenta da verificação; ela a torna mais urgente.
A lição que você pode levar e compartilhar
Fique com este modelo mental, porque ele não caduca mesmo quando os modelos mudam: a IA colapsa o custo de começar e não toca no custo de terminar. Começar nunca foi o problema difícil do software; terminar, sim. Os 70% que a IA faz de graça sempre foram a parte barata — a que um bom desenvolvedor também fazia rápido. Os 30% em que ela te deixa sozinho sempre foram a parte cara, a que custava tempo e critério, e continua custando. Então a pergunta certa diante de qualquer ferramenta que promete construir apps por você não é "quão rápido ela chega aos 70%?" — todas chegam rápido, essa corrida está ganha e é chata. A pergunta é "o que ela faz com os 30%?". Quem te vende os 100% automáticos está te vendendo a demo e escondendo a tempestade.
Como nós vemos isso
No NeuralOS a gente não finge que os 30% não existem; construímos em torno deles. Por isso a plataforma não termina onde termina a geração: o motor de Automations é retomável, com esperas duráveis e checkpoints, justamente porque os processos reais caem no meio e é preciso retomá-los sem corromper nada — esse é território dos 30%. Por isso as integrações guardam suas credenciais num vault criptografado por-tenant em vez de deixá-las soltas, e por isso trabalhamos com disciplina de verificação e testes de fumaça nas rotas que lidam com dinheiro: não porque seja glamouroso, mas porque é exatamente nos 30% que o software vive ou morre. Nossa aposta é o contrário da fumaça: a IA te leva voando ao protótipo, e nós levamos a sério o trecho chato e decisivo que vem depois. Confie na velocidade. Mas o critério — o pôr limites, o verificar, o que aguenta em produção — isso não se delega. Se sistematiza. E é toda a diferença entre uma demo que agrada o seu círculo e um produto que sobrevive aos seus usuários.