XP em 2026: as práticas mudaram de forma, os valores não

De 1999 a 2026

O Extreme Programming nasceu em 1999 com uma promessa simples: abraçar a mudança em vez de lutar contra ela. Vinte e sete anos depois, a maior mudança no jeito de construir software não veio de um novo framework, mas dos LLMs.

A minha tese é que as práticas do XP mudaram de forma, mas os valores ficaram mais importantes do que nunca. Comunicação, simplicidade, feedback, coragem e respeito são exatamente o que separa um time que acelera com IA de um time que só produz código mais rápido.

Não escrevo isso a partir da teoria. Lidero um time de tecnologia em pagamentos, onde um erro custa dinheiro real, e já vimos a IA acertar e errar bastante.

O que funciona: a IA como apoio ao código

No meu time, o que vem dando certo é usar ferramentas com apoio de LLMs no dia a dia, como Cursor, Codex e Claude Code. Elas entram como apoio ao desenvolvedor: gerar um trecho, explicar código legado, escrever um teste, sugerir uma refatoração.

O ponto em comum é que o engenheiro continua no controle do ciclo. Ele decide o que construir, revisa o que a ferramenta propõe e integra em passos pequenos. A IA acelera cada passo, mas não decide o caminho.

Visto pelas lentes do XP, isso faz sentido. O ciclo curto de feedback continua nas mãos de quem conhece o domínio, e a IA só encurta o tempo entre a ideia e o código que pode ser testado.

O que não funcionou: AI-DLC e os últimos 20%

Também testamos o caminho oposto: deixar a IA conduzir o ciclo inteiro. Usamos o AI-DLC, metodologia da AWS em que agentes propõem planos, código, testes e infraestrutura, e humanos validam cada etapa em fases de concepção, construção e operação.

Do zero aos 80%, foi impressionante. Requisitos, desenho e boa parte do código saíram rápido. A reta final, não: o refinamento, os testes de verdade e o deploy travaram, e foi ali que o projeto perdeu o ritmo.

Olhando para trás, faz sentido. Os primeiros 80% são onde o problema ainda é genérico e a IA brilha. Os últimos 20% são onde mora o contexto do nosso sistema: integrações com parceiros, regras de negócio de pagamentos, casos de borda e o ambiente de produção. É exatamente o conhecimento que o XP sempre defendeu manter perto de quem constrói.

O XP chama esse problema pelo nome. Quando o feedback chega só no fim, a surpresa chega junto. Um processo que gera muito antes de integrar e testar troca ciclos curtos por um grande lote, e grandes lotes falham na reta final.

Pair programming: o par que nunca cansa

O LLM é um par disponível o tempo todo, que não se cansa e conhece quase toda biblioteca. Nesse arranjo, o papel humano fica claro: ele é o navegador, quem decide a direção e questiona as escolhas. A IA vira o piloto.

Mas o pair programming nunca foi só sobre escrever código melhor. Era também sobre espalhar conhecimento pelo time e criar propriedade coletiva do código. Um par com IA não faz nada disso. Se cada pessoa programa sozinha com seu assistente, o time vira uma coleção de ilhas.

Por isso, eu não trocaria o par humano pela IA. Eu somaria: duas pessoas e um assistente, ou um mob com a IA como mais um participante. O conhecimento continua circulando, e a velocidade vem junto.

Test-first: o teste vira a especificação

Com LLMs, escrever o teste antes ganhou um novo papel. O teste é a especificação mais precisa que você pode entregar ao modelo: ele diz o que o código deve fazer, em uma linguagem que a máquina verifica sozinha.

O risco é deixar a IA escrever o teste e o código ao mesmo tempo. Aí ela valida a própria interpretação, e ninguém está verificando nada. O teste passa, mas pode estar testando a coisa errada.

A regra que eu proponho é simples: o humano define o comportamento esperado no teste, e a IA implementa até ele passar. Em pagamentos, onde um centavo errado vira incidente, essa separação não é opcional.

Isso conversa com a nossa reta final do AI-DLC. Os testes que importavam, com dados reais e integrações de verdade, ficaram para o fim. Se tivessem vindo antes, teriam guiado a construção em vez de travá-la.

Pequenas entregas e simplicidade

Gerar código ficou barato. Revisar, integrar e colocar em produção continua caro. Quando a IA produz mil linhas em minutos, o gargalo muda de lugar: sai da escrita e vai para a revisão e o deploy.

Por isso, pequenas entregas e integração contínua voltam ao centro. Lotes pequenos são revisáveis, testáveis e reversíveis. Lotes grandes, mesmo gerados por IA, carregam o mesmo risco de sempre.

O mesmo vale para a simplicidade. LLMs tendem a gerar mais do que o necessário: abstrações que ninguém pediu, tratamento de casos que não existem, configurações para um futuro hipotético. O YAGNI do XP vira disciplina diária: cortar o que sobra antes de integrar.

Documentação: de burocracia a contexto

O XP sempre desconfiou da documentação pesada. A ideia era que código limpo e testes bem escritos explicassem o sistema melhor do que qualquer documento desatualizado.

Os LLMs mudam essa conta. Um agente só é tão bom quanto o contexto que recebe. Arquivos de instrução, decisões de arquitetura registradas e regras de negócio escritas viram combustível para a ferramenta, e não burocracia.

A diferença é o público. Antes, a documentação era para um humano que talvez nunca a lesse. Agora ela é lida a cada interação, por um leitor incansável. Isso não contradiz o XP: é documentação enxuta, viva e com uso real, exatamente o que ele sempre aceitou.

Fechamento: feedback rápido continua sendo o jogo

A lição que tiro da experiência do meu time é que a IA funciona melhor quando acelera ciclos curtos, e pior quando tenta substituí-los. As ferramentas de apoio deram certo porque mantiveram o engenheiro no loop. O AI-DLC travou nos últimos 20% porque o feedback de verdade chegou tarde demais.

O XP nunca foi sobre as práticas em si. Era sobre receber feedback rápido e ter coragem para mudar de rumo. Os LLMs não tornam isso obsoleto. Eles tornam isso mais barato para quem mantém a disciplina, e mais caro para quem a abandona.

Fontes

• Embracing Change with Extreme Programming, Kent Beck, IEEE Computer, vol. 32, n. 10, out. 1999
• Extreme Programming Explained: Embrace Change, 2ª edição, Kent Beck e Cynthia Andres, Addison-Wesley, 2004
• AI-Driven Development Life Cycle: Reimagining Software Engineering, AWS DevOps Blog