Los Prompts Son Código Fuente Ahora
Tobi Lütke señala que tirar los prompts mientras conservas el código generado por IA es como tirar el código fuente y quedarte con los binarios. Tiene razón, y las implicaciones van más allá del control de versiones.
7 min read
Tobi Lütke —CEO de Shopify— publicó esta observación:
Esta es una de esas observaciones que parecen obvias una vez dichas e invisibles antes. Para herramientas pequeñas especialmente, el prompt es el código fuente. El código es la salida compilada.
La analogía desglosada
Cuando compilas C a un binario, pierdes:
- Legibilidad. El binario funciona, pero buena suerte entendiendo por qué.
- Modificabilidad. ¿Quieres cambiar algo? Estás haciendo ingeniería inversa, no editando.
- Portabilidad. ¿Recompilar para otra arquitectura? No sin el código fuente.
- Intención. Comentarios, nombres de variables, estructura —el porqué— desaparece.
Cuando tiras el prompt que generó tu código de IA, pierdes las mismas cosas:
- Regeneración. El modelo mejora el mes que viene. Podrías obtener mejor código gratis —si tuvieses el prompt.
- Iteración. «Hazlo manejar el caso límite X» es fácil con el prompt original. Partiendo del código generado, estás haciendo arqueología.
- Contexto. ¿Por qué existe esta función? ¿Para qué restricciones se diseñó? El prompt lo sabía. El código no lo dice.
- Transferibilidad. Este prompt funcionó para Claude. Ligeramente modificado, podría funcionar para el próximo modelo. El código generado está congelado en el tiempo.
Esto conecta con qué sigue mereciendo la pena saber en desarrollo asistido por IA. Saber cómo hacer prompts —qué contexto incluir, qué restricciones especificar— se está volviendo más valioso que saber escribir el código en sí. El prompt es donde ocurre el trabajo.
Qué cambia esto
Si los prompts son código fuente, necesitan control de versiones.
No como algo secundario —no una carpeta prompts/ que olvidas hacer commit. Como el artefacto principal. El código que genera es un output de build.
Esto suena extremo hasta que consideras el flujo de trabajo:
- Escribir prompt
- Generar código
- Probar código
- Ajustar prompt
- Regenerar
- Repetir hasta estar satisfecho
¿Dónde está el trabajo? En el prompt. El código es un efecto secundario.
Esto es estructuralmente similar a la inversión de Rust. El compilador estricto de Rust se veía como una barrera cuando los humanos escribían código. Ahora que la IA escribe código, es una ventaja —verificación gratuita. La misma inversión está ocurriendo con los prompts: se veían como inputs efímeros, pero ahora son el artefacto duradero.
Mapa y territorio
Hay una distinción útil de la semántica general: el mapa no es el territorio.
En software, este patrón aparece donde quiera que tengas una capa generativa y su output:
- El mapa: ligero, estructural, captura la intención
- El territorio: rico, específico, el resultado renderizado
Definiciones de esquema y contenidos de base de datos. Configuraciones de build y artefactos compilados. Plantillas y páginas renderizadas.
El mapa es lo que necesitas para regenerar o modificar la estructura. El territorio es lo que lees y usas. Perder el territorio es inconveniente; perder el mapa significa empezar de cero.
Los prompts y el código generado tienen la misma relación:
- Prompts: ligeros, estructurales, generativos
- Código generado: específico, ejecutable, el output
El prompt es el mapa. El código es el territorio. Si solo conservas el territorio, pierdes la capacidad de regenerar cuando las condiciones cambian.
El matiz de «herramientas pequeñas»
El encuadre cuidadoso de Tobi importa: «al menos para herramientas pequeñas».
Para un script de 50 líneas que parsea archivos CSV, el prompt es casi seguramente más valioso que el output. Regenerar desde el prompt lleva segundos. Modificar el prompt para manejar un nuevo formato lleva minutos. El código es efímero.
Para un sistema grande, es más turbio. El prompt que generó tu módulo de autenticación podría ser útil, pero:
- Probablemente has modificado el output a mano
- El código ahora tiene contexto de ejecución que el prompt no conocía
- Los puntos de integración evolucionaron más allá de la generación original
La escala cambia la proporción. Pero no elimina el valor.
El patrón más profundo
Esto conecta con un cambio que sigo notando: el locus del entendimiento se está moviendo.
En el modelo antiguo, el entendimiento vivía en el código. Lo leías para saber qué pasaba. Los comentarios explicaban la intención. La arquitectura revelaba el propósito.
En el modelo nuevo, el entendimiento vive en el prompt —o, más precisamente, en el contexto que proporcionaste. El código es una proyección de ese entendimiento en forma ejecutable. Legible, quizás. Pero no la fuente de verdad sobre la intención.
Esto es parte de por qué leer código está muriendo como guardián. El código está aguas abajo del prompt. Si quieres entender qué pasó, necesitas la cadena de prompts, no solo el diff.
Implicaciones prácticas
Versiona tus prompts. Si estás generando código desde prompts, esos prompts pertenecen a git. No como documentación —como código fuente.
Comenta los prompts, no (solo) el código. ¿Por qué lo pediste de esta manera? ¿Qué alternativas probaste? ¿Qué no funcionó? El prompt es donde esto pertenece.
Trata la regeneración como recompilación. ¿Nuevo modelo? Regenera. ¿Encontraste un mejor enfoque? Regenera. El coste es bajo. El beneficio es compuesto.
Construye bibliotecas de prompts. Igual que construirías funciones de utilidad, construye prompts reutilizables. «Parsea este formato.» «Maneja estos casos límite.» «Escribe tests en este estilo.» Entendimiento componible.
Verificaciones de realidad
Este análisis podría estar equivocado de varias maneras:
El primer output es el output final. Si la IA se vuelve tan buena que no iteras —si la primera generación es siempre correcta— entonces los prompts dejan de importar. Tampoco guardarías inputs intermedios del compilador si la compilación fuese instantánea y perfecta.
El código se vuelve autoexplicativo. Si la IA genera código con suficientes comentarios y contexto para que la intención sea obvia, el prompt se vuelve redundante. El binario incluye el código fuente, efectivamente.
El flujo de trabajo no se generaliza. Quizás la mayoría de la gente no itera sobre prompts como describí. Quizás escriben una vez, aceptan el output y siguen adelante. En ese caso, guardar prompts es overhead sin beneficio.
Las herramientas nunca se materializan. Git funciona para prompts, pero herramientas especializadas (versionado de prompts, visualización de diffs, seguimiento de cadenas) podrían no llegar nunca. Sin herramientas, la práctica sigue siendo de nicho.
Si trabajas de forma diferente y crees que me he perdido algo, me gustaría saberlo.
La conexión con la herencia
Hay una versión de esta observación que se extiende más allá del código.
Cuando trabajo con asistentes de IA entre sesiones, los documentos de contexto que mantengo —qué pasó, qué decidimos, por qué— sirven la misma función que los prompts guardados. Una nueva sesión puede regenerar entendimiento desde esos documentos. Sin ellos, cada sesión empieza en frío.
El patrón es general: la capa generativa persiste; el output está aguas abajo.
- Los prompts generan código
- Los documentos de contexto generan instancias orientadas
- El mapa genera el territorio
En cada caso, tirar la capa generativa mientras conservas el output es tirar el código fuente y quedarte con el binario. El output funciona, pero has perdido la capacidad de regenerar, modificar o entender.
La versión mínima
Si estás usando IA para escribir código:
- Guarda tus prompts en algún sitio
- Ponlos en control de versiones
- Cuando revisites código que no entiendes, comprueba si hay un prompt
Eso es todo. No se requieren herramientas nuevas. Solo el reconocimiento de que ahora tienes dos artefactos, y solo uno de ellos es verdaderamente código fuente.
Escrito en enero de 2026. El código fue fácil. El prompt llevó más tiempo.