Los problemas del vibe coding y cómo solucionarlos en Linux

Los problemas que genera el vibe coding, del que hablamos en artículos anteriores, son lo suficientemente graves para constituirse en la causa de la próxima gran catástrofe informática.  Es momento de pasar a la programación asistida por Inteligencia Artificial que implica un enfoque más profesional (y menos peligroso). Es ideal cuando necesitas programas en situaciones en las que se requiere seguridad y estabilidad.

En este artículo comenzaremos comentando cuáles son los problemas más comunes con el vibe coding y por qué, a pesar del ruido que hacen algunos promotores, no constituye la nueva revolución industrial. En los que siguen desarrollaremos el procedimiento para pasar del vibe coding a la programación asistida por Inteligencia Artificial en Linux.

Los problemas del vibe coding

Vamos a poner un ejemplo: dos personas van a un restaurante de lujo: Uno no sabe nada de cocina, el otro es un experto chef.  El primero solo sabe lo que quiere comer y, a lo sumo juzgará la calidad de lo que le sirven por el precio o por lo que le indica su paladar poco entrenado. El segundo, podrá distinguir si se usaron ingredientes frescos, si se usaron los condimentos en las cantidades correctas y, si no le están cobrando de más.

No es casualidad que pongamos como ejemplo el de un restaurant. Andrej Karpathy, experto en Inteligencia Artificial, es uno de los cofunadores de OpenAi y director de Inteligencia Artificial de Tesla. Queriendo solucionar el problema de no saber que pedir creó una aplicación con vibe coding que muestra una foto de los platos. Así cuenta su experiencia:

«Hacer MenuGen con vibe coding fue divertido como demo local, pero bastante duro como app real. Crear una app moderna es como armar muebles IKEA del futuro: muchos servicios, APIs, configuraciones, límites, precios. Los LLMs tienen conocimiento desactualizado, cometen errores sutiles, alucinan. Y lo curioso es que casi no pasé tiempo programando, sino configurando servicios en el navegador. Todo eso ni siquiera es accesible para un LLM. ¿Cómo se supone que automatizamos todo para 2027 así?»

Veamos de manera más detallada lo que le pasó a Andrej, que dicho sea de paso, no es un desarrollador web lo que probablemente lo llevó a haer las cosas más complicadas de lo necesario.

“Usé Cursor + Claude 3.7, le di la descripción de la app, y escribió todos los componentes frontend en React muy rápido, armando una web hermosa con fuentes multicolores suaves, pequeñas animaciones CSS, diseño responsive y todo eso, excepto la funcionalidad real del backend.”

Frontend y backend son las dos caras de la moneda del diseño de aplicaciones. El frontend es la parte con la que actuamos los usuarios, el backend es donde se produce el procesamiento y almacenamiento de la información. El frontend trabaja localmente mientras que el backend generalmente se desarrolla en un servidor externo.

Claude es, al menos entre los fanáticos del vibe coding, el Modelo Grande de Lenguaje dle momento. Las razones para esto son más ideológicas que técnicas. Anthropic la empresa que lo desarrolla se enfrentó al Pentágono por el uso de sus modelos sin supervisión en el ámbito militar.

Cursor es un editor de código en el que el modelo de Inteligencia Artificial establecido acutó como un compañero de programación. Hablaremos más adelante sobre cómo se instala Cursor en Linux.
React es una biblioteca para la creación de interfaces gráficas dinámicas. No conozco la aplicación por lo que no puedo juzgar sobre si el uso de React es adecuado, pero según mi propia experiancia con el vibe coding, los modelos tienen cierta tendencia a utilizar bibliotecas para cosas que podrían hacerse sin inconvenientes con HTML, CSS y Javascript puros.

Donde a Karpathy se le empezaron a complicar las cosas fue en la parte del backend. Su aplicación comienza sacando una foto al menú y haciendo reconocimiento óptico de caracteres para después poder buscar los detalles de cada comida. Veamos su descripción de lo que pasó:

