XP vs Agile en 2026: Por qué Extreme Programming le gana a Scrum en una migración legacy con IA

La sala llena de post-its que nadie lee

Son las nueve de la mañana. Quince personas se sientan frente a una pared cubierta de notas amarillas. El sprint planning lleva cuarenta minutos y aún nadie ha tocado el código. En la pantalla hay un tablero con doscientos tickets, la mitad etiquetados como “legacy”, la otra mitad como “modernización”. Alguien pregunta quién va a escribir la especificación técnica del módulo de pagos. Otro alguien responde que primero debe pasarlo QA. Un tercero recuerda que el analista de negocio está de vacaciones.

Esa escena es Agile tal como lo implementa la mayoría de las empresas. No es Agile el manifiesto. Es Agile el ritual corporativo. Y cuando tu objetivo real es mover una codebase de 200,000 líneas de un stack muerto a un stack moderno de 2026 donde ya programas con IA, ese ritual se vuelve el principal obstáculo.

Este artículo no defiende que Agile está mal. Defiende que, en un equipo de 15 personas haciendo una migración legacy con asistencia de IA, Extreme Programming (XP) es más rápido, más eficiente y más cómodo para los desarrolladores. Y lo es por una razón incómoda: el mundo ya no separa tanto a QA, analista, gerente y dev.

De dónde sale XP y por qué nació

Extreme Programming no se inventó en una consultora ni en una conferencia de moda. Nació en 1996 dentro de un proyecto de nóminas que se estaba hundiendo.

Kent Beck entró al proyecto Chrysler Comprehensive Compensation System (C3), el sistema que calculaba el pago de los empleados de Chrysler. El equipo original había intentado el camino clásico: diseño grande por adelantado, documentos de arquitectura gruesos, y un plan que se desmoronaba cada vez que el negocio cambiaba de opinión. El código no entregaba. Beck tomó una decisión incómoda: tirar el plan y construir el software mediante prácticas técnicas extremas, día a día, frente a la pantalla.

La palabra “extreme” no es marketing. Significa llevar una buena práctica hasta su límite:

Si revisar código ayuda, haz que dos personas escriban cada línea en el momento (pair programming).
Si probar ayuda, escribe la prueba antes que el código (TDD).
Si integrar ayuda, hazlo varias veces al día en lugar de una vez por release (integración continua).
Si escuchar al cliente ayuda, siéntalo al lado del equipo, no a dos meses de distancia.

En 1999 Beck publicó todo esto en Extreme Programming Explained. El método ya tenía rostro, fracasos y resultados medibles. No era una teoría: era el rescate documentado de un sistema de compensaciones que funcionaba.

Eso importa hoy porque C3 era, en el fondo, un problema de código legacy. Un sistema grande, con reglas de negocio frágiles, que había que mantener vivo mientras lo transformabas. Suena familiar, ¿verdad?

Qué es XP cuando lo sacas de la charla

Agile se vendió como un conjunto de valores. XP es ese conjunto de prácticas técnicas con dientes, nacido del campo y no de una sala de juntas. Mismas raíces del Manifiesto, distinto nivel de concreción.

Agile te dice “responde al cambio”. XP te dice cómo: pair programming, TDD, integración continua varias veces al día, refactor constante, propiedad colectiva del código, y releases frecuentes. No hay un Product Owner que guarde la verdad del negocio en su cabeza. La verdad vive en las pruebas y en el repositorio.

En una migración legacy eso cambia todo. Porque migrar no es escribir features nuevas. Es transformar código que ya existe, validar que sigue comportándose igual, y subirlo sin romper producción. Esa es la especialidad natural de XP: cambiar código con red de seguridad, exactamente lo que Beck hacía en C3.

El equipo de 15 ya no tiene silos

La premisa vieja era: el analista define, el arquitecto diseña, el dev implementa, QA prueba, el gerente coordina. Cada rol era una frontera. Cada frontera era una cola de trabajo y un lugar donde la información se degradaba.

En 2026 esa frontera se difumina por dos lados. Primero, la IA indexa el contexto del sistema completo. Segundo, el desarrollador ya no solo “implementa”: escribe la especificación, genera el código, lo prueba y lo despliega en el mismo flujo.

Cuando tu herramienta principal es un agente de código con el legacy indexado, el analista y el dev comparten la misma fuente de verdad. El agente no necesita un documento de requisitos traducido por tres personas. Necesita el repositorio y el contexto.

# CLAUDE.md (raíz del repo migrado)

## Contexto del sistema legacy
- `src/legacy/payments/` es Cobol-on-Java, NO tocar sin cubrir con tests.
- Regla de negocio crítica: rounding de impuestos en `TaxCalculator.legacyRound()`.
- Equivalencia obligatoria: todo cambio debe pasar `make equiv-tests`.

## Stack moderno objetivo
- NestJS + TypeScript, PostgreSQL, Prisma.
- Cada endpoint migrado requiere contrato en `contracts/` antes de merge.

Ese archivo es tu nueva pared de historias. No tiene story points. Tiene intención, restricciones y una definición de hecho ejecutable. Un analista lo lee. Un dev lo sigue. Un gerente lo entiende. La frontera desaparece.

Vibe coding no es caos si la red está puesta

“Vibe coding” suena a programar borracho de optimismo. La versión responsable es otra: el desarrollador describe intención, la IA genera código, y las pruebas existentes deciden si el código merece quedarse.

Aquí es donde XP brilla sobre Agile. Agile confía en que el proceso (ceremonias, aprobaciones) produce software correcto. XP confía en que las pruebas producen software correcto. Con IA en medio, la segunda postura es la única que escala.

