Martin Fowler publicou em 14 de maio um novo verbete no bliki chamado Interrogatory LLM. A ideia: quando o LLM precisa de muito contexto para entregar codigo util, e mais barato deixar o modelo perguntar o que ainda nao sabe do que o humano tentar adivinhar tudo de uma vez.
O problema que o padrao endereca
Quem usa LLM para tarefas de codigo nao triviais bate sempre na mesma parede: o modelo precisa entender o produto, a feature, o estilo de codigo do projeto, as APIs internas, as restricoes operacionais. Despejar tudo no prompt inicial e impreciso — ou falta contexto, ou sobra contexto que nao casa com o que o modelo vai realmente fazer.
Fowler observa que essa pressao para “prever o contexto necessario” e o que mais desperdica tokens em pipelines agenticos. O autor escreveu um agente de codigo no dia anterior e percebeu que metade do tempo era passada empurrando informacao que o modelo descartava, enquanto a outra metade era reescrevendo prompts quando o modelo travava por nao ter um detalhe.
O que e o padrao Interrogatory LLM
A proposta inverte o fluxo. Em vez do humano descrever o contexto antes da tarefa, o agente comeca com uma instrucao mais aberta e e configurado para perguntar antes de agir. O modelo identifica o que ainda nao sabe — quais arquivos abrir, qual convencao seguir, como o sistema externo se comporta — e pede confirmacao do humano ou consulta uma tool de leitura.
Fowler enxerga o LLM como entrevistador, nao como executor passivo. A analogia que ele usa: e parecido com um desenvolvedor novo no time. Voce nao escreve um documento de 30 paginas e entrega para ele implementar. Voce deixa ele perguntar.
Onde isso muda a economia de tokens
Dois efeitos praticos. Primeiro, o prompt inicial fica mais curto: o humano nao tenta cobrir todas as variantes. Segundo, o contexto que entra no modelo e sempre o necessario para o passo seguinte — nao um conjunto especulativo de instrucoes que talvez sirvam.
Quem usa Claude Code, Cursor ou Cody ja convive com versoes implicitas desse padrao, com agentes que decidem ler arquivos com base no que ainda nao entendem. O artigo do Fowler nomeia explicitamente o padrao e da vocabulario para discutir trade-offs.
A conexao com o retreat de agentic programming
Fowler relata que percebeu o padrao em um retreat sobre o futuro da programacao agentica, tambem em 14 de maio, reunindo varios engenheiros que usam IA no dia a dia. O encontro nao foi um evento publico com keynote; foi uma conversa fechada para mapear padroes recorrentes no trabalho com LLM.
A narrativa do verbete entrega que esse e o primeiro de varios padroes que ele pretende escrever nas proximas semanas. Para quem acompanha o bliki do Fowler ha tempo, e o modus operandi familiar: identificar uma pratica repetida, dar nome, descrever forcas.
O ponto delicado: nem toda tarefa pede interrogatorio
O proprio Fowler aponta que o padrao tem custo. Cada pergunta do modelo e um round-trip — gasta tokens, tempo do humano e quebra fluxo. Para tarefas pequenas e bem definidas, despejar contexto direto continua mais eficiente.
A fronteira sugerida no texto: usar Interrogatory LLM quando o problema tem incerteza estrutural — quando o modelo nao sabe que arquivo abrir, que padrao seguir, ou que sistema externo consultar. Tarefas mecanicas tipo “renomeia essa funcao em 12 arquivos” nao precisam de entrevista.
O que avaliar na pratica
Para times tirando proveito do padrao, faz sentido medir duas coisas: numero medio de turnos por tarefa concluida com sucesso, e proporcao de turnos que sao perguntas do agente vs execucao. Se o agente perguntar demais sem progredir, o padrao virou ruido. Se nunca perguntar e o resultado sair errado, o agente esta adivinhando contexto que nao deveria.
Reportado originalmente por martinfowler.com em 2026-05-14.
