Orca: cómo trabajo con varios agentes de código a la vez

¡Hola! Si llegaste acá es porque ya usas algún agente de código en la terminal (Claude Code, Codex, Cursor CLI o parecido) y te pasó lo mismo que a mí: le das una tarea, te quedas esperando, y cuando termina recién puedes pedirle la siguiente. Un agente, una rama, una cola. En esta entrada te cuento cómo cambié eso con Orca y cuál es el flujo que uso todos los días.

Qué es Orca y por qué no es otro IDE

Orca es una aplicación de escritorio, gratuita y open source, para correr varios agentes de código en paralelo. No trae un modelo propio: lanza los agentes que ya tienes, con la suscripción que ya pagas, y los pone uno al lado del otro.

La gente de Orca lo llama ADE, Agent Development Environment, y la diferencia con un IDE es más conceptual que de interfaz. Un IDE gira alrededor del editor, o sea, de una persona tecleando. Un ADE junta en una sola app lo que necesitan los agentes para trabajar sin pisarse: copias aisladas del repo, terminales, un navegador por tarea, revisión de diffs y una línea de comandos que los propios agentes pueden usar. Mi forma de explicarlo: el IDE es tu escritorio; el ADE es el taller donde trabajan tú y tu equipo de agentes.

Un detalle que me importaba antes de adoptarlo: no reemplaza a git. Cada pieza es un worktree de git real y puedes entrar por terminal y usar git como siempre.

El flujo en una línea

Todo el trabajo en Orca se resume así:

Proyecto → Worktree → Agente → Splits → Diff → Ship

Vamos paso por paso, con cada término explicado en el momento en que aparece.

1. Proyecto: el repo que agregas

Lo primero es agregar un proyecto, que es simplemente un repositorio git. Orca lee su estado y toma la rama por defecto (casi siempre origin/main) como base ref: el punto del que van a partir todas las tareas nuevas. Si tienes varios repos relacionados, puedes agruparlos y trabajar con un agente sobre todos a la vez.

2. Worktree: una copia aislada por tarea

Acá está la pieza central. Un worktree es una función de git que permite tener varias copias de trabajo del mismo repo en disco al mismo tiempo, cada una en su propia rama. En lugar de cambiar de rama y guardar cambios con stash, cada tarea vive en su propia carpeta.

En Orca la regla es simple: cada tarea es un worktree, con su rama, sus archivos y sus agentes. Por eso varios agentes pueden trabajar en paralelo sin molestarse: cada uno toca sus propios archivos en disco.

Un aviso que me costó un par de tropiezos: el worktree nuevo es una copia limpia. Las dependencias, las cachés y el .env que git ignora no vienen incluidos. Para eso hay tres herramientas:

• orca.yaml: un archivo en la raíz del repo donde declaras, entre otras cosas, qué carpetas ignoradas (como node_modules) se comparten entre worktrees en vez de reinstalarse.
• .worktreeinclude: una lista de archivos ignorados que se copian a cada worktree nuevo. El caso típico es el .env.
• Hooks de setup: comandos que corren al crear el worktree, como pnpm install.

Con eso resuelto, cada worktree arranca listo para trabajar.

3. Agente: uno o varios, en paralelo

Dentro de cada worktree lanzas un agente de código CLI. Un agente corriendo en una terminal dentro de un worktree es lo que Orca llama una sesión de agente, y le sigue el ciclo de vida completo: arranca, trabaja, queda inactivo, termina. Si el proceso se cierra, aparece un botón para reiniciarlo con el mismo agente y la misma carpeta.

Ojo con esto: por defecto Orca lanza los agentes en su modo de autonomía total (en Claude Code, por ejemplo, --dangerously-skip-permissions). La idea es que el worktree funcione como sandbox: si un agente rompe algo, rompe su copia, no tu rama principal. Se puede cambiar en la configuración, pero conviene entender por qué está así antes de tocarlo.

Y acá viene lo que más me gusta: agentes en paralelo. Mandas el mismo prompt a varios agentes, cada uno en su propio worktree, y te quedas con la mejor solución. Tres agentes, tres ramas, tres diffs. Sirve para explorar enfoques distintos sin esperar uno por uno, y de paso para comparar modelos sobre un problema real, no sobre un benchmark.

