Es la parte 3 de la serie sobre Orbit. En la primera conté qué es y cómo se arranca. Esta va de cómo corre una tarea.
Revisar todo al final es lo más pesado
Si le das una tarea a un agente y lo dejas trabajar hasta que termine, te toca revisar todo de una vez. Y si se equivocó en algo al principio, ese error ya está metido debajo de cientos de líneas que se ven bien.
Orbit parte la tarea en fases
Por eso en Orbit una tarea va por fases. La que viene por defecto tiene dos, una implementa y otra revisa. Son pedazos más chicos, y si algo sale mal en uno lo ves antes de que el siguiente siga construyendo.
Si las pruebas fallan, la fase se repite
Después de una fase pueden correr las pruebas del proyecto. En el video, el agente hace el cambio sin escribir pruebas, las pruebas no pasan y la fase vuelve a correr. La segunda vez escribe la prueba y pasa.
En ese segundo intento el agente sabe qué hizo el primero y qué dijeron las pruebas, así que no arranca de cero. Por defecto tiene tres intentos, y si no lo logra, la tarea se queda esperándote.
La tarea te espera antes de la revisión
Algunas fases te esperan antes de arrancar. En la que viene por defecto es la revisión: el agente termina de implementar y la tarea se queda quieta hasta que la miras. Cuando le das el visto bueno, sigue. En tus propios flujos decides dónde van esas paradas.
Mientras tanto todo pasa en un worktree aparte, y a tu copia del repositorio no entra nada hasta que tú digas.
Al final te queda lo que pasó en cada fase
Cuando termina, la tarea guarda lo que pasó en cada fase: si pasaron las pruebas, lo que costó y lo que le pidieron al agente, en pasos cortos que se leen rápido.
En el video sale una tarea completa sobre un repositorio de ejemplo, y en getorbit.sh hay uno por cada funcionalidad.