Durante los últimos meses, gran parte de la conversación sobre desarrollo de software con la IA ha girado alrededor de lo mismo: mejores prompts, mejores trucos, mejores formas de darle contexto al modelo, pero creo firmemente que el futuro del desarrollo con IA no pasa por aquí sino por tener un verdadero sistema operativo que de autonomia a los agentes sin quitarnos control en el desarrollo.
Y sí, todo lo que se habla hoy en día ayuda y mucho. Sería absurdo negarlo.
Pero cada vez tengo más claro que estamos poniendo el foco en el sitio equivocado.
No creo que el gran cuello de botella del desarrollo con IA sea que todavía no sepamos promptar lo bastante bien.
Creo que el verdadero problema es otro: seguimos intentando desarrollar software sin un sistema real alrededor de la IA. En cierto modo y de diferentes formas, las prácticas de hoy en día, en general, no dejan de ser evoluciones del Vibe Coding, algunas aportan enormes beneficios, otras no tanto, pero ¿realmente son útiles en proyectos reales?
Para cierto tipo de proyectos son suficientes, pero para otros se nota demasiado la falta de un sistema, y esto se hace más evidente cuanto más grande y complejo se vuelve un sistema y es especialmente doloroso si queremos gobernar de verdad el desarrollo de nuestro producto.
El prompting funciona. Hasta que deja de funcionar.
No voy a despreciar el prompting. Sería una tontería. El prompting ha abierto una puerta enorme. Permite explorar ideas rápido, iterar con agilidad, construir cosas útiles en poco tiempo y reducir muchísimo la fricción de arranque.
El problema es que hay una diferencia enorme entre hacer que algo salga y construir algo que de verdad se pueda sostener.
Cuando el sistema es pequeño, cuando el alcance es corto o cuando el objetivo es explorar, el flujo conversacional funciona muy bien. Pero en cuanto la complejidad sube, empiezan a aparecer síntomas bastante reconocibles:
- el contexto se vuelve frágil;
- las decisiones se diluyen entre mensajes;
- el sistema depende demasiado de cómo formules cada petición;
- la coherencia empieza a resentirse;
- y lo que parecía velocidad empieza a generar retrabajo.
Entonces entras en ese bucle que ya conocemos: prompt → corrección → nuevo prompt → ajuste → parche
Y sí, avanzas. Pero no siempre estás construyendo sobre una base estable. Muchas veces simplemente estás empujando el sistema hacia delante.
El “vibe coding” tiene sentido, pero no creo que sea el destino final
La popularización del llamado vibe coding me parece una señal clarísima de la etapa en la que estamos. Hablas con la IA, pruebas, corriges, iteras, rehaces, vuelves a pedir. La barrera de entrada cae, el desarrollo se vuelve mucho más inmediato y la sensación de fluidez es brutal. Incluso ya aparece descrito así en algún medio del sector.
Es lógico que haya atraído tanta atención. Pero también creo que deja al descubierto su propio límite.
El vibe coding funciona muy bien cuando la conversación puede sostener el sistema. El problema aparece cuando la conversación deja de ser suficiente para gobernarlo.
Porque en ese punto empiezan a pesar otras cosas:
- qué decisiones siguen vigentes;
- qué parte del sistema manda realmente;
- qué está definido y qué no;
- cómo validas que no te has desviado;
- y cómo mantienes continuidad sin depender del último intercambio con el modelo.
Ahí es donde, en mi opinión, el prompting puro empieza a quedarse corto.
No porque no sea útil, sino porque no debería seguir siendo el mecanismo principal de control.
La industria ya está dando señales bastante claras
Lo interesante es que esta sensación no sale solo de intuición personal. Cuando miras con algo de distancia hacia dónde se están moviendo las herramientas, los grandes actores y los patrones emergentes, el dibujo empieza a ser bastante coherente.
Por un lado, cada vez hay más foco en agentes, workflows, skills, herramientas y trazas de ejecución. OpenAI, Anthropic y otros, por ejemplo, está empujando una idea bastante clara: las skills funcionan mejor cuando forman parte de la configuración normal del repositorio, AGENTS.md dirige workflows y el sistema combina partes deterministas con partes contextuales.
Por otro, GitHub está empujando el enfoque spec-driven. Su Spec Kit se presenta precisamente como una forma de trabajar con agentes de código desde una estructura guiada por especificación, alejándose de “vibe coding every piece from scratch”. Además, GitHub está dando mucha importancia a los archivos agents.md dentro del repo y publicó una guía basada en el análisis de más de 2.500 repositorios para explicar cómo escribirlos bien.
Y además hay otro dato interesante: aunque el tooling avance muchísimo, la delegación total todavía está lejos. En su informe de tendencias de 2026, Anthropic recoge que los equipos reportan poder “delegar completamente” solo una fracción pequeña de las tareas, y que el uso efectivo sigue requiriendo preparación, supervisión, validación y juicio humano.
Visto en conjunto, a mí me sugiere una cosa bastante clara:
la industria está empezando a salir del prompting como interfaz principal y a moverse hacia sistemas más gobernados.
No digo que el prompting desaparezca. No va a desaparecer. Lo que digo es que puede dejar de ser el centro.
El problema ya no es generar código
Hace no tanto, el gran asombro era que la IA pudiera generar código razonable. Ese asombro ya está amortizado.
Hoy el problema importante no es ese. Hoy el problema es otro: cómo hacer que lo generado mantenga coherencia, continuidad, trazabilidad y sentido dentro de un producto real.
Porque una cosa es producir código. Y otra muy distinta es construir software que:
- no se descomponga con cada iteración;
- no dependa de recuerdos difusos;
- no acumule decisiones implícitas imposibles de seguir;
- y pueda evolucionar sin convertirse en una maraña.
Ahí ya no basta con “pedir mejor”. Ahí necesitas algo más.
“El código es la verdad”… hasta cierto punto
Aquí suele aparecer un argumento bastante habitual:
“No pasa nada si el prompting es caótico, porque al final el código es la fuente de verdad”.
Y en cierto modo, es verdad.
El código que has desarrollado es una forma de verdad. Representa lo que el sistema hace en este momento. Lo que ya existe. Lo que ya se ha implementado. Pero hay un matiz muy importante que creo que estamos pasando por alto:
El código no representa la intención. Representa únicamente lo que ya ha sido implementado.
Y esa diferencia cambia mucho las cosas.
Porque si usas el código como única verdad, lo que tienes es una fotografía de la ejecución, no una representación clara de por qué ese comportamiento existe, qué necesidad lo originó, qué reglas lo condicionaban o qué límites debía respetar.
El código te dice qué hace el sistema. No necesariamente te dice qué se pretendía construir.
El problema de usar el código como única referencia real
Cuando el código se convierte en la única verdad fuerte, pasan varias cosas.
Pierdes el rastro de por qué se tomó cada decisión. La intención original se va diluyendo. El comportamiento se interpreta a posteriori. Y cada cambio nuevo empieza a apoyarse más en “lo que parece que hace el sistema” que en “lo que el sistema debería hacer”.
En entornos tradicionales esto ya era un problema.
Con IA, se amplifica.
Porque si el desarrollo está guiado principalmente por prompting, gran parte de la intención vive en mensajes efímeros:
- mensajes no estructurados;
- mensajes que no forman una base estable;
- mensajes que no están pensados para gobernar el sistema a medio plazo.
Entonces acabas en una situación delicada:
- la intención vive en el prompt;
- la implementación vive en el código;
- y entre ambas cosas no siempre existe una capa estable que conecte una con otra.
Y ahí es donde la continuidad empieza a romperse. Creo que el corto y medio plazo, el futuro del desarrollo con la IA debe huir de esta práctica si queremos disponer de sistemas mantenibles y escalabales.
El código no debería ser el punto de partida
Para mí, el código debería ser una consecuencia.
Una materialización.
Una ejecución.
Un resultado.
Pero no debería ser el punto de partida ni la única fuente de verdad a la que volver constantemente para reconstruir el sentido del sistema.
Porque cuando eso pasa, el proceso se invierte:
en lugar de implementar una intención,
acabas deduciendo la intención a partir de lo implementado.
Y eso, a medida que el sistema crece, hace que cada cambio sea más difícil de justificar, más difícil de validar y más difícil de gobernar.
El futuro del desarrollo con IA pasa por mover el control fuera del prompt
Cada vez veo más claro que el cambio importante no está en pasar de prompt mediocre a prompt excelente.
El cambio importante está en pasar de esto:
el prompt dirige el desarrollo
a esto otro:
el sistema dirige el desarrollo, y el prompt solo expresa intención
Ese matiz cambia mucho más de lo que parece.
Porque en ese modelo el prompt deja de cargar con todo el peso. Ya no tiene que contener contexto, normas, decisiones, restricciones, estado, estructura y objetivo al mismo tiempo. Parte de ese peso pasa a vivir donde, en el fondo, siempre debería haber vivido: en el propio sistema de trabajo.
No en la conversación.
En el proyecto.
El repositorio no debería ser solo un sitio donde guardar cosas
Creo que aquí está una de las ideas que más me interesan ahora mismo.
Si la IA va a participar de verdad en el desarrollo, el repositorio no puede seguir siendo simplemente un sitio donde hay código, algunas notas, documentación dispersa y contexto más o menos implícito.
Tiene que empezar a comportarse como algo más parecido a un entorno operativo.
Un lugar donde esté definido, con suficiente claridad:
- qué artefactos mandan;
- qué reglas existen;
- qué información es base y cuál no;
- cómo se avanza;
- cuándo se puede ejecutar algo;
- y cómo se comprueba que el resultado sigue alineado con la intención original.
Dicho de otra manera: la IA no debería trabajar solo “hablando con nosotros”.
Debería trabajar dentro de un sistema que ya sabe cómo debe operar.
Reducir el prompting no significa perder control
De hecho, creo que significa lo contrario.
Reducir prompting no es dejar a la IA hacer lo que quiera. No es soltarla. No es vaciar el proceso.
Es mover el control a un sitio mejor.
- del mensaje puntual a la estructura persistente;
- de la conversación a los artefactos;
- del contexto improvisado a un marco más estable;
- del “a ver si me entiende” al “el entorno ya le marca cómo debe actuar”.
El prompt sigue ahí, claro. Pero cambia de papel.
Deja de ser el volante principal y pasa a parecerse más a esto:
- intención;
- activación;
- decisión;
- confirmación.
Y eso, al menos para mí, es un cambio profundo. Es el camino que debe toma el futuro del desarrollo con IA.
Hay una observación práctica que me parece demasiado interesante como para ignorarla
No tengo todavía una demostración formal de nada. No tengo evidencia fuerte ni resultados cerrados que me permitan afirmar grandes conclusiones.
Pero sí tengo una observación práctica que me parece lo bastante relevante como para tomarla en serio.
En algunos experimentos tempranos he probado a trabajar moviendo el contexto y las reglas fuera del prompt, apoyándome más en la estructura alrededor del sistema y reduciendo la interacción al mínimo.
Hasta el punto de que, en algunos momentos, la comunicación con la IA se acercaba muchísimo a una pura indicación de intención, casi con monosílabos.
Y lo que me llamó la atención no fue “qué bien responde el modelo”, sino otra cosa:
el resultado dependía menos de cómo formulaba el prompt y más del sistema que tenía montado alrededor
No digo que eso pruebe nada por sí solo.
Pero sí me parece una señal prometedora. Porque sugiere que, quizá, estamos sobrevalorando el prompting como mecanismo principal y subestimando hasta qué punto un buen sistema puede absorber gran parte de ese trabajo.
Esto no hace que los primeros resultados lleguen antes. Pero sí puede acelerar el proyecto de verdad.
Aquí conviene ser preciso.
Este enfoque no hace que el primer resultado aparezca antes. De hecho, normalmente ocurre lo contrario.
Los primeros avances tardan más, porque estás invirtiendo antes en estructura, contexto, reglas y base operativa. Frente al flujo conversacional puro, eso puede parecer una desventaja al principio.
Y lo es, si solo miras el arranque.
Pero creo que hay que mirar más lejos.
Porque si el objetivo no es sacar una demo rápida, sino construir un producto robusto, mantenible y escalable, esa inversión inicial puede hacer que el recorrido completo sea mucho más eficiente.
Mi intuición, y por ahora solo la presento así, es esta:
- puede ser claramente más rápido que el desarrollo tradicional;
- y en el global del proyecto también puede llegar a ser más eficiente que el vibe coding o que el prompting conversacional puro;
- no porque te dé resultados antes, sino porque reduce mucha fricción posterior: retrabajo, deriva, pérdida de continuidad, decisiones incoherentes y correcciones acumuladas.
Es decir: llegas más tarde al primer resultado, pero puedes llegar antes al producto serio.
Y eso, para cierto tipo de software, importa bastante más.
Lo que me interesa no es “cómo hacer mejores prompts”, sino cómo dejar de depender tanto del prompting
Ahí, para mí, está el centro de esta idea.
No creo que el prompting desaparezca.
No creo que deje de ser útil.
No creo que haya que renunciar a él.
Lo que sí creo es que no debería seguir siendo el eje principal sobre el que descansa todo el desarrollo con IA.
Porque si queremos construir software real, no solo generar artefactos o iteraciones rápidas, necesitamos algo más sólido que una conversación bien llevada.
Necesitamos sistema.
Mi tesis, a día de hoy sobre el futuro del desarrollo con IA
Creo que estamos entrando en una transición bastante importante.
Del:
desarrollo dirigido principalmente por prompts
al:
desarrollo gobernado por sistemas donde la IA opera con mucha menos dependencia del prompting
Y en ese cambio, el valor no estará solo en tener mejores modelos.
Entonces, el futuro del desarrollo con IA estará también en tener mejores entornos, mejores artefactos, mejores reglas de operación y mejores formas de convertir intención en ejecución sin que todo dependa del último mensaje del chat.
No creo que el problema sea que todavía no sepamos escribir buenos prompts. Creo que el problema es que seguimos intentando construir software serio con una interfaz que, en el fondo, sigue estando pensada sobre todo para conversar.
Y quizá la pregunta más importante ya no sea:
“¿cómo puedo hacer mejores prompts?”
Sino esta otra:
¿qué sistema necesito para que mis prompts dejen de ser el centro del desarrollo de mis proyectos con IA?
Por tanto en el corto plazo, el futuro del desarrollo con IA debe pasar por independizarnos del prompt como unidad de trabajo y relegar su papel a la expresión de nuestra intención, delegando el desarrollo en un verdadero sistema gobernable que nos permitar mantener el control sobre nuestro producto.