Pair programming com IA é marketing linguístico. Você não tem par. Tem assistência automática.

TL;DR

A frase “pair programming com IA” é um caso de fraude semântica: transfere para uma ferramenta promessas de comportamento que a prática não cumpre. Quatro pontos sustentam a correção do nome.

• Fraude semântica — o rótulo “pair” herda promessas de confrontação, visão compartilhada e responsabilidade distribuída que a ferramenta não entrega; o que existe é geração automatizada com aceitação posterior.
• Responsabilidade assimétrica — a sugestão vem sem custódia, mas a decisão final fica com quem aceitou; o “par” deveria dividir a conta, e a máquina não assina post-mortem.
• Síntese não é criação — modelo generativo recombina padrões do corpus de treinamento; chamar isso de “co-criação” é tomar o produto da máquina pelo seu processo, ignorando que geração estatística não é autoria.
• Uso honesto — pair programming com IA é assistência automática, não colaboração; renomear a prática para o que ela é reduz expectativa inflada e devolve a custódia técnica ao humano que decide.

O par original e o que ele resolvia

Pair programming, na definição de Beck, é uma prática de produção onde dois programadores compartilham uma estação de trabalho, com responsabilidade compartilhada pelo código escrito. O benefício central não é velocidade de digitação, e sim a confrontação produtiva: um escreve, o outro revisa em tempo real, e a decisão de manter uma linha passa pelo crivo de dois profissionais com leituras potencialmente diferentes do problema.

A definição tem três componentes operacionais:

• Visão compartilhada do problema — dois desenvolvedores alinhando o que está sendo resolvido, não dois operadores executando em paralelo.
• Transferência bidirecional de conhecimento — o programador mais experiente no domínio transfere contexto, e o programador menos experiente traz questionamento sobre decisões que parecem naturais para quem já internalizou as restrições.
• Responsabilidade distribuída — o código que entra em produção é assumido por dois nomes, e o *post-mortem* de incidente é dividido entre os dois.

Williams, em pesquisa de campo da década de 2000 sobre pair programming entre humanos, documentou que o ganho empírico da prática vem exatamente desses três componentes, e não do tempo economizado em digitação. Times que adotam a prática reportam redução de defeitos em produção da ordem de 15% a 50%, dependendo do domínio — número que cai para próximo de zero quando um dos dois “pares” não tem capacidade de questionar a decisão que o outro está tomando.

A definição importa porque é a referência que está sendo invocada toda vez que o nome “pair” é pronunciado. Sem ela, “pair” vira substantivo solto, disponível para rotular qualquer colaboração de duas inteligências em uma tela.

O que muda quando o par é uma máquina

Substituir o segundo humano por uma IA generativa não preserva nenhum dos três componentes. O modelo generativo não tem visão compartilhada do problema, porque o problema não é um *input* dele — é um *prompt* recebido em sequência. O modelo não transfere contexto do domínio, porque contexto não está nos pesos: está no histórico da conversa, e qualquer interrupção de sessão o apaga. O modelo não divide responsabilidade, porque modelo generativo não assina *post-mortem* nem responde a incidente de produção em três semanas.

O que existe, na prática, é um ciclo operacional diferente: prompt é enviado, sugestão é retornada, dev lê, dev copia, edita superficialmente ou aceita como está, e segue para o próximo bloco. Esse ciclo tem três propriedades sistemáticas:

• Alta confiança verbal — o modelo responde com afirmações que soam técnicas sem o mesmo lastro que um par humano carrega; tom assertivo substitui evidência.
• Contestação custosa — revisar linha a linha o que o modelo escreveu exige mais atenção do que revisar o que outro humano escreveu, porque o modelo não tem o constrangimento social de defender uma escolha ruim.
• Aceitação cresce com a fadiga — quanto mais longa a sessão, maior a probabilidade de o dev aprovar sem ler; a taxa de aceitação sobe conforme cai a energia cognitiva disponível.

