Usar subagentes de manera efectiva

Cuándo brillan los subagentes

Los subagentes funcionan mejor cuando la exploración está separada de la ejecución. Si cada paso de una tarea depende de lo que descubrió el paso anterior, quieres que ese trabajo esté en tu hilo principal. Pero si solo necesitas una respuesta y no te importa el recorrido, delégalo.

Los subagentes destacan en tareas donde:

• Necesitas un resultado, no un relato paso a paso de cómo se encontró
• El trabajo exploratorio saturaría el contexto de tu hilo principal
• La tarea se beneficia de una perspectiva nueva o de una indicación del sistema personalizada

Tareas de investigación

La investigación es el caso de uso clásico de los subagentes. Considera investigar cómo funciona la autenticación en una base de código desconocida. Tu hilo principal necesita saber dónde se valida el JWT, pero no necesita ver cada archivo que se buscó en el camino.

Un subagente de investigación puede leer docenas de archivos, rastrear llamadas a funciones y explorar diferentes rutas de código. Toda esa exploración permanece en el contexto del subagente. Tu hilo principal recibe un resumen limpio como:

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

El subagente hizo el trabajo pesado. Tu hilo principal obtiene exactamente lo que necesita para avanzar.

Revisiones de código

Claude revisa el código de manera más efectiva cuando el código se presenta como si hubiera sido escrito por otra persona. Si construiste una función a lo largo de muchos turnos con tu hilo principal, pedirle a ese mismo hilo que la revise a menudo produce comentarios débiles. Claude participó en su creación, así que le cuesta verla con ojos nuevos.

Un subagente revisor ve los cambios en un contexto separado. Ejecuta git diff, lee los archivos modificados y aplica sus criterios de revisión especializados sin el historial de cómo se escribió el código. Esta separación también te permite codificar estándares de revisión específicos del proyecto en la indicación del sistema del subagente, garantizando criterios de revisión consistentes en todo el equipo.

Indicaciones del sistema personalizadas

La indicación del sistema predeterminada de Claude Code enfatiza respuestas concisas y centradas en el código. Eso funciona muy bien para programar, pero no para todo.

Aquí hay dos casos en los que una indicación del sistema personalizada hace que el subagente sea genuinamente mejor que el hilo principal:

• Subagente de redacción publicitaria -- Dale instrucciones sobre el tono, la audiencia y el estilo. La indicación predeterminada de Claude Code tiende hacia una escritura técnica concisa, que realmente no es lo que quieres para una página de destino o una campaña de correo electrónico. Un subagente de redacción publicitaria puede tener instrucciones completamente diferentes sobre voz y estructura.
• Subagente de estilos -- Dile en su indicación del sistema que lea primero los archivos de tu sistema de diseño, para que conozca tus variables de color, convenciones de espaciado y patrones de componentes antes de empezar a escribir cualquier CSS.

Cuándo los subagentes perjudican

La sobrecarga de lanzar un subagente -- ocultar su trabajo del hilo principal y comprimir sus hallazgos en un resumen -- solo tiene sentido cuando el subagente hace algo que el hilo principal no puede hacer. Hay tres antipatrones comunes a los que hay que prestar atención.

Afirmaciones de experto

Los subagentes que afirman tener experiencia rara vez ayudan. Indicaciones como "eres un experto en Python" o "eres un especialista en Kubernetes" no añaden ningún valor porque Claude ya tiene ese conocimiento. No hay nada que un supuesto subagente experto pueda hacer que tu hilo principal no pueda hacer directamente.

Flujos secuenciales

Los flujos secuenciales de subagentes crean problemas. Considera un flujo de tres agentes: uno para reproducir un error, uno para depurarlo y uno para corregirlo. Los flujos funcionan cuando las tareas son verdaderamente independientes. Fallan cuando cada paso depende de los descubrimientos del paso anterior -- y la corrección de errores casi siempre lo hace. La información se pierde en el traspaso entre agentes.

Ejecutores de pruebas

Los subagentes ejecutores de pruebas tienden a ocultar información que necesitas. Cuando las pruebas fallan, quieres la salida completa para diagnosticar los problemas. Un subagente que devuelve "las pruebas fallaron" te obliga a crear scripts de depuración adicionales para obtener detalles que habrían sido visibles en la salida directa. Las pruebas han demostrado que el patrón de ejecutor de pruebas tuvo el peor desempeño entre todas las configuraciones.

La regla de decisión

Cuando estés decidiendo si usar un subagente, hazte una pregunta: ¿importa el trabajo intermedio?

Si la respuesta es no -- solo necesitas el resultado final -- delégalo a un subagente. Si la respuesta es sí -- necesitas ver y reaccionar a lo que está sucediendo en el camino -- mantenlo en tu hilo principal.

Usa subagentes para:

• Investigación y exploración
• Revisiones de código
• Tareas que necesitan una indicación del sistema personalizada

Evita los subagentes para:

• Personas "expertas" que no añaden capacidad real
• Flujos de varios pasos donde cada paso depende del anterior
• Ejecutar pruebas donde necesitas la salida completa para depurar