¿Y si el cuello de botella del desarrollo con IA ya no fuera generar código, sino decidir qué cambios pueden integrarse con seguridad? Esa es la apuesta de Entire, la empresa de Thomas Dohmke, antiguo CEO de GitHub.

El 26 de octubre de 2026, Entire presentó su plataforma completa de alojamiento y colaboración Git para equipos que trabajan con agentes. No se limita a añadir un bot de comentarios a un pull request: quiere que la evaluación continua del cambio, el historial de sesiones y el despliegue formen parte de un mismo flujo.

La novedad merece atención, pero conviene separar tres cosas: lo que ya está disponible, las cifras que anuncia el proveedor y lo que todavía debe demostrar en equipos reales.

El problema: los agentes generan cambios más deprisa que los equipos los revisan

En el flujo habitual, un desarrollador abre un pull request, alguien revisa el diff, CI ejecuta pruebas y aparecen comentarios. Con varios agentes de programación y revisión trabajando en paralelo, la conversación puede convertirse en una secuencia interminable de hallazgos, correcciones y nuevas ejecuciones.

Entire propone cambiar la pregunta: en vez de buscar el último comentario que indique «todo bien», presentar un estado verificable del cambio, con evaluaciones por cada nuevo push, hallazgos pendientes, tendencia de resultados y restricciones explícitas para permitir el merge.

Es una apuesta de producto, no una prueba de que los pull requests hayan dejado de servir. Muchos equipos ya coordinan revisores automáticos y tests sobre GitHub; Entire busca convertir esa coordinación en la interfaz principal.

1. Trails: del diff como centro a las evaluaciones por cada push

La pieza central se llama Trail. Puede iniciarse desde una incidencia o un agente, e incluso agrupar cambios que afectan a varios repositorios. Su ciclo es:

  1. Un agente o desarrollador propone un cambio y hace push.
  2. Agentes evaluadores independientes lo analizan en entornos cloud aislados y publican puntuaciones, explicación y hallazgos. Entire ofrece evaluadores de calidad, seguridad y slop (código de baja calidad o innecesariamente complejo), además de evaluadores configurables.
  3. El agente de implementación corrige los hallazgos y vuelve a publicar. La interfaz conserva la ejecución actual y las cinco anteriores para mostrar si la calidad converge.
  4. Los Gates del repositorio pueden exigir hallazgos resueltos, CI satisfactorio y aprobación humana antes del merge.

Entire indica que usa Claude Code y Codex para evaluaciones en sandboxes de Daytona y E2B. Eso es distinto de una garantía de corrección: una puntuación verde no demuestra por sí sola ausencia de vulnerabilidades o bugs. Las pruebas, la autorización y la política de cada proyecto siguen siendo indispensables.

Flujo tradicionalEnfoque de Entire
Pull request y cronología de comentariosTrail con evaluaciones visibles en primer plano
Revisiones con resultados dispersosResultados por push e historial de iteraciones
CI como estado anexo a la conversaciónCI integrado con los Gates de merge
Contexto del agente guardado aparte, si existeSesiones vinculadas al trabajo y al repositorio

Matiz importante: Entire no elimina necesariamente a las personas del proceso. La exigencia de aprobación humana es configurable; no debe confundirse la posibilidad técnica de merge sin leer cada línea con una práctica universalmente segura.

2. Git distribuido: 89 veces más rápido, pero ¿en qué medida?

Entire permite alojar repositorios privados y replicarlos entre regiones de Estados Unidos, Europa, India y Australia. Su servidor sigue siendo compatible con Git, aunque utiliza una arquitectura propia de almacenamiento de objetos y gestión transaccional de referencias.

La compañía publica un benchmark abierto en el que alcanza 418 pushes por segundo, frente a 4,7 de GitHub y 65 de Cursor Origin: de ahí provienen los titulares de hasta 89× y 6×.

Son mediciones publicadas por Entire bajo su escenario de prueba, no una mejora demostrada para cualquier repositorio ni un benchmark independiente. Tampoco equivalen a un build o despliegue 89 veces más rápido.

