632 Commits en 84 Días: Lo Que Aprendimos Al Enviar Todos los Días

El número que cuenta la historia

632 commits. 84 días. Cero días sin un commit.

Desde el 21 de noviembre de 2025 hasta el 13 de febrero de 2026, enviamos código todos los días. Días de semana. Fines de semana. Feriados. Navidad. Año Nuevo. Cada día.

Esto no se trata de la cultura del esfuerzo o de trabajar sin parar. Se trata de lo que sucede cuando mantienes el impulso en un producto que está creciendo más rápido de lo que planeaste.

El ritmo diario de envío

Así es como se ven realmente 7.5 commits por día:

Mañana: Revisa lo que se envió durante la noche (recuerda, la IA resuelve problemas a las 3 AM). Verifica el entorno de staging. Identifica qué sigue.

Mediodía: Envía la característica principal del día. Esto suele ser un PR con 3-5 commits: la característica, una corrección descubierta durante el desarrollo y un aumento de versión.

Noche: Pulir, corregir casos extremos, actualizar dependencias. Los commits que no son glamorosos pero mantienen el producto funcionando sin problemas.

Algunos días tuvieron un commit. Algunos días tuvieron veinte. El 22 de noviembre — día dos — tuvo doce commits. El día que integramos los sandboxes de E2B tuvo más de una docena. El patrón varía, pero la racha nunca se rompió.

Cómo se ve el envío compuesto

Lo más interesante de enviar todos los días no es ningún commit individual. Es el efecto compuesto.

Semana 1: Interfaz de chat + sistema de archivos + espacios de trabajo. Un producto funcional.

Semana 2: Facturación + internacionalización + bibliotecas de UI. Un producto sostenible.

Semana 4: Programación + incorporación + ejecución de código. Un producto útil.

Semana 8: Generación de imágenes + habilidades + selección de modelos. Una plataforma.

Semana 12: Ejecución en sandbox + agentes en segundo plano + CI autónomo. Una plataforma autónoma.

Cada semana se basa en la anterior. Las características no existen en aislamiento — se combinan. Programación + sandboxes = ejecución de tareas en segundo plano. Facturación + generación de imágenes = herramientas creativas sostenibles. Habilidades + sandboxes = mercado de automatización seguro.

El efecto compuesto significa que la producción de la semana 12 es cualitativamente diferente de la de la semana 1, no solo cuantitativamente mayor. No solo estamos construyendo más características. Estamos construyendo combinaciones de características más capaces.

Los commits que más importan

Si desplazas hacia abajo nuestra historia de git, encontrarás tres tipos de commits:

Los constructores. “feat: agregar módulo de agentes en sandbox,” “feat: agregar panel de configuración de espacios de trabajo,” “feat: agregar sistema de habilidades con importación de ClawHub.” Estas son las grandes características. Tienen las publicaciones en el blog. Aparecen en los changelogs.

Los solucionadores. “fix: prevenir bucle de sondeo de mensajes infinito,” “fix: eliminar eventos en cascada al eliminar sesión,” “fix: incrustar URLs de imágenes en markdown para prevenir corrupción de URLs en LLM.” Estos son menos glamorosos pero, argumentablemente, más importantes. Cada uno representa a un usuario real enfrentando un problema real.

Las mejoras invisibles. “chore: aumentar @fulldiveVR/chat-ui a 2.0.12,” “refactor: dirigir todas las llamadas de juez a través de OpenRouter,” “perf: agregar registros de trazado de PERF.” Estos no cambian lo que los usuarios ven, pero cambian cuán bien funciona. Mejoras de rendimiento. Parcheos de seguridad. Actualizaciones de dependencias.

La proporción es aproximadamente 30% constructores, 40% solucionadores, 30% invisibles. Esa proporción se siente saludable. Demasiados constructores y no suficientes solucionadores significa que los errores crecen. Demasiados solucionadores y no suficientes constructores significa estancamiento. Muy pocos commits invisibles significa acumular deuda.

Las fiestas

28 de noviembre (Acción de Gracias): 14 commits. Mejoras de plantillas, correcciones de bibliotecas de UI, modernización de agentes.

25 de diciembre (Navidad): 6 commits. Resolutor automático de problemas, protección de suscripciones, automatización de flujos de trabajo.

1 de enero (Año Nuevo): 8 commits. Correcciones de favicon, mejoras en sesiones, compartición de archivos.

No estamos presumiendo de trabajar en días festivos. Algunos de estos fueron fusiones programadas. Algunos fueron la IA corrigiendo cosas de manera autónoma. Algunos fueron un fundador que no podía dejar de pensar en un error.

El punto no es “trabajamos en Navidad.” El punto es “el producto mejoró en Navidad.” Ya sea que esa mejora viniera de un humano o de una IA, a los usuarios no les importa. Solo ven un mejor producto cuando lo abren la próxima vez.

Lo que aprendimos

Envía la unidad significativa más pequeña. No toda la característica. La cosa más pequeña que mejora el producto. Un botón que funciona. Un error que se maneja. Una etiqueta que es más clara. Los commits pequeños son fáciles de revisar, fáciles de revertir y fáciles de entender.

Corrige errores el día que se encuentran. Nuestro tiempo promedio desde el informe de un error hasta la corrección se mide en horas, no en días. Esto solo es posible porque enviamos todos los días. Un equipo que envía semanalmente retiene errores durante una semana. Un equipo que envía diariamente los corrige hoy.

Deja que la racha te motive. Hay algo psicológico en una racha diaria. Una vez que has enviado durante 30 días seguidos, no quieres romperla en el día 31. La racha se convierte en su propia motivación. No es sostenible para siempre — y tomaremos descansos — pero para una fase de lanzamiento, es poderosa.

El compuesto es real. El commit del día 84 es cualitativamente diferente del commit del día 1. No porque seamos más inteligentes. Porque estamos construyendo sobre 83 días de base. Cada día hace que el siguiente día sea más productivo. Ese es el verdadero poder del envío diario.

632 commits. 84 días. Un producto que pasó de nada a una plataforma de agente de IA autónoma.

Los próximos 84 días serán aún mejores.