Programação em Par na Era da IA - O Par que Não Dorme

Em 1999, quando Kent Beck sistematizou o Extreme Programming (XP), a ideia de colocar dois programadores diante de uma única estação de trabalho soou, para muitos gestores, como desperdício deliberado de mão de obra [1]. Alocar duas pessoas à mesma tarefa parecia contrariar o senso comum da produtividade. Mais de vinte e cinco anos depois, a atenta leitora encontra um cenário curioso: assistentes baseados em modelos de linguagem passaram a ocupar parte desse espaço de colaboração, sugerindo ou executando código em tempo real e com disponibilidade contínua. Isso não significa que tenham simplesmente substituído o segundo programador humano. A pergunta que organiza este artigo é mais cuidadosa: quando a IA entra no par, como os papéis se transformam e o que essa mudança exige de nós?

Este texto está ancorado na ementa da disciplina de Metodologias Ágeis, particularmente nos conteúdos formativos sobre práticas de XP e na importância da agilidade para a qualidade, a inovação e a adaptação às mudanças. A tese que defendo, e que este pobre escriba pede licença para sustentar até o fim, é que a IA generativa pode acelerar a inovação, mas não dispensa, e frequentemente torna mais urgentes, os pilares metodológicos que o XP propôs há mais de um quarto de século. Os gargalos da Engenharia de Software variam entre requisitos, coordenação, arquitetura, implementação, validação e entrega. Ao reduzir o custo de produzir código, a IA desloca uma parcela ainda maior do trabalho para compreender o problema, verificar a solução e controlar suas consequências.

A Programação em Par no Extreme Programming

A Programação em Par (pair programming) é uma das práticas clássicas do XP [1]. Na sua formulação original, dois desenvolvedores trabalham juntos em uma única estação de trabalho, alternando entre dois papéis bem definidos:

1. Driver (condutor): controla o teclado e escreve o código, concentrando-se na tática imediata, isto é, na sintaxe e na implementação da linha atual;
2. Navigator (navegador): observa, revisa em tempo real, pensa na estratégia, antecipa problemas e mantém o desenho global em mente.

A troca constante de papéis e o diálogo permanente produzem uma revisão de código contínua, embutida no próprio ato de programar, em vez de relegada a uma etapa posterior. Sommerville destaca a revisão contínua como um mecanismo de detecção precoce de defeitos [2]. Em geral, quanto mais tarde um problema é descoberto, maior tende a ser o esforço para recuperar contexto, localizar dependências, corrigir a implementação e validar novamente o sistema. A magnitude desse custo, porém, depende do processo, da arquitetura e da capacidade de obter retorno rápido.

A sagaz leitora pode, com razão, desconfiar de afirmações sobre produtividade que não venham acompanhadas de números. O estudo seminal de Williams e colaboradores, conduzido na Universidade de Utah, oferece-os. Comparando desenvolvedores trabalhando sozinhos e em pares, os pesquisadores observaram que os pares concluíam as atividades em menos tempo decorrido, mas consumiam cerca de 15% mais esforço total, medido em pessoa-hora. Em contrapartida, produziam soluções que passavam entre 86% e 94% dos casos de teste, contra 73% a 78% das soluções individuais [3, 4]. É importante distinguir duração da atividade e esforço de pessoal: duas pessoas podem terminar antes e, ainda assim, consumir mais pessoa-hora. O resultado pode ser resumido pela relação aproximada:

\[\text{Esforço total}_{\text{par}} \approx 1{,}15 \times \text{Esforço total}_{\text{solo}}\]

O argumento econômico de Williams e Kessler é que, no contexto estudado, o acréscimo no esforço inicial pode ser compensado pela redução dos defeitos que escapam para teste e produção [3]. Isso não constitui uma proporção universal: o resultado depende da tarefa, da experiência da dupla, da complexidade do domínio e do custo dos defeitos. A Programação em Par, portanto, não procura maximizar a velocidade de digitação, mas melhorar a qualidade das decisões e antecipar a descoberta de problemas.

Dimensão	Programador Solo	Programação em Par
Tempo decorrido para concluir	Referência	Menor no experimento
Esforço total em pessoa-hora	Referência (1,0)	Aproximadamente 1,15
Taxa de testes aprovados	73% a 78%	86% a 94%
Revisão de código	Posterior e separada	Contínua e embutida
Disseminação de conhecimento	Restrita ao indivíduo	Compartilhada na dupla

Tabela 1: Síntese do experimento comparativo entre trabalho individual e Programação em Par. Os resultados descrevem o contexto estudado e não devem ser tratados como constantes universais [4].

O Novo Par: Assistentes de IA Generativa

