AI BoutiqueAI Driven Transformation

Vozes

Martin Fowler: o abismo entre diretoria e engenharia na IA

Martin Fowler resume o retiro da Thoughtworks: gerar código não é mais o gargalo, verificar é, e diretoria e engenharia enxergam a IA de formas opostas.

Martin Fowler não é um entusiasta de IA nem um cético de plantão, e é justamente por isso que vale ler o que ele escreve. Em julho, ele fechou suas anotações do segundo retiro Future of Software Development da Thoughtworks, realizado em Engelberg, na Suíça, e o resumo que emerge é desconfortável para os dois lados do debate. A tese central: o maior risco da IA na engenharia hoje não é técnico, é organizacional. É o abismo entre o que a diretoria acha que a IA entrega e o que a engenharia sabe que ela entrega.

Cinco achados, um recado

O relatório da Thoughtworks sobre o retiro, que Fowler linka em suas anotações de 21 de julho, traz cinco achados de ponta. Traduzidos: geração de código não é mais o gargalo, verificação é; a engenharia de harness está surgindo como disciplina própria e possuível; as organizações estão batendo numa crise real de formação de gente júnior; o abismo de expectativa entre executivo e engenheiro é um risco maior do que qualquer limitação técnica; e a modernização de legado é o poço de valor mais claro e defensável no curto prazo.

O primeiro achado é o que mais mexe com quem opera. Se a IA já produz código em volume, o trabalho caro deixou de ser escrever e passou a ser confirmar. Já tratamos dessa virada quando cobrimos o Karpathy falando em Software 3.0 e verificação e o Simon Willison chamando o revisor humano de meat proxy. Fowler chega ao mesmo lugar por outra porta: a de quem estava numa sala cheia de líderes de engenharia comparando notas do mundo real.

O caso dos mosquitos

Para mostrar por que verificação importa tanto, Fowler conta um caso ouvido no retiro. Uma empresa usou um modelo de aprendizado de máquina para otimizar a troca de filtros de ar em equipamentos de campo. O modelo sugeriu trocar os filtros com menos frequência, e a economia inicial foi comemorada, algo em torno de 50 milhões de dólares.

O problema é que o modelo havia sido treinado com equipamentos usados no deserto, enquanto a frota real operava no ártico. No deserto, o filtro lida com poeira. No ártico, com mosquitos. E mosquito, diferente de poeira, apodrece. Filtro trocado com pouca frequência acumulou mosquito em decomposição, e o acúmulo virou risco de incêndio. O prejuízo com os incêndios, na conta que Fowler reproduz, chegou à casa dos bilhões de dólares.

A economia de 50 milhões virou prejuízo bilionário porque a solução certa foi aplicada no contexto errado. A IA não errou a conta. Erraram os sensores que deveriam ter avisado que o mundo mudou.

Fowler faz a ressalva honesta: essa história poderia ser contada de mil situações sem IA nenhuma. Contexto errado quebra solução desde sempre. Mas o caso serve de lembrete: diante da sugestão de um modelo, o trabalho novo é construir sensores que dão feedback rápido quando a realidade não bate com o treino. Não é desconfiar da IA por esporte, é instrumentar a operação para pegar o desvio antes que ele custe caro.

Por que diretoria e engenharia não se entendem

O ponto mais afiado das anotações é o desencontro de visões. Uma das sessões do retiro girou em torno da diferença entre como o engenheiro que usa LLM no dia a dia e a diretoria que cobra o uso enxergam a mesma ferramenta. A diretoria olha para o ganho de produtividade prometido. A engenharia olha para o risco, principalmente de segurança.

Fowler tem uma hipótese para essa distância, e ela é incômoda. Muita gente de gestão vê a IA fazendo um trabalho decente ao preparar ou resumir relatórios gerenciais e conclui, por analogia, que ela deve programar igualmente bem. Só que preparar um resumo tolerável e escrever software correto são coisas de natureza diferente. O executivo generaliza a partir da experiência que tem, e essa experiência é a mais fácil de a IA acertar.

