SPDD en martinfowler.com: lo que mi flujo con opsx no tenía
Uso SDD con opsx para estructurar cambios antes de implementarlos. Pero el artículo de Fowler sobre SPDD me mostró el gap: los prompts como artefactos gobernados. Esto es lo que propone, qué me faltaba, y la idea que más me cambió la perspectiva.
Problema
Cuando me pasaron el artículo de martinfowler.com sobre Structured-Prompt-Driven Development (https://martinfowler.com/articles/structured-prompt-driven/), no esperaba encontrar mi propio flujo de trabajo descrito en cada sección. Yo uso SDD con opsx — un workflow donde los cambios se diseñan antes de implementarse, con contexto, restricciones y tareas explícitas. Pero la parte de los prompts como artefactos gobernados, eso no lo tenía. Lo que hacía era estructurar el qué y el cómo, pero el prompt que termina llegando al modelo quedaba implícito. El gap real: prompts implícitos, sin trazabilidad entre intención e implementación.
Solución
SPDD plantea que el problema con LLMs en equipos no es el modelo — es que los requisitos ambiguos escalan directo a defectos en producción. La solución es el canvas REASONS: un prompt estructurado en siete dimensiones agrupadas en tres niveles. Abstract parts — intent & design: R — Requirements: qué problema resolvemos y cuál es la definición de done. E — Entities: entidades de dominio y sus relaciones. A — Approach: la estrategia de cómo vamos a cumplir los requisitos. S — Structure: dónde encaja el cambio en el sistema. Specific parts — execution: O — Operations: descomponer la estrategia abstracta en pasos concretos. Common standards parts — governance: N — Norms: convenciones de ingeniería (naming, observabilidad). S — Safeguards: límites no negociables (invariantes, performance, seguridad). El principio clave: 'When reality diverges, fix the prompt first — then update the code.' Yo hacía lo opuesto. Lo que voy a incorporar: formalizar los prompts de cada tarea como artefactos explícitos dentro del flujo de opsx.
Aprendizaje
'Software development isn't a contest of model IQ. It's a contest of engineer cognitive bandwidth — how clearly we can think, frame problems, and make decisions.' El cuello de botella no es el modelo. Somos nosotros, y qué tan bien articulamos el problema antes de delegarlo. SPDD no es una forma de usar mejor la IA — es una forma de pensar mejor antes de usarla. El artículo es honesto: SPDD no es para todos los contextos. Brilla con trazabilidad para auditorías o equipos que necesitan consistencia. No funciona bien en dominios mal definidos.
TL;DR
SPDD trata los prompts como artefactos gobernados, no como texto desechable. Yo usaba SDD con opsx para estructurar cambios, pero el prompt final quedaba implícito. El artículo de Fowler pone nombre al gap y da un framework concreto: el canvas REASONS. La idea que me quedó: el cuello de botella no es el modelo, es qué tan bien articulamos el problema antes de delegarlo.