Devemos revisitar o Extreme Programming (XP) na era da IA?
(hyperact.co.uk)- Graças à geração de código por IA e à inovação das plataformas, a velocidade de desenvolvimento explodiu, mas os resultados dos projetos continuam fracos e a taxa de falhas segue alta
- O problema não é a velocidade, mas a falta de validação e alinhamento; o XP induz aprendizado, alinhamento e melhoria de qualidade por meio de restrições intencionais
- Em especial, quanto mais os agentes de IA aceleram a geração, modificação e implantação de código, mais grave se torna o aumento de complexidade e vulnerabilidades sem validação
- O XP enfatiza valores centrados no ser humano, como simplicidade, comunicação, feedback, respeito e coragem, além de lotes pequenos, integração contínua e testes automatizados
- Em uma era em que a saída rápida se tornou o padrão, o XP é uma metodologia que relembra o princípio de que software, no fim das contas, é para pessoas
A aceleração da velocidade de produção de software e seus limites
- Recentemente, com as ferramentas de IA e as inovações em várias plataformas de desenvolvimento, a barreira para geração de código caiu muito e a velocidade melhorou bastante
- Com alguns prompts ou chamadas de API, é possível gerar rapidamente produtos, funcionalidades e infraestrutura inteiros
- Porém, apesar do aumento de produtividade, há o problema de que a taxa geral de sucesso dos projetos não melhorou de forma significativa
- Relatórios como o Standish Chaos Report e estudos da McKinsey apontam que casos em que projetos de TI falham ou estouram o orçamento ainda são frequentes
- Confirma-se o fenômeno de que apenas melhorar a velocidade de geração de código não eleva automaticamente os resultados da entrega de software
Por que a saída (output) não é o verdadeiro problema
- Foi repetidamente demonstrado que o gargalo do desenvolvimento de software não é a velocidade de entrada e saída de código
- Houve ondas sucessivas de aceleração, como a adoção de linguagens de alto nível, a popularização de frameworks e gerenciadores de pacotes, a expansão de DevOps e serverless, a evolução das plataformas de desenvolvimento e a geração de código por IA
- Segundo o Chaos Report, mesmo com a aceleração do output, persiste o problema de resultados finais inconsistentes e abaixo das expectativas
- Destaca-se que a resposta não está na simples aceleração, e sim em “restrições” mais inteligentes
- O XP é um conjunto de práticas que orienta para a direção correta por meio de aprendizado, alinhamento e desenvolvimento intencional, sem pressa
O papel do XP: um contrapeso à velocidade
- A aceleração sem limites causa o problema de tirar as oportunidades de aprender, descobrir erros e corrigir a direção
- O Extreme Programming (XP) foi projetado para fazer a equipe avançar na direção certa ao introduzir atrito e restrições intencionais
- Prática representativa: pair programming reduz deliberadamente a produção pela metade
- O pair programming pode reduzir o volume de entregas pela metade, mas oferece o dobro de efeitos positivos, como entendimento compartilhado, confiança, qualidade e aumento da capacidade da equipe
- O XP muda a própria forma de colaboração e investe em fortalecer a capacidade do time e dar direção
A percepção do problema no XP se aprofunda ainda mais com a IA
- À medida que a IA torna a geração de código praticamente sem esforço, cresce o risco de produção em massa de software sem validação adequada
- O risco aumenta de forma abrupta, especialmente em sistemas de agentic AI, nos quais múltiplos agentes geram, melhoram e implantam código automaticamente
- Sistemas automatizados sem restrições empilham lógica não validada em múltiplas camadas, agravando complexidade e vulnerabilidades
- Pesquisas recentes mostraram que quanto maior a janela de contexto dos LLMs, pior tende a ser a precisão
- O começo e o fim são tratados bem, mas o meio fica mais vulnerável a generalizações e erros
- Como resultado, isso leva a código frágil e de alto custo de manutenção; o XP surgiu justamente para evitar essa entropia desordenada
Software continua sendo território humano
- Mesmo com o avanço da IA, não muda a essência de que o software é feito por pessoas para pessoas, dentro da comunicação e da cultura das organizações
- Os principais obstáculos à entrega não são o grau de automação, mas fatores humanos como alinhamento, contexto compartilhado, clareza de resultados e validação com usuários
- Valores centrais do XP:
- Simplicity: redução da complexidade
- Communication: manutenção da coesão da equipe
- Feedback: condução do aprendizado e da adaptação
- Respect: construção de confiança e segurança
- Courage: apoio à transparência e à mudança
Da feature factory para a entrega de valor real
- Equipes bem-sucedidas priorizam fluxo (flow) e feedback mais do que velocidade em si
- Práticas do XP como lotes pequenos, integração contínua, testes automatizados e propriedade coletiva contribuem para adaptabilidade e foco no usuário
- Quanto mais rápida for a produção de código no futuro, mais esses métodos serão essenciais para gerir qualidade, risco e intenção
Lições do passado
- Estatísticas do relatório CHAOS:
- 1994: 16% dos projetos foram concluídos com sucesso no prazo e dentro do orçamento
- 2012: melhorou para 37%
- 2020: caiu novamente para 31%
- Mesmo após mais de 20 anos de inovação e mudanças (agile, DevOps, cloud native, IA etc.), a confiabilidade geral subiu apenas 14 pontos percentuais
- Só a toolchain não resolve o problema
- Reforça-se a importância da metodologia correta
O que será necessário daqui para frente
- 1. Output não é mais a restrição: a capacidade de produzir código supera a velocidade de validação e alinhamento
- 2. Fortalecer capacidades orientadas a resultados: feedback, direção clara de produto, colaboração forte e bom design são indispensáveis
- 3. É preciso um processo mais humano: mesmo com a evolução da IA, a entrega contínua depende de colaboração
- Ressalta-se que um Product Operating Model realmente eficaz nasce de uma operação centrada em pessoas — colaboração, clareza e fluxo
- Mais do que a inovação tecnológica (plataformas), é ao alinhar sem lacunas estratégia de equipe, ritmo operacional e práticas de engenharia que se torna possível construir um ambiente sustentável de entrega de software na era da IA
Conclusão: na era da IA, o XP é necessário?
- Sim
- Em meio a ferramentas cada vez mais poderosas, é necessário um framework que fixe práticas centradas nas pessoas
- O XP oferece, ao mesmo tempo, foco no time, empatia, entendimento compartilhado e orientação para os objetivos certos
- O foco não está na simples velocidade de output, mas em direção significativa e alinhamento dentro da equipe
- Na era da aceleração da IA e da produção sem limites, o XP é uma metodologia rara que relembra que software é trabalho de pessoas
1 comentários
Opiniões do Hacker News
Kent Beck, criador do Extreme Programming, vem fazendo vários experimentos relacionados a codificação com IA
Em textos como Augmented Coding Beyond the Vibes, ele está refletindo sobre como a IA pode ser usada na programação
Lembro que, quando o ChatGPT começou a se mostrar útil para programar, ele disse que 90% das suas habilidades agora valiam zero, e os 10% restantes tinham ficado ainda mais valiosos
90% of my skills are now worth 0
Acho que a abordagem de desenvolvimento XP com testes primeiro ficou ainda mais valiosa numa era em que a IA gera código e depois o valida
Tenho sentido que isso, em especial, facilita a geração de código com ferramentas de IA
Uma das coisas que mais me incomodam na codificação com IA hoje em dia é ver relatórios e guias antigos ficando no repositório
Por exemplo, este relatório também é um relatório gerado por IA com base no código existente no momento em que foi criado
Não vejo muito sentido em deixar esse tipo de artefato intermediário no histórico
Principalmente quando começam a se acumular arquivos como _updated_v2_from_2025
Exemplo 1, Exemplo 2
Para mim, XP é a única metodologia ágil de verdade
Com o tempo, “agile” acabou sendo esvaziado de sentido
Programação com IA ajuda a fechar o loop de feedback mais rápido, mas não acho que todo código precise de uma quantidade enorme de testes unitários
Se as pessoas voltarem a entender o núcleo do XP — para mim, o loop de feedback — e conseguirmos apertar ainda mais esse loop com sistemas de agentes baseados em LLM, isso pode representar um grande avanço para a engenharia de software
Comecei com XP e o pratiquei de forma obsessiva, então hoje já acho difícil trabalhar em organizações no estilo SCRUM
O SCRUM em grande parte derivou do XP, mas agora parece ter virado só um conjunto de práticas sem sentido
O cenário ideal, na minha visão, é dois desenvolvedores fazendo pair programming no mesmo branch junto com agentes de IA
É um loop de feedback ideal em que planejamento em dupla, revisão, desenvolvimento e testes se repetem naturalmente
Os testes unitários da era XP eram diferentes dos testes de hoje
Na época, eram testes por funcionalidade, não testes por método
Tenho a sensação de que tudo depende de quão precisamente a IA consegue fechar esse loop de feedback
Não entregar metade do código para o usuário, isto é, para produção, não é agile
Nossa equipe é formada inteiramente por ex-Pivots e pessoas vindas da Thoughtworks
Pair programming, TDD e cliente residente fazem parte do básico
Também usamos IA ativamente dentro da IDE há mais de dois anos
Mas, surpreendentemente, neste ano começamos a fazer “mobbing”, em vez de cada um trabalhar separado com IA
Ou seja, os quatro se alinham em um único projeto e mergulham juntos numa única tarefa
O Claude Code ajuda com a digitação enquanto quatro pessoas colaboram ao mesmo tempo, em tempo real
Foi a experiência mais divertida, focada e eficaz que já tivemos, uma combinação perfeita entre XP e IA
Eu tinha esquecido completamente do XP
Algumas partes dele viraram padrão hoje em dia, e o restante provavelmente pareceria muito estranho pelos critérios atuais
Em especial, eu destacaria que é preciso parar e pensar antes de usar LLM para despejar mais de 1000 linhas de código sem reflexão
Fico curioso para saber o que você acha que é a parte mais estranha do XP, pessoalmente
Isso não deve ser entendido como “todo mundo precisa fazer pair programming com IA”
Quando você faz pair programming com um colega de equipe, vocês compartilham a forma de pensar um do outro e o contexto do código
Mas, ao fazer pair programming com IA, no momento em que você fecha o prompt, a IA esquece tudo
Então o XP em discussão aqui continua sendo, como nos anos 1990, XP feito entre pessoas
A IA pode entrar em algumas partes, mas o núcleo continua sendo humano
Isso acontece se você não deixar os artefatos explícitos
Ao explorar código novo com pouca documentação, pode fazer sentido registrar no repositório, como documentação ou arquivos de agente, o que foi aprendido com o LLM
Eu penso o contrário: se você não está fazendo pair programming com IA, está fazendo da forma errada
Na verdade, mesmo quando pessoas fazem pair programming entre si, muitas vezes o meu eu do futuro esquece completamente do que lembro agora
Temos que ir para um modelo de pair com foco em documentação
Em resumo, pair programming em estilo XP com LLM deve ser praticado obrigatoriamente
Com certeza vai aparecer gente tentando vender curso de Extreme Vibing (XV)
Extreme Programming reúne várias ideias úteis de forma independente — como TDD, pair programming, CI e feedback — dentro de um mesmo paradigma
Cada uma delas pode ser útil dependendo do contexto, mas não acho que seja necessário usar todas ao mesmo tempo, sempre
Por isso, vejo o XP perdendo força como um conceito completo
Hoje, a maioria das equipes pratica apenas partes do XP, e quase nenhuma organização aplica o XP inteiro de verdade
No caso do agile, as grandes empresas em geral implementam algo como 70% com fidelidade de mais de 90% das práticas
Na prática, nunca houve uma única empresa que implementasse 100% do que o Manifesto Ágil descreve, e mesmo a melhor delas chegava a algo em torno de 90%
Mas, como as práticas centrais estavam todas agrupadas em um mesmo paradigma, ficou fácil para as organizações se chamarem de “agile”
Por isso ficou muito mais simples apenas declarar “vamos fazer a transformação ágil”
É por isso que o livro de XP é dividido em filosofia, princípios e práticas
A frase mais marcante do livro, para mim, é que valores sem prática são mortos, e prática sem valores também é vazia
No fim das contas, o objetivo não é “best practices”, mas dar autonomia ao time para definir seu próprio processo e produzir software confiável e bem projetado
O XP também parece um tipo de “caixa de ferramentas variada” justamente porque, na prática, são coisas que uma equipe ativa escolhe usar
Eu realmente aplico sempre as práticas citadas acima — TDD, pair programming, CI e feedback — em código de produção, sempre que as condições permitem
Tenho curiosidade em saber em que situação alguém consideraria essas práticas “erradas”
Acho que avançamos bastante desde o agile compulsivo dos anos 1990
Hoje, com tantos fluxos de trabalho incorporando IA, precisamos olhar mais para processos de software que aumentem de fato a probabilidade de gerar resultados reais para o usuário, e não apenas de produzir mais volume de entregas
Acho que XP é um bom ponto de partida para isso, embora não necessariamente o ponto final
Extreme Programming (XP) é uma metodologia ágil focada em iterações curtas, feedback rápido e design simples, baseada em práticas como pair programming, TDD e CI para se adaptar rapidamente a mudanças
Ela prioriza construir o menor possível, o mais rápido possível, e iterar junto com o cliente para otimizar aprendizado e qualidade
~ GPT5 no Perplexity
Ultimamente tenho achado que o modelo waterfall está voltando com a IA
Na verdade, o waterfall nunca chegou a ir embora
É lamentável ver o waterfall de volta
Na maioria dos casos, waterfall não é a abordagem correta
Como ex-Pivot e grande entusiasta de XP, concordo
Veja também meu comentário abaixo
Ainda pratico XP