Programação em par com IA: contexto define

TL;DR

Programação em par com IA não reproduz pair programming humano — ela colapsa a fricção de contexto entre dois desenvolvedores em fricção de contexto entre um desenvolvedor e uma janela. Quando o contexto é bom, o par com IA entrega mais rápido; quando é fraco, entrega código que parece certo mas resolve o problema errado. Os mecanismos são diferentes, e tratá-los como iguais é o erro de governança mais caro desta década.

• Acelerador, não substituto: a velocidade de varredura e baixa inércia da janela de prompt substituem coordenação humana apenas se o contexto chegar explícito.
• Plausibilidade como armadilha: código gerado por IA parece pronto antes de estar correto, e isso prejudica a revisão humana.
• Contexto é artefato: prompts viram peças de engenharia — escritos, versionados e revisados.
• Governança é o que viabiliza: quatro controles práticos (template de issue, review por terceiro, audit semanal, limite de PRs/dia) sustentam o ganho sem virar débito técnico.
• Senioridade muda a inclinação: o mesmo processo Amplifica sênior e multiplica defeito em júnior.

Por que programação em par com IA não é programação em par

Programação em par tradicional tem duas pessoas, dois cérebros e dois modelos mentais em sincronia constante. A fricção central é coordenação humana: negociar objetivos, expor premissas, debater trade-offs, dividir contexto compartilhado e validar entendimento com perguntas de esclarecimento. Essa fricção é o que faz o método funcionar — ela obriga o par a explicitar o que um programador solitário deixaria implícito.

Programação em par com IA troca o segundo cérebro por um sintetizador estatístico. A fricção central vira contexto: cada prompt enviado ao modelo é a única janela para o que o par humano quer dizer. Sem contexto suficiente, o modelo devolve a continuação mais provável estatisticamente — e não a continuação que resolve o problema real. O código gerado parece coerente, compila, passa em testes e, mesmo assim, erra o requisito.

A diferença operacional é direta: par humano sinaliza confusão (“espera, por que X?”), par com IA segue adiante porque o texto gerado é plausível. O custo de correção é invisível até alguém ler o PR com critério.

O que entra e o que sai quando a janela troca de pessoa por prompt

O par humano traz três coisas que a janela de prompt não traz automaticamente:

• Memória do projeto: contexto histórico do código, decisões passadas e dívida assumida.
• Senso de risco: avaliação do impacto da mudança em produção, em produção real.
• Capacidade de parar: habilidade de interromper a geração quando a premissa está errada.

Janela de prompt traz outras três coisas:

• Velocidade de varredura: localizar bibliotecas, exemplos e APIs em segundos.
• Baixa inércia: começa a escrever rascunhos sem cerimônia.
• Disposição para repetir: itera sem fadiga, útil em código mecânico.

Esses três últimos são rápidos e baratos — é por isso que muitas equipes subestimam a defasagem dos três primeiros.

Tratar o par com IA como substituto completo do par humano ignora que ele amplifica exatamente o que o desenvolvedor já sabe articular. Um sênior que sabe escrever contexto bom recebe aceleração; um júnior que ainda está construindo o modelo mental recebe código plausível e feedbacks incorretos sobre ele. As duas curvas não convergem.

A evidência empírica disponível vem de testes cegos em que o mesmo desenvolvedor avalia PRs com e sem geração por IA. PRs gerados com pouco contexto recebem notas mais altas em qualidade superficial de código (lint, formatação, nomenclatura) e notas mais baixas em correção semântica e adequação ao requisito. A divergência entre as duas escalas é onde mora a perda.

Contexto é o artefato, não o acessório

Em par humano, o contexto mora nas conversas: perguntar “qual o SLA disso?”, “quem vai ler esse código?”, “isso precisa rodar offline?”. Em par com IA, essas perguntas precisam ir para o prompt — ou não acontecem.

Derivada 1 — explícito, documentado, revisado. A primeira derivada é que times maduros precisam explicitar, documentar e revisar prompts como artefatos de engenharia. Não é exagero: um prompt ruim escrito por um sênior é code review ruim escrito por um sênior — silenciosamente deixa passar problema sério.

Derivada 2 — código que sai do prompt. A segunda derivada é que o “contexto” deixado de fora do prompt vira código deixado de fora do software. Estudos de caso publicados em 2024 e 2025 mostram bug reports recorrentes do tipo “a feature funciona em testes mas erra o caso de uso em produção” — todos derivados de prompt incompleto sobre regras de negócio, integrações legadas ou exceções regulatórias.

Derivada 3 — versionamento importa. A terceira derivada é que prompts precisam ser versionados juntos com o código. Mudar uma integração sem mudar o template que a referencia produz bugs que nenhum dos dois lados detecta sozinho. Tratar prompt como código é o pré-requisito para tratar contexto como infraestrutura.

A armadilha da plausibilidade

Código gerado por IA é linguisticamente correto antes de ser tecnicamente correto. Ele respeita convenções sintáticas, segue o estilo do projeto e cita bibliotecas que existem. Esse alto grau de plausibilidade é o que faz a revisão humana acelerar — o olho lê como código pronto e valida pela superfície.

