Por que LLMs vão falhar na Sua Empresa?

Papo reto: isso aqui é mais especulação do que tese fechada. Tô pensando alto. Pode estar incompleto, pode estar errado. Se discordar, melhor ainda. Não tô vendendo metodologia nova. Quero cutucar uma ferida que muita gente finge que não existe.

Nos últimos meses começaram a aparecer histórias de empresa grande gastando quantidade absurda de token em ferramenta de IA sem conseguir apontar, com clareza, o resultado equivalente em produto. O caso que ficou mais famoso foi a Uber queimando o orçamento anual de IA em poucos meses, com uso pesado de ferramenta como Claude Code. Executivo admitindo que ainda não traçava uma linha reta entre consumo de token e valor entregue.

Fé eles tinham de sobra. Usaram demais. Esse é o problema. Até aqui a maioria já entendeu que prompt de uma linha não resolve nada. Aquela fantasia de escrever “faça um clone da Uber” e voltar com produto pronto morreu rápido. A resposta do mercado foi correr pro outro lado: desenvolvimento dirigido por especificação.

Em vez de pedir tudo numa frase, cê escreve uma especificação. Define escopo, caso de uso, critério de aceite, arquitetura desejada, restrição, fluxo, talvez até um PRD inteiro. Depois entrega isso pro agente e espera que ele implemente com menos ambiguidade. Isso é melhor do que um chute só? Claro. Mas ainda acho que está errado.

Não. Spec não salva. Eu venho martelando isso há anos, antes de LLM virar moda. Dois vídeos meus importam pra entender o ponto: “Não Terceirize Suas Decisões” e “Esqueça Metodologias Ágeis”. O resumo é simples: a maioria dos profissionais foi treinada a não decidir.

Pensa no dia a dia. Muita gente não faz nada se não houver backlog pronto. Cruza o braço, culpa gestão, culpa colega, culpa cliente, e espera alguém dizer o que fazer. Quando a tarefa chega, executa. Quando dá errado, a culpa era do requisito. Quando o cliente reclama, a culpa era da prioridade. Quando o produto degrada, a culpa era do processo.

Quase ninguém decide de verdade, banca a decisão até o fim e sofre a consequência. E sem sofrer a consequência, cê não aprende a decidir. Não aprende quais escolhas levam a quais resultados. Não aprende a priorizar. Não aprende a explicar por que algo precisa existir. Escrever especificação porque entende o problema? Esquece. O que cola é preencher template pra ninguém reclamar.

Burocracia estruturada. Os princípios originais de 2001 foram triturados. O que muita empresa chama de Agile hoje é burocracia em ciclo menor. O desenho clássico todo mundo já viu: backlog, planning, sprint, daily, review, retrospective, próxima sprint. A Scrum Guide descreve os eventos formais. Tem até diagrama bonitinho na Wikimedia. Na prática, muita equipe transformou isso em teatro.

Passa-se um dia inteiro nisso. E o backlog final raramente é o que precisa ser feito. É o consenso de menor resistência. Compromisso em cima de compromisso. Pequena tarefa, pequeno risco, pequena vitória, pequeno fracasso. Tudo desenhado pra não gerar conflito demais. Medíocre, e de propósito: escolha ativa por decisão fácil, que não levanta muita crítica contra você.

Exato. O QA entra, encontra problema, tenta encaixar correção na próxima rodada. Mais alguns dias, talvez mais umas duas semanas. Um mês depois, talvez dois, a decisão original finalmente começa a mostrar resultado em produção. Só que o resultado está tão longe da decisão que quase ninguém faz a correlação. A equipe não sente o peso real do que decidiu. O erro não vira aprendizado. O processo não melhora.

Nunca acontece. O time aprende outra coisa: ficar invisível. Cê aprende a agradar gestão. Aprende a reduzir atrito. Aprende a sobreviver à reunião. Resolver o problema e entregar valor ficam fora do treino. E quando o resultado piora, a resposta da alta gestão é previsível: mais controle, mais regra, mais trava, mais comitê, mais checklist. A engrenagem fica mais pesada. O time fica mais covarde.

