El fin de la era de los prompts: por qué el futuro del desarrollo con IA pertenece a quienes escriben especificaciones (SDD)
El fin de la era de los prompts: por qué el futuro del desarrollo con IA pertenece a quienes escriben especificaciones (SDD)
En el último evento en el que participé con una charla, hice levantar la mano al público tres veces: quién había probado alguna vez el vibe coding, quién había generado un proyecto entero a base de prompts y café, y quién, finalmente, había tirado todo y lo había vuelto a escribir desde cero. Las manos se levantaron casi al unísono y, casi siempre, eran las mismas personas las tres veces.
Rostros desconsolados, casi resignados a tener que reescribir algo que parecía perfecto después de los primeros días de desarrollo. Parecía, de hecho.
La realidad, sin embargo, es muy diferente de la que se cuenta a base de burlas y titulares clickbait. La verdad es que dejar a una IA sin control es como darle un rotulador a un niño y salir de la habitación, convencidos de que ese papel que le has dado servirá para crear una obra maestra y no para ser reducido a un puñado de confeti, como realmente ocurrirá.
La culpa es (en parte) de un tweet
Si buscas un culpable, el nombre más citado es Andrej Karpathy. Cofundador de OpenAI, exresponsable de Autopilot en Tesla y hoy en Anthropic: Karpathy es alguien que sabe bastante sobre modelos de lenguaje. En enero de 2023 tuiteó que "el nuevo lenguaje de programación más de moda es el inglés". El tuit alcanzó millones de visualizaciones y desató titulares apocalípticos para quienes escriben código. Dos años después, redobló la apuesta y acuñó el término "vibe coding": aceptas todo lo que genera la IA, ya no lees los diffs, pegas los errores sin comentarlos y pides cambios al azar hasta que el bug desaparece. Lo decía sonriendo, refiriéndose a proyectos desechables de fin de semana, pero medio Internet se lo tomó como una metodología de trabajo seria.
Este enfoque recuerda a una famosa frase del director italiano Nanni Moretti en "Ecce Bombo": "faccio cose, vedo gente" ("hago cosas, veo gente"). Parece muy productivo, hasta que alguien te pregunta qué has construido realmente.
Luego está lo que podríamos llamar la "pereza del Siguiente, Siguiente, Siguiente": ¿cuánto placer sientes cuando instalas un software haciendo clic en "Siguiente" repetidamente, sin tener que responder a ninguna pregunta? En el vibe coding ocurre lo mismo: escribimos un prompt mal redactado —del tipo que nuestra maestra de primaria nos habría roto en la cara— pero el modelo, entrenado con billones de parámetros, entiende e interpreta todo correctamente.
El mito del zero-to-prod
El vibe coding funciona de maravilla en las demostraciones en línea, donde la IA se comporta como un desarrollador senior fullstack capaz de resolver todo en cinco minutos. El problema surge cuando se aplica al software de gestión legacy de una empresa real: cien mil líneas de código escritas por personas que, mientras tanto, han cambiado de trabajo. En ese contexto, la IA deja de parecer senior y empieza a parecerse a un becario hiperactivo en su primer día de café gratis: ese que, presa del pánico, intenta solucionar los bugs comentando líneas de código al azar solo para demostrarte que "compila". Y tú te quedas ahí mirando la pantalla, preguntándote por qué aceptaste esa pull request.
La razón es técnica y tiene un nombre preciso: context rot. Cuantos más tokens entran en la ventana de contexto, menos fiable se vuelve la respuesta del modelo. A medida que el chat se alarga, el sistema olvida las decisiones tomadas al principio e ignora las restricciones establecidas diez mensajes antes. ¿Cuántas veces has querido darle un puñetazo al monitor cuando el modelo, por enésima vez, empezó a incluir esa librería que le habías dicho explícitamente que no incluyera, o se empeñó en crear variables en camelCase cuando todo el programa está configurado en snake_case? Sin una especificación que ancle la conversación, no estás optimizando nada: simplemente estás perdiendo contexto con cada intercambio.
El efecto práctico es un código espagueti nacido de diferentes sesiones de chat: tres conversaciones distintas producen tres formas diferentes de gestionar los errores dentro del mismo proyecto, y ya nadie recuerda cuál es la "correcta".
El peor problema, sin embargo, no es el error evidente que se nota de inmediato. Es la alucinación verosímil: código que parece correcto, supera una revisión superficial y oculta un bug insidioso. El ejemplo que propongo más a menudo es un ficticio Array.shuffle() nativo en JavaScript, que en realidad no existe. El código generado lo invoca con tanta seguridad natural que tu instinto es asentir, pensar "ah, finalmente lo han estandarizado" y dejarlo pasar porque "al fin y al cabo es un caso límite". Luego, el sistema en producción se cae.
Caballo, jinete y arnés
La tesis que sostengo en el escenario no es que el vibe coding esté superado en absoluto, sino que ya es impracticable como enfoque único. Existe una vía para transformar la IA de asistente impredeciible a ejecutor gobernable, y se llama Spec-Driven Development (SDD).
La metáfora del harness engineering (ingeniería de arneses) ilustra la idea mejor que cualquier definición formal: los proyectos basados en IA fracasan en producción por falta de una infraestructura de soporte alrededor del modelo, y no por las capacidades intrínsecas del modelo en sí.
El modelo de lenguaje es como un caballo potente y veloz que no sabe adónde ir por sí solo. El arnés representa el conjunto de restricciones, guardarraíles y ciclos de retroalimentación que dirigen esa energía de forma controlada. En este escenario, quien escribe código es el jinete: indica la dirección y convalida el camino, sin tener que llevar las manos en las riendas a cada paso.
El Spec-Driven Development es una metodología en la que las especificaciones asumen el rol de artefactos ejecutables de primera clase. El flujo se invierte: se redacta primero el contrato y luego se deja que la IA genere el código respetándolo. La síntesis más eficaz se resume en este principio:
El prompt no debe hacer que la IA adivine lo que quieres. La especificación debe decirle exactamente qué ejecutar.
Escribir un contrato que la IA no pueda malinterpretar
La instrucción "Quiero un login seguro" puede ser suficiente para un desarrollador experimentado que ya ha abordado el problema y conoce los estándares de la empresa. Para un agente de IA, en cambio, no basta. Sin detalles precisos, rellenará los huecos con suposiciones, y las hipótesis de un modelo de lenguaje son estadísticamente plausibles, pero no necesariamente correctas. El esquema de especificación que adopto para cada actividad compleja es esencial, ocupa pocas líneas en Markdown y es suficiente para eliminar gran parte de las ambigüedades:
## OBJETIVO
Qué debe hacer el sistema: una línea clara
## NON-GOALS
Qué NO debe hacer (refresh token, OAuth, librerías no aprobadas...)
## RESTRICCIONES
Stack, librerías permitidas, rendimiento esperado
## RESULTADO ESPERADO
- [ ] Criterio de éxito verificable 1
- [ ] Criterio de éxito verificable 2
No se necesitan herramientas propietarias: el formato Markdown es fácilmente legible por el equipo y representa, al mismo tiempo, la lengua materna de los Large Language Models. Si se desea eliminar por completo las ambigüedades del lenguaje natural, se puede recurrir a EARS (Easy Approach to Requirements Syntax), una notazione rigorosa creata da Alistair Mavin in Rolls-Royce nel 2009 per i requisiti dei motori aeronautici. Strutture come "CUANDO [evento] EL sistema dovrà [azione]" associano ogni decisione a un vincolo logico testabile in modo automatico.
Aunque no nació para la inteligencia artificial, esta sintaxis neutraliza el principal punto débil de los agentes autónomos. Una solución ideada para prevenir malentendidos entre seres humanos se ha revelado ideal para regular la comunicación entre el desarrollador y la máquina.
Un caso real: de dos horas de caos a media hora
La diferencia se ve claramente analizando un caso real.
Imaginemos una API en PHP que deja de funcionar tras actualizar a PHP 8.1. Con el enfoque vibe coding, el flujo de trabajo degenera rápidamente: se escribe "ya no funciona", el modelo propone un parche, se responde "sigue sin funcionar", el sistema genera una segunda versión que rompe otro componente, y finalmente una tercera que restaura la primera introduciendo un nuevo bug. ¿El balance? Dos horas perdidas, recursos desperdiciados y ningún registro de los cambios realizados.
Con una especificación mínima, el mismo problema se resuelve en una fracción del tiempo:
## PROBLEMA
API /v2/orders devuelve 500 tras actualizar a PHP 8.1
## CONTEXTO
Error: [log específico] | Archivo: OrderController.php:45-67
## OBJETIVO
Solucionar manteniendo la retrocompatibilidad con el cliente v1
## NO TOCAR
src/Models/* | archivos de migración
## VALIDACIÓN
- [ ] La suite de pruebas pasa
- [ ] La API v1 sigue funcionando
Si una prueba destaca un detalle ausente —como la serialización de las fechas en la zona horaria del servidor en lugar de UTC— la solución no consiste en discutir en el chat. Se actualiza la especificación añadiendo la restricción sobre la zona horaria y se vuelve a ejecutar la tarea. De este modo, el conocimiento queda formalizado y registrado en Git, a disposición de cualquiera que deba volver a tocar ese código en el futuro, en lugar de quedar sepultado en un historial de chat que nadie volverá a abrir.
El desfase entre la documentación y el código fuente es desde siempre una de las principales causas de bugs y regresiones. El Spec-Driven Development resuelve este problema de raíz, transformando la especificación en un contrato indissoluble que guía la evolución del código.
Cuando el enfoque no sirve
Sería ingenuo presentar el SDD como una solución libre de costes. Escribir quince minutos de especificación para un bug que se resuelve en dos minutos es burocrazia, no ingeniería: para las intervenciones más elementales, el vibe coding sigue siendo la opción más lógica. Además, las especificaciones son código a todos los efectos y requieren mantenimiento. Si el software evoluciona mediante hotfixes manuales mientras el contrato queda obsoleto, la especificación se transforma de fuente de verdad en fuente de mentiras. Es necesario un proceso constante de alineación: no basta con redactar el documento una vez y olvidarse de él.
Existe también un riesgo más sutil: una especificación extremadamente precisa pero errónea producirá, con rigor determinista, el software equivocado. El documento de requisitos debe convalidarse con el mismo cuidado reservado al código, ya que no constituye un salvoconducto automático.
El código es un efecto colateral
El verdadero valor del Spec-Driven Development surge en proyectos a medio o largo plazo, o desarrollados en equipo: en estos escenarios, las ventajas se materializan tras unos pocos días, con una reducción drástica de las iteraciones y de los imprevistos.
Se trata de una revolución cultural: el código fuente pasa de ser el producto principal del trabajo al papel de simple artefacto de compilación.
La especificación se convierte en el verdadero activo. Hoy en día, saber redactarla de forma clara, verificable y libre de ambigüedad representa la verdadera ventaja competitiva para quienes quieren gobernar la IA en lugar de sufrirla.
Si tú también has pulsado "Aceptar" tras infinitas sesiones de chat que te habían fundido la corteza cerebral, solo para terminar el trabajo e irte a casa, aprobando una PR con la promesa "lo reviso el lunes"; si tú también formas parte de este grupo, el SDD no resolverá mágicamente todos tus problemas, pero reducirá el número de cafés que tendrás que pagar a tus compañeros por haber perdido la carrera del código con menos errores.