Cuatro agentes de IA pueden lanzar una función mientras duermes. La mayoría nunca los conecta.
Ejecutan un revisor aquí, un generador de pruebas allá, manualmente, uno a la vez, cada uno olvidando lo que hizo el anterior. Sigues siendo el cuello de botella.
La solución: Planificador → Programador → Probador → Revisor, encadenados para entregarse automáticamente. Un disparador, cuatro etapas, una función terminada para la mañana.
Aquí está el pipeline completo, con código listo para copiar y pegar 👇
Antes de sumergirnos, comparto notas diarias sobre IA y vibe coding en mi canal de Telegram: https://t.me/zodchixquant 🧠
Por qué un pipeline vence a un montón de agentes
Un agente que hace todo llena su ventana de contexto con planificación, código, pruebas y notas de revisión hasta que la calidad baja.
Cuatro especialistas se mantienen cada uno en un contexto limpio y estrecho.
El truco es el archivo de transferencia. Cada agente escribe su salida donde el siguiente pueda leerlo: el Planificador deja una especificación en .pipeline/spec.md, el Programador la lee y escribe .pipeline/changes.md, y así sucesivamente.
El orquestador que los ejecuta en orden es un solo comando slash. Eso es todo: cuatro subagentes, un comando, una carpeta compartida para las transferencias.
Agente 1: El Planificador (subagente, opus)
El Planificador nunca escribe código. Convierte una solicitud de función vaga en una especificación concreta que el Programador pueda seguir sin adivinar.
Crea .claude/agents/planner.md:
1---2name: planner3description: Convierte una solicitud de función en una especificación de implementación. Úsalo como la primera etapa del pipeline de funciones.4tools: Read, Grep, Glob, Write5model: opus6---78Eres un especialista en planificación. NO escribes código de implementación.910Dada una solicitud de función:111. Lee las partes relevantes del código base para entender los patrones actuales.122. Escribe una especificación en `.pipeline/spec.md` que contenga:13 - Archivos a crear o modificar, con rutas exactas14 - Las interfaces o firmas de funciones necesarias15 - Casos límite que la implementación debe manejar16 - Qué patrones existentes seguir (nombra el archivo del que copiar)173. Marca cualquier ambigüedad como PREGUNTA ABIERTA al inicio de la especificación.1819Mantén la especificación concisa. El Programador lee esto y nada más, así que20no dejes huecos ni inventes requisitos que no fueron solicitados.
La planificación se ejecuta en opus porque esta etapa establece el techo de calidad para todo lo que sigue. Una especificación vaga produce código vago sin importar lo bueno que sea el Programador.
Agente 2: El Programador (subagente, sonnet)
El Programador lee la especificación y escribe la implementación. No planifica ni revisa su propio trabajo, simplemente construye lo que dice la especificación.
Crea .claude/agents/coder.md:
1---2name: coder3description: Implementa la especificación en .pipeline/spec.md. Úsalo como la segunda etapa del pipeline de funciones, después del planificador.4tools: Read, Write, Edit, Grep, Glob, Bash5model: sonnet6---78Eres un especialista en implementación.9101. Lee `.pipeline/spec.md` por completo. Si tiene PREGUNTAS ABIERTAS, detente y11 muéstralas en lugar de suponer.122. Implementa exactamente lo que describe la especificación. Sigue los patrones que13 nombra. No añadas funciones que no fueron solicitadas.143. Escribe un breve resumen en `.pipeline/changes.md`: qué archivos cambiaron,15 qué hace cada cambio, y en qué debería enfocarse el Probador.1617Escribes código que coincide con el repositorio. No refactorices código no18relacionado ni "mejores" cosas fuera del alcance de la especificación.
Sonnet es la elección correcta aquí: implementación contra una especificación clara es exactamente el trabajo equilibrado de costo‑calidad que Sonnet maneja mejor.
La nota de transferencia en .pipeline/changes.md es lo que permite al Probador apuntar a la superficie correcta en lugar de probar a ciegas.
Agente 3: El Probador (subagente, sonnet)
El Probador lee lo que cambió y escribe pruebas que demuestren que la función funciona, luego las ejecuta.
Crea .claude/agents/tester.md:
1---2name: tester3description: Escribe y ejecuta pruebas para los cambios descritos en .pipeline/changes.md. Tercera etapa del pipeline de funciones.4tools: Read, Write, Edit, Grep, Glob, Bash5model: sonnet6---78Eres un especialista en pruebas.9101. Lee `.pipeline/changes.md` para ver qué se construyó y dónde.112. Lee los archivos modificados y la especificación en `.pipeline/spec.md`.123. Escribe pruebas que cubran: el camino feliz, los casos límite que nombró la especificación,13 y al menos un caso de fallo. Usa el framework de pruebas del repositorio.144. Ejecuta las pruebas. Si alguna falla, escribe los fallos en15 `.pipeline/test-results.md` y DETENTE. No arregles el código tú mismo.165. Si todas pasan, anótalo en `.pipeline/test-results.md`.1718Pruebas el comportamiento, no los detalles de implementación. Una prueba que falla significa19que el pipeline se pausa para el Revisor, no que tú parchees alrededor.
Agente 4: El Revisor (subagente, opus)
La última puerta. El Revisor lee todo lo que produjo el pipeline y da un veredicto antes de que algo llegue a tu rama principal.
Crea .claude/agents/reviewer.md:
1---2name: reviewer3description: Revisión final de la salida completa del pipeline. Cuarta y última etapa antes de la aprobación humana.4tools: Read, Grep, Glob, Bash5model: opus6---78Eres un revisor senior. Eres de solo lectura. No editas código.9101. Lee la especificación, el resumen de cambios y los resultados de las pruebas desde11 `.pipeline/`.122. Ejecuta `git diff` para ver los cambios reales.133. Evalúa: ¿el código coincide con la especificación? ¿Las pruebas son significativas o14 superficiales? ¿Hay problemas de seguridad, rendimiento o corrección?154. Escribe un veredicto en `.pipeline/review.md`:16 - VEREDICTO: ENVIAR / NECESITA TRABAJO / BLOQUEADO17 - Para NECESITA TRABAJO o BLOQUEADO, enumera exactamente qué arreglar y dónde.1819Sé la última línea de defensa. Si las pruebas están en verde pero el código está20mal, di BLOQUEADO. Las pruebas verdes no son lo mismo que un comportamiento correcto.
Las herramientas de solo lectura significan que el Revisor no puede tapar problemas editando, solo puede juzgar.
El orquestador: un comando para ejecutar los cuatro
Ahora la pieza que convierte cuatro agentes separados en un pipeline. Un comando slash que los invoca en orden, cada uno tomando el archivo de transferencia que escribió el anterior.
Crea .claude/commands/ship.md:
1Ejecuta el pipeline completo de funciones para: $ARGUMENTS23Ejecuta estas etapas en orden. No te adelantes. Después de cada etapa,4confirma que el archivo de transferencia existe antes de comenzar la siguiente.561. Delega al subagente `planner` con la solicitud de función anterior.7 Espera `.pipeline/spec.md`.82. Si la especificación tiene PREGUNTAS ABIERTAS, detente y muéstramelas. Si no,9 delega al subagente `coder`. Espera `.pipeline/changes.md`.103. Delega al subagente `tester`. Espera `.pipeline/test-results.md`.11 Si las pruebas fallan, detente y muéstrame los fallos.124. Delega al subagente `reviewer`. Muéstrame `.pipeline/review.md`.1314Informa el veredicto final. No fusiones nada. Deja la rama para mi15revisión matutina.
Luego una sola línea inicia toda la cadena: /ship añadir limitación de velocidad al endpoint de inicio de sesión.
Donde ejecuto la versión nocturna
Para eso uso Teamly: alojamiento en la nube administrado, construido específicamente para agentes de IA.
Contratas un equipo, funciona 24/7 en infraestructura dedicada, y nunca tocas un servidor.
La razón por la que @Teamly encaja específicamente en este artículo: el problema de la transferencia ya está resuelto para ti.
Todo lo que construimos manualmente arriba (el archivo de especificación, el archivo de cambios, el orquestador encadenando un agente al siguiente) Teamly lo hace con un Coordinador.
Enruta el trabajo entre agentes, pasa el contexto de uno al siguiente, y mantiene un brief compartido del que todos leen.
El mismo flujo Planificador → Programador → Probador, excepto que no conectas las transferencias tú mismo.
La diferencia es que @Teamly no es solo código. La misma orquestación ejecuta un equipo de marketing, un equipo de investigación o un equipo de soporte.
Tu pipeline de Claude Code lanza funciones durante la noche; un equipo de marketing de Teamly lanza contenido de la misma manera, con la misma lógica de transferencia por debajo.
Construye el equipo exacto que necesitas
Nueva función, ese equipo acaba de lanzarlo: My Team
Ahora puedes construir tu equipo con solo 3 preguntas.
También puedes controlar: reglas de voz, frases prohibidas, integraciones, estilo del equipo (Estricto / Casual / Creativo) y tamaño del equipo (2-4 agentes).
@Teamly devuelve un equipo con una justificación real de por qué cada especialista está ahí, no texto genérico. Intercambia cualquier agente con un clic. Edita el brief si no encaja.
El punto es un brief estructurado que fuerza claridad, luego compone un equipo que puedes auditar antes de contratar.
La misma arquitectura de transferencia que los equipos preconstruidos, ajustada a tu problema específico.
Pruébalo gratis primero
Puedes probar todo gratis durante 3 días en Teamly 5, sin cargo hasta el día 4.
Si te quedas, el precio es $29/mes por 5 agentes.
Suficientemente barato como para que una función lanzada pague el mes.
En resumen
La diferencia entre un montón de agentes y un pipeline es la transferencia.
Cuatro especialistas escribiendo en archivos compartidos, un orquestador ejecutándolos en orden, cada etapa construyendo sobre la anterior en lugar de empezar desde cero.
Construye primero el Planificador y el Programador y ejecútalos como una cadena de dos etapas. Una vez que ese flujo se sienta sólido, añade el Probador y el Revisor.
Para cuando los cuatro estén conectados, lanzarás una función antes de dormir y leerás un veredicto con tu café.
Para notas diarias sobre agentes de IA, vibe coding y configuraciones de Claude Code: https://t.me/zodchixquant 🧠
