Parei de pedir melhor. Comecei a combinar.

Não tenho um caso marcante para contar. Tenho uma coleção de irritações pequenas, todas parecidas.

Pedia um ajuste num arquivo e recebia uma refatoração em vários, com uma abstração que ninguém tinha pedido. Perguntava se estava pronto e ouvia que sim, que estava tudo funcionando, e na hora de rodar não estava. Nada grave. Só o suficiente para eu escrever, de novo, no pedido seguinte: faça só o que eu pedi, rode antes de dizer que terminou.

Demorei para perceber que eu estava corrigindo o mesmo comportamento pedido a pedido. E que, se eu precisava repetir a mesma frase em toda conversa, aquilo não era parte do pedido. Era outra coisa.

A ordem de serviço e o contrato

O que me ajudou a dar nome a isso foi um vídeo do IndyDevDan, um dev que publica sobre agentes de IA, a respeito do Opus 5, da Anthropic. A tese dele: o modelo é muito inteligente e, justamente por isso, cansativo. Responde mais do que foi perguntado, concorda com tudo, amplia o escopo por conta própria, escreve com os mesmos tiques.

A saída que ele propõe não é pedir melhor. É separar duas coisas que costumam vir misturadas. Uma é o pedido, que vale para uma tarefa, como uma ordem de serviço. A outra é o system prompt, as instruções que valem para toda a conversa, mais parecido com um contrato. Prompt engineering não morreu, diz ele, só que o trabalho importante saiu do pedido e foi para o contrato. Numa frase dele que eu gostei: "boa comunicação é boa engenharia".

Não é prompt, é combinado

Quando eu traduzi aquilo para a minha experiência, a palavra que veio não foi contrato. Foi combinado.

Todo time bom em que trabalhei tinha combinados. Como abrir um PR, quando avisar que travou, o que conta como pronto. Quase nunca estavam escritos. A gente aprendia errando, ou alguém falava no café. Com a IA isso não funciona: o que não está escrito não existe. No post anterior eu falei de como a IA está ensinando a gente a pedir. Este é o passo seguinte: parar de pedir melhor a cada vez e combinar uma vez como se trabalha.

O que tem nos meus combinados

Todo projeto meu hoje tem um CLAUDE.md ou um AGENTS.md, os arquivos que os agentes leem antes de começar. E quase sempre uma pasta docs com as especificações do projeto: os fluxos de usuário, os guardrails de código, as bibliotecas que eu quero que sejam usadas, o que é permitido e o que não é, a lista de entidades e uma visão do todo.

Das técnicas do vídeo, as que eu mais uso são as mais sem graça: limite de escopo e guardrail. Entregue só o que foi pedido. Não crie abstração para um futuro que ninguém pediu. Não diga que terminou sem mostrar que funciona. Não é muito diferente do que um líder cobra de quem está começando no time. A diferença é que, para a IA, eu escrevo uma vez e não preciso repetir.

Tem também a lista do que é proibido. Nos meus projetos, os agentes seguem um guia de tom de voz para o que escrevem em commits e documentação: nada de travessão, frase de efeito ou entusiasmo forçado. Ele nasceu porque as mensagens de commit e os documentos que eles geravam voltavam todos com a mesma cara. No vídeo, o IndyDevDan conta que também cortou o travessão dos próprios textos, para não parecer que estava respondendo com IA. Achei curioso dois lados diferentes chegarem na mesma lista.

O gargalo agora é quem pede

Uma fala do vídeo que ficou comigo: o gargalo agora não é o modelo, é quem pede.

Passei uns quinze anos em consultoria. O difícil nunca foi construir. O difícil era entender o que o cliente queria e conseguir explicar isso para quem ia construir. Antes, dava para esconder essa dificuldade atrás do tempo de desenvolvimento. O pedido vago virava semanas de idas e vindas, e todo mundo achava que era normal. Com a IA a ida e volta leva segundos, e o pedido vago aparece na hora.

O autor diz que escreve o system prompt à mão e devagar, porque cada palavra se multiplica por todas as conversas. Achei a ideia boa justamente por ir contra o momento. Todo mundo quer acelerar, e o arquivo que mais influencia o resultado é o que merece mais calma. Vale para decisão de arquitetura, vale para combinado de time.

Os combinados do time também precisam mudar

Os combinados de time que eu conheço existiam antes da IA. Padrão de PR, definição de pronto, o básico. Só que foram feitos para uma época em que escrever código era caro. Agora ele sai em volume, e o combinado precisa responder perguntas novas: quantos commits fazem sentido numa tarefa, como encaixar o tanto de código gerado nos padrões que já existem, como evitar que o repositório fique verboso só porque ficou barato escrever.

Tem um combinado que eu ainda não resolvi de vez, o da coautoria. Os agentes costumam assinar os commits como coautores, e o vídeo recomenda proibir isso. Eu não gosto, mas por outro motivo: a coautoria pode dar a entender que você não é responsável pelo que fez. Nos projetos da empresa prefiro sem. Em alguns projetos pessoais, onde deleguei mais e a responsabilidade é menor, eu deixo, porque ali o trabalho ficou mesmo mais a cargo da IA. O que me incomoda é abrir um projeto e ver todos os commits com um agente de coautor. Parece que o time deixou de fazer o próprio trabalho.

E tem o tamanho da resposta. Concordo com o vídeo que conciso é quase sempre melhor. No código eu prefiro o explícito ao implícito, mas na resposta da IA eu quero o essencial. A exceção é quem está aprendendo. Para um júnior, a explicação longa às vezes é exatamente o valor, porque é ali que ele entende o porquê. Um bom combinado talvez precise saber para quem está falando.

O que o vídeo não prova

Vale dizer o que o vídeo não mostra. A prova dele é um teste lado a lado em uma tarefa só: mostra direção, não mede ganho em código de verdade. Parte das regras dele é gosto pessoal, e copiar a lista de outra pessoa não resolve o seu problema. O que vale é o método. E a lista de tiques muda a cada modelo. O combinado que funciona hoje vai precisar de revisão no próximo, como qualquer documento de time que alguém leva a sério.

Combinar dá mais trabalho que pedir

Durante muito tempo eu achei que melhorar o resultado da IA era questão de pedir melhor. Um pedido mais claro, mais contexto, mais exemplo. Ajudava, mas eu continuava repetindo as mesmas frases.

O que mudou não foi o pedido. Foi parar e escrever, uma vez, o que eu considero pronto, até onde vai o escopo e o que não se faz. Dá mais trabalho do que pedir. Pedir deixa a decisão para depois, para a hora em que a resposta chega errada. Combinar obriga a decidir antes.