Martin Fowler: o tamanho do pedaço que você dá ao agente

Martin Fowler é a pessoa que nomeou refatoração para uma geração inteira de programadores e coescreveu o Manifesto Ágil. Ele também é, por confissão própria, alguém que desconfia de narrativas bonitas: diz que odeia quando pedem um grande resumo depois de um evento, porque raramente sai de um com narrativa coerente, e desconfia da narrativa quando ela se forma. Por isso vale prestar atenção quando ele publica, em 13 de julho, as notas do retiro Future of Software Development da Thoughtworks e admite que dessa vez alguém achou a narrativa, e que ela convence até um negador de narrativa como ele.

A narrativa é de Kief Morris, e Fowler a cita assim:

As sessões tinham títulos diferentes e elencos diferentes, e na superfície eram sobre problemas diferentes. Mas não eram. Quase todas eram uma faceta diferente do mesmo argumento. Quanto deixamos um agente decidir, e como continuamos confiantes no que ele faz?

E o parágrafo seguinte, que é o que interessa para quem opera:

Por baixo de todas essas sessões, o debate de operação, o time de mandato amplo, o espectro da fábrica apagada, a discussão sobre quem tem permissão de guiar o modelo, as pessoas estavam fazendo o mesmo punhado de escolhas repetidas vezes sobre uma única coisa: a unidade de trabalho que estavam dispostas a entregar a um agente. Qual o tamanho dela. Quanto do serviço ela cobre. O que você faz para prepará-la. Como você confere o que volta. O que você põe em volta do agente para mantê-lo dentro das linhas. Salas diferentes ajustavam isso de formas diferentes, mas estavam mexendo nos mesmos controles.

Isso é o mapa mais útil que apareceu esse ano para a discussão de agentes. Reduz uma dúzia de debates que parecem separados (code review ainda importa? agente pode mexer em incidente de produção? PM pode dirigir modelo?) a quatro botões que você já está ajustando, com ou sem consciência disso.

Os quatro botões

Vale escrever na parede:

1. Tamanho da unidade. Você entrega uma função, um pull request, uma feature, um incidente ou um processo?
2. Cobertura. Quanto do serviço aquela unidade abrange de ponta a ponta?
3. Preparo. O que você faz antes de entregar? Contexto, especificação, exemplo, restrição?
4. Conferência. O que você faz com o que volta? E o que você põe em volta para segurar o agente?

Repare que nenhum desses botões é sobre qual modelo você usa. Todos são sobre desenho de trabalho. É a mesma conclusão que o mercado inteiro chegou por outro caminho quando a Anthropic e a Blackstone apostaram US$ 1,5 bilhão em implantação: a escolha do modelo é o menor dos seus problemas.

Harness: a discussão saiu do tamanho e foi para o foco

Fowler nota uma mudança de vocabulário em cinco meses. No primeiro retiro, em Utah, em fevereiro, ninguém tinha ouvido falar de harness engineering. No de junho, na Suíça, teve sessão inteira sobre o tema.

E o conteúdo da sessão contraria o senso comum. Do lado dos guias, quase toda a conversa foi sobre gestão de contexto, e o ponto é este: janela de contexto cresceu, mas isso não significa que o modelo vai olhar para as partes certas. Modelos tipicamente focam atenção só em parte do contexto, então gerir esse foco é trabalho seu. Um participante mantém o agents.md com menos de 200 linhas. Deliberadamente.

Do lado dos sensores, apareceu algo mais interessante: sensores computacionais. Dois padrões relatados por um participante, migrar para linguagens com mais controle (Rust em vez de Python) e subir o nível da validação, com mais testes baseados em propriedade e técnicas de métodos formais. E o comentário mais honesto do texto: um participante disse que não é inteligente o bastante para escrever especificação em linguagem formal, mas é inteligente o bastante para ler uma e conferir se faz sentido no domínio dele.

