Qué es realmente un lanzamiento de 127 commits

Hay una versión de este artículo que simplemente enumera todo lo que trae GeekBye v1.7.0 — una pantalla de inicio rediseñada, un flujo de calibración, una barra lateral plegable, ajustes nuevos, y así sin parar. Sería exacta y no te enseñaría nada. Porque la historia honesta de un lanzamiento de 127 commits no es la lista. Es la forma.

Aquí está la forma. Ciento veintisiete commits suenan a ciento veintisiete cositas. Casi nunca lo son. v1.7.0 fueron dos grandes funciones, construidas en paralelo sobre ramas de larga duración durante unos once días, entretejidas al final. Entender un lanzamiento grande significa entender esas dos hebras — y el único lugar donde construimos algo en el sitio equivocado y tuvimos que arrancarlo en pleno vuelo.

Hebra uno: calibración

La primera hebra era la calibración — una evaluación por voz con IA de tus habilidades de comunicación. Inicias una llamada en vivo con un "coach de carrera" de IA, recorres un conjunto estructurado de fases (calentamiento, comportamental, comunicación técnica, respuesta bajo presión, fijación de objetivos), y al final te puntúan en seis dimensiones: confianza, claridad, concreción, involucración, compostura, relevancia. Por debajo también mide métricas concretas del habla: tu ritmo al hablar, la frecuencia de muletillas, si tus pausas se leen como estratégicas o dubitativas.

El resultado no es una nota, es un punto de partida. La calibración produce tus fortalezas, tus áreas de mejora y — crucialmente — una dificultad recomendada para empezar a practicar. Calibra dónde debería encontrarte el producto. Cada habilidad vuelve como una tarjeta de feedback expandible con un resumen, una sugerencia concreta y una frase citada literal de tu propia llamada como ejemplo. Es la función sobre la que se construye el resto de la experiencia de práctica.

Hebra dos: una ventana totalmente nueva

La segunda hebra era un rediseño premium — y llamarlo rediseño lo infravalora. No era un reskin de las pantallas existentes; era en la práctica una segunda ventana de la aplicación, desarrollada en seis fases explícitas: una barra lateral plegable estilo Notion, un desplegable de cabecera que sustituyó la antigua lista de sesiones, navegación estilo navegador con historial y migas de pan, y reconstrucciones premium de Inicio, Perfiles, Reuniones y Ajustes.

Dos grandes funciones. Eso fueron en realidad 127 commits. Y la parte más difícil de lanzarlas no fue escribir ninguna de las dos — fue el entretejido. Las dos ramas eran interdependientes; una se fusionó dentro de la otra, y la rama de calibración tuvo que traer la rama main cuatro veces distintas solo para no desviarse mientras el rediseño se movía debajo. El número de commits no es el coste de un lanzamiento grande. Lo son las ramas de larga duración y el orden de integración.

La parte que vale la lectura: construimos la calibración en el lugar equivocado

Aquí está el error, y es uno bueno porque es muy común.

GeekBye tiene una regla arquitectónica firme: todas las operaciones de IA viven en el backend. El cliente es una carcasa fina que habla con un servidor. Todo el mundo lo sabía.

Y aun así la calibración se construyó primero en la base de datos local del cliente. Una tabla dedicada, una migración de base de datos, un repositorio de 254 líneas, handlers de IPC y un banco de 515 líneas de preguntas de evaluación — todo viviendo en la máquina del usuario. Funcionaba. También violaba silenciosamente el contrato sobre el que se construye toda la app.

Tres días después, un commit borró 680 líneas repartidas en ocho archivos para llevarlo todo al backend, donde los datos de calibración pasaron a ser un modelo propio del lado del servidor, y la lógica de preguntas y la puntuación pasaron a ser una preocupación del servidor. Otro commit borró de raíz el banco de preguntas de 515 líneas del cliente. El diff es casi gracioso: una inserción, seiscientas ochenta eliminaciones.

Nadie se propuso escribir 680 líneas de código desechable. Pasó como siempre pasa esto: el atajo del cliente está ahí mismo, es más rápido prototipar en local, y "ya lo movemos al backend después" parece inofensivo. Pero cuando tu arquitectura ya te dice dónde vive la fuente de la verdad, construirlo en cualquier otro sitio no es un atajo — es retrabajo que te has agendado a ti mismo por adelantado. La lección que caló: ponlo donde dice el contrato, a la primera, incluso cuando la versión local sea más rápida de levantar.

El bug que solo la integración podía encontrar

Un recibo más, porque es el modo de fallo característico de los lanzamientos grandes. Una vez que la calibración y la nueva navegación quedaron conectadas y corriendo de verdad, la app empezó a hacer saltar un límite de tasa — HTTP 429 — sin motivo aparente.

La causa era pura integración. El estado de la calibración se pedía a nivel de componente, así que cada navegación lo volvía a pedir — y el strict mode de React, que invoca los effects a propósito dos veces en desarrollo para destapar bugs, lo duplicó de nuevo. El resultado fueron de cuatro a ocho peticiones de calibración idénticas disparándose por cada cambio de pantalla, suficientes para hacer saltar el limitador de tasa del servidor. El arreglo consolidó el fetching a un par de llamadas en el montaje.

No podrías haber encontrado este bug probando la calibración sola, ni la navegación sola. Solo existe en la costura — donde se encuentran dos funciones independientemente correctas. Ese es el impuesto que cobra un lanzamiento grande: la última milla no es construir las funciones, es descubrir todo lo que solo se rompe cuando por fin están en la misma sala.

Tres cosas que enseñó un lanzamiento grande

1. Un lanzamiento de 127 commits son dos o tres grandes temas, no cien pequeños. Encuentra las hebras. El trabajo — y el riesgo — vive en cómo se entretejen, no en el número.
2. Pon la fuente de la verdad donde dice el contrato que vive, a la primera. Borramos 680 líneas reubicando la calibración del cliente al backend. El atajo local es retrabajo agendado por adelantado; la arquitectura ya te dio la respuesta.
3. La integración destapa fallos que el aislamiento no puede. La tormenta de 429 vivía en la costura entre dos funciones correctas y solo apareció cuando corrieron juntas. Presupuesta una pasada de integración, no solo pruebas por función.

Este es un primo de la era v1 de una historia que volveríamos a contar a una escala mucho mayor — mira qué exige de verdad una versión 2: 206 commits de estados honestos (v2.0.0), donde la misma verdad de "un número grande son en realidad unas pocas ideas grandes" se despliega por toda la reescritura de v2. Para el capítulo anterior en la historia de v1, cómo transmitir un informe en vivo sin el parpadeo (v1.6.13); y para todo el arco, la anatomía de publicar software hasta la perfección.