Vibe-coding: programar siguiendo el flow de la IA

You can just do things. / Puedes simplemente hacer cosas

Sin permisos, certificaciones, cursos o autorizaciones, solo dejándote llevar puedes hacer el producto digital que quieras. Escribes unas líneas sueltas y ¡pam! Dejas que tu modelo de IA haga todo lo que quieres. Al menos, esa es la promesa del vibe-coding. ¿Pero es tan así?

Hace poco más de un mes vi un post de Linkedin de Agustín Feuerhake donde contaba cómo hizo un “Wordle” con las palabras de artículos del Fintualist. Un juego que tenía complejidad, back-end, Google Tag Manager y una conexión directa con la última edición del newsletter.

Inspirado en la “La Palabra de Fintualist” de Agustín y “you can just do things” decidí hacer mi propio experimento: crear una versión en español del puzzle de palabras que me tiene entretenido todos los días –> https://bracket.city/.

La bauticé “[Entre Corchetes]” y sigo tratando de mejorarla.

Pero antes de contar mi experiencia, ¿qué significa vibe coding?

¿Qué es el vibe-coding?

Vibe coding es programar casi exclusivamente con comandos en lenguaje natural (en mi caso inglés y español) como input a una aplicación de Inteligencia Artificial como Replit, Cursor, Bolt o Loveable.

El concepto lo acuñó Andrej Karpathy, ex Tesla y ex Open AI en este post de X (tweet):

Como dice Karpathy, usar los matices propios de los lenguajes naturales, permite que el modelo sepa qué hacer, y en vez de comenzar escribiendo funciones, clases y estilos en un archivo, le dictas al modelo cosas como:

• Hazme una página con un juego en su homepage
• Haz que el botón del centro tenga la letra más grande y con mejores sombras
• Haz que se vea más sexy y aesthetic

Y en general, funciona, y bastante bien. 

Si el código te da un error, le dices “hey, te equivocaste y me salió esta alerta” y como si fueras un GP de Investment Banking, le respondes: Pls fix con el pantallazo. Y listo , se pone a trabajar inmediatamente para enmendarlo.

“Ay, pero esto solo debe funcionar con aplicaciones webs muy simples…” 

Quizás para un principiante (como el autor) que está aprendiendo a programar y no tiene la capacidad de diseñar para crear algo complejo. Pero, para programadores avanzados, es algo que simplifica bastante la parte más tediosa del código.

Tanto así, que entre programadores independientes (conocidos como indie hackers), el vibe-coding se ha convertido en un requisito.

Si no me crees, puedes ver el juego de Pieter Levels, un simulador de vuelos llamado Fly. Según el programador holandés, cerca del 95% de ese juego fue escrito por inteligencia artificial. Esto ha inspirado a muchos más a crear guías de juegos 3D y multiplayers que solo necesitan un navegador web.

Inspirado también en este indie hacker, me lancé con mi experimento. 

El experimento: [Entre Corchetes]

Hace unas semanas descubrí un juego que se llama Bracket City. Una especie de Wordle, más cerebral y caótico, que incluye aspectos de los crucigramas.

Cada día tienes una efeméride encriptada dentro de pistas, cada una de ellas anidada de otra pista. Como muñecas rusas (Mamushkas) cada pista te ayuda a descifrar la siguiente con una palabra.

Es un juego entretenido, pero que también requiere entender aspectos propios de la cultura estadounidense, así que decidí tratar de traducirlo.

El ¿programador? prompter

Para dar contexto, yo soy alguien no-técnico, soy ingeniero comercial y MBA. Mis conocimientos de programación vienen del uso de Excel y un par de cursos de manejo de bases de datos como SQL y PowerBI. 

Eso sí, hace poco más de un año decidí aprender a programar, tomé un curso de DataCamp de Python y después uno de Udemy de HTTP, Java y CSS. Después de eso me animé con algunos proyectos: empecé a construir mi página web personal, traté de resolver Advent of Code (aunque terminaba dependiendo de Reddit y ChatGPT) y comencé a usar un par de herramientas simples con Replit.

Antes de partir, pensaba que iba a necesitar solo un prompt. No sabía lo equivocado que estaba.

La herramienta: Replit

Replit es una aplicación que se apoya en la creación de páginas y aplicaciones web con LLMs. Su uso es muy simple. Haces un prompt como si fuera ChatGPT, te da feedback del prompt y se lanza a escribir el código.

Lo mejor de Replit es que te muestra una versión funcional de tu producto a la derecha de tu conversación con el agente. Eso te ayuda tanto con la visualización como en la detección de errores, pudiendo sacar pantallazos o incluso acceder a los Devtools y compartir el error completo.

Al final tu objetivo es que puedas iterar todas las veces necesarias para resolver los bugs que van surgiendo y llegues a tu producto mínimo viable. En ese momento, Replit te facilita el hosteo de tu producto. 

Intento 1: solo explicar el juego al LLM

Lo primero que intenté fue hacerlo directamente en Replit (lo elegí porque ya tenía la suscripción). Le di una instrucción larga donde detallé lo que quería, pero pese a varias iteraciones, no lograba dar con lo que buscaba en términos de funcionalidad.