Até pouco tempo atrás, o maior gargalo de desenvolvimento era escrever e ajustar código. Codar levava dias ou semanas. Por isso tanto esforço ia pra fase de planejamento. Se o time vai gastar umas duas semanas implementando, parece fazer sentido gastar um dia discutindo o que entra na sprint. Mas ferramenta de código com LLM muda a posição do gargalo.

É a história da corrente e do elo mais fraco. Cê reforça um elo, outro passa a limitar o sistema. Antes, o elo fraco era a velocidade de codificação. Agora, cada vez mais, é a capacidade humana de decidir, explicar, testar e revisar. O erro das empresas é colocar LLM dentro do mesmo processo quebrado e esperar ganho multiplicativo.

É mole? Cê se surpreende quando sai lixo mais rápido. Tá ligado? A economia do processo inverteu e ninguém quis redesenhar a esteira.

Um agente de código precisa que cê explique o objetivo, o contexto, as restrições, as prioridades, o que não pode quebrar, quais caminhos são aceitáveis, como medir sucesso. Ele precisa de uma direção objetiva. Agora vai entrevistar seu time. Pergunta pra cada pessoa: qual é o objetivo real do que você está fazendo? Como isso melhora o produto? Qual métrica deveria mudar?

Muita gente não sabe responder. Sabe qual ticket pegou. Sabe que precisa fechar algumas tarefas por semana. Sabe que tem daily amanhã. Mas não sabe por que aquilo importa. E aí cê entrega uma LLM pra essa pessoa. O resultado é um espelho. Código ruim muito mais rápido. Bug muito mais rápido. Cliente irritado muito mais rápido. Pull request gigante muito mais rápido.

Desenvolvimento dirigido por especificação tenta corrigir isso com documentação. Mas se a especificação nasce do mesmo processo covarde, ela só documenta a covardia. Um PRD escrito por quem não entende a decisão continua ruim. Critério de aceite escrito pra evitar conflito continua desviando do problema real. O agente só vai executar melhor uma decisão ruim.

Minha hipótese é que o processo inteiro precisa ser redesenhado ao redor da nova restrição. De novo: é especulação. Eu não tenho dado suficiente pra provar isso. Mas, olhando pro tipo de falha que vejo em empresa e pro tipo de sucesso que vejo em uso individual intenso, minha teoria é essa: joga fora o ritual de sprint como unidade central de trabalho.

Não faz sentido manter isso. Com LLM, o ciclo precisa ficar mais curto. Muito mais curto. Idealmente, dentro do mesmo dia. No meu desenho ideal, cada programador com LLM deveria parear diretamente com um Product Owner por blocos de trabalho curtos. O papel do PO é fechar a lacuna que o programador normalmente tem: objetivo, prioridade, restrição, contexto de negócio, resultado esperado. Isso precisa entrar no prompt e na conversa com o agente.

Ele pode sentar com o programador durante uma manhã, implementar uma pequena fatia funcional, ajustar na hora, decidir na hora, cortar escopo na hora. Depois roda pra outro programador. Em seguida entra QA. Não como uma fase distante, mas como pareamento no mesmo ciclo. O QA fecha outra lacuna comum do programador: testar só o caminho feliz, esquecer caso de erro, não automatizar o suficiente, não pensar em regressão de comportamento.

Também no mesmo dia, não duas semanas depois. Ele olha pro que mudou e fecha a terceira lacuna: complexidade desnecessária, design ruim, regressão escondida, documentação faltando, vulnerabilidade óbvia, performance piorando, acoplamento que nasceu sem necessidade. Constrói, checa, ajusta. Tudo em tempo real.

Adoram na daily, onde a responsabilidade ainda dá pra diluir no “a gente”. O programador deixa de ser a pessoa que só pega ticket. Ele precisa aprender a transformar objetivo em instrução executável. Precisa discutir concessão. Precisa entender por que está codando. Precisa usar a LLM como ferramenta de execução e investigação, não como desculpa pra desligar o cérebro. O PO deixa de ser fábrica de backlog. Ele precisa decidir com o programador, olhando pro produto vivo. Escrever card e desaparecer não cola.

O QA deixa de ser a pessoa que recebe o pacote no fim e devolve defeito. Ele entra cedo pra transformar comportamento esperado em verificação. Se a LLM acelera código, QA precisa acelerar aprendizado sobre risco. O Tech Lead deixa de ser carimbo de pull request atrasado. Ele entra enquanto ainda dá pra mudar barato. Ajuda a manter simplicidade, remove complexidade, protege arquitetura, documentação, segurança e performance.