“Acá empezaron algunos problemas. Necesitaba llamar a las APIs de OpenAI para hacer OCR de los ítems del menú desde la imagen. Tuve que obtener las claves API. Navegar menús algo enredados sobre “proyectos” y permisos detallados. Claude alucinaba con APIs deprecadas, nombres de modelos y convenciones de entrada/salida que cambiaron recientemente, lo cual era confuso, pero se resolvía después de copiar y pegar documentación varias veces. Una vez que las llamadas a la API funcionaban, enseguida me encontré con límites de tasa bastante fuertes, que me dejaban hacer solo unas pocas consultas cada 10 minutos.”

Este es un ejemplo clásico sobre la tendencia de los modelos a matar moscas a cañonazos. Lo de hacer el reconocimiento de la imagen del menú podía haberse hecho con una biblioteca local como Tesseract.js
Tesseract.js se basa en la herramienta de Google del mismo nombre y es compatible con más de 100 idiomas. Se puede usar sin problemas dese el navegador, y lo más importante, no consume tokens, no necesita claves de API y no tienen limitaciones.

Lamentablemente, lo de las alucinaciones con APIs depreciadas y trabajo con documentación desactualizada no tiene solución. Salvo, la de aprender a programar y no usar herramientas automatizadas.
Tuvo problemas parecidos con la segunda parte de la aplicación. Convertir la descripción de cada plato en imágenes.

“Me registré, conseguí una API key de Replicate y tuve problemas similares. Las consultas no funcionaban porque el conocimiento del LLM estaba desactualizado, y además esta vez incluso la documentación oficial estaba un poco desfasada por cambios recientes en la API, que ya no devuelve JSON directo sino un objeto de streaming que ni Claude ni yo entendíamos bien. Luego volví a toparme con límites de uso, lo que hacía difícil depurar. Después me dijeron que estas son medidas comunes contra fraude, pero también dificultan empezar con cuentas nuevas legítimas. Me comentaron que Replicate está migrando a un modelo de créditos prepagos, lo que podría ayudar.”

Andrej podía haber solucionado esto sin recurrir a generadores de imágenes. Existen varmas herramientas que pueden buscar imágenes reales de los platos (Evitando las posibles alucinaciones de IA). Entre ellas tenemos dos APIs de bases de datos de recetas: TheMealDB y Spoonacular Food API.

Los problemas no terminaron ahí para nuestro amigo el vibe coder. Al subir la aplicación a Vercel (Una plataforma que permite desplegar y alojar aplicaciones desde un repositorio de GItHub) le aparecieron errores que no se producían localmente. Tardó una hora en darse cuenta de que las claves de las APIs no se habían subido al servidor. Un programador experimentado lo hubiera sabido y se hubiera ahorrado el gasto de tokens.

La idea del autor es cobrar por el uso de la aplicación (Me pregunto quién va a pagar por algo que se puede obtener grátis preguntándole a Gemini o Siri) para esto necesita la autenticación del usuario. Por sugerencia de Claude, Karpathy recurrio a otra plataforma en la nube conocida como Clerk. Clerk se ocupa de todo lo necesario para la registración y el acceso. No tengo nada que objetar a esta decisión.
El problema es que Claude hizo el código para una versión de la API de Clerk depreciada y se le olvidó avisarle de que si quería usarlo en producción necesitaba un dominio propio y no el gratuito que da Vercel. Tuvo que comprarlo y configurarlo.

Tampoco faltaron complicaciones al configurar la plataforma de pagos. Cuando finalmente lo pudo mandar a producción descubrió que:
“Todo el procesamiento era en tiempo real, sin persistencia. Si tardaba mucho, fallaba. Si refrescabas, perdías todo. La solución correcta sería base de datos + sistema de colas. Pero eso implicaba más servicios (ej. Supabase, Upstash), más complejidad. Demasiado. Lo dejé para el futuro.”

Más bien la solución es aprender a programar o pagarle a alguien que sepa lo que hace. En el próximo artículo comenzaremos a ver los pasos para hacer lo primero.