Fowler recusa a especulação sobre se harness vai virar desnecessário quando os modelos melhorarem. Diz que nunca teve sucesso em adivinhar o futuro e não vê por que seria mais fácil agora. Mas registra o dado prático: por ora, atenção a harness compensa, porque reduz uso de token e permite que modelos mais fracos sejam úteis, o que sustenta hospedagem local de modelos de peso aberto.

Gerenciar por objetivo, o velho truque de 1959

A parte mais afiada vem da sessão de Sam Ruby, "Bring me a Rock", cujo nome evoca a disfunção do chefe que manda buscar uma pedra e vai rejeitando sem explicar até uma bater com a expectativa não dita. Ruby argumenta que com LLMs isso deixa de ser xingamento e vira forma defensável de trabalhar, porque a máquina tem paciência infinita e devolve pedras em minutos, não em dias.

Mas a sala levou a conversa para um lugar mais estreito e melhor, que Ruby resume assim: a preocupação não era como explorar por eliminação, era quem deveria ter permissão de fazê-lo. Product managers, e cada vez mais gestores de pessoas, estão indo direto no modelo, e engenheiros experientes tiram resultado mensuravelmente melhor dele. Daí o medo: se experiência é o que separa bom resultado de lixo, gente que não é de engenharia deveria estar dirigindo o modelo?

A resposta de Ruby, citada por Fowler, é a melhor coisa que li sobre gestão de IA nesse mês:

Quando um gestor recorre a um LLM em vez de rotear o trabalho para o time que se reporta a ele, ele não pegou uma ferramenta, ele fez uma contratação. E você não pede permissão para gerenciar o seu próprio time. Colocado assim, a pergunta da permissão se dissolve numa pergunta mais velha e mais bem compreendida, a que Drucker nomeou em 1959: quando o trabalhador sabe mais sobre as especificidades do que o gestor, você gerencia por objetivo, não por método.

Ou seja: a pergunta não é "essa pessoa pode contratar?". É "essa pessoa sabe gerenciar por objetivo?". E isso dá para ensinar, contratar e cobrar, sem que ninguém precise virar engenheiro antes. É exatamente o argumento de John Cutler sobre mandato e agência, chegando pelo outro lado.

O limite: você não terceiriza o critério de aceite

Fowler fecha com a ressalva que salva o texto de virar otimismo. Dá para terceirizar muita coisa, mas não o critério de aceite. Em algum ponto existe um pedido humano e um julgamento humano sobre se aquele pedido foi executado direito. E o perigo não está no objetivo mal escrito, está no objetivo importante que ficou implícito, às vezes porque nem foi imaginado.

O exemplo dele é doméstico e assustador. Peça um app que examine seus emails e monte a lista de tarefas do dia. Por baixo dessa frase simples mora uma moita de suposições não ditas: que o gênio não vai incluir funcionalidade indesejada, apagando emails que julgar indignos da sua atenção; que ele não vai deixar um email instruí-lo a mandar informação privada para vilão@mal.com. Teste de conformidade (sensor) vale mais que especificação (guia), mas é difícil imaginar todos os testes necessários para dizer o que não deve acontecer.

E o argumento final, o que mais importa para quem lidera time: construir software é exploração. Para um humano guiar essa exploração, ele precisa entender o processo. Fowler acha que construir modelo mental continua importante, e que mesmo se o gênio construir o modelo sozinho, ele precisa nos ensinar esse modelo, porque é o modelo que nos permite imaginar e comunicar os objetivos que damos à máquina.

Ou seja: o entendimento não é overhead do trabalho. É o insumo do próximo objetivo. Quem terceirizar isso fica sem a capacidade de pedir a próxima coisa. Comece pelos quatro botões de Morris e escreva, para o seu time, qual unidade de trabalho vocês entregam hoje, e como conferem o que volta. É meia hora de reunião e vale mais que trocar de modelo.

Se quiser ajuda para desenhar o harness e o critério de aceite do seu time, fala com a gente no WhatsApp.