Pair programming com IA: como trabalhar com um agente

Pair programming com IA é a mesma prática que desenvolvedores usam há décadas, com um dos lugares ocupado por um agente de código. Um lado dirige: digita o código. O outro navega: segura o plano, fica de olho nos erros e decide o que vem a seguir. A diferença é que um agente digita muito mais rápido do que você lê, então a parte difícil não é mais escrever código. É manter o controle do que está sendo escrito.

Este guia mostra como dividir os papéis com um agente, quando deixá-lo dirigir sozinho e quando revisar cada passo, como os modos de aprovação do Claude Code, do Codex e do Gemini CLI se encaixam nessa escolha, como manter passos pequenos e diffs legíveis, como fazer par para aprender em vez de só delegar e como deixar dois agentes fazerem par entre si enquanto você navega. Os nomes de comandos e modos seguem a documentação oficial de outubro de 2026.

Driver e navigator, com um agente num dos lugares

No pairing clássico, os papéis trocam com frequência. Com um agente, há duas configurações úteis.

Você navega, o agente dirige. É o padrão para a maior parte do trabalho. Você descreve o objetivo, as restrições e o próximo passo; o agente edita arquivos e roda comandos; você lê o que ele fez e corrige o rumo. Seu trabalho é o de um bom navigator: manter a visão geral, perceber quando o código vai para o lado errado e pará-lo cedo.

Você dirige, o agente navega. Você escreve o código e usa o agente como segundo par de olhos. Peça para ele revisar a função que você acabou de escrever, sugerir casos de borda, descobrir de onde vem um valor ou escrever o teste antes de você escrever o código. É mais lento, mas é a configuração certa quando você precisa entender cada linha, por exemplo em código que vai manter sozinho ou quando está aprendendo uma linguagem nova.

Decida a configuração antes de começar uma tarefa e diga isso no prompt: “Eu escrevo o parser, você revisa cada função que eu colar e lista casos de borda” é uma sessão bem diferente de “Implemente o parser; pare depois de cada função para eu revisar.” Trocar de papel no meio sem avisar é como se acaba com um código que ninguém entende por inteiro.

Quando deixá-lo dirigir e quando revisar cada passo

A pergunta não é se você confia no agente. É quão caro é um erro e quão rápido você o perceberia. Uma regra prática simples:

Duas coisas tornam seguro deixar o agente dirigir: testes que falham quando o comportamento quebra e uma forma de desfazer. Se você tem as duas, um caminho errado custa alguns minutos. Se não tem nenhuma, revise cada passo, ou adicione testes primeiro (escreva testes unitários com IA mostra como).

Um bom meio-termo para tarefas maiores é planejar primeiro. No Claude Code, o plan mode deixa o agente ler e propor um plano sem editar nada; você revisa o plano, corrige e então troca de modo e deixa executar. Plan mode do Claude Code explica passo a passo. Revisar um plano leva um minuto; revisar uma implementação errada leva muito mais.

Modos de aprovação: quanto o agente pode fazer sem perguntar

Toda CLI de agente de código relevante tem uma configuração de com que frequência ela para e pergunta. Essa configuração é o seu estilo de pairing escrito como config.

O Claude Code tem modos de permissão, em outubro de 2026:

• default: pergunta antes de editar arquivos e antes de comandos que ainda não foram permitidos. É o revisar-cada-passo.
• acceptEdits: edições de arquivos no diretório de trabalho, mais comandos simples de arquivo como mkdir e mv, são aceitos sem perguntar; outros comandos continuam perguntando.
• plan: lê e propõe, não edita.
• auto: um classificador em segundo plano verifica cada ação e bloqueia as arriscadas, então o agente pergunta menos. A disponibilidade depende do seu plano e do modelo, e admins podem desativá-lo.
• bypassPermissions: nenhuma checagem. A documentação recomenda usar só em ambientes isolados, como contêineres ou VMs.

Pressione Shift+Tab para alternar entre os modos durante uma sessão, inicie com claude --permission-mode acceptEdits ou defina permissions.defaultMode nas configurações. Quando você responde a um pedido com “Yes, and don’t ask again”, a regra é salva e o mesmo comando não pergunta de novo. Permissões do Claude Code explica a ponta arriscada da escala.

