Orbit necesita a Orbit

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, 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:

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:

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 trae varios armados.

El meme de Spiderman

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:

curl -fsSL https://getorbit.sh/install.sh | bash

El repositorio está en github.com/e1i0r/orbit y el sitio en 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.