AI BoutiqueAI Driven Transformation

Vozes

Armin Ronacher: a torre de Babel dos agentes que não desaba

O criador do Flask alerta: com agentes, cada dev constrói em paralelo e some a linguagem comum que mantinha o time entendendo o próprio sistema de software.

Armin Ronacher começa o ensaio olhando um quadro. A Torre de Babel de Bruegel, já uma pintura de construção caótica, serve de gancho para uma tese incômoda sobre o que os agentes de código fazem com as equipes de software. Ronacher, criador do Flask e voz antiga das comunidades Python e Rust, publicou A Torre Continua Subindo em 13 de julho de 2026, e o texto foi direto ao topo do Hacker News. O motivo é que ele nomeia um efeito colateral que quase todo mundo sente e poucos conseguem descrever.

O argumento

A história de Babel costuma ser lida como parábola sobre orgulho. Ronacher a lê como parábola sobre coordenação. No relato bíblico, o que dá poder ao povo não são os tijolos nem o conhecimento de como fazê-los. É a língua comum. Quando ela some, Deus não tira o material nem a técnica, tira a capacidade de as pessoas se entenderem, e a construção para.

A ponte para o software é precisa. Existe a ideia sedutora de que IA significa ferramentas melhores, que permitem construir software mais ambicioso. No nível do indivíduo, diz Ronacher, isso é verdade sem dúvida: um desenvolvedor com um agente muda um código muito mais rápido. Mas grandes projetos nunca foram limitados pela velocidade de uma pessoa produzir código. Eles são limitados por quão bem as pessoas coordenam o entendimento do sistema que estão mudando.

E aqui vem o conceito central. A linguagem compartilhada de um projeto de software não é Python nem inglês. É o entendimento comum do que os conceitos significam, onde estão as fronteiras, quais invariantes importam, quem é dono de quê e por que o sistema tem a forma que tem. Essa linguagem raramente está escrita num lugar só. Vive em parte na documentação e no código, mas também na revisão, nas conversas, nas discussões e na experiência de ter que explicar uma mudança para outra pessoa.

O atrito que sincronizava

O trecho mais forte do ensaio é sobre atrito. Antes dos agentes, parte desse entendimento compartilhado era mantida por fricção. Nas palavras de Ronacher, se ele quisesse mudar a camada de armazenamento de um colega, precisava ler o código do outro, fazer perguntas, talvez coordenar com um terceiro time cujo serviço dependia daquilo. Era lento, e boa parte dessa lentidão era desperdício. Mas não toda. Parte dela era o processo pelo qual o entendimento de um virava o do outro, e pelo qual os dois descobriam se ainda concordavam sobre como o sistema funcionava. "Esse atrito sincroniza as pessoas", ele escreve.

Agentes removem quase todo esse atrito. Um pede ao agente para adicionar OAuth, outro pede cache, um terceiro manda reconstruir o banco do zero e deixar a interface rosa. Cada mudança pode ser razoável isoladamente. O código compila, os testes passam, e a explicação é gerada sob demanda. Ninguém precisa falar com ninguém, nem adquirir a parte do modelo mental que aquela mudança um dia teria forçado a aprender.

A torre não cai, e por isso não notamos o que foi perdido. Ela só continua subindo.

Por que isso não desaba na hora

A observação que dá o título e fecha o texto é a mais perturbadora. Ronacher lembra uma frase que já repetiu outras vezes: agentes não sentem dor, só humanos sentem. Agentes agora deixam a gente agir em partes do sistema onde antes precisaríamos de outras pessoas, e em bases de código onde essas pessoas teriam se revoltado.

Mas não é a história bíblica. Em Babel, a perda da língua comum interrompe a construção. Na engenharia assistida por IA, a construção continua depois que o entendimento compartilhado já ruiu. A ausência de uma falha imediata é o que torna tudo curioso e um pouco desorientador. Não há o desabamento que sinalizaria o problema. A torre segue subindo, cada vez mais alta e cada vez menos compreendida por quem a levanta.

Nossa leitura

Para quem opera IA em produção, o ensaio de Ronacher é um aviso de arquitetura organizacional, não de ferramenta. O ganho de velocidade individual é real e não vai voltar. O risco é confundir código que anda com time que entende. Três movimentos ajudam a não cair na Babel silenciosa.

Primeiro, reintroduzir atrito de propósito onde ele sincronizava. Revisão de código com humano no circuito não é burocracia, é o mecanismo pelo qual o entendimento vira compartilhado. Cortar a revisão porque o agente já entrega pronto é economizar no lugar exato onde o valor estava. Isso conversa com a ideia de limitar o trabalho em progresso do Kanban aplicada a times de agentes: menos frentes abertas ao mesmo tempo, mais chance de o time acompanhar o que muda.

Segundo, tratar fronteiras e donos como explícitos. O desenho de Team Topologies, com times donos de domínios claros, fica mais importante quando qualquer um pode alterar qualquer canto com um prompt. Se a fronteira não está no organograma nem no código, o agente vai atravessá-la sem avisar.

Terceiro, medir a coerência, não só a entrega. A tese de que garantir código bom continua caro ganha uma camada aqui: o caro não é só o teste que prova que a função funciona, é o entendimento coletivo de que o sistema, como um todo, ainda faz sentido. Esse é o ativo que a Babel dos agentes corrói em silêncio.

Ronacher não pede para desligar os agentes, e nós também não. O recado é mais fino: a velocidade voltou de graça, o entendimento compartilhado não. Quem quiser que a torre continue subindo sem virar Babel vai ter que investir, de propósito, na língua comum que os agentes deixaram de exigir.

Se o seu time acelerou com agentes mas anda perdendo o fio de como o próprio sistema funciona, fala com a gente no WhatsApp.

Fontes

Perguntas frequentes

Quem é Armin Ronacher e por que a opinião dele pesa?

Armin Ronacher é um engenheiro austríaco, criador do Flask, um dos frameworks web mais usados em Python, e autor de bibliotecas amplamente adotadas como o Jinja e o Click. Ele é uma voz antiga e respeitada nas comunidades Python e Rust, e nos últimos anos vem escrevendo com regularidade e honestidade sobre programação assistida por IA no seu blog. A opinião dele pesa porque não é vendedor de ferramenta nem cético de plantão: é um engenheiro sênior que usa agentes de perto e descreve tanto o ganho quanto os efeitos colaterais que a maioria dos entusiastas prefere não olhar.

Qual é o problema prático que Ronacher aponta com agentes em equipe?

O problema não é a qualidade de cada mudança isolada, é a perda do entendimento compartilhado do sistema. Ronacher observa que, com agentes, cada desenvolvedor pode alterar qualquer canto do código sem precisar ler, perguntar ou negociar com quem mantinha aquela parte. Cada alteração pode ser razoável sozinha, compilar e passar nos testes. Mas a linguagem comum do projeto, o acordo tácito sobre o que os conceitos significam, onde ficam as fronteiras e quais invariantes importam, se dissolve. E como nada quebra na hora, ninguém percebe que ela sumiu até o sistema ficar impossível de raciocinar em conjunto.

← Todos os artigos