Em 2021, a apresentação pública do GitHub Copilot, seguida por sua disponibilidade geral em 2022, popularizou uma nova forma de colaboração: o assistente de IA generativa integrado ao editor, capaz de completar linhas, gerar funções e propor implementações a partir de comentários em linguagem natural. A própria GitHub batizou a ferramenta de AI pair programmer, apropriando-se deliberadamente do vocabulário do XP [10]. A metáfora, porém, merece exame cuidadoso, pois pode ocultar diferenças importantes de autonomia e responsabilidade.

Na Programação em Par clássica, os dois participantes são humanos e relativamente simétricos: ambos podem ser driver, ambos podem ser navigator, e a autoridade sobre o código é compartilhada. No par com IA, essa simetria desaparece, mas a distribuição dos papéis varia conforme a ferramenta. No modo assistivo, baseado em completação ou conversa, o humano normalmente continua como driver, enquanto a IA sugere alternativas e recupera informações. No modo agentivo, em que a ferramenta planeja, edita arquivos, executa testes e itera sobre a solução, a IA pode assumir boa parte do papel de driver, e o humano se desloca para a posição de navigator, supervisor e responsável pela aprovação.

As ferramentas atuais podem ler o repositório, consultar documentação, executar comandos e manter contexto durante uma sessão. Isso não equivale, contudo, a uma compreensão garantida do domínio, da história arquitetural ou dos efeitos organizacionais da mudança. Tampouco transfere responsabilidade: a decisão sobre o que entra em produção continua sendo humana e institucional. A relação entre humano e IA, portanto, não é uma simples troca de um parceiro por outro, mas um contínuo entre assistência, delegação e supervisão.

No comparador acima, alterne entre o par humano clássico, a IA assistiva e a IA agentiva para visualizar como a distribuição de responsabilidades se desloca. Note que a responsabilidade final, isto é, a accountability sobre o que entra em produção, permanece do lado humano e da organização. Esse é o detalhe que nenhuma métrica de velocidade captura.

O Que os Dados Dizem (2023 a 2026)

A discussão sobre IA na programação seria estéril se ficasse no terreno da opinião. Entre 2023 e 2026, cresceu a quantidade de evidência empírica, embora os estudos ainda sejam heterogêneos quanto às ferramentas, tarefas, populações e métricas. Experimentos controlados em tarefas curtas, estudos de campo, análises observacionais de repositórios e pesquisas de percepção respondem a perguntas diferentes. O quadro é mais matizado do que sugerem tanto o entusiasmo irrestrito quanto o pessimismo definitivo.

O ganho de velocidade é real

Um experimento controlado de grande repercussão foi conduzido por Peng e colaboradores, em colaboração com a GitHub [11]. Em um estudo randomizado, desenvolvedores receberam a tarefa de implementar um servidor HTTP em JavaScript, com metade do grupo usando o Copilot e a outra metade não. O grupo com IA concluiu a tarefa 55,8% mais rápido. Esse número, amplamente citado, é verdadeiro e relevante. Mas a sagaz leitora deve perguntar: mais rápido em quê, exatamente, e até que ponto o resultado se transfere para outras tarefas e contextos?

No trabalho real, o ganho pode se inverter

Em 2025, a organização de pesquisa METR conduziu um experimento que complicou bastante a narrativa otimista [12]. Em vez de tarefas isoladas e artificiais, mediram 16 desenvolvedores experientes trabalhando em 246 tarefas de seus próprios repositórios de código aberto, projetos maduros e familiares. Com ferramentas disponíveis entre fevereiro e junho de 2025, sobretudo Cursor Pro e Claude 3.5/3.7 Sonnet, esses desenvolvedores levaram 19% mais tempo para completar as tarefas. Mais revelador ainda foi o descompasso entre percepção e realidade. Eles previam que a IA os deixaria 24% mais rápidos e, depois do experimento, ainda estimavam ter sido 20% mais produtivos [12].

Esse descompasso é um achado importante para quem forma futuros engenheiros. A sensação de produtividade não é uma medida suficiente de produtividade. Sugestões fluentes podem criar percepção de avanço mesmo quando parte do tempo é consumida na leitura, correção ou reversão do código produzido. Ao mesmo tempo, o resultado descreve um grupo pequeno, experiente, trabalhando em sistemas maduros com ferramentas do início de 2025; ele não autoriza concluir que a IA torna todo desenvolvimento real mais lento.

O cenário mudou novamente em 2026