Para saber en qué anda cada uno sin entrar a su pestaña, Orca muestra los estados del agente: Working, Needs You (espera un permiso o una respuesta tuya), Done, Idle y Blocked. Cada worktree además puede tener un checkpoint, una nota corta de estado que el propio agente actualiza desde la CLI. Es el post-it que deja pegado en la tarjeta para que sepas qué está haciendo y cuál es el próximo paso.

4. Splits: mirar varios a la vez

La pantalla se organiza en tres niveles. Una tab contiene una sola cosa: una terminal, un archivo, un navegador, un diff o un PR. Un pane es un grupo de pestañas. Y un split es lo que pasa cuando arrastras una pestaña al borde de un panel y lo partes en dos, horizontal o vertical. Los splits se anidan, así que puedes tener tres terminales de agentes y el navegador en la misma vista.

Cada worktree recuerda su propia distribución: al cambiar de tarea cambia todo el layout. Y cada worktree tiene su propia ventana de Chromium para ver el resultado de esa rama (el localhost del dev server, por ejemplo) sin mezclar pestañas entre tareas.

Dentro de ese navegador hay una función que, como diseñador, me resulta muy natural: el Design Mode. Convierte la página en un selector. Haces clic sobre cualquier elemento de la interfaz y se lo pasas al agente con su HTML, sus estilos computados, un recorte de pantalla y, si hay source maps, el archivo y la línea de origen. Después escribes qué quieres cambiar. Es señalar con el dedo en vez de describir “el botón azul de abajo a la derecha”.

5. Diff: revisar antes de confiar

Cuando los agentes terminan, toca revisar. El visor de diffs muestra qué cambió en cada worktree respecto de su punto de partida: líneas agregadas, borradas y modificadas. Si corriste tres agentes en paralelo, acá es donde comparas los tres y eliges.

Dos funciones hacen que esta revisión sea distinta a mirar un PR en GitHub:

• Annotate AI Diff: dejas comentarios sobre una o varias líneas del diff y los mandas todos juntos al agente para que haga una sola pasada de corrección. Comentar de a uno hace que el agente vaya y vuelva; un solo paquete de feedback da una revisión más coherente. Los comentarios quedan anclados a la línea aunque el diff cambie, así puedes verificar el arreglo y marcarlos como resueltos.
• Attribution: Orca marca qué líneas escribió un agente y cuáles una persona. Si editas a mano una línea de origen IA, vuelve a figurar como humana. Sirve para saber qué partes del PR merecen más escrutinio.

6. Ship: commit, push y PR sin salir

El último tramo es ship: commit, push, abrir el pull request y esperar los checks de CI, todo desde Orca. Después archivas o borras el worktree, y con él se va su rama. Los worktrees de las soluciones descartadas se borran igual: no quedan ramas huérfanas dando vueltas.

Y cuando una persona ya no alcanza: orquestación

Todo lo anterior lo coordinas tú: creas los worktrees, lanzas los agentes, revisas. Hay un segundo nivel, todavía experimental, en el que un agente coordina a otros. Se llama orquestación y tiene sus propias piezas: un coordinador que reparte el trabajo, workers que reciben una tarea y la ejecutan bajo supervisión, tasks con dependencias del tipo “esta arranca cuando terminen aquellas dos” y decision gates, preguntas que bloquean una tarea hasta que alguien con criterio las responde.

La regla práctica que dan es buena: un objetivo claro por worker; los que solo revisan leen, los que escriben reciben su propio worktree; y un único responsable integra y prueba. Y también dicen cuándo no hace falta: para un prompt suelto a un agente que estás mirando, alcanza con mandárselo directo.

Esto es posible porque la Orca CLI la pueden usar los propios agentes. Un agente puede abrir worktrees o lanzar a otros agentes desde la terminal. Para que sepan hacerlo, Orca publica skills, paquetes de instrucciones que le enseñan a un agente a usar la CLI, y se instalan con un comando:

npx skills add https://github.com/stablyai/orca --skill orca-cli --global

Lo que me cambió

No es que ahora escriba más código. Es que dejé de esperar. Mientras un agente arma un componente, otro revisa accesibilidad en su propia copia y un tercero prueba otra forma de resolver lo mismo. Yo miro, comparo y elijo. Y eso, para un perfil que vive en el medio entre diseño y desarrollo, es exactamente el tipo de trabajo que quiero hacer.

Si tienes dudas sobre alguno de los términos o ya probaste Orca y quieres comparar flujos, escríbeme y charlamos.