A prática não é má por si. É um ciclo de produtividade que entrega valor mensurável, e o estudo do GitHub Copilot de 2024 documenta ganho de velocidade de tarefas combinatórias da ordem de 30% a 55%. O problema não é a entrega. O problema é o nome que embrulha a entrega e a vende como algo que ela não é.

Responsabilidade sem suporte

Pair programming, na sua definição original, distribui a custódia do código entre dois profissionais. O segundo humano é testemunha do que foi escrito, conhece o histórico da decisão, e divide a responsabilidade técnica e jurídica quando o código entra em produção e falha. Modelo generativo não divide nada disso. Ele não assina *commit*, não está presente no *code review* quando o PR é aberto por outro dev, não acorda às três da manhã para o plantão, e não responde ao cliente quando o sistema cai.

A assimetria tem efeito direto na conta de incidente. Caso de campo em sistema de pagamento: três sugestões consecutivas de IA foram aceitas sem contestação por dois revisores humanos diferentes ao longo de uma semana. O sistema entrou em produção com *race condition* em *path* de cancelamento de transação. O sintoma apareceu três semanas depois, em horário de pico, com fila de pedidos pendentes. O post-mortem do incidente listou a ausência de revisão contestatória como fator contribuinte — não porque a ferramenta escreveu código ruim, mas porque ninguém exerceu a função que o nome “pair” prometia.

Stack Overflow Developer Survey 2025 registra 84% de uso de IA generativa entre desenvolvedores e 46% de desconfiança na acurácia das respostas. O número descreve com precisão a assimetria: o uso subiu porque a entrega é rápida, e a desconfiança persiste porque a custódia da decisão continua sendo do dev que aceita a sugestão. A conta do uso e a conta da desconfiança caem sobre o mesmo profissional — e o nome “pair” esconde que a outra parte da equação não divide essa conta.

Co-criação como ficção útil

Modelo generativo opera por predição estatística sobre o corpus de treinamento. Cada token produzido é o próximo token mais provável dado o contexto recebido. O resultado, quando o contexto é um prompt técnico bem formado, é uma sequência que parece criação, e que tem alta probabilidade estatística de estar correta, dado o volume de código similar no corpus.

A questão não é se a sequência é útil. A questão é se a sequência é criação. “Co-criação” sugere autoria conjunta, e autoria exige três propriedades: intencionalidade sobre o que está sendo produzido, accountability pelo que foi produzido, e continuidade de contexto entre o que foi produzido e o que será produzido em seguida. Modelo generativo tem continuidade de contexto dentro de uma sessão, mas intencionalidade e accountability são externas à sessão, e pertencem ao humano que formula o prompt e aceita a saída.

Chamar o processo de co-criação é tomar o produto da máquina pelo seu processo. O produto — um bloco de código que resolve um problema local — é real. O processo — recombinação estatística de padrões do treinamento — não é autoria. A confusão importa porque infla o que o dev pode esperar da próxima sessão: a próxima sugestão não é “continuação da nossa conversa”, é a próxima predição do modelo, sujeita aos mesmos limites da anterior.

Três propriedades separam autoria de geração estatística:

• Intencionalidade — só o humano define o que está sendo resolvido; o modelo responde ao que recebe, sem avaliação do propósito.
• Accountability — só o humano responde pelo que foi escrito; o modelo não carrega consequência pela saída.
• Continuidade de contexto — dentro da sessão o modelo preserva, mas sessão é delimitada por janela de contexto; passado fora dela e futuro depois dela não entram na predição.

O DORA Report 2024 documenta que times com alta adoção de IA generativa reportam ganho de produtividade individual, mas sem ganho equivalente em estabilidade de entrega. A divergência entre os dois números é o mesmo fenômeno visto de outro ângulo: ganho local no que é gerado, sem ganho global no que é assumido.

Linguagem mascara operação

