# La spec es la fuente. El prompt es desecho del build. En una base de código que escribe un agente, ¿cuál es el 'código fuente'? No el código generado: eso ahora es salida del build, como un binario compilado. Y tampoco el prompt: eso es un fósforo que enciendes para arrancar el build y luego tiras. Lo duradero, lo que escribes, posees, versionas y revisas, es la spec. La jerarquía se invirtió, y la mayoría sigue puliendo justo la parte que debería tirar. - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, specs, methodology - **Source:** https://fedorthinks.com/es/blog/the-spec-is-the-source --- Aquí va una pregunta que suena simple y no lo es, una vez que un agente de IA escribe la mayor parte de tu código: ¿cuál es ahora el _código fuente_? Señala la cosa que es el artefacto real, autoritativo, el-que-tú-editas del proyecto. La mayoría señala el código que generó el agente. Algunos señalan el prompt. Ambos están equivocados, y la distancia entre la respuesta correcta y esas dos es todo el cambio que vale la pena entender. Ya [escribí antes](/blog/specs-are-the-artifact) que la spec, y no el prompt, es el artefacto sobre el que deberías razonar. Un año de esto convirtiéndose en una industria solo ha afilado la afirmación. No es solo que la spec sea _un_ artefacto. Es que la spec es ahora **la fuente** — y las dos cosas que por instinto agarras, el código y el prompt, han quedado ambas degradadas por debajo de ella. ## La vieja jerarquía: el código era la verdad Durante toda la historia del software, el código fuente fue la fuente de la verdad. Era lo duradero que escribías a mano, que poseías, que ponías bajo control de versiones, que revisabas línea por línea y sobre lo que discutías. La documentación y los comentarios eran secundarios — descripciones _del_ código, con permiso para desviarse, nunca la autoridad. Cuando los docs y el código no coincidían, ganaba el código, porque el código era real y los docs eran un relato sobre él. Esa jerarquía se está invirtiendo, y tiene nombre. ## El giro: la spec es la fuente, el código es la salida del build El **spec-driven development (desarrollo guiado por especificación)** — la metodología de la que cada herramienta importante de codificación con IA lanzó su propia versión en 2025–26 — convierte a [una especificación escrita y bajo control de versiones en la única fuente de la verdad, y trata al código como una salida generada](https://thebcms.com/blog/spec-driven-development). Escribes la spec — qué hace el sistema y por qué —, derivas un plan, lo divides en tareas, y el agente genera el código a partir de ella. La spec es el artefacto que editan los humanos; el código es lo que emite el build. La analogía a la que el campo recurre una y otra vez es exactamente la correcta: [la spec es la fuente del mismo modo que un archivo .c es la fuente, y el código es el binario al que compila](https://www.augmentcode.com/guides/what-is-spec-driven-development). No editas a mano un binario compilado; editas la fuente y recompilas. En el spec-driven development el [código generado es el binario](https://www.morphllm.com/spec-driven-development) — tampoco lo parcheas a mano, porque en el momento en que lo haces, queda desincronizado de la fuente que se supone que lo define. Cambias la spec y regeneras. Esto ya no es una idea marginal. El [Spec Kit](https://www.marktechpost.com/2026/05/08/meet-github-spec-kit-an-open-source-toolkit-for-spec-driven-development-with-ai-coding-agents/) de GitHub superó las 90,000 estrellas y soporta más de 29 agentes; AWS Kiro es un IDE construido por completo a su alrededor; Cursor, OpenSpec, Tessl y los demás lanzaron todos su propio sabor. Alguien incluso lo llamó la [quinta generación de la programación](https://medium.com/google-cloud/spec-driven-development-54cdf7e0b088). Todo el mundo del tooling convergió en la misma inversión a la vez. ## Por qué es correcto, no solo una moda La razón por la que esto funciona es la misma por la que compilar desde la fuente funciona: razonas y haces cambios al nivel de la _intención_, y dejas que el build produzca el artefacto. El spec-driven development [surgió específicamente como el antídoto contra el "vibe coding"](https://thebcms.com/blog/spec-driven-development) — darle prompts a un agente hasta llegar a un montón de código plausible que se desvía de lo que querías decir, alucina una API y se pudre a medida que crece. Ancla el build a una intención escrita y la desviación tiene algo contra qué medirse. Y rinde. GitHub reporta que los equipos que usan Spec Kit lanzan funciones con aproximadamente [un orden de magnitud menos de ciclos de "regenerar desde cero"](https://www.fundesk.io/spec-driven-development-github-spec-kit-guide) que el prompting improvisado; AWS documenta [funciones de 40 horas lanzadas en menos de 8 horas](https://www.morphllm.com/spec-driven-development) de tiempo humano cuando se escriben con la spec primero. Eso no es una eficiencia pequeña — es lo que pasa cuando dejas de editar el binario a mano y empiezas a poseer la fuente. ## Entonces, ¿qué es el prompt? Esta es la parte que reencuadra todo. Si la spec es la fuente y el código es la salida del build, el prompt ni siquiera está en la jerarquía de las cosas que conservas. **El prompt es desecho del build** — la orden transitoria que emites para arrancar una generación, como la línea de shell que escribes para correr `make`. No pones tu invocación de `make` bajo control de versiones ni la revisas en un pull request; versionas el Makefile y la fuente, y el comando es solo cómo arrancaste el build esa vez. Por eso obsesionarse con la redacción del prompt siempre fue apuntar al blanco equivocado — el mismo punto que hice cuando argumenté que [la ingeniería de prompts está muerta](/blog/prompt-engineering-is-dead). Los equipos pulen la redacción de algo desechable mientras invierten de menos en la spec, que es la cosa sobre la que deberían trabajar, versionar y revisar. Están corrigiendo el fósforo e ignorando el plano. ## Cómo se ve en la práctica Así es como construyo, sin más. La spec es el artefacto sobre el que de verdad trabajo — la cosa que redacto, sobre la que discuto conmigo mismo, que pongo bajo control de versiones y que reviso como si importara, porque es la parte que sí importa. El agente genera el código a partir de ella. Si el código está mal, casi nunca parcheo el código; arreglo la spec y regenero, porque parchear la salida a mano es editar el binario y desincronizarse de la fuente. ¿Y el prompt que impulsó una generación dada? Desaparecido al día siguiente. Nunca lo vuelvo a mirar, porque era desecho — la cosa que enciendes para arrancar el build, no la cosa que conservas. Así que la pregunta con la que abrí tiene ahora una respuesta limpia. El código fuente de un sistema construido con IA es la spec. El código es lo que el build emite a partir de ella. El prompt es el fósforo que enciendes y luego tiras. Escribe la spec como si fuera la fuente — porque es exactamente en lo que se convirtió.