👋 Bienvenido a mi blog

A estas alturas es muy posible que te hayas enterado de que hay un clon cutre del flight simulator de Microsoft que factura más que tú. Y no, no es una broma. Es un juego de vuelo en 3D hecho por Pieter Levels **en menos de 3 horas y que factura más de $87k al mes**. Y todo surgió a raíz de la tendencia de moda en X: el vibe coding. El vibe coding consiste en dejar que la IA programe por ti. Le pides que cree algo y, en lugar de revisar qué hace, aceptas todo. ¿Que el código que devuelve funciona? Pues asumes que está bien. ¿Que no? Le pides que lo cambie. Así de simple. En este post descubrirás: - De dónde sale todo esto del vibe coding - Por qué de repente está hasta en la sopa - Qué se puede y qué no se puede hacer con vibe coding - Cómo **tú** puedes crear juegos o lo que quieras haciendo vibe coding <small> Por cierto, si tienes una idea de un juego pero no tienes ni idea de por dónde empezar y quieres que la IA te lo haga, hay una GameJam organizada por @levelsio en curso hasta el próximo 1 de abril. Investiga en [#vibejam](https://x.com/hashtag/vibejam). </small> ## ¿De dónde sale el vibe coding? Según Andrej Karpathy[^1], "hay un nuevo tipo de programación que yo llamo 'vibe-coding' en el que te entregas completamente a los vibes y te olvidas de que el código existe". Y con solo un Tweet (¿o un X 🤔?) nació un concepto. Lo bueno es que no necesitas entender el lenguaje de programación ni la tecnología que utilizas ni nada. De hecho, ni siquiera saber programar. Y si el modelo alucina algún método, el IDE te hará saber que no existe. Si parece un flujo arriesgado, es porque lo es. Pero el vibe coding no es sólo un meme. Es varios órdenes de magnitud más rápido que un tutorial, o incluso que revisar la documentación, por lo que se convierte en una forma de aprendizaje no sólo mucho más rápida, sino también más divertida. ## El caso de Fly Pieter El pasado 21 de febrero Pieter Levels anunció en Twitter que había creado un simulador de vuelo en 30 minutos diciéndole a Cursor "créame un juego de volar 3d para navegador con rascacielos". <a class="inline-block" href="https://x.com/levelsio/status/1893350391158292550" > <img src={pieterTweet.src} alt="El tweet que inició todo" /> </a> <p> <small>El tweet que inició todo</small> </p> <br /> En menos de tres días ya tenía una versión multijugador online, con colisiones y disparos. Un mes y varios salseos más tarde (incluido un hackeo que consiguió meter triángulos alienígenas asesinos), el juego ha ejecutado más de 320.000 vuelos y, **tras llenar todo el mapa de publicidad** ya gana más de $87,000 al mes con este proyecto. <img src={flyPieter.src} alt="Captura de pantalla del simulador de vuelo de Pieter Levels, lleno de publicidad hasta las orejas" /> <p> <small> Captura de pantalla del simulador de vuelo de Pieter Levels, lleno de publicidad hasta las orejas </small> </p> Es verdad que tiene 635.4k seguidores en Twitter y cualquier cosa que haga va a tener un gran público. También es verdad que el producto no tiene la mejor calidad, ni las mejores prácticas de seguridad. Pero no deja de haber algunas lecciones interesantes: - Jamás antes había creado un videojuego y sin duda no habría podido hacer esto sin IA. - Todo lo ha hecho una sola persona, por un coste casi gratuito (aparte de su tiempo). - Desde el minuto 0 involucró a su audiencia y se dedicó a regalar titulares para blogs sensacionalistas. Supo jugar su mano. - Consiguió monetizar un producto gratuito que parecía inmonetizable y en un mes es su segunda principal fuente de ingresos. Y claro, es tan divertido dejar que la IA cree memejuegos por ti, que no iban a tardar en salir otros proyectos. Es por esto que pago internet. ## ¿Qué otros proyectos lo han intentado y qué resultados han tenido? Sin duda la estrella aquí son los juegos. Desde lo más chorra, como un flappy birds en 3D hasta cosas bastante curradas, como [Chakras](https://chakras.itch.io/chakras). La tendecia se ha hecho tan popular que el propio creador de Three.js ha incorporado un agente de IA en su editor. Incluso hay un [directorio de juegos](aibuiltgames.com) (todos igual de reguleros) hechos con IA. Además, este directorio cuenta con un propio juego dónde puedes moverte con una mochila propulsora hacia diferentes puertas, y cada una te lleva a un juego. <img src={livingTheFuture.src} alt="GameVerse, un juego vibe-coded que te lleva a otros juegos vibe-coded. Estoy viviendo en el futuro" /> <small> GameVerse, un juego vibe-coded que te lleva a otros juegos vibe-coded. Estoy viviendo en el futuro (nótese la ironía) </small> Pero no todo son juegos. También hay proyectos como [justbuildthings.com](justbuildthings.com) que contiene decenas de herramientas (supuestamente) creadas completamente por IA por alguien que apenas sabe programar. ## ¿Puede el vibe coding convertirse en la nueva forma de programar? Según Garry Tan en CNBC, el 25% de las compañías del último batch de YCombinator tienen un 95% de código hecho por IA. Y "10 ingenieros que sean muy buenos utilizando estas herramientas pueden hacer el trabajo de 50 o 100 ingenieros a lo largo del día". ¡PAM! 🤯 Thibaud Zamora, creador de dos estudios de videojuegos dice que lleva 20 años haciendo esto. Ya en 2004 sacaba prototipos rápidos de juegos para que las gente los pruebe ASAP, e iteraban a partir de feedback real, no opiniones. <blockquote class="twitter-tweet"><p lang="en" dir="ltr">I built &amp; sold two game studios (the latter to Ubisoft), shipped 30+ F2P games reaching 100M+ players since the early 2000s.<br /><br />The new &quot;vibe coding&quot; trend? It&#39;s exactly how we succeeded in F2P gaming 20 years ago.<br /><br />A thread on shipping fast, embracing imperfection &amp; finding magic…</p>&mdash; Thibaud Zamora (@thibaudz) <a href="https://twitter.com/thibaudz/status/1903362643877896195?ref_src=twsrc%5Etfw">March 22, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> La diferencia es que estos prototipos creados casi completamente por IA, quizás tengan menos calidad que los que hacía Thibaud, pero **se hacen en minutos, no en semanas**. Las posibilidades de iterar para encontrar qué productos funcionan, crecen exponencialmente. Luego está Andrew Chen, que afirma que [la mayoría del código será escrito por chavales a los que le sobra el tiempo](https://andrewchen.substack.com/p/predictionsthoughts-on-vibe-coding), como ahora pasa con el contenido de YouTube o TikTok. Lo dudo, pero el futuro nunca en la historia fue tan impredecible como ahora. ## ¿Cómo se hace? La verdad que no tiene muchos misterio. 1. Abre Cursor (VSCode te servirá también cuando saquen el modo agente para todo el mundo) 2. Pídele que te haga algo, en mi caso le pedí "create a 3d game for the browser using three.js where you are a tank in a city and you can shoot other tanks and also shoot the buildings to destroy them". Como puedes ver, no hay que currarse mucho ni la gramática siquiera. 3. Acepta todo lo que te devuelva Cursor 4. Cuando algo no funciona, pídele que lo cambie. Si tienes algún error, cópialo y pégalo en el chat tal cual, sin necesidad de explicar nada. <br /> <br /> <video controls alt="Vídeo del juego de tanques que me ha devuelto Cursor"> <source src={tankVideo} type="video/mp4" /> Your browser does not support the video tag. </video> <small> Juego de tanques que me ha escupido. No tengo ni idea de qué hace el código </small> En la primera versión de "mi juego", la rotación de la cámara iba mal, las balas eran invisibles, las colisiones no funcionaban... Pero tras varios prueba y error, empezó a funcionar. Aún hay algunos fallos como que el proyectil salga del lugar correcto o el cañón está rotado 90º, pero nunca antes había hecho un juego en 3D y jamás había usado Three.js. **Hubiera tardado semanas en conseguir esto de haberlo intentado hace un año**. ### Algunos consejos - No intentes que te lo haga todo bien a la primera. Ve refinando. La primera versión llena de fallos me llevó 2 minutos, conseguir que arreglara los problemas más básicos me llevó casi 1 hora. - Confórmate con cosas sencillas, no intentes hacer un MMORPG en tu primer intento. - Utiliza la consola de depuración para entender qué ocurre cuando algo falle y añade esta información a tu prompt cuando le pidas que arregle algo. Si no lo haces, es muy posible que para ciertos errores se quede dando vueltas una y otra vez haciendo cambios insustanciales que no tienen nada que ver con el error. Y si tienes algo medio funcional y necesitas assets, Majid Manzarpour [te enseña a hacerlo también con IA en pocos minutos](https://x.com/majidmanzarpour/status/1900922438570905883). También tienes esta [increíble herramienta](https://hyper3d.ai/) que te genera modelos 3D automáticamente con IA. ## Desmontando mitos ### 1. Cualquiera puede programar ahora. Relaja. El momento no ha llegado...aún. Tarde o temprano te vas a topar con una pared que no sabrás cómo superar. Si no sabes absolutamente nada de programación, podrás probar cosas a ciegas (y de paso aprender en el proceso), pero te llevará muchísimo más tiempo y tendrás que atravesar un enorme mar de frustración. Al final acabarás por aprender igualmente, y sólo tras ese aprendizaje resolverás esos problemas. O dicho de otra manera, **no conseguirás programar algo serio sin saber**. ### 2. Al final estás incrementando el tiempo que invertirás en depurar. Esto es cierto a medias. La mayoría de errores que me he encontrado, copiándolo y pegándolo en el prompt sin necesidad de explicar ni una palabra, los arregla a la primera. Y aunque sí que habrá momentos donde la IA no sea capaz de encontrar el problema y te toque leer y entender un código que no es tuyo, compensa MUCHÍSIMO. Lo único que sí hay de cierto: tienes errores en el código evidentes y no lo sabes. **Esto sí es un problema**. ### 3. Puedes ganar dinero fácil creando juegos así. No, no puedes. Si quieres crear un juego en un día y hacerte rico, siento decirte que no tienes una audiencia dispuesta a comprarte un pedo que metas en un bote. No eres Pieter Levels. Pero si quieres hacer algo serio, esta es una gran forma de iterar más rápidamente sobre diferentes ideas y acabar creando un mejor producto. Recuerda, la distribución lo es todo. Hacer un juego es mucho más fácil que nunca, pero sigue siendo un reto conseguir gente que quiera jugarlo. ## Conclusiones: cambio de chip El vibe coding ha llegado para quedarse. Pero hay que volver a aprender a programar. - Para un proyecto serio, la calidad de la solución se incrementa por x1000 si se diseña una arquitectura y unos tests, y a partir de ahí se construye. - Los problemas de seguridad van a ocurrir. Volvamos al ejemplo del simulador de vuelo de Levels. Recibió ataques que inyectaron código JavaScript en el cliente y generaban naves espaciales que atacaban a los jugadores. Esto es inocuo, pero ojo al tema porque no es menos: alguien ha conseguido ejecutar código remoto en más de 320.000 dispositivos. Además, el servidor casteaba las IPs de todos los jugadores, por lo que eran visibles para todos. Es necesario establecer pruebas robustas (posiblemente también basadas en IA) que automaticen detectar estos problemas.Y seamos sinceros, la seguridad siempre es el último ítem en la lista de prioridades. - También tendrás problemas de rendimiento, pero ocurrirán por pedir a la IA basándote en premisas falsas. Eso te llevará a emplear tecnologías para algo para lo que no fueron diseñadas. Para grandes proyectos, evalúa todas las alternativas y diseña un producto completo antes de empezar a "programar". - Es la mejor manera de aprender a programar que existe. Deja a la IA resolver el problema y luego lee y comprende qué ha hecho. O por el contrario inténtalo tú y compara resultados. Es válida para novatos, pero también para expertos que necesiten utilizar una nueva tecnología. Te dejo video que describe el proceso mejor que ningún tutorial. <blockquote class="twitter-tweet" data-theme="light"> <p lang="en" dir="ltr"> Coding with AI in 2024.{' '} <a href="https://t.co/6wc3OHap1U">pic.twitter.com/6wc3OHap1U</a> </p> &mdash; Kai Lentit (e/xcel) (@KaiLentit) <a href="https://twitter.com/KaiLentit/status/1848843623808540679?ref_src=twsrc%5Etfw">October 22, 2024</a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8" ></script> [^1]: <span>https://x.com/karpathy/status/1886192184808149383</span>

Lunes, 9 de la mañana. Tu escritorio huele a café. Das el primer sorbo y miras el calendario. Parece un tablero de ajedrez. La productividad está por los suelos, cada bug que se arregla genera 3 nuevos.Tu manager está obsesionado por implementar "buenas prácticas", lo que sea que eso signifique. El junior quiere implementar TDD porque lo acaba de ver en un video de Fireship y el senior sólo quiere que le dejen programar en paz. ¡No pasa nada! ¡Tengo la solución! DevOps para todos!! 🎉 Defines un proceso infalible donde hay que hacer una pull request, que se rechaza automáticamente si el linter o el formatter no acepta el estilo, que tiene que incluir tests y actualizaciones del changelog y cada línea de código tiene que ser un verso endecasílabo. Es broma. Este cambio **jamás** va a salir bien. El problema es que, por muy perfecto que sea este nuevo sistema, el equipo no sabe usarlo. No sabe cómo configurar cada herramienta, ni por qué hace falta. Sólo ve que cada vez que termina su trabajo, no puede incorporarlo a la base principal del código cada vez por un error distinto. Peor aún, el fracaso minará la confianza de todos en un futuro mejor, y cualquiera que ahora proponga un cambio a mejor sólo consigue provocar en el resto flashbacks de Vietnam. ## Implementar buenas prácticas es como hacer mayonesa Formatter, linter, actions, tests, PRs, SOLID, DRY, KISS, AC/DC, Metallica...Todo a la vez. ¿Qué puede salir mal? Si quieres arreglar las cosas necesitas un proceso de cambio que te garantice que: - No se aplican de una vez más cambios de los que se pueden absorber. - Todo el mundo entiende para qué sirve cada cambio que se adopte. - Nadie se queda con fuertes opiniones en contra de ningúna decisión. Para resolver este problema que durante años me he encontrado en muchos equipos utilizo lo que llamo _La Constitución_. ## La Constitución Cuando estaba en el instituto, un día nos vino a dar una charla un catedrático de derecho constitucional. Empezó diciendo algo que me extrañó bastante: "la Constitución es la única ley que no resuelve ningún problema". 🤔 En realidad sí que resuelve un problema: poner a todo el mundo de acuerdo sobre qué consideramos que debería estar o mal hacer. Bajo estos cimientos, es mucho más fácil crear leyes que con un criterio arbitrario para cada situación. La Constitución de un equipo de desarrollo es exactamente como la de un país: es la única ley que no resuelve ningún problema concreto pero establece un acuerdo común sobre con qué mentalidad se debe evaluar qué prácticas consideramos "buenas". Esta Constitución ahorra tiempo y disgustos: si no se está de acuerdo en algo, vamos a la Constitución y actuamos de la manera más fiel a esta. Al igual que en democracia, cuando alguien no esté de acuerdo contigo siempre podrás decirle: "¡ah! Pues cuando acordamos la Constitución dijiste esto", y así ganar todas las discusiones. ### ¿Cuáles son los principios de la Constitución? Cada equipo debe acordar en común estos principios, es lo que le da legitimidad. Como comienzo, puedes utilizar los míos. ## 1. La energía intelectual es limitada. {<blockquote> <p className="text-xl italic font-medium leading-relaxed text-white">"La técnica es el esfuerzo para ahorrar esfuerzo."</p> <p class="pl-4 mt-2">- Ortega y Gasset</p> </blockquote>} Es evidente que un trabajador de una obra se cansará mucho antes si transporta sacos de cemento a la espalda. Sería absurdo no utilizar al menos una carretilla. ¿Por qué en el software no hacemos lo mismo? Hay gente que parece que **cuanto más difícil hacen el trabajo más listos son**. A lo largo del día hay un límite de horas que podemos dedicar a crear software, incluso cuando entramos en ese estado de casi adicción resolviendo algún problema. Llega un punto en el que es imposible concentrarse más. Si queremos aprovechar al máximo la energía intelectual diaria, necesitamos hacer el menor trabajo posible. Empleemos carretillas. Algunos ejemplos: - **Utilizar un formatter** (Prettier, Black, Ruff format...) en lugar de mantener el estilo a mano. - **Utilizar un linter** que detecte potenciales errores y homogeinice el código sin tener que pensar. - **Utilizar herramientas basadas en IA**. Hay gente que lo ve como un deshonor o algo reconocer que las usa. No entiendo. - **Comitear con frecuencia** en lugar de recordar cambios o copiar archivos por si hay que volver atrás. - **Aprender a utilizar tipado** en lugar de memorizar qué tipo era cada cosa, usar assertions o simplemente confiar en _yo no me voy a equivocar nunca_. - **Crear tests automáticos** básicos en lugar de realizar _siempre_ las mismas pruebas en consola. - **Aprender atajos de teclado** para las 4 tareas que se realicen constantemente en lugar de andar leyendo submenús haciendo decenas de clicks una y otra vez. ## 2. Toda solución necesita un problema. Asegúrate de que has leído la frase correctamente. Es obvio que todo problema necesita una solución, pero se nos olvida que una solución también necesita un problema. Adoptamos nuevos procesos sin pensar si de verdad los necesitamos. - No se añade ninguna herramienta extra si no es para solucionar un problema. - No se impone ninguna nueva regla si no es para solucionar un problema. Eso debería evitar los clásicos "se tiene que hacer así porque es como se hace en \[introduzca FAANG+\]". O mejor aún "así es como lo dictan las _buenas prácticas_". 🤮 ## 3. La estandarización es ortografía. Durante un tiempo trabajé con un desarrollador muy crack pero que sólo había trabajado en solitario. Se preguntaba por qué debía respetar las guías de estilos del equipo, si todo se entiende igual. A la hora de escribir en lenguaje humano respetar la ortografía no es necesario para entenderse. Sin embargo, _tener una serie de reglas comunes para todos nos ahorra mucho esfuerzo_. - **A quien escribe**: no tiene que invertir energía constante en tomar la decisión de cómo escribir cada palabra - **A quien lee**: necesita menos energía mental si todas las palabras aparecen escritas siempre de la misma manera, en lugar de tener múltiples grafías que significasen todas lo mismo. El software _es igual_. ## 4. DX matters. Un desarrollador infeliz es un desarrollador improductivo...y una próxima silla vacía. Las reglas deben, a medio-largo plazo, generar paz mental. Nunca infelicidad. ¿Qué hacer si quieres quemar a tu equipo de desarrollo? - Oblígales a documentar todas y cada una de las líneas que escriben. Mejor aún, oblígales a mantener esos comentarios con cada cambio para que nunca dejen de ser verdad. - Haz que tengan que escribir tests incluso para los prints. - Impón un montón de herramientas lentas y pesadas contra su voluntad. - Configura un montón de pre-commit hooks que les impida tener código sucio temporal en local para que no puedan hacer pruebas rápidas. ## 5. Los errores los cometen individuos. Las consecuencias las crean los sistemas. - Ningún sistema debe depender de que nadie cometa fallos. - Nadie debería trabajar con miedo a tocar nada, por si acaso se rompe algo. Ejemplos: - Alguien pushea a main por accidente y altera cambios en producción -> No existe una política de ramas que lo impida. - Alguien elimina por error datos en la BBDD -> No había un backup automatizado, no había una política de roles y permisos eficaz. Cómo garantizar esta regla: si algún nuevo desarrollador consigue romper algo, todo el equipo le invita a comer. ## Sugerencias de extensión ### A. La democracia no funciona. A menudo un equipo puede sentirse tentado a tomar decisiones democráticamente. El problema es que el efecto [Dunning-Kruger](https://es.wikipedia.org/wiki/Efecto_Dunning-Kruger#Definici%C3%B3n) es demasiado potente en desarrolladores. En lugar de eso, denomina a un dictador de confianza que decidirá qué se va a hacer. Deja que todo el mundo exponga su opinión y después deja que esa persona tome la decisión. ### B. Si no se despliega no está terminado. Desde escribir el código hasta que se despliegue y utilice, puede ocurrir todo tipo de errores. Para evitar el clásico "pues en mi ordenador funcionaba", es conveniente desplegar los cambios, aunque sea en un entorno de desarrollo que al que el cliente final no tiene acceso. Esta regla puede obviarse en función de la sencillez del proyecto y de los entornos involucrados. ### C. No reinventamos la rueda Aprender nuevas tecnologías existentes > crearlas desde 0. Cuando el equipo es talentoso y entiende cómo funciona la tecnología que necesita, puede ser tentador crear todo de 0. De esta manera entenderemos perfectamente todo lo que está ocurriendo. La alternativa sería aprender a utilizar una dependencia que ya tenga implementada la funcionalidad deseada. Construir es MUCHO más divertido que estudiar, por lo que la primera opción suena mucho más interesante, ¿no? Sin embargo, con frecuencia se estimará de manera demasiado optimista el tiempo que conlleva hacer todo desde cero. Además, cada nuevo bug deberemos arreglarlo por nuestra cuenta, mientras que en el caso de una dependencia externa, esta responsabilidad recae en un tercero (o entre todos en el caso de open-source). ## Repito: implementar buenas prácticas es como hacer mayonesa No sólo porque si no se introducen los cambios gota a gota, todo se estropea. Sí. Pero también porque para que salga bien, primero se ha tenido que hacer mal múltiples veces.