Entire lanza Git forge para agentes y personas

El anuncio es una propuesta de flujo de trabajo, no un cambio universal en Git ni una prueba de que los pull requests dejaron de ser útiles. La página de Entire no informa la hora de publicación y los números de desempeño son declaraciones de la propia empresa.

En este artículo vas a ver:

• Lo que Entire lanzó
• Cómo el Trail organiza la revisión
• Qué demuestran los números de Entire y qué no demuestran
• Cómo evaluar la plataforma antes de migrar

Lo que Entire lanzó

Entire describe el producto como una forge Git independiente para colaboración entre agentes de programación y desarrolladores. Una forge es una plataforma que hospeda repositorios Git y añade recursos para revisar e integrar cambios.

El diferencial anunciado es reunir el repositorio, los rastros de las sesiones de los agentes y evaluaciones automatizadas en el mismo flujo. En lugar de mostrar solo una diferencia entre versiones, la propuesta es registrar el objetivo, el trabajo del agente y el resultado que el equipo necesita validar.

La empresa dice que el servicio está disponible para desarrolladores y que los repositorios privados pueden hospedarse en regiones en Estados Unidos, en la Unión Europea, en India y en Australia. La misma página lista hospedaje propio de nodos Git, repositorios públicos y más integraciones como ítems previstos, no como recursos ya entregados.

Entire también anunció integraciones de CI con Buildkite y Depot. CI, o integración continua, ejecuta etapas de compilación y prueba cuando el código cambia. La página dice que los equipos pueden adaptar flujos existentes de GitHub Actions para esos socios.

Cómo el Trail organiza la revisión

El Trail es la unidad de trabajo presentada por Entire. Cada Trail reúne una idea, los cambios hechos por el agente y el resultado producido, para que la revisión acompañe más contexto que un diff aislado.

La plataforma puede ejecutar evaluaciones a cada envío de código. Según la empresa, los agentes analizan los resultados y pueden trabajar en correcciones hasta que se cumplan los criterios definidos. Una persona aún necesita decidir si los criterios son suficientes y si el cambio puede integrarse.

La demostración oficial del producto muestra indicadores visuales llamados Confidence, Slope y Drift. Muestran cómo Entire pretende presentar el estado de una evaluación, pero el video no prueba que esas medidas detecten todos los defectos posibles.

El Cursor Agent SDK también trata a los agentes como componentes de software. La diferencia anunciada por Entire es colocar el rastro del agente junto al hospedaje Git y al proceso de revisión, en vez de enfocarse solo en la definición del agente.

Lo que demuestran los números de Entire

Entire afirma que sus pushes son hasta 89 veces más rápidos que en GitHub y seis veces más rápidos que en Cursor Origin. Son resultados divulgados por la propia empresa en el anuncio del producto, no un benchmark independiente presentado junto con la metodología completa.

Por eso, esos factores no deben leerse como una predicción para cualquier repositorio. El rendimiento puede variar según el tamaño del proyecto, la red, la región, el cliente Git y la configuración. El equipo debe medir su propio flujo antes de asumir que una operación será más rápida.

Otro componente es Continuous Memory, un sistema que registra sesiones en el repositorio y permite que los agentes consulten ese historial. Entire describe un grafo de la base de código que ayuda a localizar relaciones entre archivos y afirma que puede reducir el uso de tokens hasta en un 71 por ciento.

Ese porcentaje también es una afirmación de la empresa. El anuncio no presenta una evaluación externa con los datos y las tareas necesarias para reproducir el resultado. Sirve como hipótesis para probar, no como garantía de ahorro en todos los proyectos.

El paquete combina hospedaje, revisión y memoria de agentes. Para equipos que ya tienen procesos maduros en GitHub, la cuestión central no es solo la velocidad del push. Es saber si los datos, los permisos, las automatizaciones y la trazabilidad de auditoría siguen siendo adecuados después del cambio.

Cómo evaluar la plataforma antes de migrar

Comienza con un repositorio de prueba, no con el proyecto más crítico. Haz push, crea un cambio pequeño, ejecuta la CI y observa lo que registra Trail. Compara la experiencia con el flujo actual sin eliminar la copia original.

Define qué verificaciones son obligatorias. Las pruebas unitarias, las pruebas de integración, el análisis estático y la revisión de una persona responden a preguntas diferentes. Una evaluación automatizada solo cubre lo que se incluyó en tus criterios y puede dejar riesgos fuera de ellos.

Revisa cómo quedan los permisos de agentes, usuarios e integraciones. Verifica quién puede leer un repositorio, iniciar una acción, aprobar un resultado y acceder a los registros de sesiones. Para proyectos sensibles, confirma la retención de datos, la recuperación ante incidentes y las opciones de exportación en la documentación de Entire.

También vale la pena probar la portabilidad. Usa Git para clonar y comparar un repositorio, verifica los flujos de CI y confirma cómo migrar historial y automatizaciones. La compatibilidad anunciada reduce la barrera de entrada, pero no elimina el trabajo de validar hooks, claves y pipelines.

El equipo que usa Codex puede comparar este flujo con una guía para crear sistemas con IA usando Codex. El punto en común es dividir implementación, pruebas y revisión, manteniendo criterios explícitos para que una persona pueda verificar la entrega.

Cómo ver la demostración oficial de Entire Trails

Entire publicó un video corto que muestra la presentación visual de Trails y sus indicadores de evaluación. Ayuda a entender la interfaz propuesta, pero no sustituye un análisis de seguridad, una prueba de migración o la lectura de los términos y la documentación.

La nueva forge merece una evaluación práctica por parte de equipos que quieren conectar el trabajo de agentes con los repositorios y la CI. El principal cuidado es tratar métricas, automatizaciones y promesas de revisión como recursos a validar, no como sustitutos automáticos del proceso de ingeniería.