Cambiar de postura
Durante años mi placer era devorar código. Pero con los agentes, una buena parte del trabajo se desplazó.
A fines de abril, y sobre todo a principios de mayo con Claude Code, empiezo a escribir mucho menos código a mano. Sigo siendo desarrollador, pero mis días cambian de materia: encuadrar la tarea, dividir el problema, releer el código, testear el resultado, retomar el control cuando el agente inventa, generaliza o rompe algo. El agente puede sacar el código. Si el diff está mal, el problema sigue siendo mío.
La IA me acelera, pero también acelera mis malos reflejos. De tanto ver salir cientos de líneas correctas, me pasó releer demasiado rápido. Más tarde volvía sobre un diff y me preguntaba: “what the fuck?”. Bug escondido, code smell, decisión de arquitectura tambaleante. El agente había producido código; yo había dejado de tratarlo como código a releer.
Empiezo a tratar mis prompts como tickets de los que sigo siendo responsable: entender la necesidad, validar un plan, aislar el trabajo en una branch o un worktree, lanzar los checks, releer el diff. Le digo orquestación, a falta de mejor palabra.
Cuando llegan los subagentes
Antes de los subagentes ya orquestaba a mano: Markdown reutilizables, escenarios de ticket, custom slash commands. Le daba un procedimiento al agente: leer esto, producir esto, verificar esto, parar acá.
Cuando Claude Code agrega los subagentes personalizados vía /agents, el cambio pasa sobre todo por el aislamiento: cada subagente trabaja en su propio contexto. Ejecuta una tarea, devuelve un informe y después desaparece. Veo el truco: encuadrar una tarea, mandarla a un contexto descartable, recuperar un informe, verificar.
Al día siguiente del release, llevo el truco demasiado lejos: en lugar de escribir un agente, escribo un meta-agent que lee la documentación oficial y después escupe agentes especializados a demanda.
En una noche, me encuentro con una treintena de agentes especializados: front-end generalista, front-end “UI state”, front-end “accesibilidad”, back-end, base de datos, “diagnóstico tests”, “tester Playwright”, “lint/format”, “CI triage”, “doc writer”, etc.
Sobre el papel, parece un equipito. En Claude Code, rápido se vuelve otra cosa: una cadena de transmisión.
Yo le doy una intención al agente padre. El agente padre resume, elige un subagente, le pasa una parte del contexto. El subagente trabaja en su burbuja, devuelve un informe y desaparece. En cada paso, algo puede perderse: restricción olvidada, matiz aplastado, resultado demasiado parcial. ¿Ven adónde voy? Otra vez el contexto, sí. Acá es la entrada la que condiciona la salida.
Recreo en miniatura una ceremonia que ya conozco demasiado bien: cliente, PO, arquitecto, dev, tester, reviewer, tech lead, y vuelta al humano.
El problema no viene de los agentes en sí. Viene de la cantidad de pasos. Cada rol agregado pide un encuadre, un pase de testigo, una verificación. Apenas se multiplican los relevos, se paga en coordinación; acá ese costo pasa por resúmenes y ventanas de contexto.
Quería crear un equipo ideal. Creé una burocracia.
Corto la grasa.
Me quedo con menos agentes especializados y vuelvo a roles más generalistas. El contexto sigue siendo la palanca real: un agente generalista con un buen prompt suele rendir mejor que un agente especializado con una consigna pobre.
Algunos subagentes mantienen su utilidad, sobre todo para explorar una pista, testear una hipótesis o aislar una tarea. Pero el agente principal se vuelve el punto de paso obligado: encuadra, delega, recupera los informes y me devuelve un estado legible.
De mi lado, pongo los límites: alcance, criterios de fin, validaciones, orden de paso. A esta altura todavía no busco el workflow perfecto. Busco sobre todo bajar el ruido para seguir experimentando.
Mi workflow de orquestación
Una vez bajado el ruido, queda otro problema: trabajar con los agentes sin armarles un sistema recontra complicado alrededor.
Mantengo dos comandos en el centro:
/issuepara hablar con GitHub (crear, actualizar o comentar issues),/worktreepara crear copias de trabajo paralelas, una por subtarea.
Probé un enfoque más pesado, con muchos scripts, logs y tests end-to-end. Lo mantuve lo suficiente para ver dónde se rompía: demasiado frágil, demasiado complicado para lo que aportaba.
A esta altura todavía no tengo un workflow perfecto. Tengo sobre todo una superficie más chica: un prompt reutilizable que describe el flujo esperado, los pasos, las acciones posibles y los momentos en los que llamar a /issue o /worktree.
No era mi workflow para todas las tareas. Para una corrección simple, era mucho más pesado de la cuenta. Lo usaba sobre todo cuando el pedido era lo bastante difuso como para merecer un rodeo por el encuadre: entender, encuadrar, dividir, verificar.
En mi cabeza siempre arrancaba antes del código. Le daba el objetivo, el alcance, las restricciones y qué quería decir “terminado”. El agente después leía el proyecto, identificaba los archivos importantes, miraba los tests y me decía qué había entendido. Quería ver su comprensión antes de dejarlo escribir.
Cuando el tema seguía borroso, rompíamos las ambigüedades. Le pedía un enfoque, a veces una o dos exploraciones por subagentes, después una versión consolidada que pudiera releer. Recién ahí lanzaba la implementación.
Para una tarea simple, un agente trabajaba en un worktree dedicado. Para una tarea más amplia, dividía con más franqueza: varios worktrees, pedazos acotados, y menos mezcla en los diffs.
Después venían las verificaciones: tests, lint, tipos, a veces arquitectura. Los errores volvían a un bucle corto. Al final, el agente me presentaba el diff. Releía, testeaba, pedía correcciones. La PR no contaba toda la historia: solo el objetivo, los cambios, los checks, las issues vinculadas.
Pregunta abierta, no solo de IA: ¿a partir de cuántos relevos la señal se degrada más rápido de lo que se transmite?
La regla que empieza a perfilarse es bastante simple: pocos agentes, pedazos acotados, relevos legibles, y verificaciones que dicen rápido si el trabajo banca. /issue y /worktree siguen siendo útiles porque vuelven el trabajo observable sin agregar demasiado glue code: un pedido, un espacio aislado, un diff, una PR.
Crash-test de la sobreorquestación
Después caigo en el exceso opuesto: canalizar todo.
Muy rápido voy en la otra dirección: quiero canalizar todo. Branches, worktrees, issues, PR, hooks, guards, workflows “seguros”: cada acción termina con su subcomando, su camino previsto, su pequeño wrapper alrededor de Git.
Al principio tranquiliza. Todo parece encuadrado. Después paso días iterando sobre el dispositivo en sí: un camino funciona en una máquina y se rompe en otra, un script se vuelve tedioso de debuggear, una regla corrige un caso y abre otros, la doc engorda porque el sistema ya no se entiende sin ella.
Un caso típico: describo el plan en una especie de YAML, con las branches a crear, los worktrees a preparar y después el orden de merge esperado. La herramienta sabe hacer el scaffolding. El problema llega cuando el orquestador tiene que seguir ese plan en el tiempo. Lee el comando, lo interpreta demasiado rápido, salta un paso, o trata una regla como una sugerencia. Termino corrigiendo al agente en vez de corregir el código.
Por encima de /worktree, agrego /orc, mi comando de orquestación. Clasificaba la tarea, elegía el nivel de aislamiento, preparaba las branches o worktrees y después intentaba seguir los pasos hasta la PR.
A fuerza de iterar termino viendo un problema: los comandos existen, pero los agentes no siempre los siguen como esperaba. /orc, /worktree, las consignas de PR, los hooks, los guards: todo está escrito en algún lado, y aun así muchas veces tengo que volver a pasar por encima. El agente salta un paso, interpreta una regla demasiado rápido, u olvida por qué existe el comando. La fricción no está solo en la herramienta. Está en la brecha entre el comando escrito y lo que el modelo hace con él.
A principios de noviembre empiezo a cortar. Comandos especializados desaparecen. El glue code puesto alrededor de Git también. Reduzco también la documentación, porque una parte ya no sirve para transmitir una idea: sirve para hacer soportable un sistema que se volvió demasiado pesado. Unos días después hago otra pasada sobre los skills y los documentos. Menos ejemplos, menos escenarios “por las dudas”, menos estrategia congelada en archivos que el agente relee sin necesitarla siempre.
Lo que me llevo de este corte es más simple: si la orquestación no reduce la ambigüedad o el costo de coordinación, solo agrega una capa. No reemplaza a Git, los tests, la PR ni la CI. Sirve para ayudar al agente a saber dónde actuar, qué verificar, cuándo parar y cómo devolverme un estado legible.
A partir de ahí, desconfío sobre todo del apilamiento. De tanto agregar comandos, docs, guards y recordatorios para mantener a los agentes dentro del cuadro, a veces termino cargando el contexto que justamente intento proteger. No es un problema en todas las tareas. Se rompe sobre todo cuando el orquestador tiene que sostener demasiadas cosas a la vez: planificar, repartir, seguir los worktrees, releer los retornos, preparar la PR. El cuadro debería ayudarlo; a este nivel de complejidad, se vuelve una carga más. La salida la encuentro menos en un comando mágico que en tareas más chicas y relevos más cortos.
Lo que sobrevive no es el gran workflow. Es la disciplina. Una tarea más chica. Un espacio de trabajo aislado cuando vale la pena. Un relevo corto. Un informe que puedo releer. Un diff que sigue contando la intención inicial. La orquestación queda útil cuando reduce la ambigüedad; apenas se vuelve un sistema a mantener por sí mismo, vuelve a contaminar el contexto.
Actualización (abril 2026)
Unos meses después de escribir este capítulo, casi no uso el plugin de orquestación como workflow diario. El repo sigue existiendo: claude-code-plugins/orchestration, y lo hice evolucionar bastante en ese tiempo, pero una parte de lo que fabricaba a mano se desplazó: a veces a las herramientas, a veces a prácticas más livianas.
Con la perspectiva, el plugin pesa menos que el reflejo que me dejó: mantener la orquestación liviana, observable y lo bastante simple como para que ella misma no se vuelva el problema.