Cuando una tecnología cambia el proceso de producción de forma significativa, las prácticas que rodean ese proceso necesitan tiempo para ponerse al día. Con la IA generativa ese tiempo se ha comprimido: en menos de dos años han emergido propuestas concretas en las tres dimensiones que estructuran el trabajo ágil.

Lo que sigue no es un catálogo exhaustivo ni una prescripción. Es un mapa de lo que está sucediendo, con el nivel de honestidad que merece un terreno en construcción.

Prácticas técnicas: nuevos flujos para nuevo trabajo

Test-Driven Generation (TDG)

El TDD clásico tiene un ciclo conocido: escribir el test que falla, escribir el código mínimo para que pase, refactorizar. Con IA ese ciclo puede reorganizarse de forma más potente. Chanwit Kaewkasi describe una variante donde el desarrollador proporciona los requisitos en alto nivel, la IA genera los tests basándose en esos requisitos, y después genera el código que debe pasar esos tests. El desarrollador revisa y valida.

La ventaja crítica respecto a la práctica habitual es que cuando los tests se generan sobre el código ya existente, el modelo simplemente completa un puzzle de tokens: produce tests que coinciden con el código, no necesariamente con el comportamiento correcto. El TDG invierte ese orden y recupera el principio original del TDD: primero definir qué debe hacer el sistema, luego hacerlo. El informe DORA 2025 confirma que este tipo de práctica fundacional amplifica el impacto positivo de la IA, actuando como red de seguridad cuando el volumen y la velocidad de cambios se disparan.

El TDG no es una práctica cerrada, pero su lógica es sólida y replicable sin necesitar herramientas especiales.

Context Engineering como práctica de equipo

El prompt engineering tuvo su momento de protagonismo en 2023 y 2024. En 2025 los mejores equipos comprendieron algo más fundamental: el problema no es el prompt, es el contexto. Andrej Karpathy y Tobi Lütke, CEO de Shopify, nombraron esta disciplina «context engineering»: la gestión sistemática de qué información ve el agente, cuándo la ve y cómo está estructurada.

La diferencia práctica es significativa. Un agente que recibe un prompt genérico produce resultados genéricos. Un agente que recibe el contexto correcto —estándares de arquitectura del proyecto, patrones de código existentes, decisiones de diseño anteriores, restricciones técnicas específicas— produce outputs relevantes y coherentes con el sistema real. Algunas organizaciones están implementando una «Definition of Done orientada al contexto»: ninguna funcionalidad se considera completa hasta que su documentación técnica y los architecture decision records están actualizados. Esto garantiza que la base de conocimiento del equipo —la «memoria a largo plazo» de la organización— crece con cada entrega.

Como práctica de equipo, el context engineering tiene varias dimensiones concretas:

• mantener ficheros AGENTS.md o equivalentes con las convenciones del proyecto;
• gestionar los architecture decision records como fuente de verdad para los agentes;
• y establecer quién es responsable de mantener ese contexto actualizado.

La investigación académica en Structured Agentic Software Engineering lo formula así: un agente que puede incorporarse rápidamente al contexto específico de un equipo, proyecto u organización es más valioso que un agente brillante pero frágil fuera de su dominio estrecho.

QA de nueva generación: IA supervisando IA

El testing tradicional asume que los tests los escriben humanos para verificar código escrito por humanos. Cuando ambos lados de esa ecuación pueden involucrar IA, el modelo de QA necesita revisión.

Están emergiendo tres enfoques complementarios:

• Usar una IA como revisora automática del output de otra: semáforos automatizados que detectan patrones de deuda técnica, duplicación, vulnerabilidades de seguridad o código que no sigue los estándares del proyecto, antes de que ese código llegue a revisión humana.
• Specification by Example (SbE): crear tests basados en ejemplos concretos y verificables que sirven como especificación del comportamiento esperado. Se identifica este enfoque como especialmente relevante porque la IA no puede «corregir sus propios deberes»: si se le pide que genere código y luego lo revise, tenderá a validar lo que ella misma produjo.
• Auditoría continua de métricas de salud del código como contrapeso explícito a la velocidad de generación.

