Contexto técnico
Me encantan estos textos no por su bella filosofía, sino por su utilidad práctica. En el artículo A sufficiently detailed spec is code, la idea es muy simple: si llevo una especificación a un estado donde se describen las ramas lógicas, los casos límite (edge cases), los errores, las restricciones y el comportamiento esperado, eso ya es casi código. Simplemente está escrito en un lenguaje más humano, no en TypeScript o Go.
Lo veo en la práctica constantemente. Le doy al modelo una tarea vaga como “haz un checkout para un e-commerce” y obtengo un festival creativo de esa LLM en particular. Pero si le doy una especificación densa con contratos de API, estados de la interfaz de usuario, reglas de validación, tiempos de reintento (retry) y estructura de pruebas, la dispersión entre los modelos se reduce drásticamente.
Aquí no hay magia. No es que el modelo se haya vuelto más inteligente de repente, sino que yo eliminé el espacio para la imaginación. Cuando la entrada se parece a un sistema formal, la salida comienza a comportarse casi como un algoritmo determinista.
Esto funciona especialmente bien en tareas in-distribution. Un e-commerce típico, un formulario de CRM, un panel de usuario, una integración con una pasarela de pago... los modelos ya han “digerido” esto millones de veces. Si la especificación es buena, GPT, Claude u otro generador de código a menudo llegan a un resultado más o menos idéntico.
Pero en I+D (R&D) la cosa es más interesante. Tan pronto como la tarea sale de la distribución habitual, como un pipeline no estándar de extracción de señales, un dominio exótico o una lógica multiagente compleja, cualquier ambigüedad en la especificación empieza a costar caro. El modelo completa los vacíos basándose en su experiencia, no en mi intención.
Por eso, desde hace tiempo, trato las especificaciones como un artefacto de desarrollo, no como un papel complementario. Hay que versionarlas, revisarlas y, en ocasiones, probarlas. Y sí, en este esquema, el prompt engineering se convierte gradualmente en una disciplina de ingeniería, no en chamanismo.
¿Qué cambia esto para el negocio y la automatización?
Para el negocio, el principal cambio es este: no gana quien tiene “el modelo más inteligente”, sino quien tiene los requisitos mejor empaquetados. Si un equipo tiene una definición de tareas deficiente, ninguna nueva LLM los salvará. Simplemente generará una incertidumbre costosa.
La implementación de la inteligencia artificial en el desarrollo a menudo se rompe aquí. Todos miran los benchmarks, pero deberían mirar la calidad de las especificaciones, los contratos y los criterios de aceptación. Es más aburrido que una demostración de autogeneración, pero es precisamente ahí donde se esconde el ROI.
Yo dividiría el efecto así. Para productos típicos, una especificación detallada abarata la automatización con IA: menos iteraciones, menos reescritura manual, más fácil cambiar de modelo sin perder calidad. Para casos complejos de I+D, se convierte en un seguro contra el caos, porque sin ella, un pipeline multi-modelo comienza a desmoronarse.
Pierden los equipos que esperan “lanzar un prompt rápido”. A corto plazo, parece ágil. A largo plazo, se convierte en un caos de soluciones incompatibles, comportamiento inestable y eternas disputas sobre qué es lo que realmente se quería implementar.
En Nahornyi AI Lab, trabajamos mucho en la intersección del desarrollo de soluciones de IA y la ingeniería de producción, y un buen enfoque spec-first realmente ahorra meses. No porque esté de moda, sino porque a través de él es más fácil construir una arquitectura de IA donde varios modelos, herramientas y personas no se estorben mutuamente, sino que se integren en un proceso gestionable.
En resumen, mi conclusión es esta: una especificación detallada no elimina el trabajo de ingeniería, sino que lo traslada a un punto más temprano. Pero a cambio, facilita la integración de la inteligencia artificial, el cambio de modelos y el mantenimiento de la calidad bajo control sin una lotería constante.
Este análisis fue escrito por mí, Vadym Nahornyi de Nahornyi AI Lab. Me dedico a la automatización con IA de forma práctica: diseño pipelines, construyo escenarios con agentes y compruebo dónde termina la magia de las LLM y comienza la ingeniería de verdad. Si quieres discutir tu proyecto y entender cómo simplificar la implementación de IA sin caos, escríbeme y analizaremos tu caso juntos.