Em fevereiro de 2026, a METR informou que seu novo experimento já apresentava sinais de ganho, mas que efeitos de seleção tornavam a estimativa pouco confiável. Desenvolvedores que consideravam a IA mais útil passaram a evitar participar de uma pesquisa que os obrigaria a trabalhar sem ela, e o uso simultâneo de vários agentes dificultou a medição do tempo. Entre participantes do estudo original, a estimativa bruta indicava 18% de aceleração; entre novos participantes, 4%, ambos com intervalos de confiança compatíveis com efeitos menores ou nulos [13]. Em maio, a organização resumiu seus resultados mais recentes como pequenos ganhos, aproximadamente entre 4% e 20%, provavelmente subestimados pelos mesmos efeitos de seleção [14].

A sequência de resultados não invalida o experimento de 2025; mostra que “a produtividade da IA” não é uma constante. Ela varia com a geração da ferramenta, a familiaridade do usuário, a natureza da tarefa, o grau de autonomia e a maturidade do repositório. A conclusão intelectualmente segura não é que o ganho sempre existe nem que sempre desaparece, mas que precisa ser medido no contexto em que a ferramenta será usada.

A qualidade exige cautela

Se a velocidade depende do contexto, a qualidade exige atenção igualmente cuidadosa. Em um relatório observacional, a empresa GitClear analisou 211 milhões de linhas de código alteradas entre 2020 e 2024 e documentou tendências temporais consistentes com o período de adoção massiva dos assistentes de IA [15]:

• O code churn, definido como a proporção de linhas revertidas ou reescritas em menos de duas semanas, subiu de 3,1% em 2020 para 5,7% em 2024. É o sinal mais claro de código que nasce e morre rápido;
• A frequência de blocos duplicados de cinco ou mais linhas cresceu de forma acentuada, com a clonagem de código saltando de 8,3% para 12,3% das linhas alteradas;
• A proporção de linhas associadas a refatoração despencou de 25% em 2021 para menos de 10% em 2024.

Essas associações não demonstram, por si mesmas, que a IA causou as mudanças: o relatório não é um experimento controlado e não identifica com precisão quais linhas foram produzidas com assistência. Uma hipótese plausível é que ferramentas orientadas à completação favoreçam a adição local de código em vez da consolidação arquitetural. Contudo, agentes atuais também podem mover, refatorar e remover código quando recebem contexto e objetivos adequados. O dado relevante para o processo é outro: aumentar a capacidade de produzir mudanças sem fortalecer revisão e refatoração pode elevar duplicação, churn e complexidade [15].

A estabilidade depende do sistema

O relatório State of DevOps de 2024, produzido pela equipe DORA do Google, estimou que um aumento de 25% na adoção de IA estava associado a uma redução de cerca de 7,2% na estabilidade de entrega e a uma queda de 1,5% na vazão (throughput) [16]. Trata-se de associação, não de demonstração causal. O relatório propôs como mecanismo o aumento do volume de código e do tamanho dos lotes de mudança, historicamente relacionados a maior risco de instabilidade.

Em 2025, o DORA atualizou a interpretação: a IA apareceu como um amplificador das forças e fraquezas do sistema organizacional. O relatório encontrou melhora de vazão em determinados contextos, mas alertou que os ganhos podem vir acompanhados de menor estabilidade quando faltam testes, plataformas internas adequadas, ciclos rápidos de retorno e processos sólidos. Assim, a evidência mais recente não sustenta que a IA necessariamente prejudique a entrega; sustenta que seus efeitos dependem da qualidade do sistema sociotécnico no qual ela é introduzida [17].

O gráfico interativo acima reúne essas evidências em um único painel. A persistente leitora pode alternar entre as métricas para perceber o padrão que emerge: a IA frequentemente eleva o volume e pode elevar a velocidade, mas seu efeito sobre qualidade e estabilidade depende da tarefa, da ferramenta e dos mecanismos de controle. Os resultados de 2025 e 2026 devem ser lidos como uma evolução temporal, não como medições diretamente comparáveis de uma tecnologia imutável.

Velocidade Não é Agilidade

Chegamos ao coração do argumento. Há uma confusão, comum e perigosa, entre velocidade e agilidade. O Manifesto Ágil nunca prometeu que escreveríamos código mais rápido. Prometeu a capacidade de responder a mudanças com mais segurança e a entrega contínua de software funcionando com valor para o negócio [5, 6]. São coisas distintas. Produzir o dobro de código no mesmo tempo só é agilidade se esse código for correto, sustentável e adaptável. Caso contrário, é apenas dívida técnica produzida com mais eficiência.

Podemos expressar a distinção de forma compacta. A agilidade não é uma função apenas da velocidade:

\[\text{Agilidade} = f(\text{Velocidade},\ \text{Qualidade},\ \text{Adaptabilidade})\]