La IA puede generar quinientas líneas en un minuto. Tu capacidad humana de revisarlas a ojo es de veinte. La diferencia la cubres con la red de XP: TDD, CI que corre en segundos, y propiedad colectiva para que cualquiera pueda corregir lo que la IA rompió.

Pair programming reinventado: tú y el agente

El pair programming clásico pone a dos humanos frente a un teclado. En 2026 el par es tú y Claude Code. Tú llevas el juicio de dominio; el agente lleva la velocidad de tecleo y la memoria del repo indexado.

# Flujo de par humano-IA en la migración
$ claude "migra src/legacy/inventory a NestJS, mantén la firma
  de InventoryService.findBySku, escribe tests que repliquen el
  comportamiento actual antes de tocar la implementación"
# El agente escribe tests que fallan (caracterización), luego el código.
# Tú revisas la intención, no cada llave.

Ese es pair programming de verdad: pensamiento continuo en voz alta, ningún compromiso silencioso con el legacy. El agente no se aburre, no tiene ego con el código viejo, y no olvida reglas que pusiste en CLAUDE.md. Tú mantienes la responsabilidad. Eso es exactamente lo que XP pedía del par: dos cerebros, una sola cuenta de quien responde por el resultado.

TDD sigue vivo, pero ahora es instantáneo

Hay quien dice que con IA el TDD murió. Al revés: el TDD es lo único que hace al vibe coding seguro. La diferencia es la velocidad del ciclo.

Antes escribías el test, corría en segundos, y esperabas. Ahora escribes la intención, el agente genera el test de caracterización del comportamiento legacy, y en la misma pulsación genera la implementación moderna que lo satisface.

// Tests de caracterización: congelan el comportamiento actual ANTES de migrar
describe("TaxCalculator.legacyRound (comportamiento a conservar)", () => {
  it("redondea impuestos con la regla legacy, no la estándar", () => {
    expect(legacyRound(10.005, "MXN")).toBe(10.01); // regla de negocio, no redondeo bancario
  });
});

// Solo después de que este test pasa contra el legacy, migras a:
describe("TaxCalculator.modernRound", () => {
  it("mantiene equivalencia con legacyRound", () => {
    expect(modernRound(10.005, "MXN")).toBe(legacyRound(10.005, "MXN"));
  });
});

El test de caracterización es tu seguro de vida en una migración. Si la versión moderna se comporta distinto al legacy en un caso límite, falla antes de tocar producción. XP lo llamaba “refactor con red”. Hoy la red la teje el agente en segundos, pero la disciplina es la misma del 99.

Integración continua cuando la IA escribe el 60%

Con quince personas y un agente generando código a granel, tu mayor riesgo no es escribir poco. Es que quince ramas diverjan y el merge se vuelva un infierno a la semana cuatro.

XP responde con integración continua varias veces al día. No una vez por sprint. Varias veces por hora. Cada push corre la suite de equivalencia contra el legacy. Si rompes el comportamiento, lo sabes en el momento, no en la release.

# .github/workflows/equiv-check.yml
name: legacy-equivalence
on: [push]
jobs:
  equiv:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test:characterization   # comportamiento legacy congelado
      - run: npm run test:modern              # nueva implementación debe coincidir
      - run: npx claude-code review --strict  # agente revisa el diff por reglas de CLAUDE.md

Ese pipeline es la ceremonia de XP automatizada. Reemplaza la reunión de sincronización de media hora con un fallo rojo en tu terminal. Más rápido, más honesto, y no depende de que alguien asista.

Por qué XP es más rápido en una migración legacy

Juntémoslo. En una migración legacy con IA:

Menos colas. Sin fronteras rígidas entre analista, dev y QA, el trabajo no espera aprobación de alguien ausente. La especificación vive en CLAUDE.md y las pruebas.
Más redes, menos miedo. TDD de caracterización y CI frecuente te permiten tocar el legacy sin pánico. Agile puro te deja con reuniones y un plan que se vence cada dos semanas.
Velocidad del par humano-IA. El agente indexado escribe a la velocidad de la intención. XP ya estaba diseñado para programación en pareja y cambio continuo; solo que ahora tu par no se cansa.
Definición de hecho ejecutable. No “listo cuando QA firma”. Listo cuando los tests de equivalencia pasan y el pipeline es verde. Eso se puede medir a las tres de la tarde, no al cierre del sprint.

En un equipo de 15, Agile-espectáculo gasta el tiempo de quince personas en coordinación. XP gasta el tiempo de quince personas en código que el pipeline valida solo. La diferencia se ve en el gráfico de velocidad a la semana seis.

Errores comunes de los equipos que intentan esto

Creer que “usar IA” ya es XP. No lo es. Sin TDD de caracterización y sin CI frecuente, solo tienes código generado rápido y sin red. Migras basura a mayor velocidad.

Pensar que la IA elimina la necesidad de código compartido. Al contrario: con quince personas y un agente, la propiedad colectiva es más crítica. Si solo tres personas entienden el módulo de pagos, el agente los va a perseguir a ellos toda la semana.

Mantener al gerente como cuello de botella. En XP el gerente no aprueba cada decisión; elimina obstáculos. Si tu gerente sigue firmando cada merge, no estás haciendo XP, estás haciendo Agile con un robot en la sala.

La diferencia que importa

Agile te ayuda a estar de acuerdo sobre qué construir. XP te ayuda a construirlo sin romper lo que ya funciona. En una migración legacy con IA, lo segundo es lo que decide si terminas el trimestre o lo pospones otro año.

El manifiesto decía “individuos e interacciones sobre procesos y herramientas”. En 2026 la herramienta es un agente de código con tu legacy indexado. XP es el método que mejor lo abraza: poca ceremonia, mucha red, y la responsabilidad siempre en las manos de quien escribe el código.