Ninguno de estos enfoques sustituye la revisión humana. La complementan y la hacen más eficiente, filtrando los problemas mecánicos para que la atención humana pueda centrarse en los errores de lógica y arquitectura que la IA no detecta.

Prácticas de gestión y flujo: repensar cómo se organiza el trabajo

Estimación en tres niveles

Los story points fueron diseñados para estimar esfuerzo cognitivo humano en trabajo de implementación. Cuando parte del trabajo lo ejecuta un agente, esa unidad de medida deja de ser homogénea. Proponemos distinguir explícitamente tres tipos de trabajo:

• Las tareas automatizadas (Zero-Point) son las que la IA ejecuta de forma autónoma o casi autónoma. No se estiman en story points: se miden por coste computacional y tiempo de revisión humana necesario.
• Las tareas humanas (Standard) requieren creatividad, juicio o conocimiento que la IA no puede aportar; se estiman con los métodos habituales.
• Las tareas de revisión e integración (R&I) son trabajo humano dedicado a revisar, validar e integrar lo que genera la IA, y son las más fáciles de subestimar y las que generan más cuellos de botella. Estimar estas explícitamente es lo que evita el escenario en que todo el código está «generado» pero nadie ha podido revisarlo.

La lógica detrás de este modelo conecta directamente con lo que documenta la investigación. DORA 2025 identificó que la IA tiende a aumentar el tamaño de los PRs de forma significativa, creando una tensión directa con la práctica de trabajar en lotes pequeños. La estimación R&I es el mecanismo que hace visible ese cuello de botella antes de que llegue al final del sprint.

Definition of Ready para IA

La Definition of Ready clásica define cuándo una historia está lista para entrar en un sprint: definida, estimada, con criterios de aceptación claros. Cuando parte del trabajo del sprint lo ejecutará un agente de IA, esa definición necesita una extensión.

Una historia está «ready para IA» cuando además cumple: la especificación es suficientemente detallada para que el agente genere output relevante; el agente tiene acceso al contexto necesario (arquitectura, estándares, patrones del proyecto); los criterios de aceptación son verificables y testeables de forma objetiva; y se ha estimado explícitamente el tiempo de revisión humana del output y se ha incluido en la planificación. Esta última condición es la más frecuentemente omitida y la que más cuellos de botella genera.

El A3 Framework: Assist, Automate, Avoid

Stefan Wolpers ha documentado un marco de decisión simple y accionable para equipos que necesitan criterios explícitos sobre qué delegan a la IA. El A3 distingue tres categorías:

• trabajo que la IA debe asistir (el humano mantiene el criterio, la IA acelera la ejecución);
• trabajo que la IA puede automatizar (ejecución rutinaria con revisión periódica);
• y trabajo que conviene evitar delegar a la IA (juicio ético, gestión de conflictos de equipo, decisiones estratégicas de producto).

La utilidad del A3 no está en las categorías en sí sino en el hecho de que el equipo tenga una conversación explícita sobre dónde están esos límites en su contexto específico. Sin esa conversación, la delegación ocurre por inercia.

Prácticas de equipo y reflexión: hacer consciente lo que ocurre por defecto

La retrospectiva de gobernanza IA

La retrospectiva estándar examina cómo ha funcionado el proceso del equipo: qué salió bien, qué mejorar, qué experimentar. En equipos con IA, hay una dimensión adicional que raramente entra en esa conversación de forma estructurada: cómo está funcionando la integración de la IA en el proceso.

El workshop XP2025 sobre IA y desarrollo ágil identificó como reto central que la mayoría de equipos ágiles carecen de guías claras sobre cómo operacionalizar la gobernanza de IA en el trabajo diario, incluyendo cómo garantizar el cumplimiento de protecciones de datos, cómo gestionar la propiedad intelectual de artefactos generados por IA y cómo mantener transparencia en decisiones asistidas por IA.