A Codex CLI combina um sandbox com uma política de aprovação. O preset padrão Auto deixa editar e rodar comandos dentro do workspace e pergunta antes de sair dele (--sandbox workspace-write --ask-for-approval on-request). Use /permissions durante uma sessão para trocar, por exemplo para Read Only, ou inicie com --sandbox read-only quando só quiser que ele olhe.

O Gemini CLI tem --approval-mode com default (pergunta), auto_edit (aceita edições, pergunta para outras ferramentas), plan (somente leitura) e yolo (aceita tudo).

Um mapeamento prático: revisar cada passo significa o modo padrão em todos. Deixar dirigir em trabalho rotineiro significa aceitar edições, mas ainda aprovar comandos de shell, porque é nos comandos que acontecem as coisas irreversíveis. Automático total é para um contêiner ou uma worktree descartável, nunca numa máquina com credenciais de produção.

Passos pequenos

O pairing funciona porque cada passo é pequeno o bastante para ser discutido. Com um agente isso importa ainda mais, já que ele consegue produzir mil linhas antes de você terminar de ler as primeiras cem.

• Peça um passo de cada vez. “Adicione a função de validação e os testes dela, depois pare” é melhor que “construa o fluxo de cadastro.”
• Diga quando parar. Agentes tendem a seguir para a próxima coisa óbvia. “Pare depois disso e resuma o que mudou” mantém o ritmo nas suas mãos.
• Faça commit depois de cada passo verde. Um commit por passo dá um ponto limpo para desfazer e um histórico legível. git add -p deixa você conferir cada hunk na entrada.
• Use checkpoints para o meio do caminho. No Claude Code, /rewind (ou apertar Esc duas vezes) volta o código e a conversa para um prompt anterior. Mudanças feitas por comandos de shell não são rastreadas por ele, então o git continua sendo sua rede de segurança real. Desfazer mudanças do Claude Code cobre os dois.

Se um passo der errado, desfaça e refaça o prompt com o que aprendeu. Pedir ao agente que corrija o próprio desvio em cima do código errado costuma fazer uma bagunça maior do que recomeçar o passo.

Revisando diffs

Como navigator, o diff é sua ferramenta principal. Leia antes de aceitar o passo, não depois dos próximos três.

git status
git diff --stat
git diff

No Codex, /diff mostra as mudanças atuais dentro da sessão. Em qualquer agente você pode pedir: “Mostre o diff do que você mudou e explique cada hunk em uma linha.”

O que procurar, além de o código funcionar:

• Escopo. Arquivos alterados que não têm nada a ver com a tarefa. Renomeações, reformatações e “pequenas limpezas” escondem mudanças reais.
• Testes apagados ou enfraquecidos. Uma asserção alterada para bater com a nova saída, ou um teste marcado como skip, é um sinal de alerta.
• Erros silenciados. Blocos catch vazios, casts para any, regras de lint desativadas, flags --force.
• Dependências novas. Cada uma é código que agora você mantém.
• Coisas que você não consegue explicar. Se não sabe dizer por que uma linha está ali, pergunte antes de aceitar.

O guia de code review com IA aprofunda a revisão do que o agente produz na etapa de pull request.

Aprender versus delegar

Fazer par com um agente pode te deixar mais rápido no que você já sabe ou te ensinar o que você não sabe. Isso pede sessões diferentes.

Quando você delega, o que importa é o resultado. Dê critérios de aceite claros, deixe o agente dirigir, revise o diff e os testes. Isso serve para boilerplate, migrations e código em áreas que você já entende.

Quando você quer aprender, desacelere de propósito:

• Peça um plano e uma explicação antes de qualquer código: “Explique como você abordaria isto e por quê, não escreva código ainda.”
• Digite você mesmo a lógica central e peça ao agente para revisar.
• Pergunte “por que isto e não aquilo?” sobre as escolhas dele e peça para mostrar a alternativa.
• Peça para ele escrever primeiro um teste que falha e faça-o passar você mesmo.

