Estaba hace unos meses inmerso en un cambio arquitectural de cierta envergadura: sistema de colas, muchas piezas móviles, el tipo de modificación que toca suficientes capas del sistema como para que un error de criterio sea difícil de deshacer. Abrí el modo de planificación del agente y empecé a trabajar con él – que escaneara el código existente, que identificara dependencias, que propusiera opciones y razonara las descartadas. El plan fue creciendo solo, incorporando trade-offs, fragmentos de código, enlaces a funciones concretas. En algún punto me alejé del teclado y lo leí de un tirón, como se lee un documento antes de enviárselo a alguien.

Y ahí vino el pensamiento que me trajo aquí: si un compañero viera este plan antes de que yo lo ejecutara, la pull request no tendría sorpresas. Y acto seguido, el que no me ha abandonado desde entonces: ¿y si lo que nos pasáramos entre nosotros, casi como contratos, fueran planes?

Esto es lo que yo llamo Plan-Driven Development, o PDD.

La genealogía del artefacto

Cada metodología de desarrollo que ha sobrevivido lo suficiente para tener nombre propio ha desplazado, en algún momento, el artefacto alrededor del cual giraba el trabajo del equipo, y comprender esa genealogía ayuda a entender por qué PDD no es una rareza sino el siguiente paso lógico en una secuencia que ya lleva décadas en marcha.

Waterfall organizaba el trabajo alrededor del documento de especificación: requisitos, diseño, arquitectura, todo capturado por escrito antes de que un solo ingeniero escribiera una línea de código, lo que en teoría era impecable pero en la práctica se estrellaba contra el hecho irremediable de que los documentos de especificación no sobreviven al contacto con la realidad – el código emergente los deja obsoletos casi de inmediato y nadie tiene incentivo suficiente para mantenerlos actualizados, de modo que el artefacto y la implementación se divorciaban en algún punto del camino y todo el andamiaje burocrático que los rodeaba se convertía en puro ritual: trabajo que se hace porque siempre se ha hecho, no porque aporte valor.

Agile respondió con la iconoclasia necesaria proclamando que el artefacto relevante es el software funcionando y no la documentación, la victoria del código sobre el papel, los sprints sobre los Gantt, la conversación sobre el contrato, y funcionó en gran medida porque acortó el ciclo de feedback de meses a semanas, a días, aunque en el proceso minimizó la planificación de forma a veces excesiva y el péndulo, como siempre, pasó de un extremo al otro.

Test-Driven Development intentó algo más refinado: desplazar el artefacto al test, de modo que escribir el test antes que el código hiciera de él la especificación viva del sistema – idea elegante y disruptiva en su momento, pero con la limitación de que los tests codifican el qué –el comportamiento esperado– y no necesariamente el por qué ni el cómo, de suerte que puedes perfectamente tener una batería de tests exhaustiva sobre una arquitectura equivocada, porque el test te dice si el código hace lo que se le pidió, no si se le pidió lo correcto.

Plan-Driven Development propone que el artefacto principal sea el plan – un plan que captura el por qué del cambio, el qué se va a construir y el cómo se va a implementar, con suficiente detalle para que otro ingeniero –o un agente– pueda ejecutarlo fielmente. La diferencia crítica con Waterfall no es la forma sino la naturaleza del ejecutor: cuando el encargado de implementar es un agente de IA, la distancia entre plan e implementación colapsa, porque el agente no se aburre, no improvisa, no reinterpreta. Ejecuta.

PDD no es Waterfall 2.0 sino Agile aplicado al plan en lugar de al código: iteras con el agente sobre el plan –lo interrogas, lo desafías, lo refinas– hasta que estás satisfecho, y entonces lo ejecutas.

Qué es un plan, exactamente

Aquí es donde la puerca tuerce el rabo, porque la palabra plan es suficientemente vaga para que cada cual la interprete a su conveniencia.

En PDD, un plan no es un documento de cuarenta páginas escrito por un arquitecto en una torre de marfil ni un ticket de Jira con tres líneas y un enlace a un Figma, sino un documento preciso, del tamaño adecuado para el cambio que describe, que contiene al menos lo siguiente:

• Enunciado del problema: qué falla, qué falta, o qué se quiere mejorar, y por qué importa ahora.
• Solución elegida y alternativas descartadas: no basta con describir lo que se va a hacer; hay que razonar por qué no se hace de otra manera, dado que las alternativas descartadas con su justificación son frecuentemente la parte más valiosa del documento.
• Arquitectura: los componentes involucrados, los flujos de datos, las interfaces entre sistemas.
• Detalle de implementación: firmas de funciones, fragmentos de código relevantes, enlaces a las partes del código existente que se van a modificar.
• Criterios de aceptación: cómo sabremos que el cambio funciona correctamente.

Un plan así puede revisarse en quince minutos y ofrecer una comprensión completa de la intención y la estrategia, y hay una disciplina adicional que el agente te impone gratuitamente: si el plan no es suficientemente claro para que lo ejecute sin ambigüedades, tampoco lo es para que un compañero lo entienda, de modo que el agente actúa como primer revisor implacable que no adivina, no asume, no da nada por sobreentendido, y si el plan tiene huecos, los encuentra.

El plan como contrato

La tesis que más me interesa defender es esta: el plan debería reemplazar a la pull request como artefacto principal de revisión.