De hecho, cuando se usa el modo mirror y GitHub permanece como fuente de verdad, el tráfico de push sigue pasando por GitHub. Ese modo permite probar Trails sin migrar, pero no hereda automáticamente las ventajas de velocidad del hosting nativo.

3. Continuous Memory: conservar el porqué, no solo el qué

Quizá la propuesta más duradera sea Continuous Memory: que los agentes puedan recuperar decisiones y contexto de sesiones anteriores sin empezar cada tarea desde cero.

Entire presenta dos componentes abiertos y locales:

  • entire-graph: construye un mapa consultable del código —definiciones, llamadas, rutas e impacto de cambios— con análisis local mediante tree-sitter, sin peticiones de red o al modelo para construirlo.
  • entire-brain: vincula ese mapa con sesiones y prompts capturados en el historial del repositorio para recuperar el razonamiento práctico detrás de decisiones pasadas. Puede conectarse al backend de Entire para compartir memoria entre agentes.

Entire afirma que entire-graph ahorró hasta un 71 % de tokens en sus pruebas. La cifra no significa que Entire reduzca un 71 % todas las facturas de IA: depende del workload y del método de comparación.

Hay un asunto operativo que no conviene perder de vista: persistir prompts y sesiones puede exponer secretos, datos personales o contexto sensible si no se define retención, filtrado y control de acceso antes de sincronizar esos registros.

4. CI y lo que falta por llegar

El lanzamiento incorpora integraciones de CI con Buildkite y Depot. Buildkite ofrece conversión de pipelines, y Depot permite reutilizar flujos compatibles con GitHub Actions. Esto no significa que GitHub Actions funcione nativamente dentro de Entire sin adaptación.

A 27 de octubre de 2026, Entire indica que los repositorios públicos, los nodos Git autoalojados y más integraciones todavía están en la hoja de ruta. Por eso una migración completa es prematura para proyectos open source que dependen de alojamiento público.

La empresa anunció en febrero una ronda semilla de 60 millones de dólares. Esa financiación aporta contexto empresarial, pero no valida por sí misma el rendimiento o la precisión de sus agentes evaluadores.

¿Conviene migrar desde GitHub hoy?

Para un equipo pequeño o mediano que ya dispone de control de revisión, tests y despliegue confiables, no parece necesario migrar de inmediato. Sí tiene sentido estudiar un experimento acotado, especialmente cuando varias revisiones automáticas generan fricción.

Una prueba razonable sería:

  1. Elegir un repositorio privado no crítico y mantener GitHub como origen mediante mirror.
  2. Probar Trails con evaluadores y criterios explícitos; comparar hallazgos con los del sistema actual.
  3. Mantener los tests, controles de permisos y la aprobación humana para cambios sensibles.
  4. Medir falsos positivos, defectos omitidos, tiempo hasta merge, número de iteraciones y costo de tokens.
  5. Evaluar Continuous Memory sobre sesiones depuradas de secretos antes de almacenar trazas reales.

Esta es una recomendación editorial, no un procedimiento oficial de Entire.

Conclusión: el próximo cuello de botella es la confianza

El lanzamiento de Entire no significa que GitHub haya quedado obsoleto. Significa que ya existe un competidor que trata el trabajo de los agentes y sus evaluaciones como objetos centrales de la plataforma, no como mensajes adicionales en un PR.

El cambio de paradigma interesante no es «la IA escribe y la IA aprueba». Es este: si los agentes multiplican la producción de cambios, los mecanismos de evidencia, auditoría y control deben mejorar al mismo ritmo.

Que Trails consiga hacerlo mejor que un flujo GitHub cuidadosamente automatizado todavía exige pruebas independientes y experiencia operativa. Hasta entonces, la innovación más útil puede ser adoptar el ciclo de evaluaciones y la memoria persistente sin cambiar precipitadamente la infraestructura que ya funciona.

Fuentes