Los agentes de código IA necesitan XP

8 min de lectura

La programación agéntica necesita columna vertebral

Si no trabajas en software todos los días, el problema central igual es fácil de entender: la máquina escribe rápido, pero rápido no significa coherente. Mucho software falla por la misma razón que falla una cocina mal organizada. Cuchillos en un cajón, tenedores en otro, especias por todas partes excepto donde se cocina, y tres bolsas de arroz abiertas porque nadie sabía que ya había arroz en casa. El trabajo sigue. El desperdicio se multiplica.

El software cae en ese mismo caos cuando una persona o una máquina copia la misma regla en cinco archivos, inventa una clase nueva por cada capricho o refactoriza código solo porque le produce picazón intelectual. Puede que el resultado siga funcionando. Solo se vuelve caro cambiarlo.

XP sigue funcionando porque la física sigue funcionando

Extreme Programming fue construido para un mundo donde el software cambia constantemente y los desarrolladores se equivocan varias veces al día. Ese mundo no desapareció porque un modelo de lenguaje aprendiera a autocompletar archivos enteros.

Los hábitos de XP que importaban en 2000 importan aún más con agentes en 2026:

• Escribir primero un test que falle.
• Hacer el cambio más pequeño que convierta rojo en verde.
• Refactorizar solo mientras los tests sigan en verde.
• Integrar constantemente en vez de guardar sorpresas para después.

Nada de esto es glamoroso. La buena práctica rara vez lo es. La buena práctica casi siempre se parece a negarse a mentirse.

La programación agéntica sube la apuesta porque el modelo puede producir mucho disparate plausible antes de que un humano termine el café. Por eso los tests superan a las instrucciones. El hábito importa porque importa el bucle de feedback. Si lo quitas, te quedas con velocidad y esperanza, que es la forma elegante de producir errores caros en serie.

DRY significa una regla, una casa

DRY suele reducirse a un eslogan sobre escribir menos. Ese no es el punto. El punto no es teclear menos. El punto es asegurarse de que una regla de negocio no se bifurque en silencio en varias versiones que compiten entre sí.

Si la lógica de descuentos vive en un controlador, un proceso en segundo plano, un servicio de pago y un script de informes, eso no es reutilización. Son cuatro desacuerdos futuros esperando el fin de semana de despliegue.

Ese es exactamente el tipo de suciedad que crean los agentes cuando falta disciplina. El modelo ve código parecido en dos sitios y pega con gusto una tercera versión porque eso resuelve la tarea inmediata. No es malicia. Es oportunismo. La salida rápida sin presión de diseño siempre deriva hacia la duplicación.

Por eso la regla vieja sigue importando:

• Reutilizar un objeto de dominio o helper existente antes de crear uno nuevo.
• Si una regla de negocio aparece dos veces, extraerla antes de considerar terminada la tarea.
• No copiar validación, precios, autorización o lógica de mapeo entre módulos.

Ese es el trabajo humano cuando se colabora con un agente. No romantizar el oficio mientras se tolera duplicación evitable. El viejo hábito sigue ganando: dejar la regla en un solo sitio y defender ese sitio cada vez que el código cambia.

Para quien no vive dentro del software, DRY es simplemente esto: cuando cambia una política de empresa, quieres actualizarla en un lugar y no olvidarla en siete.

OOP va de responsabilidad, no de cosplay de herencia

La programación orientada a objetos también se maltrata a manos de gente que confunde vocabulario con diseño. Una jerarquía de clases no es arquitectura. Muy a menudo es solo la ruta larga hacia el arrepentimiento.

Buena OOP, sobre todo en programación agéntica, significa unas pocas cosas sencillas:

• Cada objeto o módulo debería tener una sola razón clara para cambiar.
• El comportamiento debería vivir cerca de los datos de los que depende.
• Las interfaces públicas deberían mantenerse pequeñas.
• La composición debería ganar a la herencia salvo que la herencia sea obviamente más simple.

Esto importa porque a los agentes les encanta inventar abstracciones. Dales un prompt vago y producirán BaseManagerFactoryAdapter como si la sátira fuera un patrón de diseño.

El hábito que mantiene esto bajo control es más viejo que la ola actual de herramientas: preferir objetos pequeños con responsabilidades claras, extender una abstracción existente solo cuando el código que la rodea ya usa ese patrón, y no introducir una capa nueva mientras la actual no esté fallando.