Quando a IA aumenta apenas a primeira variável e degrada as demais, o efeito líquido sobre a agilidade pode ser nulo ou negativo. Quando a velocidade vem acompanhada de qualidade, retorno rápido e capacidade de mudança, o efeito pode ser positivo. A evolução dos resultados da METR e do DORA reforça precisamente essa dependência do contexto [12, 13, 14, 16, 17]. É aqui que o Extreme Programming, longe de estar obsoleto, reaparece como uma rede de segurança. As práticas de XP ajudam a impedir que velocidade se converta em fragilidade:

1. Test-Driven Development (TDD) e testes automatizados: quando o código vem de uma fonte que não compreende o domínio do problema, a verificação automatizada deixa de ser recomendação e passa a ser condição de sobrevivência. O teste é a especificação executável contra a qual a sugestão da IA é julgada;
2. Integração Contínua (CI): integrar em pequenos lotes, com construção e testes automatizados, reduz o risco associado ao aumento do volume de mudanças e encurta o ciclo de retorno [16, 17];
3. Refatoração: diante dos sinais observacionais de maior duplicação e menor consolidação, a disciplina de mover, renomear, simplificar e remover código precisa fazer parte explícita do fluxo assistido por IA [15];
4. Propriedade Coletiva do Código: se ninguém na equipe compreende profundamente um trecho gerado por IA, a propriedade coletiva foi rompida, e com ela a capacidade de manter o sistema.

Decisão prática: transformar velocidade em agilidade

O cenário abaixo convida a aplicar essas práticas a uma mudança produzida por um agente. Antes de revelar o retorno, escolha quais ações preservam qualidade, pequenos lotes, retorno rápido e responsabilidade coletiva.

O objetivo do exercício não é decorar uma lista de boas práticas, mas perceber que a aprovação de uma mudança exige evidências proporcionais ao risco. Testes existentes, velocidade de geração e confiança subjetiva não substituem critérios de negócio, integração incremental, refatoração e revisão responsável.

Sommerville já sublinhava que essas práticas formam um sistema interdependente, em que cada uma sustenta as demais [2]. A IA não substitui nenhuma delas. Ao aumentar a velocidade potencial de produção e o volume de mudanças, ela também aumenta a carga sobre os mecanismos de especificação, revisão, integração e verificação.

Uma Releitura dos Papéis

Quando a IA assume parte da implementação, o ser humano precisa exercer, de forma deliberada e competente, o papel de navigator e responsável pela aprovação. Ser um bom navigator exige a capacidade de ler criticamente código que não se escreveu, de identificar o erro sutil em meio à fluência sintática, de manter o desenho arquitetural em mente e de negociar requisitos com clareza suficiente para instruir tanto a máquina quanto as pessoas, competência que Vazquez e Simões situam no centro da engenharia de software orientada ao negócio [7]. Um estudo iniciado em 2023 que catalogou problemas relatados por desenvolvedores no GitHub e no Stack Overflow mostrou que a experiência com assistentes envolve dificuldades de operação, compatibilidade, validação e integração, além da simples geração de código [18].

Isso conversa diretamente com a competência C4 e a habilidade H19 da ementa, que tratam da gestão da qualidade e dos projetos em seus aspectos tecnológicos e organizacionais, dimensão que a literatura de gestão ágil de serviços e projetos detalha com cuidado [8, 9]. O profissional valioso na era da IA não é apenas o que produz código rapidamente, capacidade em que a máquina oferece vantagem crescente, mas o que pensa com rigor sobre o que deve ser construído, como verificar o resultado e quais consequências aceitar. A IA eleva o piso da produção e, ao mesmo tempo, eleva o teto exigido do julgamento humano.

Conclusão

A Programação em Par do Extreme Programming foi, desde o início, uma tecnologia social para produzir qualidade por meio de revisão contínua, diálogo e responsabilidade compartilhada. A chegada da IA generativa não a torna obsoleta, mas a reconfigura. O novo par é assimétrico: a ferramenta pode oferecer grande disponibilidade, velocidade e acesso ao contexto registrado, mas não assume responsabilidade pelas consequências. As evidências de 2023 a 2026 não produzem um veredito único. A IA acelerou tarefas isoladas, tornou mais lentos alguns desenvolvedores experientes em sistemas maduros e, com ferramentas mais recentes, voltou a apresentar sinais de ganho. Estudos observacionais, por sua vez, alertam para riscos de duplicação, churn e instabilidade quando a capacidade de gerar mudanças cresce mais rápido do que a capacidade de verificá-las [11, 12, 13, 14, 15, 16, 17].

