Tres formas de dar instrucciones a un agente de programación: especificación, modelo de producto o revisión con ojos nuevos

Un agente de programación que entrega lo que no era normalmente entendió la petición y malinterpretó el producto. La pregunta interesante a finales de 2026 ya no es qué agente usar, sino cómo darle las instrucciones, y han surgido tres respuestas distintas. Difieren en una cosa: qué dejas por escrito y cuánto tiempo vive.

Guiado por especificaciones: un documento por cambio

El enfoque más adoptado escribe una especificación para cada funcionalidad, después un plan y una lista de tareas, y hace que el agente construya a partir de ellos. Spec Kit (4,3) es la versión de GitHub, con unas 143.000 estrellas y un paso de convergencia que contrasta la implementación con los documentos; es compatible con más de 40 agentes concretos. BMAD-METHOD (3,8) cubre un terreno parecido con un reparto de personajes. Su fuerza es que el contrato vive en git y pasa por pull requests como el código. El coste es el tiempo de lectura: la prueba publicada por Scott Logic situó la revisión humana en aproximadamente dos a tres horas y media por funcionalidad, y por eso ambas herramientas incluyen vías más ligeras para arreglos pequeños.

Guiado por el producto: un modelo permanente

Una escuela más reciente sostiene que una especificación describe el cambio, no el producto, de modo que el producto se reconstruye una y otra vez desde cero. pdd-kit (3,7) mantiene un único modelo de producto versionado en git, con entidades, recorridos, reglas de negocio y variaciones, que todos los agentes leen en lugar de adivinar, con un paso de verificación que contrasta el código con él. Es una idea más afinada que una carpeta de especificaciones, pero está en una fase temprana: unas 97 estrellas y un solo mantenedor, y un modelo que se queda atrás respecto al código confunde más a los agentes que no tener ningún modelo. Compensa en productos con una complejidad de dominio real, no en una aplicación CRUD.

Primero la revisión: que unos ojos nuevos encuentren los agujeros

El tercer enfoque acepta que el agente que redacta no verá sus propios puntos ciegos, e introduce un revisor que nunca vio la conversación. Elephant-Goldfish Model (4,2), un plugin de código abierto de Google, redacta un diseño con un agente con contexto profundo (el Elephant) y después se lo pasa a subagentes sin contexto (los Goldfish) que solo leen el documento y las fuentes que cita. Como no pueden apoyarse en el chat que produjo el diseño, sacan a la luz las suposiciones no explícitas. El método está bien argumentado y ya tiene unas 6.500 estrellas; la pega es que necesita un entorno capaz de lanzar subagentes nuevos, y se detiene en lugar de simular una revisión cuando no puede hacerla.

Dónde encajan los paquetes de flujo de trabajo

Junto a estos están los instaladores de flujos de trabajo generales como Superpowers (4,7), que dan al agente hábitos de planificación y autocomprobación sin imponer un formato de especificación. Se combinan con cualquiera de los tres estilos de instrucciones en lugar de competir con ellos, y son el punto de partida que menos esfuerzo exige.

Cuál usar

Para un arreglo de una línea, nada de esto: ganan git, las pruebas y un prompt corto que nombre los archivos. Para una funcionalidad que necesita decisiones de diseño antes del código, empezar por la revisión detecta más fallos reales con menos escritura, siempre que tu agente admita subagentes. Para un cambio regulado que un auditor leerá más adelante, el rastro documental del enfoque guiado por especificaciones es precisamente lo que importa. Y para un producto complejo en el que los agentes no paran de reinventar las mismas reglas, un modelo de producto compensa su mantenimiento, si, y solo si, alguien lo mantiene al día.