Renomear uma prática operacional não é descuido terminológico. É estratégia de mercado, e a estratégia funciona porque nomenclatura molda expectativa. Antes de pair programming, “programação” era o nome da atividade de escrever software. Quando a prática de dois humanos em uma estação ganhou o nome “pair”, o nome trouxe consigo o conjunto de promessas descritas na definição de Beck. Quem ouve “pair” hoje herda essas promessas automaticamente, sem necessidade de releitura da definição original.

A rebrandagem de geração automatizada como “pair programming com IA” aplica o mesmo mecanismo. O nome “pair” injeta no consumidor da ferramenta a expectativa de confrontação, visão compartilhada e responsabilidade distribuída, e o nome “IA” injeta a expectativa de capacidade técnica aproximada à de um par humano. A combinação das duas expectativas produz um terceiro objeto, que não existe na prática: uma ferramenta que, ao mesmo tempo, contestaria o dev quando o código fosse ruim e dividiria a conta quando o código falhasse em produção.

O custo da divergência entre nome e prática é suportado por três classes de profissional:

• Dev sênior que pede ao júnior para usar “pair com IA” — e descobre, três meses depois, que o júnior parou de questionar sugestões, porque o “par” sempre concorda; a transferência de conhecimento que o par humano faria não aconteceu, e a expectativa de mentoria foi drenada em revisão de código gerado.
• Tech lead que justifica ao gestor de engenharia a contratação de menos uma vaga — porque “o par agora é a IA”; a conta da vaga não contratada aparece em incidente de produção que precisava de segunda leitura humana e não teve.
• Gestor que aprova o orçamento de uma ferramenta que entrega metade do que o nome promete — e descobre a outra metade quando o primeiro incidente sério entra em produção; o ROI calculado sobre o nome, e o ROI real sobre a prática, não fecham.

O que sobra quando o nome é corrigido

Assistência automática por IA generativa é ferramenta legítima, com ganho mensurável de produtividade, limites operacionais claros, e custódia técnica integral do lado de quem aceita a sugestão. Renomear a prática para o que ela é — “assistência automática” ou “geração com revisão” — desfaz a fraude semântica, devolve a custódia ao humano que decide, e permite usar a ferramenta com expectativa calibrada.

Três critérios de uso honesto, na próxima sprint:

• Aceite com custódia — o dev que aceita uma sugestão de mais de cinco linhas deve assinar o *commit* e responder ao plantão; o aceite define a custódia, e a custódia exige nome no rodapé.
• Segunda revisão independente — *pull request* com mais de 30% de código gerado por IA exige segunda revisão humana, feita por quem não participou da sessão de prompting; o revisor não viu o prompt, e deve ler o código como leria o de qualquer autor anônimo.
• Post-mortem com rastreabilidade — incidente com trecho de IA em produção entra no post-mortem identificado pela sessão de prompting que produziu o trecho — não pelo modelo, mas pelo dev que aceitou; sem essa identificação, o padrão recorrente não é corrigível.

O ganho de produtividade individual permanece. A custódia técnica volta para quem decide. O orçamento volta a ser comparado com o que a ferramenta realmente entrega. O próximo orçamento de tooling volta a ser comparado contra o que o fornecedor entregou no trimestre, não contra o que a marca promete. O nome deixa de prometer o que a ferramenta não entrega — e o time para de pagar a conta da divergência.

Leitura relacionada

• Você não tem atraso. Você tem expectativa errada. — mostra como prazo de entrega sem readiness produz o mesmo tipo de conta que “pair com IA” sem custódia: a decisão foi tomada sobre promessa, e quem executa paga o descolamento.
• Programação em par com IA: aceleração evolutiva — documenta o ganho mensurável de produtividade da prática que este post desfaz semanticamente; os dois posts se complementam, e a divergência entre eles é produtiva, não adversarial.
• Dependência de IA na revisão de código — aprofunda o caso de uso específico em code review, onde a assimetria de responsabilidade descrita neste post vira ponto de falha operacional documentado em DORA 2024.