Um hábito útil: se você não conseguiria reescrever um trecho de código sem o agente, ainda não aprendeu, só aceitou. Isso é aceitável para parte do código, mas deve ser uma decisão, não um acidente.

Dupla de agentes: um escreve, outro revisa

O papel de navigator também pode ficar com um segundo agente. Um agente escreve; outro, de preferência de outro modelo para que os pontos cegos sejam diferentes, revisa; você decide o que fazer.

Uma versão simples com duas CLIs no mesmo repositório:

# Terminal 1: Claude Code implements the step
claude "Add rate limiting to the /login route. Stop when tests pass."

# Terminal 2: Codex reviews the uncommitted changes
codex review --uncommitted

codex review também revisa contra uma branch base (--base main) ou um único commit (--commit <sha>), e dentro de uma sessão /review faz o mesmo. Cole de volta para o agente que escreve os apontamentos com que você concorda e ignore os outros: a saída do revisor é um conselho para você, não uma ordem para o outro agente.

Algumas regras fazem o pairing entre agentes funcionar:

• Outro modelo, ou pelo menos uma sessão nova. Um revisor que compartilha o contexto de quem escreveu tende a concordar com ele.
• O revisor não edita. Rode-o em modo somente leitura. Dois agentes editando os mesmos arquivos ao mesmo tempo é um conflito de merge, não uma revisão.
• Você continua como navigator. Não mande a saída da revisão direto para quem escreve num loop sem fim. Leia, escolha os problemas reais e envie esses.
• Escreva os critérios. “Verifique validação de entrada faltando, erros não tratados e comportamento alterado” rende uma revisão muito mais útil do que “revise isto”.

Para trabalhos maiores, o mesmo padrão escala para vários agentes escrevendo em worktrees separadas com um revisor, tema de equipes de agentes de IA.

Fazendo isso com o AgentVera

O AgentVera roda Claude Code, Codex, Gemini CLI e outros agentes de CLI lado a lado numa só janela, então as duas configurações de pairing cabem numa única visão.

• Workspace. Coloque o agente que escreve e o que revisa em painéis lado a lado no mesmo projeto. Cada agente tem a própria configuração de permissão (Ask, Auto ou Full access), então quem escreve pode aceitar edições enquanto o revisor só lê.
• Aprovação automática (Pro e Team, Claude Code). Leituras, git somente leitura e comandos de teste, lint e build são aprovados por você, enquanto comandos arriscados como git push, rm ou git reset --hard sempre chegam até você. É o “deixa dirigir, mas as partes perigosas são minhas” sem clicar em cada pedido.
• Notificações e aprovações. Quando um agente está esperando por você, um atalho leva direto ao que espera há mais tempo.
• Checkpoints. Cada turno é salvo, então você pode desfazer um passo de uma sessão sem mexer no histórico do git.
• Code review. No fim de um turno, um modelo Claude que você escolhe revisa as mudanças e lista apontamentos com severidade e arquivo:linha, e você pode mandá-los de volta ao agente. É um segundo agente embutido no lugar de navigator.
• Caixa de revisão. O trabalho concluído espera em cards com os arquivos alterados, notas de risco e diffs, onde você aprova ou devolve com um comentário.
• Mensagens entre agentes. Agentes do mesmo projeto podem trocar mensagens e compartilhar uma lista de tarefas, entre CLIs diferentes, então quem escreve pode perguntar direto a quem revisa.

Conclusão

Pair programming com IA funciona quando os papéis estão claros. Decida quem dirige antes de cada tarefa. Ajuste o modo de aprovação ao risco, não ao seu humor. Mantenha os passos pequenos e faça commit depois de cada um que passar. Leia todo diff antes de aceitar. Escolha de propósito entre delegar e aprender. Quando quiser uma segunda opinião, deixe um segundo agente revisar enquanto você continua como navigator.

Se quiser um trabalho longo, passo a passo, para praticar, migrar JavaScript para TypeScript com IA é uma boa opção: cada passo é pequeno, e o compilador avisa quando terminou.