Lancé una orquestación de cinco subagentes para refactorizar un módulo de autenticación. Me costó $11, tardó doce minutos y produjo un resultado peor que haberlo hecho en un solo hilo. Los subagentes están sobrevalorados para los builders en solitario, y las demos de Twitter que muestran hermosos enjambres de agentes no te están contando la parte en la que se vuelve caro y raro.
No me malinterpretes. Los subagentes son una funcionalidad real con usos reales. Pero el consejo por defecto — "divide todo en agentes especializados" — es incorrecto para la persona que construye un producto sola. La mayoría de las veces quieres un agente plano y de un solo hilo que simplemente haga el trabajo. Déjame explicar por qué.
Lo que realmente cuesta un subagente
Cuando lanzas un subagente, no estás simplemente delegando una tarea. Estás iniciando un contexto nuevo que no sabe nada sobre tu hilo principal. Así que tienes que informarlo. Cada subagente necesita los archivos relevantes, las convenciones, el objetivo, explicados desde cero. Ese informe son tokens. El trabajo del subagente son tokens. Luego informa de vuelta, y sintetizar su informe en el hilo principal son más tokens.
Para una tarea paralela con límites claros, esa sobrecarga vale la pena. Para una tarea donde las piezas están entrelazadas — lo que describe la mayoría del código real — pagas el impuesto del informe una y otra vez, y los subagentes siguen pisándose los pies porque ninguno puede ver el panorama completo.
La versión de un solo hilo simplemente... ya tiene el contexto. Leyó los archivos una vez. Recuerda lo que hizo tres pasos atrás. Sin informe, sin síntesis, sin sobrecarga de coordinación. A menudo es tanto más barata como mejor.
El problema de la fragmentación de contexto
Este es el sutil. La razón por la que los agentes son buenos en programar es el contexto compartido — el modelo mantiene el problema, los archivos y sus propias decisiones previas en un solo lugar y razona sobre todo ello. Los subagentes rompen eso. Cada uno ve un trozo.
El subagente A arregla el manejo de errores a su manera. El subagente B, informado por separado, arregla la validación de una manera diferente. Ninguno sabe lo que hizo el otro. Tú, en el hilo principal, ahora tienes que reconciliar dos cambios localmente razonables que no encajan juntos. He pasado más tiempo reconciliando la salida de subagentes del que los subagentes ahorraron. Esa es la trampa.
Para un builder en solitario, tu ventaja es que tú mantienes todo el panorama en tu cabeza y el agente lo mantiene en contexto. Fragmentarlo para parecer un equipo es hacer cosplay de una organización que no tienes.
Cuándo los subagentes realmente valen la pena
No estoy diciendo nunca. Aquí es donde los uso realmente:
- Trabajo verdaderamente paralelo e independiente. "Ejecuta la suite de tests mientras también haces lint del codebase." Sin estado compartido, sin reconciliación. Fan-out limpio.
- Aislamiento de contexto intencionado. Cuando una subtarea inundaría mi contexto principal con basura que no quiero contaminando el hilo principal — como leer 40 archivos para responder una pregunta. El subagente lee los 40, devuelve la única respuesta, mi contexto principal se mantiene limpio. Ese es un gran uso.
- Investigación acotada. "Ve a averiguar cómo funciona la autenticación de esta librería e infórmame." La exploración es desordenada; solo quiero la conclusión.
Fíjate en el patrón: los subagentes se ganan su lugar cuando la subtarea es independiente y resumible. Cuando el valor está en mantener el desorden fuera del hilo principal, no en fingir ser un equipo.
La fantasía de la orquestación
Hay un género de contenido que vende el sueño multi-agente — un agente planificador, un agente programador, un agente revisor, un agente probador, todos coordinándose como una pequeña empresa. Se ve increíble en un diagrama. Para un builder en solitario es principalmente una forma de convertir una tarea de $0,50 en una de $6.
El planificador le reexplica la tarea al programador. El programador produce trabajo. El revisor, con su propio contexto nuevo, relee todo para revisarlo. El probador lo relee de nuevo. Cada traspaso reprocesa el mismo código. Has recreado la ineficiencia de un equipo grande — toda la sobrecarga de comunicación — sin el beneficio, porque sigue siendo solo tú y el modelo.
Un agente capaz en un solo hilo planifica, programa y se autorevisa mientras mantiene todo en contexto. Tú lees el diff al final. Ese es tu revisor. Tú eres el organigrama.
Mi regla
Por defecto, plano. Un hilo, un agente, contexto completo. Recurro a un subagente solo cuando puedo responder sí a: ¿es esta subtarea independiente, y solo quiero el resumen de vuelta?
# La pregunta que me hago antes de lanzar un subagente:
# - ¿Independiente del trabajo principal? (ningún estado compartido que reconciliar)
# - ¿Resumible? (quiero una conclusión, no la salida en bruto)
# Ambos sí -> subagente. De lo contrario -> mantenerlo plano.
Todo lo demás se queda en el hilo principal, donde el contexto es completo y la factura es pequeña.
El enjambre de agentes parece el futuro. Para una persona que lanza un producto, suele ser un disfraz. Quítatelo y haz el trabajo en un solo hilo. Tu presupuesto de tokens te lo agradecerá, y el código también.