Porque esse processo expõe decisão. No processo atual, a decisão se dilui. Foi o backlog. Foi o PO. Foi o refinamento. Foi a sprint. Foi o time. Foi a dependência. Foi o cliente que mudou de ideia. Todo mundo consegue se esconder.

Num ciclo curto com LLM, a decisão aparece rápido. Cê disse que aquilo era prioridade? Então implementa agora. Cê disse que o critério de aceite era esse? Então testa agora. Cê disse que esse design era bom? Então revisa agora. Se estiver errado, a consequência aparece no mesmo dia. Isso é desconfortável. Mas é assim que se aprende. Sem consequência próxima, decisão vira teatro. Com consequência próxima, decisão vira treino.

O primeiro passo é aceitar uma coisa que programador profissional costuma odiar: dá pra jogar código fora. Na verdade, cê deveria jogar código fora com muito mais frequência. Código não é monumento. Código é material de trabalho. Deletar código é tão importante quanto escrever código novo. É por isso que usamos Git.

No processo tradicional, código fica caro demais emocionalmente. Se levou umas duas semanas pra sair, ninguém quer admitir que foi desperdício. O gerente sente que apagar aquilo prova que a decisão anterior foi ruim. O programador defende a implementação porque sofreu pra fazê-la. O time empurra o problema pra frente porque deletar parece derrota. Deletar não prova derrota. Às vezes é higiene.

Fica barato fazer prova de conceito. Fica barato testar dois caminhos e jogar um fora. Fica barato pedir pro agente reescrever uma abordagem inteira numa branch temporária, comparar, documentar o aprendizado e dar git reset sem drama. Então faz mais disso. Mais protótipo. Mais prova de conceito. Mais teste A/B interno. Mais branch descartável. Menos apego ao primeiro código que apareceu.

Sucesso em repetir a Uber no escritório ao lado. Não espera que todo mundo receba token numa segunda e saiba fazer isso sozinho. Esse é o jeito mais rápido de queimar orçamento e depois dizer que IA não funciona. Minha sugestão é o contrário: assume uma ou duas semanas sem entrega planejada. Diz claramente que aquelas semanas existem pra treinar o novo processo. Sem feature no quadro. Quebrar o ritual antigo. Deixar o time praticar em ambiente seguro.

Nessa fase, o PO não deveria escrever especificação de umas vinte páginas. Deveria parear com o programador e construir prompt pequeno, um passo de cada vez, vendo o resultado em tempo real. A cada resposta da LLM, o PO aprende quanto detalhe o código realmente precisa. O programador aprende a perguntar melhor. QA aprende a transformar comportamento em teste cedo. Tech Lead aprende a cortar complexidade enquanto ela ainda é barata.

A conclusão incômoda: LLMs falham tanto porque elas entram em processos feitos por pessoas que foram treinadas a não decidir. Prompt melhor ajuda. Spec maior ajuda. Governança de token ajuda. Nada disso toca o centro do problema.

Não tô nem aí pra essa desculpa. O centro é que muita gente não sabe explicar objetivo mensurável, não sabe priorizar, não sabe assumir concessão, não sabe conectar decisão com resultado. E uma LLM precisa exatamente disso pra ser útil. Se cê coloca IA no processo velho, cê acelera o processo velho. Mais backlog medíocre. Mais decisão ruim. Mais bug. Mais custo. Mais retrabalho. Mais relatório tentando provar produtividade que o cliente nunca sentiu.

Ciclo menor. Pareamento real. Decisão perto da execução. Teste perto da decisão. Revisão perto do código. Resultado perto de quem decidiu. Essa é a parte que programador precisa encarar: sim, cê provavelmente nunca aprendeu a decidir direito. Nunca aprendeu a descrever objetivo de forma objetiva. Nunca aprendeu a medir consequência. O processo te treinou pra isso. E agora a IA está revelando a falha.

Mas não vai acontecer com mais uma cerimônia, mais uma planilha de prompt, mais uma política de uso de IA, ou mais uma sprint cheia de ticket escrito pra ninguém ser criticado. Vai acontecer quando cê parar de terceirizar decisão. Na moral: o resto é teatro com token.