Hace tres semanas, Mitchell Hashimoto — GitHub user #1299, co-fundador de HashiCorp, la persona que probablemente le debe más de su carrera a GitHub que casi cualquier otro referente del open source — anunció que movía Ghostty fuera de la plataforma.
No fue una decisión impulsiva. Pasó un mes llevando un diario, marcando con una “X” cada día en que una caída de GitHub le bloqueó la capacidad de trabajar. Casi todos los días tenían una X.
“This is no longer a place for serious work if it just blocks you out for hours per day, every day”, escribió. Y se cuidó de aclarar: el problema no es Git. El problema es la infraestructura construida alrededor — issues, PRs, Actions.
Esa distinción importa. Y apunta a algo más grande que una queja de disponibilidad.
El problema estructural del que nadie hablaba
La degradación de GitHub no es aleatoria. Un flujo masivo de agentes de coding está empujando la plataforma al límite — inundándola con pull requests a una escala y cadencia para la que el sistema nunca fue diseñado.
Git fue construido para humanos. Los humanos hacen commit cuando terminan algo. Abren PRs con intención, las revisan, las cierran. Hay un throttle natural incorporado al ritmo humano. Los agentes no tienen ese throttle. Commitean de forma continua. Abren PRs en paralelo. Pushean a velocidad de máquina, en volumen, sin parar.
La infraestructura alrededor de Git — los issue trackers, los runners de CI, las colas de PR — fue diseñada con el throughput humano como baseline implícito. Nadie arquitectó para 50 PRs generadas por agentes simultáneamente sobre el mismo repositorio. Y ahora están llegando.
Este es un problema de diseño de sistemas disfrazado de problema de confiabilidad. GitHub puede parchear servidores y agregar capacidad, pero la incompatibilidad fundamental entre un modelo de control de versiones pensado para ritmo humano y las tasas de commit a velocidad de agente no se resuelve tirando hardware encima.
Por qué Jujutsu es el candidato serio a mirar
Hay varias alternativas a Git que están recibiendo atención ahora mismo. Pero la que vale la pena observar es Jujutsu — conocida como jj en la línea de comandos.
Jujutsu es un sistema de control de versiones open source escrito en Rust, creado por Martin von Zweigbergk en Google. Tiene más de 27.000 GitHub stars y se usa internamente en Google — lo que lo convierte en la alternativa Git-compatible más validada en producción disponible en 2026.
La palabra clave es compatible. jj no te pide que abandones Git. Es un VCS Git-compatible diseñado para simplificar tareas cotidianas y reducir el riesgo de errores costosos — no un reemplazo de Git sino una interfaz alternativa sobre repositorios Git existentes, que permite adoptarlo de forma incremental sin romper los workflows actuales.
Pero la filosofía de diseño de jj es lo que lo hace genuinamente interesante para la era de los agentes.
Git gira en torno a commits. jj gira en torno a changesets — trata el trabajo como mutable por defecto. No hay dirty state que gestionar, no hay flujo de stash-primero para cambiar de contexto. Todo vive en el mismo modelo. Tu working copy ya es siempre un changeset.
Esto tiene implicaciones profundas para el código generado por agentes. Los agentes no piensan en ritmos de commit humanos. Producen cambio continuo. Un VCS que trata el working copy como un estado permanente y rastreado — en lugar de un borrador sin guardar — se adapta mejor a los flujos de trabajo a velocidad de agente que cualquier cosa que Git ofrece hoy.
Y después está el operation log: jj registra las operaciones del repositorio, no solo los commits. Si algo sale mal con un split, un rebase o una reescritura, podés revertir el repositorio completo a un estado anterior. Para los equipos que supervisan agentes — donde genuinamente no sabés qué acaba de hacerle el agente a tu repo — esto es menos un nice-to-have y más un requisito.
El operation log de jj captura el estado completo del repositorio en cada punto. Es más parecido a Time Machine para tu repo que cualquier cosa que Git ofrece de forma nativa.
Qué significa esto para los líderes técnicos
Quiero ser claro sobre lo que no estoy diciendo. No estoy diciendo que GitHub vaya a desaparecer, ni que debas migrar toda tu organización a jj mañana.
Lo que sí estoy diciendo es que la historia de Hashimoto es una señal, no un incidente aislado. Cuando un desarrollador con 18 años de trayectoria y la credencial de ser el user #1299 se va de GitHub citando bloqueos diarios de workflow, le prestás atención. No por el drama, sino por lo que revela sobre la arquitectura subyacente.
Las herramientas en las que confían nuestros equipos fueron construidas para desarrollo a ritmo humano. El mundo del desarrollo cambió. Los agentes ahora commitean código. La infraestructura no se puso al día.
jj está diseñado para hacer fácil el desarrollo en paralelo — una excelente opción para los estilos de desarrollo modernos donde tenés IA generando código, comparando variaciones y en constante prueba y error.
Eso no es copy de marketing. Es una descripción de lo que cada equipo que corre agentes de coding está haciendo en realidad.
Los equipos que van a tener ventaja en los próximos 18 meses no son los que tienen los mejores modelos. Son los que pensaron seriamente sobre su infraestructura de control de versiones. Hoy, la mayoría no lo hizo.
Por dónde empezar
jj se instala junto a tu setup de Git existente. Como jj escribe commits estándar de Git, volver a Git puro en cualquier momento no requiere ningún esfuerzo de migración. Es un experimento de muy bajo costo para una mejora de infraestructura de potencialmente alto valor.
El repo: github.com/jj-vcs/jj