Martin Fowler: o melhor uso da IA é entender o código legado

Enquanto o mercado de IA vende a fantasia do código que se escreve sozinho, uma das maiores autoridades em arquitetura de software aponta para o lado oposto do problema. Martin Fowler, cientista-chefe da Thoughtworks, chama a IA da maior mudança na programação que ele viu na carreira inteira, e diz, sem rodeio, que ainda estamos aprendendo a fazer isso. A frase que mais interessa a quem opera não é sobre gerar código. É sobre entendê-lo. Para Fowler, o uso mais valioso da IA hoje é decifrar sistemas legados, aquele emaranhado antigo que sustenta a operação e que ninguém mais entende por completo.

Quem fala, e por que ouvir

Fowler não é um comentarista de ocasião. É autor de livros que formaram gerações de engenheiros, de Refactoring a Patterns of Enterprise Application Architecture, e voz de referência em design de software há décadas. Quando ele diz que a IA é a maior virada da carreira dele, o peso vem de quem já viu muitas ondas passarem e sobreviverem ou naufragarem. E a leitura dele é a de um arquiteto, não a de um vendedor: mede tolerância, desconfia de promessa e separa o que é útil hoje do que ainda é aposta.

O ponto de partida da análise é técnico e importante. LLMs são uma forma de computação não determinística, diferente de tudo que chamamos de computação até agora. O software tradicional é determinista: mesma entrada, mesma saída. Um modelo pode dar uma resposta agora e outra diferente depois, porque opera por probabilidade, não por regra fixa. Aceitar essa natureza fuzzy é o primeiro passo para usar a ferramenta sem se frustrar com ela, e é a mesma raiz do problema de confiabilidade que já discutimos ao falar de orçamento de erro em IA.

A tese contraintuitiva: entender vale mais que gerar

Aqui está o insight que contraria a manchete. Fowler reconhece que a IA é ótima para levantar protótipos rápido, ajudada pelo vibe coding, e que dá para explorar uma ideia muito mais depressa do que antes. Mas o app matador, na visão dele, é outro: usar IA para entender sistemas legados. No radar de tecnologia da Thoughtworks, o relatório periódico que a empresa publica sobre o que adotar e o que evitar, usar IA generativa para modernizar sistemas legados foi a única técnica de IA a receber a nota máxima, Adote.

A lógica é direta. O gargalo em software antigo raramente é escrever linha nova. É descobrir o que o código existente faz, por quê, e o que quebra se você mexer. Décadas de decisões, correções e regras de negócio ficam fossilizadas ali, e o conhecimento de quem as criou já evaporou. Um LLM lê esse emaranhado rápido, resume, mapeia dependência e responde pergunta sobre comportamento. Fowler é categórico: se você trabalha com sistema legado, deveria estar usando LLM de algum jeito para ajudar.

O valor durável da IA, para Fowler, não está em produzir código novo e descartável, está em recuperar o entendimento perdido de um sistema que já roda em produção.

A Thoughtworks transformou isso em receita. Para clientes tentando modernizar sistemas antigos, a empresa criou uma rotina que analisa o código semanticamente, joga o resultado num banco de grafos e depois consulta esse grafo com um processo de RAG para entender como a aplicação funciona. Não é magia, é engenharia de recuperação de conhecimento. A IA vira a lupa que enxerga a floresta que ninguém mais conseguia mapear.

O colaborador produtivo em que nao se confia

Entender é uma coisa. Modificar com segurança é outra, e aqui Fowler impõe disciplina. A metáfora dele é a melhor descrição que já vi do trabalho com código gerado por IA: trate cada trecho como um pull request de um colaborador bastante duvidoso, muito produtivo no sentido de linhas por hora, mas em quem você não pode confiar em nada do que ele faz. Ou seja, aceite a velocidade, jamais abra mão da revisão. Produtividade em linhas de código não é produtividade em software confiável.

O conselho que segue é sobre método. Fowler recomenda conversar com o LLM de um jeito mais rigoroso para tirar resultado melhor, e sugere que domain-driven design e linguagens específicas de domínio podem ser o caminho: dar ao modelo um vocabulário preciso do negócio, em vez de pedido vago. Ele ainda empresta uma imagem da esposa, engenheira estrutural, que pensa sempre em tolerâncias, quanto de folga além do que a conta pede é preciso reservar por segurança. Usar IA em produção pede a mesma mentalidade: margem, verificação e ceticismo calibrado.

O que isso muda na sua operacao

Três movimentos saem direto da fala de Fowler.

Primeiro, aponte a IA para o seu legado antes de apontá-la para o greenfield. Se a sua empresa tem um sistema antigo que trava mudanças e assusta o time, esse é o lugar de maior retorno. Use o modelo para mapear, resumir e documentar o que existe, recuperando entendimento antes de tocar em qualquer linha. É a diferença entre modernizar às cegas e modernizar enxergando.

Segundo, mantenha o humano no portão. A regra do colaborador duvidoso vale para tudo: código gerado entra por revisão, com teste e verificação, nunca direto em produção. A velocidade da IA só vira valor quando amarrada a rigor, a mesma conclusão a que chega quem trata a IA como ferramenta, não como bala de prata.

Terceiro, invista em vocabulário de domínio. Quanto mais preciso o jeito de falar com o modelo, melhor o resultado. Isso significa escrever o problema em termos do negócio, e não em pedido genérico, o que conversa direto com a disciplina de começar pelo job que o cliente quer resolver antes de sair construindo.

A leitura de Fowler é valiosa justamente por ser calma. Ele não anuncia o fim da profissão nem promete milagre. Enxerga uma ferramenta poderosa, não determinística, cujo maior valor imediato é iluminar o que já existe. Para o Brasil, cheio de sistemas legados que sustentam banco, varejo e governo, esse é talvez o conselho mais prático do ano: antes de pedir à IA para escrever o futuro, peça a ela para explicar o passado que ainda está em produção.

Se a sua operação carrega um sistema legado que ninguém entende por inteiro, fale com a AI Boutique no WhatsApp. A gente ajuda a mapear o código, recuperar o entendimento perdido e modernizar com revisão e método.