Sua Organização É um Tornado Tático

John Ousterhout cunhou o termo “tornado tático” em A Philosophy of Software Design para descrever um perfil específico de programador: aquele que produz muito, produz rápido, e deixa destruição para quem vem depois. Código que funciona mas não se explica. Soluções que resolvem o problema de hoje e criam três para amanhã.

Todo time de engenharia já teve um tornado tático. A pessoa que entrega mais tickets por sprint e gera mais incidentes por trimestre.

Facundo Olano, em dois ensaios publicados em fevereiro de 2026, faz uma observação que merece atenção: LLMs são tornados táticos por design. A interação tarefa-por-tarefa, diff-por-diff, que define o uso atual de ferramentas de IA para código, opera contra o pensamento estratégico de design. Não por má intenção. Por estrutura.

A pergunta que importa não é se LLMs escrevem código tático. É o que acontece quando uma organização inteira adota essa dinâmica como modo de operação.

O Mecanismo

Programação tática, no sentido de Ousterhout, significa priorizar a próxima funcionalidade sobre a integridade do sistema. Não é incompetência — é incentivo. A recompensa imediata vai para quem entrega rápido. O custo da complexidade acumulada aparece depois, distribuído entre pessoas que não estavam na sala quando a decisão foi tomada.

LLMs amplificam esse mecanismo de três formas.

Primeira: eles não têm memória de design entre sessões. Cada interação começa do zero. Não existe “a visão arquitetural que discutimos na semana passada”. Existe o prompt atual e o contexto disponível. Decisões estratégicas que dependem de continuidade — consistência de abstrações, coerência de interfaces, evolução gradual de módulos — não sobrevivem a essa fragmentação.

Segunda: a velocidade de geração supera a capacidade de absorção. Um desenvolvedor que escreve código manualmente desenvolve entendimento conforme escreve. Com LLMs, o código aparece mais rápido do que o desenvolvedor consegue compreender. O resultado não é produtividade. É acúmulo de artefatos que ninguém entende completamente.

Terceira: a granularidade da interação é tática por definição. “Implemente essa função.” “Corrija esse teste.” “Adicione esse endpoint.” Cada instrução é uma tarefa isolada. O pensamento que conecta tarefas a um design coerente — o trabalho estratégico — permanece fora do loop.

Os Números que Ninguém Celebra

Se a tese fosse apenas teórica, seria fácil descartar. Não é.

O relatório CircleCI 2026, analisando 28 milhões de workflows, encontrou um padrão revelador: throughput de feature branches aumentou 15%. Throughput da branch principal caiu 7%. Mais código sendo gerado. Menos código chegando a produção. A distância entre “escrever” e “entregar” está aumentando, não diminuindo.

LinearB analisou 8,1 milhões de pull requests em 2026. Taxa de aceitação de PRs gerados por IA: 32,7%. Taxa de aceitação de PRs manuais: 84,4%. Dois terços do código gerado por IA não sobrevive ao review.

CodeRabbit reportou que código gerado por IA produz 1,7 vez mais issues totais que código escrito por humanos. O estudo da METR, com desenvolvedores experientes, mostrou que IA os tornou 19% mais lentos — enquanto eles acreditavam estar 24% mais rápidos. Pesquisa da Sonar com 1.149 desenvolvedores: 96% não confiam na precisão do código gerado por IA.

Leia esses números juntos. Não isoladamente.

Mais código gerado. Menos código aceito. Mais defeitos por unidade. Desenvolvedores mais lentos que acreditam ser mais rápidos. A organização inteira se comporta como um tornado tático: produção alta, valor líquido questionável.

A Lei de Amdahl e o Gargalo que Migra

Olano faz uma observação que, apesar de tecnicamente imprecisa na formalização, é intuitivamente correta. Codificação representa entre 20% e 30% do valor total da cadeia de desenvolvimento de software. Mesmo que IA tornasse a codificação 10 vezes mais rápida — uma hipótese generosa — o ganho total do sistema seria algo em torno de 22%.

A intuição da Lei de Amdahl é esta: acelerar a parte que já não é o gargalo não acelera o sistema. O gargalo migra.

Para onde? Para review, integração, teste, especificação, design. Exatamente as atividades que exigem julgamento humano, contexto organizacional e continuidade de raciocínio — as três coisas que LLMs não oferecem.

O paradoxo é que muitas organizações respondem ao gargalo de review fazendo menos review. A flag --dangerously-skip-reading-code que Olano usa como título do segundo ensaio não é ficção. É o nome real de uma opção de configuração. A ironia do nome não é acidental.

