# Orbit necesita a Orbit Un modelo produce más rápido de lo que alcanzas a revisar, y llega un punto donde apruebas confiando en que las pruebas pasaron. Por qué estoy construyendo Orbit, una cabina de mando para agentes de código. 13 sep 2026 · https://e1i0.com/es/orbit-necesita-a-orbit.html --- Un modelo ayuda a definir una solución: te ordena las ideas y te propone por dónde cortar. Una vez que está definida, produce más rápido de lo que puedes seguir. Me viene pasando seguido, en varios proyectos. El último fue una funcionalidad complicada de Orbit: terminó en una rama que dejé ahí, sin integrar, porque llegamos a un punto donde ni el modelo ni yo sabíamos si el resultado cumplía con lo que habíamos definido. Por eso decidí empezar a trabajar en [Orbit](https://getorbit.sh/), una cabina de mando para agentes de código. Corres varios agentes a la vez sin perder el hilo de lo que hizo cada uno, y sin vivir dentro de la terminal vigilándolos uno por uno. ## Antes de empezar a tirar código Me siento a organizar el problema antes de pedirle código a alguien, persona o modelo: qué solución quiero, con qué la voy a armar, los tradeoffs que acepto. Después decido para qué sirve la primera versión. Lo que se queda fuera suele ser la decisión más difícil, porque todo parece necesario cuando lo miras junto. Un modelo te deja abarcar más que antes, así que ahora hay más cosas que podrían entrar. Después parto eso en pedazos chicos y los agrupo en fases, cada fase con su milestone, y cada milestone escrito en términos de qué tiene que quedar funcionando cuando termine. Trato de arrancar así cada funcionalidad. ## Los guardrails A un modelo hay que decirle cómo se trabaja en tu repositorio. Algunas cosas se las dices en un documento que lee, y otras se las pones como límites que revientan la compilación si se los salta. En inglés a eso le dicen guardrails. En Orbit hay unos cuantos, estos seis entre ellos: - **300 líneas por archivo.** Pasarse rompe la compilación. - **100 columnas por línea**, y ese número solo puede bajar. La prueba que lo sostiene guarda el conteo de hoy como techo. - **16 pruebas de arquitectura** que hacen fallar la compilación por decisiones de diseño. Una salta si un paquete exporta algo que no es una puerta, otra si aparece un import fuera del mapa de capas, otra si el `go.mod` suma una dependencia que nadie argumentó. - **Seis tipos de prueba**, cada uno con su cuándo: unitarias, de propiedades, fuzzing, integración contra el binario real, mutation testing antes del pull request, y adversariales. - **90% de cobertura como piso**, con el comando saliendo en error si baja. - **Un linter** que normaliza la forma del texto. El código de Orbit lo escriben cuatro motores distintos, y sin eso tendría cuatro estilos conviviendo en el mismo repositorio. Todo se corre con un comando: ```bash make check ``` ## Del 23 de agosto al 13 de septiembre Entraron 751 commits y 143 pull requests, con actividad los 22 días seguidos. Son unas 80.500 líneas de Go de producción y otras 99.300 de pruebas, sin código de terceros copiado adentro y sin nada generado. Repartido por semana: | Semana | Commits | Pull requests | Commits por día | |---|---|---|---| | 23 a 29 de agosto | 347 | 48 | 49,6 | | 30 de agosto a 5 de septiembre | 220 | 54 | 31,4 | | 6 a 12 de septiembre | 171 | 33 | 24,4 | Cada pull request ahí es una tarea cerrada, con sus pruebas y su revisión. Nada de esa arquitectura existía antes. La estaba armando al mismo tiempo que salía el código. Ese ritmo también tiene que ver con que la idea base estaba clara. Cada funcionalidad arrancó con su definición y sus fases, y lo demás lo fui iterando sobre la marcha sin esperar a tenerlo perfecto. ## La IA va más rápido de lo que alcanzas a revisar Los guardrails hacen su trabajo. El cambio llega al pull request bien formado y con sus pruebas, así que esa parte deja de pesar en la revisión. Queda la otra pregunta: si el cambio hace lo que se pidió. Hubo días de 18 pull requests. Antes de cada uno pasas minutos mirando la consola, esperando a ver si va a terminar, si va a hacer lo que pediste, o si entendió otra cosa. Revisar cada uno, entendiendo qué tocó y por qué, desgasta rápido. Para la quinta revisión del día ya apruebas confiando en que las pruebas pasaron. ## Qué busca Orbit Le das una tarea y la deja corriendo. Puedes tener varias trabajando al mismo tiempo. - Cada tarea corre en **su propio worktree**, así que no se pisan entre ellas. - Cuando vuelves ya **está escrito lo que hizo**: los pasos que dio, lo que fue diciendo, y qué quedó afectado aparte de los archivos que tocó. - **Ninguna sube nada sola.** Se detiene antes y espera a que tú lo apruebes. - **Un supervisor revisa el trabajo antes que tú**, y puedes preguntarle qué encontró. - **Los pasos los defines tú**: los mismos milestones de antes de arrancar, cada uno con su modelo y sus permisos. [Orbit](https://getorbit.sh/) trae varios armados. ## El meme de Spiderman ![El meme de los dos Spiderman idénticos señalándose el uno al otro](https://e1i0.com/assets/images/spiderman-orbit.jpg) Llegué a la conclusión de que necesito a Orbit para poder seguir construyendo Orbit. Así que lo uso a diario mientras le voy agregando lo que falta. ## Las partes de Orbit Trabajando con un modelo pierdes lo que costó cada tarea, cuánto tardó, y lo que podrías aprender de las anteriores. Le voy a dedicar un post a cada una: 1. Arrancar 2. El menú 3. Una corrida completa 4. El autopilot 5. Varias tareas en paralelo 6. Leer lo que hizo 7. La CLI 8. El supervisor 9. Lo que Orbit sabe 10. Escribir tus propios flows 11. Cambiar de proveedor a mitad de tarea sin perder el contexto 12. El brain, cuando exista ## Puedes ir a verlo Orbit es de código abierto, con licencia Apache 2.0. Corre en macOS y Linux. Se instala con una línea: ```bash curl -fsSL https://getorbit.sh/install.sh | bash ``` El repositorio está en [github.com/e1i0r/orbit](https://github.com/e1i0r/orbit) y el sitio en [getorbit.sh](https://getorbit.sh). Los números de arriba salen del historial de git y de la API de GitHub, así que los puedes sacar tú mismo. Las 16 pruebas que sostienen el diseño están en `internal/arch`. Y si quieres meter mano, `CONTRIBUTING.md` es corto. Lo que mandes tiene que cumplir los mismos guardrails de arriba, y `make check` te lo dice antes de abrir el pull request.