La retrospectiva de gobernanza IA es una sesión periódica (no necesariamente cada sprint, puede ser mensual o trimestral) que examina específicamente estas preguntas:

• ¿Qué proporción del código que entregamos ha sido generado por IA y quién lo revisa?
• ¿Nuestra DoD refleja cómo trabajamos realmente?
• ¿Los roles del equipo han cambiado en la práctica y lo hemos hecho explícito?
• ¿Hay decisiones que estamos delegando a la IA que deberían ser humanas?
• ¿Tenemos criterios claros sobre qué datos del proyecto puede procesar la IA y cuáles no?

No es una auditoría de cumplimiento. Es el mismo espíritu de la retrospectiva clásica (hacer visible lo que ocurre, decidir qué ajustar) aplicado a un territorio que los equipos están navegando sin mapa.

El canvas de integración IA

Más allá de la retrospectiva, algunos equipos están usando herramientas de reflexión estructurada antes de adoptar IA en nuevos flujos de trabajo, no solo después. Un canvas sencillo con cinco dimensiones puede servir como punto de partida para esa conversación:

• ¿Qué hace la IA en nuestro flujo actual (aunque sea de forma informal y no acordada)?
• ¿Qué fricción sentimos en esa integración?
• ¿Qué criterios tenemos para decidir qué delegamos y qué no?
• ¿Cómo revisamos el output de la IA antes de considerarlo válido?
• ¿Cómo aprenderemos si esto funciona o no?

El AI4Agile Practitioners Report 2026 describe lo que los profesionales piden cuando se les pregunta qué mejorarían: no modelos más potentes, sino herramientas que encajen en su sprint sin fricción, con outputs que entiendan el contexto específico de su equipo y su dominio. El canvas no es una herramienta de IA, es una conversación de equipo; pero es precisamente el tipo de práctica que permite que esa integración sea deliberada en lugar de reactiva.

Una nota de honestidad sobre el estado del arte

La mayoría de las prácticas descritas aquí tienen entre seis meses y dos años de vida documentada. Algunas tienen nombres propios y referencias claras; otras son patrones que distintos equipos están descubriendo de forma independiente sin haberlos bautizado todavía. Ninguna tiene el respaldo empírico acumulado que tienen el TDD, el planning poker o la retrospectiva.

Eso no las hace menos valiosas. La comunidad ágil siempre funcionó así: las retrospectivas no estaban en el Scrum original, el refinamiento del backlog tampoco. Emergieron porque equipos reales encontraron que los necesitaban. Lo mismo está ocurriendo ahora, con la diferencia de que el ritmo de aparición es más rápido que nunca.

Las prácticas descritas en este artículo no son soluciones mágicas. Son herramientas para que la integración de la IA sea consciente, revisable y mejorable. Que es, exactamente, lo que la agilidad lleva décadas proponiendo para todo lo demás.

¿Estás usando alguna de estas prácticas, o algo parecido? ¿Hay algo que hayas inventado en tu equipo que no esté aquí?

Bibliografía

• Ashmore, D. (2026). 5 ways agentic engineering transforms agile practices. CIO.
• Dell'Acqua, F. et al. (2025). The Cybernetic Teammate. Harvard Business School Working Paper No. 25-043.
• Google Cloud / DORA (2025). State of AI-Assisted Software Development.
• Hassan, A. et al. (2025). Agentic Software Engineering: Foundational Pillars and a Research Roadmap. arXiv.
• Kaewkasi, C. (2025). Test-Driven Generation (TDG): Adopting TDD Again This Time with Gen AI. Medium.
• Karpathy, A. & Lütke, T. (2025). Context Engineering.
• Seidel, F. et al. (2025). AI and Agile Software Development: A Research Roadmap from the XP2025 Workshop. arXiv.
• Wolpers, S.
  • (2025). A3 Framework: Assist, Automate, Avoid. Age-of-Product.com
  • (2026). AI4Agile Practitioners Report 2026. Age-of-Product / Scrum.org.