Quando a resposta ao gargalo é eliminá-lo em vez de resolvê-lo, a organização não acelera. Ela perde o mecanismo que distingue código que funciona de código que deveria existir.

A Proposta e Seus Limites

A solução que Olano propõe é transferir rigor para especificações e suítes de teste. Se não podemos revisar cada linha de código gerado por IA — e não podemos, não na velocidade em que ele é produzido — então precisamos de artefatos verificáveis que antecedam a geração.

A ideia tem mérito. O grupo de Thoughtworks, em retiro técnico em fevereiro de 2026, chegou a formulações semelhantes: “TDD é a forma mais forte de prompt engineering.” A Anthropic, com o Model Context Protocol, e o GitHub, com o Spec Kit, estão construindo ferramentas que apontam nessa direção. Desenvolvimento orientado por especificação não é conceito novo. A novidade é que agora existe pressão econômica real para adotá-lo.

Mas a proposta tem uma dependência circular que merece honestidade. Quem verifica as especificações? Se o argumento é que não podemos confiar no código gerado por IA sem verificação, por que confiaríamos em especificações geradas por IA sem o mesmo escrutínio? O problema se desloca, não desaparece.

E a experiência prática já oferece contrapontos. A Marmelab, ao testar desenvolvimento orientado por especificação em codebases grandes, concluiu que a abordagem é “majoritariamente inutilizável” nessa escala. Especificações suficientemente detalhadas para gerar código confiável se tornam, elas mesmas, artefatos complexos que precisam de manutenção, review e governança.

O Que Realmente Funciona

A contribuição mais valiosa de Olano não é a solução que ele propõe. É a pergunta que ele formula: se decidirmos não ler código gerado por IA, que infraestrutura precisa existir para substituir o julgamento humano?

Essa é a pergunta certa. E a resposta não é binária — ler tudo ou não ler nada.

Existe um espectro de verificação que a maioria das organizações ignora porque elas pensam em code review como uma atividade, não como um sistema. Sistemas de tipo, análise estática, linters, scanners de segurança, testes de propriedade, testes de contrato — essas ferramentas já existem. Não precisam ser inventadas. Precisam ser compostas em uma camada de verificação que opera em velocidade compatível com a geração.

Addy Osmani, do Google Chrome, sintetizou isso com precisão: “Se o seu PR não contém evidência de que funciona, você não está entregando mais rápido — está movendo trabalho para downstream.”

A distinção é entre review como leitura e review como verificação. Leitura é atividade humana, linear, que não escala. Verificação é infraestrutura, paralela, que escala. O erro da maioria das organizações é tratar code review como sinônimo de leitura, concluir que leitura não escala, e abandonar o review inteiro.

O caminho é decompor o review em camadas: o que pode ser verificado automaticamente deve ser. O que exige julgamento humano — decisões de design, adequação arquitetural, alinhamento com a direção do sistema — precisa de um processo diferente, com cadência diferente, feito por pessoas diferentes.

A Decisão Organizacional

Olano faz um ponto final que é fácil de subestimar: essa não é uma decisão individual. Não adianta um desenvolvedor decidir sozinho que vai ler todo código gerado por IA se a organização recompensa volume de entregas. Não adianta um arquiteto insistir em revisão estratégica se o processo de desenvolvimento não prevê esse momento.

A transição de “tornado tático” para operação sustentável é uma decisão de estrutura, não de disciplina pessoal. Requer que a organização defina explicitamente:

O que será verificado automaticamente e com quais ferramentas. O que será revisado por humanos e com qual cadência. Quem é responsável pelo design estratégico — não como atividade eventual, mas como papel definido. Como medir progresso — não por linhas geradas ou PRs abertos, mas por código que chega a produção e permanece lá.

Organizações que não tomam essa decisão de forma deliberada já a tomaram por omissão. Elas escolheram ser tornados táticos. Escolheram produzir muito e entregar pouco. Escolheram acumular complexidade apostando que a próxima versão da IA vai resolver.

Não vai. O tornado tático não é um bug da ferramenta. É uma propriedade emergente de sistemas que otimizam velocidade de geração sem infraestrutura de verificação.

A ferramenta não precisa mudar. O processo precisa.

Thiago Victorino é fundador do Victorino Group, consultoria especializada em implementação governada de IA. Para discutir como sua organização pode estruturar processos de desenvolvimento para a era de IA generativa, entre em contato: contato@victorino.com.br | www.victorino.com.br