Quem tem o contexto decide, quem não tem executa, e ninguém aceita o diff sem ler

"IA que escreve código" virou uma coisa só na conversa de mercado: um agente que pensa e codifica ao mesmo tempo, e quanto mais autônomo, melhor. Entendo o apelo. Uma ferramenta só, um prompt só, o diff aparece no fim. Parece mais eficiente que qualquer arranjo com dois agentes trocando de papel no meio.

Só que a separação que uso, Claude Code pensa e Codex codifica, não nasceu de limitação de nenhum dos dois. Nasceu de uma linha de responsabilidade que precisa existir em algum lugar, com ou sem IA. Alguém decide o quê e o porquê; alguém transforma isso em código. Quando a mesma entidade faz os dois sem parar no meio, a decisão vira efeito colateral da digitação, e ninguém nota que ela foi tomada.

O gargalo nunca esteve em quem digita o código. Está em quem declara que não há mais nada a decidir.

A pergunta prática, então, é onde exatamente essa linha corta.

O que fica com quem pensa é tudo que depende de ter estado na conversa

A divisão está escrita no meu ~/.claude/CLAUDE.md. Claude fica com análise, arquitetura, spec, plano e revisão. Codex fica com uma coisa só: transformar um spec ou plano já acordado em diff. O gatilho do repasse é o momento em que o quê e o como estão definidos e o que sobra é geração mecânica de código.

Antes desse ponto, repassar é repassar ambiguidade. O Codex não estava na conversa em que o requisito foi negociado, não viu a restrição que apareceu no meio do caminho, não sabe que uma alternativa foi descartada por um motivo que ninguém escreveu. Ele preenche a lacuna com a suposição mais plausível, e a suposição mais plausível para quem não estava lá raramente é a decisão que foi tomada. Não é falta de capacidade do modelo. É falta de contexto, e contexto não se recupera na hora de codificar.

O repasse pede confirmação explícita, nunca automática

A política padrão é propor e depois confirmar. Claude diz "isso virou trabalho mecânico, posso despachar?", e o despacho só acontece com o meu sinal verde. Nunca automático. Sem esse gatilho, o agente que pensa pode decidir sozinho que a tarefa "já virou mecânica" quando ainda tem uma decisão escondida dentro dela, e executar antes da hora.

Escrevi o skill /dispatch-to-codex depois de ver esse erro dos dois lados. De um lado, Claude implementando sozinho tarefas que deveriam ter sido repassadas, porque parecia mais rápido continuar. Do outro, tarefas repassadas com o spec pela metade, e a saída do Codex aceita sem ninguém conferir contra o que tinha sido pedido. Os dois erros têm a mesma origem: ninguém parou para declarar que a decisão estava fechada.

Parar para confirmar custa ritmo, não tempo. A pausa cai exatamente no momento em que o desenho parece pronto e dá vontade de mandar executar. Só que esse é o momento em que um atalho passa despercebido se não houver uma parada explícita. O ponto de checagem fica onde a tentação de pular é maior, e é por isso que ele precisa ser regra, não bom senso.

O brief precisa carregar tudo, porque o Codex não estava na sala

O Codex não recebe o histórico da conversa. Recebe o brief de repasse, e só ele. Isso muda o que "bem especificado" significa: um brief autocontido precisa substituir o contexto que normalmente viria de perguntas de acompanhamento, porque não vai haver pergunta de acompanhamento. Qual arquivo, qual função, qual comportamento nos casos de borda, o que não tocar.

A execução roda com codex exec num sandbox com escrita restrita ao workspace, o modo workspace-write. Isso limita o estrago de um brief ruim, mas não conserta o brief. Se uma decisão importante só existe na minha cabeça, ou na conversa com o Claude, e não está no brief, ela não existe para quem vai codificar. O Codex vai fazer alguma coisa no lugar dela, e vai fazer com confiança.

O resumo do Codex não vale como aceite; o diff contra o spec vale

O Codex devolve o diff e um resumo do que fez. A regra é nunca confiar no resumo. O resumo descreve a intenção do Codex, não o que o diff contém, e os dois divergem com frequência suficiente para que a checagem seja obrigatória. Claude relê o diff contra o spec com três perguntas: faz o que foi pedido? Faz só o que foi pedido? Faz alguma coisa que o spec não autorizou?

É o mesmo tipo de checagem que fecha o ciclo de revisão do plan-driven-development. A diferença é que aqui quem decide e quem revisa continuam sendo o mesmo agente, o que tem o contexto da conversa inteira. Só a execução mecânica foi para fora. Quando o diff volta, a responsabilidade volta junto.

Se o diff entra sem leitura, a linha já sumiu

Se um diff do Codex for aceito sem alguém reler contra o spec, o protocolo já reverteu, em silêncio, para "confiar no resumo". Essa é exatamente a falha que ele existe para evitar, e ela não avisa quando acontece: o diff entra, o teste passa, e mais tarde alguém descobre uma função que ninguém pediu.

A tese cai se despachar sem confirmação explícita deixar de produzir repasses mal especificados. Se um dia o agente que pensa souber sozinho, e sem errar, quando a decisão está fechada, a parada deixa de ser necessária. Até lá, a linha fica onde está: quem tem o contexto decide, quem não tem executa, e ninguém aceita sem ler.