Claude Code se ha convertido en una palanca de productividad seria para los equipos de ingeniería. Las ganancias en las primeras semanas suelen ser obvias. Lo que no es tan obvio es lo que sucede una vez que su equipo comienza a usarlo para trabajos más largos y ambiciosos: refactorizaciones de varios archivos, auditorías grandes, desarrollo de funciones de principio a fin. A esa escala, la calidad de la producción y el costo dejan de seguir el ritmo que tuvieron al principio, y las razones no siempre son fáciles de ver desde una perspectiva de liderazgo.
La respuesta casi nunca es el modelo. Es la arquitectura que rodea al modelo. Los equipos que obtienen de 5 a 10 veces más de Claude Code no ejecutan una versión diferente de Claude. Ejecutan la misma versión con subagentes de Claude conectados, lo que mantiene las sesiones largas nítidas en lugar de permitir que decaigan. Esta pieza es para las personas que deciden dónde invertir el tiempo de ingeniería: analiza los cinco cuellos de botella que limitan silenciosamente el rendimiento de su equipo, los patrones de subagentes que solucionan cada uno y cuándo pasar a equipos de agentes de Claude Code. Al final, sabrá qué preguntar a su líder de ingeniería y cómo detectar si su configuración actual está dejando dinero real sobre la mesa.
Qué son realmente los subagentes de Claude
Un subagente de Claude es una instancia aislada de Claude Code con su propia ventana de contexto de ~200K, su propio prompt del sistema, su propia lista de herramientas permitidas y sus propios permisos. La sesión principal le delega una tarea. El subagente realiza el trabajo de forma aislada y luego devuelve solo un resumen. Todo lo ruidoso que sucedió dentro del subagente permanece dentro del subagente.
El valor real aquí no es el paralelismo, aunque eso ayuda. Es el aislamiento. Cuando un subagente lee cuarenta archivos para encontrar un patrón, la sesión principal nunca ve esos cuarenta archivos. Ve un párrafo: “encontré el patrón, vive aquí, se ve así”. Eso mantiene el hilo principal nítido a lo largo de una sesión larga.
Tres tipos son dignos de mención. Los subagentes integrados como Explore y Code se distribuyen con Claude Code y se ejecutan automáticamente. Los subagentes personalizados viven en su carpeta .claude/agents/ y le permiten definir especialistas para seguridad, pruebas o documentación. Y si una sesión realmente no puede contener el trabajo, los equipos de agentes de Claude Code le permiten coordinar múltiples sesiones con mensajería entre ellas.
Claude Code se encuentra dentro de un panorama más amplio de frameworks de IA multiagente como LangChain, el SDK de Agentes de OpenAI y Google ADK, cada uno con diferentes compensaciones en orquestación, memoria y acceso a herramientas. Los subagentes son la respuesta de Anthropic al mismo problema de coordinación que esos frameworks intentan resolver, construidos directamente en el tiempo de ejecución de Claude Code en lugar de adjuntarse como una capa separada.
Los cinco cuellos de botella que rompen flujos de trabajo largos de Claude Code
Los líderes de ingeniería suelen describir las ralentizaciones de Claude Code en términos vagos: “el modelo empeora”, “olvida cosas”, “las sesiones se vuelven caras”. Estas son observaciones reales pero no son aleatorias. Cada una se mapea a una causa arquitectónica específica dentro de cómo una sesión de contexto único maneja el trabajo a lo largo del tiempo, y cada una tiene un patrón de subagente que la resuelve sin necesidad de un modelo diferente o una herramienta diferente.
Los cinco patrones a continuación cubren la mayoría de lo que ralentiza las sesiones largas. Saber cuál está afectando a su equipo es la diferencia entre lanzar más tokens al problema y arreglar realmente el flujo de trabajo.
La degradación del contexto es el lento declive en la calidad de la salida a medida que la ventana de contexto se llena. Se activa mucho antes del límite de tokens. Cuanto más contexto tiene el modelo, menos peso tienen sus instrucciones originales. Después de tres horas, el plan arquitectónico que trazó al principio está enterrado bajo los resultados de las herramientas, el contenido de los archivos y el razonamiento previo, y el modelo efectivamente comienza a ignorarlo.
La solución es delegar el trabajo ruidoso a un subagente. Todo lo que lea más de cinco archivos, analice grandes diffs o procese logs va a un subagente de Explore. La sesión principal nunca ve la salida sin procesar. Ve los hallazgos.
Sabrá que esto está funcionando cuando la calidad de la hora tres coincida con la calidad de la hora uno.
Arrastre secuencial en el trabajo independiente
Cuando un flujo de trabajo largo ejecuta todo a través de una sesión principal, las piezas de trabajo independientes terminan esperando unas a otras sin una buena razón. La revisión de seguridad espera las pruebas, las pruebas esperan la documentación, la documentación espera la refactorización. El trabajo en sí nunca fue secuencial. La arquitectura lo hizo secuencial.
El patrón de dividir y fusionar disuelve esto. Los flujos de trabajo independientes se distribuyen a través de subagentes paralelos y los resultados regresan a un solo lugar. Donde los equipos se equivocan es al enviar subagentes en términos genéricos, lo que produce trabajo superpuesto, ediciones en los mismos archivos y un lío de fusión al final. Los equipos que lo hacen bien dan a cada subagente un rol nombrado, un entregable definido y límites claros sobre lo que puede tocar. Esa precisión es lo que convierte la ejecución paralela en un rendimiento real en lugar de tres agentes pisoteándose mutuamente.
Contaminación entre dominios
La degradación del contexto se trata de lo que se desvanece con el tiempo. La contaminación entre dominios se trata de lo que compite en el momento. Cuando a una sesión se le pide que contenga reglas de backend, reglas de frontend y convenciones de SDK simultáneamente, esos conjuntos de reglas interfieren entre sí. El modelo no se está quedando sin espacio. Se le está tirando en tres direcciones a la vez.
El fallo visible: los patrones de backend se filtran en los componentes de React, o las convenciones de frontend aparecen en los objetos de transferencia de datos. El código parece plausible a simple vista pero viola las convenciones que estableció para cada capa. Este es el resultado de pedirle a un contexto que sea experto en demasiadas cosas al mismo tiempo.
La solución es un subagente por dominio. El subagente de backend carga solo las instrucciones de backend. El subagente de frontend carga solo los patrones de componentes. El orquestador coordina entre ellos pero nunca intenta mantener todas las reglas por sí mismo. El mismo principio sustenta la arquitectura limpia en el desarrollo de software, y funciona por la misma razón: la separación de preocupaciones evita la deriva.
El colapso de las cuatro horas
El colapso de las cuatro horas ocurre cuando falla uno de los pasos del flujo de trabajo y toda la canalización se detiene, o cuando la sesión se queda sin espacio a mitad de camino y se pierde el estado acumulado. La mayoría de los flujos de trabajo de contexto único son frágiles de esta manera porque nada se guarda entre pasos.
La solución es un pipeline estructurado de Explorar, Planificar, Ejecutar. Cada fase es una invocación de subagente separada con una transferencia limpia a la siguiente. La puerta de revisión humana se encuentra entre Planificar y Ejecutar, donde el costo de detectar un error es menor.
Esto es importante a escala. El lanzamiento de Dynamic Workflows de Anthropic el 28 de mayo de 2026 mostró a Claude Code realizando migraciones de bases de código a través de cientos de miles de líneas, con el conjunto de pruebas existente como barra de validación. Una demostración migró una base de código de 750.000 líneas en once días con una tasa de aprobación de pruebas del 99,8%. Las ejecuciones a esa escala no sobreviven sin transferencias estructuradas entre fases.
Sobrecarga del orquestador
Los otros cuatro cuellos de botella se encuentran en el nivel del trabajador. La sobrecarga del orquestador es lo que sucede en el nivel del coordinador una vez que los trabajadores están en marcha. Tienes subagentes paralelos produciendo resúmenes limpios, pero el agente principal se está ahogando en el tráfico de llegada: diez resúmenes para leer, diez conjuntos de recomendaciones para reconciliar, diez hilos para mantener coherentes. El rendimiento se detiene no porque los trabajadores sean lentos, sino porque nada aguas abajo puede sintetizar su salida lo suficientemente rápido.
La solución es la moderación en la cima. El orquestador debe coordinar y nada más. El paralelismo debe coincidir con la independencia real de las tareas, no solo con la capacidad disponible. Un subagente revisor de solo lectura con una proporción de 1:3 o 1:4 ayuda a mantener alta la calidad sin aumentar la carga de fusión. Solo lectura es importante porque un revisor con acceso de escritura comenzará a solucionar problemas por sí mismo, lo que crea conflictos con los subagentes implementadores. La misma lógica sustenta cómo funciona una buena revisión de código en un equipo humano: el revisor marca, el implementador corrige. Cinco subagentes paralelos es el límite práctico para la mayoría de los equipos dentro de una sesión.
Subagentes vs. Equipos de agentes
Los subagentes son trabajadores dentro de una sesión de Claude Code. Los equipos de agentes de Claude Code coordinan múltiples sesiones, cada una con su propio contexto, comunicándose a través de mensajes entre compañeros de equipo. La elección entre ellos no es académica. Si se equivoca, o bien gasta dinero en equipos de agentes cuando los subagentes serían suficientes, o estira los subagentes más allá de donde una sesión puede manejar el trabajo.
Utilice subagentes cuando tenga un flujo de trabajo que necesite ayudantes debajo de él. Exploración paralela, delegación con alcance, lecturas aisladas de alto contexto. Utilice equipos de agentes cuando el trabajo en sí se divide en múltiples sesiones de mayor duración, los compañeros de equipo necesitan hablar entre sí o el contexto total excede lo que una sesión puede manejar de manera realista.
Ámbito
Una sesión, delegación con alcance
Múltiples sesiones coordinándose
Comunicación
Devuelve un resumen único al principal
Mensajes entre compañeros de equipo
Mejor para
Exploración paralela, lecturas aisladas
Trabajo de varios días, flujos de trabajo distintos
Perfil de costo
Más ligero
Más pesado por compañero
Tamaño práctico del equipo
Hasta 10 en paralelo
De 3 a 5 compañeros es el punto óptimo
La mayoría de los equipos se exceden con los equipos de agentes. Empiece con subagentes. Pase a equipos de agentes solo cuando una sesión realmente no pueda coordinar el trabajo.
Los errores que convierten los subagentes en un pasivo
Los subagentes son potentes, y también es fácil usarlos mal. Aquí están los patrones que vemos que matan la productividad en lugar de ayudarla:
- Delegar en exceso tareas simples. Una lectura de un solo archivo no necesita un subagente. La sobrecarga de coordinación excede el ahorro. Utilice la sesión principal para cualquier cosa que quepa cómodamente en ella.
- Especificar insuficientemente las salidas. Los prompts de envío vagos producen resúmenes vagos. Siempre indique la forma del entregable: “devuelve una tabla markdown con las columnas X, Y, Z” es mejor que “resume lo que encuentres”.
- Paralelismo falso. Encadenar subagentes secuencialmente cuando el trabajo no tiene dependencias reales. Si dos subagentes no dependen el uno del otro, ejecútelos en paralelo.
- Revisores con acceso de escritura. Socava el aislamiento. Un revisor que pueda editar comenzará a solucionar problemas, lo que crea conflictos de fusión y deshace el trabajo que sus otros subagentes acaban de hacer.
- Expansión de permisos. Cada herramienta adicional amplía su superficie de ataque. Nuestro artículo sobre gobernanza de agentes de IA cubre por qué la higiene de permisos importa más de lo que la mayoría de los equipos creen, especialmente después de que el incidente de ClawBank restableció cómo se ve la seguridad de la IA empresarial.
Si se equivoca en esto, los subagentes le costarán más tokens, más tiempo y más retrabajo del que le habría costado ejecutar todo en una sola sesión.
La configuración mínima de subagentes que sobrevive
Si está empezando desde cero, aquí está la configuración de producción más pequeña que sobrevive a una sesión de Claude Code de cuatro horas sin colapso de calidad:
- Un orquestador en Opus. Solo coordina. Nunca implementa.
- Un subagente de Explore en Haiku. Lee, resume, devuelve hallazgos. Barato y rápido.
- Un subagente de Code en Sonnet. Implementa contra el resumen de Explore.
- Un Revisor de solo lectura en Opus. Se ejecuta después de cada tarea completada. La salida son hallazgos estructurados, bloqueantes y no bloqueantes.
- Pase a equipos de agentes solo cuando una sesión realmente no pueda contener el trabajo.
La división del modelo importa porque controla el costo. El análisis de McKinsey sobre las ganancias de productividad de la IA en 2026 señala que el valor de la IA reside en remodelar cómo se organiza el trabajo, no solo en ejecutar el trabajo existente más rápido. Los subagentes son exactamente ese tipo de remodelación. Deja de tratar a Claude como un solo modelo que hace todo y empieza a tratarlo como un equipo de ingeniería.
Esta configuración es más importante para los equipos que envían productos SaaS a escala, donde una sesión de Claude Code de cuatro horas no es inusual y el costo de la degradación del contexto se acumula en el ciclo de lanzamiento.
Mismo modelo, mejor arquitectura
Los equipos que obtienen 10 veces más de Claude Code no ejecutan un modelo mejor. Ejecutan el mismo modelo con la estructura adecuada a su alrededor. Los cuellos de botella son predecibles. Los patrones están documentados. La diferencia entre los equipos que obtienen un impulso incremental de Claude y los equipos que cambian cómo envían es si tratan la herramienta como un solo agente o como un equipo de ingeniería.
Construya la arquitectura antes de que la necesite, no después del colapso de las cuatro horas. Si desea ayuda para armar esto para un flujo de trabajo real, contáctenos.
Preguntas frecuentes
¿Qué son los subagentes de Claude?
Los subagentes son instancias aisladas de Claude Code a las que la sesión principal les delega tareas. Cada uno tiene su propia ventana de contexto, sus propias herramientas y sus propias instrucciones. El subagente realiza el trabajo y devuelve un resumen. El ruido intermedio permanece dentro del subagente, lo que mantiene enfocada la sesión principal.
¿Por qué Claude Code se vuelve más lento con el tiempo?
Degradación del contexto. A medida que la ventana de contexto se llena, las primeras instrucciones tienen menos peso, por lo que después de tres horas el modelo está efectivamente ignorando el plan establecido al inicio de la sesión. Los subagentes solucionan esto manteniendo el trabajo ruidoso fuera de la sesión principal.
¿Cuántos subagentes pueden ejecutarse en paralelo?
Hasta diez en paralelo dentro de una sesión de Claude Code, con cinco como el punto óptimo práctico antes de que el coordinador se convierta en el cuello de botella. Dynamic Workflows en Opus 4.8 eleva considerablemente el límite para trabajos muy grandes.
¿Cuándo debo usar equipos de agentes de Claude Code en lugar de subagentes?
Cuando el trabajo en sí se divide en múltiples sesiones de mayor duración, cuando los compañeros de equipo necesitan comunicarse o cuando el contexto total excede lo que una sesión puede contener. Para la delegación con alcance limitado dentro de un flujo de trabajo, quédese con los subagentes.
¿Cuál es el mayor error que cometen los equipos con subagentes?
Exceso de delegación. Enviar lecturas de un solo archivo o tareas triviales a un subagente cuesta más en sobrecarga de coordinación de lo que ahorra. Utilice subagentes para el trabajo que de otro modo contaminaría el contexto principal.
Vea cómo Redwerk reconstruyó la arquitectura de Sentient Ascend para potenciar la solución de crecimiento digital #1 impulsada por IA.
