Del Qúe al Cómo
Una mirada diferente a la verdadera diferencia entre Vibe Coding y Desarrollo Asistido por Inteligencia Artificial.
Durante los últimos meses he visto una idea repetirse una y otra vez en conversaciones sobre Desarrollo Asistido por IA.
Cuando alguien menciona el Vibe Coding, rápidamente aparecen respuestas como: “yo no hago Vibe Coding”, “yo reviso todo el código que genera la IA”, “yo entiendo lo que está haciendo” o “yo corrijo los errores antes de aceptarlo”. La conclusión implícita suele ser que la capacidad de revisar y comprender el código generado hace que deje de ser Vibe Coding.
No estoy convencido de que esa sea la diferencia real.
De hecho, creo que estamos observando el problema desde el lugar equivocado. La discusión suele centrarse en lo que ocurre después de que la IA genera una solución, cuando la verdadera diferencia aparece mucho antes, incluso antes de que se escriba la primera línea de código.
Cuando la decisión ya fue tomada
Cuando las personas argumentan que no hacen Vibe Coding porque revisan, corrigen o entienden el código generado por la IA, están poniendo el foco en una etapa muy específica del proceso: la validación. Todas esas actividades ocurren después de que la IA ya produjo una solución.
Para cuando llegamos a revisar el resultado, gran parte de las decisiones importantes ya fueron tomadas. La arquitectura fue propuesta, los patrones fueron seleccionados, las dependencias fueron escogidas y existe una estrategia concreta para resolver el problema. Lo que estamos haciendo en ese momento no es diseñar la solución, sino evaluarla.
Y no me malinterpreten: esa evaluación tiene valor. Entender el código sigue siendo importante. Corregir errores sigue siendo importante. Incluso rechazar una solución propuesta por la IA es una habilidad valiosa. Lo que cuestiono es que esas capacidades sean suficientes para distinguir el Desarrollo Asistido por IA del Vibe Coding.
Porque no responde la pregunta que realmente importa:
¿Quién decidió CÓMO resolver el problema?
El problema del QUÉ
La mayoría de los prompts que solemos asociar con Vibe Coding tienen algo en común: describen con bastante claridad el resultado esperado, pero dicen muy poco sobre el camino para llegar a él.
Queremos una aplicación. Queremos una pantalla. Queremos una API. Queremos una integración. Sabemos qué problema queremos resolver y qué resultado esperamos obtener. El foco está puesto en el destino.
Hasta allí todo parece razonable. Después de todo, definir objetivos es una parte importante del trabajo. El problema aparece cuando asumimos que definir el resultado es suficiente y dejamos que la IA tome todas las decisiones restantes.
En ese escenario, el QUÉ sigue perteneciendo al humano, pero gran parte del CÓMO pasa a manos de la IA. Es ella quien propone la arquitectura, selecciona patrones, organiza componentes, decide estructuras de datos y establece la estrategia de implementación. Nosotros simplemente evaluamos el resultado una vez que ya existe.
Eso, para mí, es la esencia del Vibe Coding.
No porque el desarrollador no entienda el código generado. No porque sea incapaz de corregirlo. Sino porque ha delegado la responsabilidad de decidir cómo se resolverá el problema.
Introduciendo el CÓMO
Cuando observo a desarrolladores que utilizan la IA de una manera diferente, encuentro un patrón común. Sus conversaciones con la IA no se limitan a describir el resultado esperado. También describen las restricciones, principios y decisiones que deben guiar la solución.
No solamente dicen qué quieren construir. También explican cómo quieren construirlo.
Definen arquitecturas. Definen patrones. Definen convenciones. Definen límites. Definen tecnologías. Definen criterios de calidad. En muchos casos, la IA recibe instrucciones mucho más parecidas a un plano de construcción que a una lista de deseos.
El resultado sigue siendo generado por la IA, pero las decisiones fundamentales ya fueron tomadas por una persona.
El prompt deja entonces de ser una descripción del destino y se convierte en una descripción del camino.
Y esa diferencia lo cambia todo.
Simon Sinek ya nos había advertido
Mientras desarrollaba esta idea me di cuenta de que existe un paralelismo interesante con el famoso Círculo Dorado de Simon Sinek.
Según Sinek, la mayoría de las personas y organizaciones comienzan por el nivel más superficial de la conversación: el QUÉ. Hablan de los productos que construyen, los servicios que ofrecen o los resultados que quieren alcanzar.
Sin embargo, las organizaciones más efectivas profundizan un nivel más y hablan del CÓMO. Explican los principios, criterios y métodos que utilizan para alcanzar esos resultados. Algunas incluso llegan hasta el POR QUÉ, la razón fundamental que guía todas sus decisiones.
Creo que algo parecido está ocurriendo con la adopción de la IA en el desarrollo de software.
Muchos desarrolladores describen con precisión qué quieren construir, pero dedican muy poco tiempo a definir cómo consideran que ese problema debe resolverse; esta es realmente la parte difícil de crear soluciones. La consecuencia es que terminan delegando mucho más que la implementación. Terminan delegando el criterio.
Y cuando delegamos el criterio, inevitablemente cedemos la parte más importante de nuestro rol como diseñadores de soluciones.
Programar sigue siendo decidir
Durante décadas hemos asociado la programación con escribir código. Quizás era inevitable. Después de todo, el código es la manifestación visible de nuestro trabajo.
Sin embargo, cuanto más experiencia acumulamos, más evidente se vuelve que escribir código es solamente una consecuencia de algo más profundo.
Lo que realmente hacemos al programar es tomar decisiones.
Decidimos qué restricciones existen. Decidimos qué compromisos aceptar. Decidimos cómo fluirá la información. Decidimos qué patrones utilizar y cuáles evitar. Decidimos cómo resolver un problema dentro de un contexto determinado.
En otras palabras, programar consiste principalmente en definir el CÓMO.
El código es simplemente la representación tangible de esas decisiones.
Por eso un desarrollador puede producir muy poco código y seguir aportando enorme valor. Porque el valor nunca estuvo en la cantidad de líneas escritas, sino en la calidad de los criterios utilizados para tomarlas.
La analogía del desarrollador junior
Imaginemos que trabajamos con un desarrollador junior muy competente.
Le decimos:
“Necesito un sistema de autenticación para los usuarios.”
Y nada más.
A partir de allí, el desarrollador toma una larga serie de decisiones. Selecciona las librerías, define la estructura del proyecto, decide cómo manejar las sesiones, dónde almacenar la información y qué patrones utilizar. Cuando termina, revisamos el resultado, hacemos algunas observaciones y corregimos los detalles que consideramos necesarios.
La mayoría de nosotros reconoceríamos inmediatamente que, en ese escenario, gran parte del diseño de la solución fue delegado al desarrollador junior.
Ahora imaginemos una situación diferente.
Le decimos:
“Necesito un sistema de autenticación. Quiero usar JWT almacenados en cookies HttpOnly, PostgreSQL para persistencia, middleware separado para autorización y una arquitectura basada en servicios.”
En este caso, el desarrollador junior sigue escribiendo gran parte del código, pero las decisiones fundamentales ya fueron tomadas. Lo que estamos delegando es principalmente la implementación, no el diseño de la solución.
La IA funciona de una manera sorprendentemente similar.
Cuando nos limitamos a describir el resultado esperado y dejamos que el modelo tome todas las decisiones técnicas, estamos delegando el CÓMO. Cuando definimos explícitamente las restricciones, los patrones, la arquitectura y los criterios que deben guiar la implementación, seguimos siendo nosotros quienes controlamos el CÓMO, aunque la IA escriba la mayor parte del código.
La diferencia no está en quién implementa.
La diferencia está en quién decide.
Y esa diferencia existe independientemente de que quien implemente sea una persona o una inteligencia artificial.
Entonces, ¿qué separa realmente ambos enfoques?
Durante mucho tiempo pensé que la diferencia entre Vibe Coding y Desarrollo Asistido por IA tenía que ver con el conocimiento técnico del desarrollador. Hoy creo que la línea divisoria es otra.
No está en la capacidad de leer código.
No está en la capacidad de depurarlo.
No está en la capacidad de corregir errores.
La diferencia real aparece mucho antes, en el momento en que decidimos quién será responsable del CÓMO.
Si delegamos el CÓMO, estamos haciendo Vibe Coding.
Si conservamos el control sobre el CÓMO y delegamos principalmente la implementación, estamos haciendo Desarrollo Asistido por IA.
La pregunta importante no es quién escribió el código.
La pregunta importante es quién tomó las decisiones de diseño.
Porque programar nunca fue simplemente escribir código.
Programar siempre ha sido decidir cómo resolver un problema.
Compartir:
¿Te gustó este artículo? Apoya este blog y ayuda a que siga creciendo.
Invítame un café