Esse padrão é perigoso justamente porque pune quem revisa bem: revisar código plausível exige gasto cognitivo para desconfiar do que parece certo. É mais fácil aprovar. E aprovar o que parece certo é a falha clássica de governança em revisão de código — amplificada em uma ordem de grandeza pelo volume de código gerado.

A solução prática é adotar o mesmo princípio usado em revisões de criptografia: pressão de revisão proporcional à plausibilidade. Quanto mais o código parece pronto, mais lento e criterioso o review precisa ser.

Três heurísticas operacionais:

• Ler o teste antes da implementação: testes gerados por IA tendem a validar o código produzido, não o requisito — olhar o teste antes obriga a confrontar o requisito.
• Exigir changelog narrativo: par que entende o problema descreve em poucas linhas por que mudou o que mudou. Falta de narrativa é proxy para prompt magro.
• Difícil de explicar, fácil de aceitar: quando a justificativa do PR é longa mas plausível, isso é sinal de alerta — solicitar exemplo concreto do problema em produção.

Métricas que expõem o problema antes do post-mortem

Medir aceitação de PRs com e sem IA é indicador tardio. O sintoma aparece antes, em quatro métricas concretas:

• Taxa de retrabalho em histórias aceitas: histórias “concluídas” que voltam por defeito semântico. Acima de 15% em uma squad, considere auditoria de contexto em prompts.
• Idade média do defeito: quanto tempo entre merge e detecção do bug? Ferramentas tendem a reduzir a idade — porque o código costuma falhar em testes de fumaça primeiro. Mas os defeitos que passam pelos testes são mais profundos e mais antigos no fluxo.
• Carga de PR review: aumento de volume de PRs sem aumento de revisores seniores é o precursor direto de regressões.
• Densidade de hipóteses no PR: PRs que entregam pouco contexto sobre o problema resolvido (descrições curtas como “corrige bug X”, “refatora Y”) costumam ser os que vieram de prompts magros.

A métrica mais simples e menos invasiva é contar quantos PRs foram abertos sem descrição de problema acima de 50 palavras. Esse número é proxy direto para “quanto contexto vazou para dentro do prompt”. Em squads maduras, o número fica abaixo de 10% das aberturas; acima de 30%, é hora de parar e treinar template de issue.

Governança mínima viável para times que adotam IA em código

Quatro controles práticos, nesta ordem:

• Template de prompt de issue: ao abrir issue que vai ter código gerado, o template exige (a) caso de uso concreto, (b) restrições de integração, (c) critério de aceite verificável. Sem isso, o trabalho não começa.
• PR review obrigatório por humano não envolvido na geração: o revisor não viu o prompt, vê apenas o diff. Força uma camada externa de contexto.
• Audit semanal de 1 PR aleatório por dev: alguém de fora lê o PR e o prompt que o gerou. Discrepância entre intenção declarada e código entregue vira ticket de treinamento.
• Limite de PRs por dia por autor: desacelera e obriga priorização. Captura a síndrome “code spam” antes de virar débito técnico.

Esses quatro controles substituem, com vantagem, o que par humano fornecia por construção:

• Pergunta de esclarecimento: capturada por template de issue.
• Debate sobre premissas: capturada por PR review por terceiro.
• Validação de adequação: capturada por audit semanal.
• Pressão de ritmo: capturada por limite de PRs por dia.

A ordem importa: implementar limite de PRs sem template de issue penaliza o time sem mudar a qualidade. Implementar audit semanal sem PR review por terceiro sobrecarrega audit e ninguém conserta o que aparece.

Senioridade muda o cálculo, não a regra

Programador sênior com bom contexto gera código assistido de alta qualidade e usa a aceleração para investir em testes, refatoração ou dívida paga. A aceleração vira alavanca.

Programador júnior com pouco contexto gera código assistido de baixa qualidade e usa a aceleração para produzir mais código ruim por dia. A aceleração vira multiplicador de defeito.

A regra é a mesma — ganho depende de contexto. Mas a inclinação da curva muda violentamente com a senioridade. Governança que trata a média do time como se fosse uniforme prejudica júnior e desperdiça sênior.

A implicação prática: parear júnior com sênior para revisar todo código gerado por IA até o júnior acumular evidência de qualidade própria. Não é castigo — é o mesmo investimento que se faria em qualquer tecnologia nova que muda a economia de produção.

A diferença é contexto. Sempre foi. A novidade é que agora ele é um artefato de engenharia que precisa ser escrito, versionado e revisado. Times que tratam prompt como documentação descartável pagam juros alto; times que tratam como código revisável colhem a aceleração sem perder a correção. O par com IA é uma terceira forma de colaboração, com regras próprias de higiene, e exige governança para escalar sem virar débito técnico.

Leitura relacionada

• Programação em par com IA: aceleração evolutiva — análise do ganho de produtividade em pares humanos assistidos por IA, com números de DORA e cadência de PRs.
• Dependência de IA em revisão de código — como a relação de confiança com a ferramenta muda ao longo do tempo e quando reverter importa.
• Programação em par com IA: cinco vetores que decidem — mapeamento complementar dos cinco vetores (domínio, tarefa, senioridade, estágio e métrica) que determinam resultado em programação em par com IA.