Ele cita, com evidente prazer, uma observação de Kelsey Hightower: quanto menos trabalho de baixo valor você tem, menos atraente a IA parece. Quem passa o dia em tarefa repetitiva vê mágica. Quem passa o dia em decisão difícil vê uma ferramenta útil e limitada. O abismo de expectativa nasce dessa assimetria de experiência, e nenhuma quantidade de slide otimista fecha essa conta.

Há um agravante que Fowler levanta: boa parte da adoção de IA hoje é puxada por corte de custo, e corte de custo é o que anima diretoria. Enquanto o motor for economia, e não uma enxurrada de produtos melhores construídos com a tecnologia, a desconfiança da engenharia tende a persistir. Ele lembra que quase todos no retiro reconhecem estar em alguma forma de bolha, sem saber quanto tempo ela dura nem o que sobra depois que estoura.

O que muda para a operação por aqui

Para quem coloca IA em produção, as anotações de Fowler viram três instruções práticas.

Primeira, otimize a verificação, não a geração. Se o gargalo mudou, o investimento tem que mudar junto. Isso significa tratar a engenharia de harness como disciplina com dono: testes, guardrails, observabilidade e controle de acesso ao redor do modelo, não como enfeite, mas como o produto de verdade. Um time medido por linhas geradas está contando a métrica errada.

Segunda, construa sensores de contexto. O caso dos mosquitos é uma aula sobre feedback. Antes de confiar numa sugestão de modelo em escala, pergunte: como eu descubro rápido que o contexto mudou? Sem esse sensor, a economia de hoje é o incêndio de amanhã. Isso vale para código, para atendimento e para qualquer decisão automatizada.

Terceira, feche o abismo de expectativa de propósito. O trabalho de liderança aqui não é escolher entre o otimismo da diretoria e a cautela da engenharia, é traduzir um para o outro. Leve o risco para a linguagem do negócio, com casos concretos, e leve o ganho para a linguagem da engenharia, com metas de resultado. Já defendemos essa disciplina de fluxo ao aplicar o Kanban para IA em produção: tornar o trabalho visível é o primeiro passo para alinhar quem cobra e quem entrega.

Fowler não fecha com profecia, e nós também não vamos. O recado é modesto e por isso confiável: a parte difícil da IA em 2026 não é fazer o modelo produzir, é verificar o que ele produz e alinhar as pessoas em volta sobre o que isso vale de verdade. Quem trata esse alinhamento como problema de engenharia, e não de marketing interno, opera melhor.

Se a diretoria e o time de tecnologia da sua empresa estão vendo a IA de formas opostas, e você precisa de um plano que alinhe expectativa com o que a tecnologia realmente entrega, fale com a AI Boutique no WhatsApp. A gente ajuda a montar a verificação e a conversa que faltam.

Fontes

Perguntas frequentes

O que Martin Fowler quer dizer com 'verificação é o novo gargalo'?

Que a IA já produz código em volume, então gerar deixou de ser a parte cara. O trabalho que sobra, e que agora domina o tempo, é confirmar que o que foi gerado está correto, seguro e adequado ao contexto. Fowler resume o achado do relatório da Thoughtworks nessa frase: a geração de código não é mais o gargalo, a verificação é. Quem organiza o time em torno de produzir mais, e não de verificar melhor, otimiza a etapa errada.

O que é 'engenharia de harness' que Fowler menciona?

É o conjunto de andaimes em volta do modelo: os prompts estruturados, as ferramentas que o agente pode chamar, os testes, os guardrails, a observabilidade e os controles de acesso que transformam um modelo genérico em algo confiável para uma tarefa. O relatório da Thoughtworks trata isso como uma disciplina própria e possuível, ou seja, algo que um time pode assumir como responsabilidade, com dono e prática, em vez de deixar solto.

← Todos os artigos