La prueba práctica es brutalmente simple: si un desarrollador humano no puede explicar dónde vive una regla y por qué, el agente tampoco va a mantenerla coherente.

TDD le da al agente un metrónomo

Muchos equipos dicen que quieren que el modelo haga TDD cuando en realidad quieren decir: “escribe también algunos tests para que esto parezca respetable”. Eso no es TDD. Eso es papeleo con assertions.

Si quieres que un agente se comporte como un desarrollador disciplinado, el bucle de desarrollo tiene que seguir intacto en vez de convertir los tests en burocracia decorativa.

El bucle es viejo y sigue invicto:

1. Leer los tests y el código existentes antes de cambiar nada.
2. Agregar o actualizar un test que falle y describa el siguiente comportamiento.
3. Implementar el cambio más pequeño que haga pasar ese test.
4. Ejecutar los tests relevantes.
5. Refactorizar solo después de tener verde.

Eso le da ritmo al modelo. Reduce el espacio de búsqueda. Convierte la tarea de “escribe algo impresionante” en “cumple este contrato concreto sin romper el resto”. Los modelos necesitan esa disciplina más que los humanos, porque son muy buenos sonando correctos mientras están estructuralmente equivocados.

Si quieres el alegato completo contra el prompting freestyle, está aquí: el vibe coding no es desarrollo de software. Es improvisación con mejor autocompletado.

Lo que de verdad dicen unas buenas instrucciones para agentes

La mayoría de los malos archivos de instrucciones comparten el mismo fallo: intentan anticipar cada decisión de código en prosa. Eso está perdido de antemano. El archivo se hincha, aparecen contradicciones y el agente escoge el patrón de tokens que le resulte más cómodo en contexto.

El mejor enfoque es más pequeño y más duro. Un buen archivo de instrucciones debería cubrir sobre todo esto:

• Flujo de trabajo: tests primero, cambio mínimo, verde antes de refactorizar.
• Barandillas de diseño: mantener DRY, preferir objetos pequeños, reutilizar abstracciones existentes.
• Reglas de seguridad: no debilitar tests, no inventar dependencias a la ligera, preguntar cuando los requisitos sean ambiguos.
• Reglas de cierre: tests en verde, lint en verde, diff enfocado.

Eso basta para moldear comportamiento sin fingir que Markdown puede reemplazar el juicio.

Dicho de otra manera: los archivos de instrucciones son para hábitos. Los tests son para pruebas. Los linters son para consistencia. Cada herramienta debería hacer su propio trabajo.

Un mejor hábito de prompting para equipos y para quien trabaja solo

Hay una fantasía tentadora alrededor de la programación agéntica: escribir una vez un prompt maestro brillante y dejar que la máquina cargue con el oficio. Esa fantasía sobrevive porque las primeras demos suelen funcionar.

Luego llega la realidad. El modelo duplica lógica. Cambia una interfaz que nadie quería tocar. Agrega un helper que casi coincide con el helper existente, pero no del todo. De pronto el equipo está escribiendo derecho procesal de prompts en vez de software.

La cura no es más drama en el prompt. La cura es un repositorio que diga la verdad:

• Los tests explican qué debe hacer el sistema.
• Los archivos de instrucciones explican cómo debería comportarse el agente mientras lo cambia.
• El código existente muestra qué patrones ya están vivos.

Cuando esas tres cosas encajan, hacer prompts se vuelve más simple. Puedes decir: “Añade IVA suizo para facturas”, y confiar en que el agente entrará por la puerta principal en vez de romper una ventana.

Eso también importa para quien desarrolla solo. Un repositorio personal también puede convertirse en pantano. De hecho suele convertirse en pantano más rápido, porque no hay nadie alrededor que se queje antes de que los juncos lleguen al hombro.

Archivos de ejemplo alojados

Los ejemplos de abajo son intencionalmente cortos. No intentan serializar todo el oficio del desarrollo de software en Markdown. Establecen disciplina y luego devuelven la aplicación de esa disciplina a tests y herramientas.

• Instrucciones de ejemplo para GitHub Copilot
• Instrucciones de ejemplo para Claude
• Ejemplo de AGENTS.md para trabajo multiagente

Róbalos. Recórtalos. Ajústalos a tu stack. Pero deja el centro de gravedad donde corresponde: bucles de feedback pequeños, responsabilidades claras y menos estupidez duplicada.