VibeRacing: Cuando la velocidad revela el craft
Del pod racing al code racing: cómo una competencia de programación nos enseñó sobre feedback loops y colaboración
Por qué la velocidad importa (pero no como piensas)
El sábado pasado, en medio de 80 personas creando en el Release before Ready de CDMX, hicimos algo diferente. Mientras algunos construían sus primeros sitios web, otros pausaron sus proyectos para unirse a un experimento. Edd dejó de diseñar user personas para Terapify, Mario pausó su taller de chatbots con Neuraan, y junto con otros siete developers, se sentaron a competir.
Una hora. Un reto. Sin distracciones.
Lo llamamos VibeRacing, y lo que empezó como una semilla plantada por Sergio Prado en julio sobre quién era el developer más rápido, creció en la comunidad hasta convertirse en un experimento sobre cómo aprendemos cuando no hay tiempo para dudar.
De una semilla a un formato: el origen del pod racing
Todo comenzó con este mensaje de Sergio el 11 de julio:
"En otros temas saben que me gustaría ver por puro amor al arte Jonathan Olvera y Santiago Zavala son los developers más rápidos que conozco, que se avienten un 1 vs 1 de 30 minutos a ver quién gana este sábado 🤣"
En ese momento lo llamábamos "copilot racing" por el pod racing de Episode I de Star Wars. La idea fue nutriéndose poco a poco en la comunidad hasta que Santiago, todavía picado con el reto, decidió bautizarlo como VibeRacing. En lugar de 30 minutos, le dimos una hora completa.
A las 5pm en punto, la mesa estaba lista. Nueve participantes. Dos jueces: Rox de Mexico TechWeek y Denis de ComeBien. Yo fungí como maestro de ceremonias. La energía cambió completamente - del ambiente colaborativo usual del RbR a una tensión palpable.
El reto: Encontrar la señal en el ruido de IA
Cuando Santiago me pidió crear el prompt del proyecto, sabía que tenía que ser algo especial. No podía ser otro TODO list o CRUD básico. Tenía que forzar a los participantes a:
- Pilotear múltiples agentes simultáneamente - no solo copiar y pegar código
- Desarrollar varios tracks en paralelo - frontend, scraping, análisis
- Lidiar con data real y compleja - Los modelos de hoy tienen contextos enormes (Claude puede manejar 200k tokens), pero una semana completa de Hacker News es aún más. No hay prompt que pueda contener toda esa información.
El reto quedó así:
"En la última semana hubo muchos releases de modelos, muchas noticias y mucho hype. Tu objetivo es crawlear Hacker News, recolectar TODAS las noticias de los últimos 7 días, catalogar qué modelos de IA tuvieron más menciones y determinar si el tono era positivo o negativo. Crea un dashboard que muestre esta información de manera que los jueces puedan entender el panorama de las noticias de IA de la semana."
Simple de explicar. Complejo de ejecutar.
Una hora, múltiples caminos
Santiago, quien ganó la competencia, compartió su approach técnico:
"Mi solución fue crear una app de Next.js con dos agentes en paralelo: uno trabajando en la aplicación y otro en scripts para alimentar la base de datos. Usé Prisma con SQLite. El primer script con Algolia solo me regresó mil noticias - intuí que no eran todas."
El problema de Algolia lo forzó a pensar diferente. En lugar de pedir las noticias más recientes hacia atrás, descubrió con ChatGPT cómo pedirlas día por día. Ningún día tenía más de mil noticias, así que pudo obtener TODO.
Mientras su script procesaba 25 noticias a la vez con GPT-4-mini para analizar sentiment y detectar modelos, Santiago construía el UI en paralelo: lista de noticias, dashboard de modelos, hasta un pequeño admin para limpiar falsos positivos.
Luis Mi, quien vino desde Medellín a su primer RbR, quedó segundo con 1,000 noticias. Jon tercero, y además logró deployar en hackernews.dev durante la competencia.
La mayoría usó Node.js (Next.js) o Python. Pero lo interesante no fue el stack - fue ver cómo cada uno priorizaba diferente bajo presión.
El giro inesperado: de competencia a colaboración
A las 6pm paramos. La tensión se disolvió instantáneamente.
Lo que pasó después fue mágico: mientras cada participante presentaba su solución, los demás comenzaron a compartir tips. Santiago le explicó a Luis Mi cómo obtener las 5,000 noticias faltantes. Luis Mi, en lugar de guardarse el conocimiento para "la próxima", abrió su laptop y comenzó a implementar las mejoras ahí mismo.
La competencia había terminado, pero el aprendizaje apenas comenzaba.
Feedback loops acelerados y la velocidad como herramienta
En el post anterior sobre Coding Katas, hablamos de la práctica deliberada - repetir los mismos ejercicios hasta que los patrones se vuelvan instinto.
VibeRacing es el complemento perfecto. Como explicó Santiago después del evento:
"Para mí no es interesante en el sentido de ir más rápido a mercado. Es retarte a entender: todo tiene una versión de una semana, una de un día, una de cuatro horas y una de una hora. ¿Cuál es la versión de una hora de tu idea?"
Santiago también compartió una memoria de hace años:
"Me recuerda mucho cuando Jeff Lindsay me retó a tener hackathons de cuatro horas todos los días, tratar de hacer algo de cero a uno. Creo que esas cuatro horas hoy pueden ser una hora."
Con el poder de los tools actuales - Cursor, Claude, v0, Replit - podemos comprimir aún más estos ciclos de aprendizaje. Deberíamos estar retándonos constantemente a crear versiones de una hora de nuestras ideas, no para shipear más rápido, sino para entender más profundo qué es lo esencial de lo que queremos construir.
VibeRacing no es sobre programar más rápido para shipear más rápido. Es sobre comprimir el ciclo de aprendizaje hasta que no quede más que lo esencial. Cuando tienes una hora:
- No puedes investigar todas las opciones - tienes que confiar en tu instinto
- No puedes refactorizar - tienes que vivir con tus decisiones
- No puedes dudar - tienes que construir
Y paradójicamente, esas limitaciones te liberan. Te muestran qué partes de tu proceso son verdaderamente importantes y cuáles son solo procrastinación disfrazada.
Descubres rápidamente:
- Que crawlear Hacker News no es trivial (todos se toparon con esa pared)
- Que manejar dos agentes de IA en paralelo multiplica tu velocidad
- Que tu approach cambia completamente cuando no hay tiempo para dudar
- Qué partes de tu arquitectura son críticas y cuáles son nice-to-have
Esta claridad sobre los retos reales de una aplicación te permite planear mejor. Cuando entiendes que el 80% de la solución se puede lograr en una hora, puedes tomar decisiones más inteligentes sobre en qué invertir el tiempo restante. ¿Vale la pena pulir ese 20% final? ¿O es mejor usar ese tiempo para agregar otro feature que los usuarios realmente necesitan?
Más importante aún: al tener esa claridad de esa primera versión, entiendes rápido cuáles serán los retos reales de construir el 100%. ¿El scraping será el bottleneck? ¿La sincronización de datos? ¿El manejo de estado en el frontend? Al identificar estos retos en una hora, puedes después practicarlos específicamente con Katas y planear cómo resolverlos con mucha más claridad. Esta perspectiva te ayuda a construir apps más robustas y enfocadas en lo que realmente aporta valor a tus usuarios.
Los principios de RbR en acción
Lo que más nos entusiasmó de VibeRacing es cómo encarna perfectamente los pilares fundamentales de Release before Ready. No fue algo planeado - simplemente emergió naturalmente de la dinámica, y eso nos confirma que estos principios realmente capturan la esencia de lo que queremos construir como comunidad.
Craft: Versiones imperfectas, aprendizaje rápido
Nadie terminó con una solución perfecta. Santiago ganó pero su código tenía TODOs por todos lados. Luis Mi tuvo que arreglar su scraper después. Jon deployó algo hermoso pero con poca data.
Y está bien. Como dice nuestro manifiesto: "Done is better than perfect".
Comunidad: La competencia como catalizador
Durante la hora de competencia, el silencio era casi total. Cada uno en su burbuja, tecleando furiosamente. Pero apenas terminó, la mesa explotó en conversaciones:
- "¿Cómo resolviste el rate limit?"
- "¿Por qué elegiste SQLite sobre Postgres?"
- "Mira, si usas este endpoint en lugar de ese..."
La competencia no mató la colaboración - la amplificó. Ahora todos tenían un problema compartido, múltiples soluciones para comparar, y el ego suficientemente massageado (o golpeado) para estar abiertos a aprender.
En el próximo RbR, mientras algunos estarán practicando sus Katas, perfeccionando su craft con paciencia y repetición, otros estarán en VibeRacing, descubriendo qué pueden crear cuando no hay tiempo que perder.
Ambos caminos llevan al mismo lugar: ser mejores builders.
¿Y ahora qué? Necesitamos tu feedback
VibeRacing fue un experimento. Uno que nos gustó mucho, pero un experimento al fin.
Queremos saber:
- ¿Te gustaría participar en el próximo VibeRacing?
- ¿Qué tipo de retos te gustaría ver? ¿Más largos, más cortos, en equipos?
- ¿Preferirías que fuera parte del RbR o un evento separado?
- ¿Qué otras dinámicas podríamos probar?
Santiago ya está pensando en hacer "VibeRacing diario" - una hora cada día construyendo algo desde cero. Yo estoy considerando retos temáticos: solo frontend, solo DevOps, solo IA.
Pero más que nuestras ideas, queremos escuchar las tuyas.
¿Te animas a intentarlo?
Nos vemos en los próximos Release before Ready. Tenemos eventos en Bogotá (23 de agosto), Guadalajara (20 de septiembre), CDMX (18 de octubre y 8 de noviembre).
Y no olvides: compártenos tu feedback sobre VibeRacing. Esta comunidad la construimos entre todos.