Diante disso, a resposta da Engenharia de Software não é rejeitar a ferramenta nem abraçá-la sem crítica, mas reancorar seu uso nos fundamentos que o XP nos legou. Testes automatizados, integração contínua, pequenos lotes, refatoração disciplinada, propriedade coletiva e julgamento humano rigoroso formam a infraestrutura que transforma velocidade potencial em agilidade sustentável. A máquina pode sugerir, executar e até ocupar temporariamente o papel de driver. A responsabilidade pela qualidade, pelo valor entregue e pela adaptação às mudanças continua sendo humana e organizacional.

Referências

1. BECK, Kent. Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley, 1999.

2. SOMMERVILLE, Ian. Engenharia de software. 10. ed. São Paulo: Pearson Education do Brasil, 2018. E-book. Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/168127. Acesso em: 23 jun. 2026.

3. WILLIAMS, Laurie; KESSLER, Robert. Pair Programming Illuminated. Boston: Addison-Wesley, 2002.

4. WILLIAMS, Laurie; KESSLER, Robert R.; CUNNINGHAM, Ward; JEFFRIES, Ron. Strengthening the case for pair programming. IEEE Software, v. 17, n. 4, p. 19-25, 2000.

5. GOMES, André Faria. Agile: desenvolvimento de software com entregas frequentes e foco no valor de negócio. São Paulo: Casa do Código, 2014. E-book. Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/212908. Acesso em: 23 jun. 2026.

6. FOGGETTI, Cristiano (org.). Gestão ágil de projetos. São Paulo: Pearson, 2014. E-book. ISBN 978-85-4301-010-6. Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/22131. Acesso em: 23 jun. 2026.

7. VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de Requisitos: software orientado ao negócio. Rio de Janeiro: Brasport, 2016. E-book. Disponível em: https://plataforma.bvirtual.com.br/Leitor/Publicacao/160193/epub. Acesso em: 23 jun. 2026.

8. MASSARI, Vitor L. Agile Scrum Master no Gerenciamento Avançado de Projetos: certificação EXIN Agile Scrum Master. Rio de Janeiro: Brasport, 2016. E-book. ISBN 978-85-7452-785-7. Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/160394. Acesso em: 23 jun. 2026.

9. OLIVEIRA, Bruno Souza de. Métodos Ágeis e Gestão de Serviços de TI. Rio de Janeiro: Brasport, 2018. E-book. ISBN 978-85-7452-871-7. Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/160046. Acesso em: 23 jun. 2026.

10. GITHUB. GitHub Copilot is generally available to all developers. 2022. Disponível em: https://github.blog/news-insights/product-news/github-copilot-is-generally-available-to-all-developers/. Acesso em: 23 jun. 2026.

11. PENG, Sida; KALLIAMVAKOU, Eirini; CIHON, Peter; DEMIRER, Mert. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590, 2023. Disponível em: https://arxiv.org/abs/2302.06590. Acesso em: 23 jun. 2026.

12. BECKER, Joel; RUSH, Nate; BARNES, Elizabeth; REIN, David. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089, 2025. Disponível em: https://arxiv.org/abs/2507.09089. Acesso em: 23 jun. 2026.

13. METR. We are Changing our Developer Productivity Experiment. 2026. Disponível em: https://metr.org/blog/2026-02-24-uplift-update/. Acesso em: 23 jun. 2026.

14. METR. Frontier Risk Report (February to March 2026). 2026. Disponível em: https://metr.org/blog/2026-05-19-frontier-risk-report/. Acesso em: 23 jun. 2026.

15. GITCLEAR. AI Copilot Code Quality: 2025 Research Report. 2025. Disponível em: https://www.gitclear.com/ai_assistant_code_quality_2025_research. Acesso em: 23 jun. 2026.

16. DORA; GOOGLE CLOUD. Accelerate State of DevOps Report 2024. 2024. Disponível em: https://dora.dev/research/2024/dora-report/. Acesso em: 23 jun. 2026.

17. DORA; GOOGLE CLOUD. State of AI-assisted Software Development 2025. 2025. Disponível em: https://dora.dev/dora-report-2025/. Acesso em: 23 jun. 2026.

18. ZHOU, Xiyu; LIANG, Peng; ZHANG, Beiqi; LI, Zengyang; AHMAD, Aakash; SHAHIN, Mojtaba; WASEEM, Muhammad. Exploring the Problems, their Causes and Solutions of AI Pair Programming: A Study on GitHub and Stack Overflow. arXiv:2311.01020, 2023. Disponível em: https://arxiv.org/abs/2311.01020. Acesso em: 23 jun. 2026.