Vozes
Martin Fowler: a IA amplia a prática que você já tem
Martin Fowler resume o que decide o valor da IA na engenharia: a habilidade que já existe no time. A leitura da AI Boutique sobre time bom, time ruim e IA.
Martin Fowler é o tipo de voz que vale ouvir sobre IA justamente porque não vive de vender IA. Autor de livros que formaram gerações de engenheiros, de Refactoring a Patterns of Enterprise Application Architecture, e referência da Thoughtworks, ele passou décadas estudando o que faz software bom ser bom. Nos seus escritos recentes, Fowler tem voltado a um ponto que corta o barulho todo: o valor que a IA entrega depende muito da habilidade que já existe no time. A ferramenta não cria competência, ela multiplica a que já está lá.
A tese: IA amplifica o que você já é
Num dos seus registros de agosto, Fowler destaca um relato detalhado de programação por agentes na Zalando, escrito por Bartosz Ocytko. A empresa, com mais de 200 times explorando o assunto, chegou a uma conclusão que Fowler faz questão de sublinhar. Nas palavras da própria Zalando, citadas por ele, a IA amplifica as boas e as más práticas ao longo da organização. Times que se deixam levar pela empolgação com engenharia por agentes acabam com pull requests enormes, que desestimulam quem revisa e atrasam a entrega, até o time ajustar a prática.
É uma frase simples com uma consequência dura. A IA não é um nivelador que puxa todo mundo para cima. Ela é um amplificador. Onde há disciplina de revisão, testes e boa arquitetura, o agente acelera o trabalho bom. Onde há bagunça, o agente gera bagunça mais rápido. Fowler repete isso como um fio condutor: a régua do ganho não é a ferramenta, é a base sobre a qual ela roda.
A IA não conserta um time ruim. Ela deixa o time bom mais rápido e o time ruim mais perigoso. A diferença entre os dois continua sendo a prática de engenharia que já existia antes da IA entrar.
O exemplo que vale copiar
O relato da Zalando que Fowler destaca traz um detalhe prático que merece atenção de quem opera. A empresa usa um modelo para avaliar o risco de cada pull request. Os de baixo risco de rollout podem ser aprovados automaticamente, o que reduziu o lead time em algo entre 20 e 40%. Uma consequência interessante apareceu sozinha: as pessoas passaram a quebrar os pull requests, separando as partes de baixo risco para aproveitar a aprovação rápida. E qualquer alteração em configuração é automaticamente classificada como alto risco, o que, segundo o time, protege contra as armadilhas mais comuns de indisponibilidade.
Repare no que está acontecendo ali. A IA não substituiu a revisão, ela redirecionou o esforço humano para onde ele importa. O revisor deixa de gastar tempo com mudança trivial e concentra a atenção no que é arriscado. É o mesmo princípio de fluxo que defendemos ao falar de limitar o trabalho em andamento com Kanban: a IA vira mais valiosa quando serve a um sistema desenhado, e não quando é jogada solta esperando mágica.
O ceticismo saudável sobre a bolha
Fowler não é um pessimista de IA, mas também não engole o discurso de revolução sem freio. Em outro registro, ele trata a IA abertamente como uma bolha financeira, comparando o momento ao estouro das pontocom. Ele lembra um detalhe que os entusiastas esquecem: mesmo quando a bolha da internet estourou, quem tinha investido continuou com um ganho anual saudável ao longo dos anos. A tecnologia era real, o exagero financeiro é que não era.
Essa distinção é o presente que Fowler dá para quem opera. Bolha de investimento e ganho de produtividade são duas coisas diferentes. O mercado pode estar caro demais, os data centers podem estar sendo financiados com dívida arriscada, e ao mesmo tempo o ganho concreto de um agente que corta o seu lead time em 30% continua sendo real, mensurável e seu. Confundir as duas coisas leva a dois erros opostos: apostar tudo achando que é revolução infinita, ou ignorar o ganho achando que é só bolha. Fowler aponta o caminho do meio, que é o caminho de quem coloca IA em produção de verdade.
Nossa leitura
O recado de Fowler conversa direto com o que vemos nos times brasileiros. A pergunta certa não é "que ferramenta de IA eu compro", é "que prática de engenharia eu tenho para a IA amplificar". Um time que não revisa código direito vai revisar pior com o dobro de volume. Um time que não mede resultado vai medir hype. A IA torna urgente arrumar a casa, porque ela expõe e acelera cada rachadura que já estava lá.
Isso ecoa o que discutimos ao falar de tarefas, não empregos, e do risco do PowerPoint infinito: a IA remove o gargalo da execução, e joga o peso de volta para o julgamento humano, o que decidir fazer, o que revisar, o que deixar passar. E conecta também com a disciplina de descobrir o que vale construir antes de construir, porque velocidade sem direção só produz mais coisa errada, mais rápido.
A conclusão prática é quase antiquada, e é por isso que é boa. Antes de perguntar como a IA vai transformar o seu time, olhe para a prática que o seu time já tem. É ela que a IA vai amplificar, para o bem ou para o mal. Investir em fundamentos, revisão, testes, clareza de arquitetura e de método, deixou de ser higiene e virou a alavanca que decide quanto de IA você consegue colher.
Se você quer descobrir quais práticas do seu time a IA vai amplificar, e arrumar a base antes de acelerar, fale com a gente no WhatsApp para desenhar o próximo passo com os pés no chão.
Fontes
Perguntas frequentes
Quem é Martin Fowler e por que ouvir a opinião dele sobre IA?
Martin Fowler é autor de livros que moldaram a engenharia de software moderna, como Refactoring e Patterns of Enterprise Application Architecture, e é uma referência da Thoughtworks. Ele não é um entusiasta de IA vendendo ferramenta, é um veterano de práticas de engenharia observando como a IA muda o trabalho. Por isso a leitura dele é útil: foca em prática, não em hype.
O que significa a IA amplificar boas e más práticas?
Significa que a IA não conserta um time desorganizado, ela acelera o que já existe. Um time com boa revisão, testes e disciplina usa IA para ir mais longe. Um time bagunçado usa IA para gerar mais código ruim, mais rápido, com pull requests que ninguém consegue revisar. A ferramenta é a mesma, o resultado depende da base.