Es una verdad universalmente reconocida que un proyecto singular con potencial necesita un equipo. Este equipo debe estar formado por buenos desarrolladores con experiencia, criterio, habilidades analíticas y lógicas, y una sólida comunicación interpersonal. El lugar que ocupa la programación con IA sigue siendo muy controvertido. La opinión sobre la programación de vibraciones en las TI corporativas es más clara: o se vende el producto o se evita el problema.
Las razones son simples. La generación de código se vende con promesas de resultados rápidos a partir de indicaciones en lenguaje natural, sin necesidad de conocimientos especializados sobre su funcionamiento real. Esto es cierto en parte, y es posible realizar demostraciones impresionantes de dos minutos, si se eligen bien. En este sentido, la programación de vibraciones se asemeja mucho al movimiento low-code/no-code que lleva 30 años presente.
La programación de vibraciones fracasa a partir de entonces porque no es determinista. Las plataformas low-code/no-code tienen consistencia en la forma en que su interfaz responde a la entrada del usuario. Los ajustes iterativos funcionan, desde modificar las fuentes hasta reiniciar con un enfoque completamente nuevo. La codificación de vibración puede ofrecer resultados diferentes a lo largo del tiempo para las mismas indicaciones. Intentar ajustar los resultados depende en gran medida de cómo la IA interprete tus solicitudes y de su apego a la idea original. Lo cual suele ocurrir.
No hablemos de cómo mantener una base de código que ningún humano ha entendido jamás cuando tus herramientas están en constante mutación. Si no hay muchas aplicaciones de producción bajo el lema «low/no-code» después de 30 años, las perspectivas para la codificación de vibración son realmente escasas. Incluso si la codificación de vibración cumple su función más básica, producir rápidamente un modelo de prototipo para explorar ideas, se basará en el principio de que los prototipos no se pueden eliminar, sino que se transforman en monstruos. Una vez que algo parece funcional, la presión externa para desarrollarlo inmediatamente suele ser inmensa. Eso ya es bastante malo en cualquier entorno, pero la vibración no lo aceptará.
Sin embargo, en cierto sentido, la codificación de vibración tiene un atributo atractivo difícil de encontrar en otros entornos. Por primera vez desde que los ordenadores domésticos de encendido instantáneo se integraron directamente en un intérprete de BASIC, es posible hacer que las cosas funcionen con solo escribir un poco, incluso para un usuario muy ingenuo. Linus Torvalds lo considera una gracia salvadora, comparándolo la semana pasada con la época en que se tecleaban programas de las últimas páginas de las revistas de informática. No es incorrecto: si estuviste allí, recordarás lo horrible que era corregir errores lógicos o de impresión en cientos de líneas de código gnómico, pero es casi completamente irrelevante.
BASIC recibió críticas similares a las del código de vibración en su época, al ser visto como un incentivo para malas prácticas de programación y código desestructurado, impenetrable e inmantenible. El dios mayor Edsger Dijkstra argumentó en «Go To Statement Considered Harmful» que este fue el origen de esta crítica, y la frase resonó a lo largo de las décadas. Lo cual es como decir que los niños que tocan un instrumento musical para ver qué pueden hacer, o que reciben clases de profesores sin formación formal, harán música terrible. A menudo, eso es cierto. La cuestión es que ahí es donde empiezan la mayoría de los buenos músicos. Es donde empieza la música. Si descubres que te encanta, mejoras. Lo mismo ocurre con BASIC.
La programación Vibe no tiene ese camino. No es su culpa, no del todo. Llegar a la etapa de «hacer algo útil» en un entorno informático moderno implica producir código complejo con API y estructuras, y un sinfín de detalles en torno a la lógica central. Insistir en indicaciones iterativas no construirá el marco interno de comprensión que genera la creación de código, y sin la dosis de dopamina de la comprensión repentina que impulsa tantas experiencias tempranas de programación, el proceso no recompensará al autodidacta a seguir buscando más de lo mismo.
Una programación Vibe que no codifica sería una idea mucho mejor. Material que sugiere por dónde empezar, qué aprender y ayuda a crear un entorno donde se pueden obtener resultados que dependen de forma rápida y clara del descubrimiento y la experimentación de ideas. Estas herramientas ya existen. Se llaman libros. Se llaman tutoriales.
Sería bueno ser productivo al instante mientras se aprenden los fundamentos, y ningún tutorial ni libro ofrecerá la especificidad de un resultado único e innovador. No está claro si los LLM podrían lograr esto de forma fiable o en absoluto, pero sería un experimento interesante. Afortunadamente, hay una manera de lograrlo: unirse a un equipo de apoyo y con experiencia, preparado para guiarte y proporcionarte las tareas adecuadas para desarrollar tus habilidades.
Si no sabes mucho sobre las realidades de la programación, la codificación vibrante suena genial. Ese es uno de los mayores factores de riesgo de la IA generativa: la capacidad de inspirar confianza independientemente de la realidad. Del mismo modo, si recuerdas los días en que no sabías mucho sobre programación, la codificación vibrante suena como una buena manera de ayudar a otros a dar los mismos pasos que tú.
Ambos pasan por alto que gran parte del aprendizaje y la programación se centra en la motivación, la recompensa, la comprensión, la comprensión del futuro y, lo más importante, en hacer todo esto rodeado de otras personas. Esa es la verdadera onda, amigo.