El flujo estándar hoy es que el desarrollador recibe una tarea, la piensa en su cabeza, implementa, abre una PR, y es entonces cuando el resto del equipo descubre su intención y su arquitectura leyendo código, momento en el que los desacuerdos ya son caros porque refactorizar una decisión arquitectural equivocada después de que está implementada no es solo costoso en tiempo sino en ánimo, en confianza, en esa energía que se va por el sumidero cuando sientes que has construido la casa en el suelo equivocado.

Con PDD, el plan se revisa antes de que exista una sola línea de implementación: los stakeholders validan el por qué, los leads el cómo, los compañeros el qué, el plan circula, recibe comentarios, se itera, y cuando se aprueba es un contrato en el sentido más preciso – todos han visto el documento, todos han tenido la oportunidad de objetar, y todos entienden qué se va a construir y cómo. La PR que surge de ese proceso no es un descubrimiento sino una verificación de que la implementación siguió el plan acordado, y las sorpresas pasan a ser la excepción en lugar de la norma.

Hay una analogía que me resulta útil, aunque soy consciente de que tiene algo de pedante traerla a colación: la democracia griega funcionaba sobre el principio de la desconfianza institucionalizada, no porque los ciudadanos se consideraran corruptos por defecto, sino porque el mecanismo de deliberación explícita producía mejores resultados que la confianza implícita en el juicio individual. PDD opera sobre una lógica similar: no implica desconfianza en el criterio del ingeniero, sino que el alineamiento explícito, cuando la escala de la decisión lo justifica, produce mejores resultados que la autonomía silenciosa.

Lo que cambia en el rol del ingeniero

Una objeción razonable es que el modelo parece empobrecer el trabajo del ingeniero, pero si el agente ejecuta el plan, lo que queda para el humano es precisamente lo más difícil.

El assignee de hoy canaliza su creatividad en una feature y carga con la responsabilidad de entregarla – diseña, implementa, depura, revisa –, aunque el problema es que buena parte de ese trabajo –la implementación pura, el boilerplate, las pruebas unitarias– es la fruta bajocolgante del oficio, trabajo que no requiere creatividad sino atención y tiempo, y el agente puede ocuparse de esa parte con una fidelidad que ya es sorprendente y que seguirá mejorando.

El assignee de mañana conduce al agente a través de una implementación acordada cuyo trabajo es anterior y más exigente: formular el problema con precisión, elegir entre opciones arquitecturales con criterio, anticipar los casos límite, producir un documento que otro profesional pueda entender y criticar, de suerte que la creatividad se desplaza hacia arriba, al plan, y diseñar un plan que un agente pueda ejecutar fielmente requiere más claridad de pensamiento que implementarlo directamente, no menos – es la diferencia entre saber hacer algo y saber explicarlo de manera que cualquier ejecutor competente llegue al mismo resultado.

Si alguna vez vuelvo a liderar un equipo, me imagino pasando planes. No tickets. No user stories. Planes.

La objeción honesta

Debo concederle espacio a un argumento que no es desdeñable: en la era de los agentes de IA, generar tests exhaustivos es trivial, y un agente puede enumerar todos los casos límite de una función y producir una batería de pruebas completa en minutos. Los tests hiperfit –esos tests tan acoplados a la implementación que se rompen con cualquier refactorización– eran una carga insoportable cuando los escribía un humano, pero ahora son desechables porque simplemente los vuelves a generar, lo que hace que TDD a escala industrial se convierta en algo viable por primera vez y que pueda argumentarse con cierta seriedad que tests bien generados son contrato suficiente.

No estoy convencido, pero lo reconozco como un argumento serio. Mi respuesta es que plan y tests son complementarios, no competidores: los tests validan el comportamiento, el plan valida la intención y la arquitectura, y el plan viene primero porque le da forma a los tests – sin plan, estás enumerando tests sobre una arquitectura que nadie revisó; con plan, los tests emergen de criterios de aceptación que ya fueron discutidos y aprobados.

Pero esto es una opinión, no una ley, y puede que el futuro demuestre que tests-first a escala es suficiente y que mis reflexiones sobre el plan sean solo la nostalgia de alguien que leyó demasiados documentos de diseño en su momento. Lo dudo, pero lo concedo.

Una tesis, no una profecía

Escribo esto como alguien que lleva años construyendo sistemas distribuidos en producción, que ha visto modas metodológicas irse y venir, y que en los últimos meses ha encontrado en el modo de planificación con agentes algo que le parece genuinamente nuevo – no tengo datos, solo práctica e intuición, que son cosas distintas y menos fiables, pero son las que tengo.

La trayectoria que veo es esta: los agentes de IA son cada vez más capaces de ejecutar instrucciones complejas de manera fiel. A medida que esa capacidad crece, el valor del plan –del documento que contiene las instrucciones– crece con ella. El cuello de botella se desplaza de la implementación al diseño, del hacer al pensar. Y pensar bien, de forma explícita, colaborativa, y documentada, es exactamente lo que PDD propone.

La próxima vez que abras el modo de planificación con tu agente y el documento empiece a tomar forma –con sus trade-offs, sus decisiones razonadas, sus fragmentos de código– pregúntate si ese plan merecía una segunda opinión antes de ejecutar. Si la respuesta es sí, ya estás practicando PDD. Solo le faltaba el nombre.