El 23 de julio nos juntamos de nuevo con la comunidad de Ruby en Buenos Aires. Fuimos sponsors del Ruby Sur Meetup en La Maquinita Innovation Lab, el mismo espacio donde ya habíamos estado con la comunidad de React unas semanas antes. Puesta la comida, las pantallas y el lugar, la noche quedó armada para dos charlas que terminaron generando bastante más pregunta de la que cualquiera esperaba.
El costo real de elegir mal tu primary key
Santiago Merlo, Rails Senior Developer en Rootstrap, abrió la noche con una charla que arrancó de una discusión de pasillo: un compañero suyo estaba trabajando en un proyecto legacy que usaba UUID como primary key, y a Santiago la decisión le pareció rara. En vez de quedarse con la duda, se puso a benchmarkear.
Los números que mostró fueron contundentes. Usar UUID versión cuatro como primary key en Postgres, comparado con un BIGINT tradicional, significa perder más del cuarenta por ciento de velocidad de escritura y sumar hasta un cincuenta por ciento de fragmentación en el índice B-tree. La versión siete de UUID mejora bastante ese panorama, pero sigue ocupando el doble de espacio que un entero. La alternativa que más lo convenció fue un enfoque híbrido: usar un BIGINT como primary key interno de la base de datos, y exponer un UUID hacia afuera para no filtrar información como el volumen de registros o el orden de creación.
La charla generó preguntas técnicas de las buenas: qué pasa con las colisiones de ID en un blue-green deployment, si conviene un microservicio dedicado solo a generar UUIDs únicos, y hasta una anécdota sobre un sistema de registro de mascotas en Reino Unido que usa strings de cuatro caracteres para escribir números romanos, y se queda sin combinaciones antes de llegar a los cuarenta.
Cuando un cliente prefiere pagar tokens antes que pagar sueldos
La segunda charla fue de Patricio Mac Adden, co-fundador de Sinaptia, y arrancó con una historia que dejó la sala en silencio: hace unos meses, un cliente de su empresa avisó que iba a reducir el equipo humano porque prefería gastar ese presupuesto en tokens de IA en vez de en gente. Quería mover el desarrollo hacia specs y agentes que trabajaran solos, sin acompañamiento.
De esa crisis salió la charla. Patricio repasó cómo pasamos del autocompletado de Copilot a los agentes que hoy pueden planificar, escribir código y hasta corregirse solos, y por qué eso cambia las reglas del juego: generar código ya es barato, pero equivocarse sigue costando lo mismo o más. Habló de vibe coding versus desarrollo guiado por especificaciones, de harness engineering, y probó en carne propia varias herramientas (Claude Code, OpenCode, agentes minimalistas como Pi) hasta encontrar la que le sacaba de encima la fricción sin sacarle el control.
Su consejo central fue simple de decir y difícil de aplicar: no delegues el pensar. Puedes dejar que el agente escriba el código, pero la planificación y el entendimiento de por qué se hace algo tienen que seguir siendo tuyos. Ese mismo criterio se extendió a la charla con el público: usar skills locales por proyecto en vez de skills globales, para no terminar con los mismos problemas de inconsistencia que ya tenías con equipos humanos grandes.
Lo que se llevó la comunidad
Ruby Sur es una comunidad que ya lleva más de treinta meetups y varios miles de mates encima, y esta edición sumó otra noche de charlas que valieron la pena, comida y networking hasta tarde. Antes de despedirse, hubo sorteo de un parlante JBL entre los que se quedaron hasta el final.
Al día siguiente, la propia organización de Ruby Sur agradeció públicamente el sponsoreo de Howdy en sus redes, y ya quedaron pensando en la próxima edición. Nosotros también. Cuando una charla sobre primary keys termina con la sala haciendo preguntas de arquitectura real, y una charla sobre IA termina con la sala repensando cómo trabaja todos los días, la meetup cumplió su función.