Su primera respuesta fue una aplicación de puzzles más parecidos a los juegos de palabras. No mostraba las pistas y la página web quedaba en un spanglish poco apto para el consumo.

Después de muchas iteraciones decidí cambiar mi enfoque, por un lado porque a medida que hay más instrucciones el modelo puede perder el contexto original y porque también el costo está asociado a la cantidad de comandos y créditos que usa la API de Replit.

Intento 2: pelotear la idea con mi buen amigo, ChatGPT

Para mejorar el uso de Replit, decidí realizar una de las prácticas recomendadas para entender y mejorar el prompt con otro LLM. Con eso, fui a ChatGPT y lo llené de contexto, le di ejemplos de puzzles, incluso agregué un puzzle hecho a mano con sus respuestas. Todo para agarrar el prompt y entregárselo a Replit.

Con esto me lancé a Replit y lo logró de mejor forma. Partir de cero me permitió pedirle a Replit que quería un back-end para crear mis propios puzzles.

Ahora, la piedra de tope era la capacidad de anidar pistas. Pese a múltiples intentos, Replit no lograba entender la lógica de resolver lo interno y de ahí lo externo.

En ese minuto, entraron en juego mis (pocos) conocimientos de Java y recurrí a la fuente. Descargué los archivos originales de bracket.city y los subí a Replit como contexto. En esos archivos estaba la clave de la lógica del juego mostrando cómo visualizar la resolución del puzzle. Con ellos se destrabó y al fin empezó a acercarse a mi objetivo.

El back-end

Un aspecto relevante para que el juego fuera más que un juguete desechable, era permitir que se pudieran agregar nuevos puzzles. No depender de pedirle a Replit un nuevo puzzle al código duro, sino que facilitara la creación de una nueva edición con un back-end.

Este era un desafío nuevo. Como usuario tenía experiencia de cómo se ven los juegos, las páginas web, pero al crear la plataforma quería tener un menú donde pudiera ingresar los puzzles. Esta especie de formulario serviría de comunicación con la base de datos de los puzzles.

Solo sabía que necesitaba un back-end, sin saber si era mejor que fuera SQL o JSON, por lo que a punta de vibes le pedí a Replit: “quiero crear un back-end para construir frases y pistas. De esta forma puedo subir una frase cada día."

Y así nació mi back-end. La verdad es que no traté de entenderlo si no de quererlo, con pocas observaciones funcionaba e incluso resultó tener menos bugs que el front-end.

El prototipo final

Después de asegurarme que al menos el puzzle principal estuviera funcionando, decidí lanzarlo. Apreté el “temible” botón de deploy. Una de las ventajas de Replit es la facilidad con la que permite compartir algo en la Web. Después de unos pocos minutos, tenía un link que le podía pasar a amigos sin necesidad de subir los html, css, java y crear un servidor en AWS para la base de datos. Solo con un botón tenía el link de mi primer producto (compartible) vibe-codeado.

¡Al fin!

¿Fue tan fácil como esperaba? Lamentablemente, no. Si hubiera sabido qué necesitaba y cómo explicar el diseño, las funciones y las estructuras que buscaba, creo que me hubiera podido demorar menos que las 5 horas que le dediqué. Además el loop de correcciones sería más efectivo, si leyera el código entendiendo cuál era la verdadera razón de los bugs.

A pesar de que la primera iteración de Replit fue buena, uno puede pasar horas tratando de que se vea perfecto. Pillas un bug, pantallazo y comentarios a mi agente. Lo mejor es que nunca tuve que abrir el código para poder lograr que la aplicación funcionara. Bastaba con pedirle a la aplicación que agregara una cosa, que quitara otra y rezar para que lo lograra a la primera. A veces se ponía terco (¿terca?), y había que insistir con más pantallazos hasta lograrlo.

Otro tema es el diseño: la IA decidió que fuera dark mode. Probablemente no hubiera elegido lo mismo si lo hacía desde cero. Me quedaba corto en palabras para poder describir de mejor manera lo que veía en mi cabeza. Le decía “la parte principal” pero, ¿estará entendiendo lo mismo que yo la IA con “parte principal”?

Quizás mi gran conclusión es que tener la capacidad de describir una idea para comunicarse con la IA va a ser más relevante que hacer buen código (al menos para problemas simples). 

¿Será también real para la música? Rick Rubin, productor musical lo dijo en una entrevista: “No tengo ninguna habilidad técnica, no sé nada de música(...), solo sé lo que me gusta y lo que no me gusta y lo expreso con confianza”.

No estoy seguro cómo me debería sentir respecto a esto, o de las versiones de fotos tipo ”Ghibli”, o del slop de IA en general. Pero como decía Charlie Munger: “hay que ver el mundo cómo es, no cómo uno quiere que sea.” 

De lo que estoy seguro es que me estoy encargando un libro de diseño UX/UI por Amazon…

¿Quieres jugar con [Entre Corchetes]? Puedes probar la aplicación aquí:

https://bracket-challenge-ffierroc.replit.app/ 

* El you can just do things me animó a escribirle a Florencia para que publicara la columna.