Práctica: Guía paso a paso para usar 7 Agentes y elevar Vibe Coding a un proceso de desarrollo experto

El autor @sairahul1 desglosó la revolución del flujo de trabajo de la actualización de 「Vibe Coding」 a 「Fábrica de Software」: dividir una única conversación de IA en 7 agentes especializados: investigador, escritor de historias, redactor de especificaciones, constructor backend, constructor frontend, verificador de pruebas, validador de implementación, cada uno con una única responsabilidad, contexto limpio y límites estrictos.
(Resumen previo: ¿Puede MCP conectado con Web3, que conecta todo, ser la próxima ola de narrativas AI con cien veces más impacto?)
(Información adicional: ¡El mejor maestro inversor trabaja para ti! Reúne a Buffett, Munger, Cathie Wood… 19 agentes AI que analizan el mercado)

Índice de este artículo

Alternar

• La pregunta que nadie discute
• Giro: de Vibe Coding a Fábrica de Software
• Los siete agentes
  • Agente 1: Investigador de código (Codebase Researcher)
  • Agente 2: Escritor de historias (Story Writer)
  • Agente 3: Redactor de especificaciones (Spec Writer)
  • Agente 4: Constructor backend (Backend Builder)
  • Agente 5: Constructor frontend (Frontend Builder)
  • Agente 6: Verificador de pruebas (Test Verifier)
  • Agente 7: Validador de implementación (Implementation Validator)
• Cómo funciona toda la cadena
• Fundamentos: antes de que los agentes puedan operar, necesitas esto
  • CLAUDE.md — La memoria en cada conversación
  • Desplazamiento de contexto — El asesino silencioso
• Resultados: ¿qué cambia realmente?
  • Antes de la fábrica:
  • Después de la fábrica:
  • El cambio real:
• Crea tu propia versión este fin de semana
  • Lista de 8 pasos:
• Los siete agentes — Referencia rápida

Pensé que usaba IA para programar. En realidad, solo escribo más rápido.

Lo que quiero decir con esto es la diferencia — y la revolución completa: 「el sistema de 7 agentes」.

Guarda esto. Te ahorrará varios meses.

La pregunta que nadie discute

Ese ciclo que parece productivo, pero en realidad no lo es:

→ Pides a Claude que te haga una función → Genera código → Algo se rompe → Pegas el error de vuelta → Lo arregla → Se rompe en otro lado → Preguntas otra vez

Día 1: Esto parece magia.

Día 30: Pasas más tiempo supervisando a la IA que escribiendo tú mismo.

El mismo patrón aparece en tres lugares diferentes. Claude olvida las reglas que estableciste hace dos semanas. La nueva función rompe la antigua. Las pruebas son insuficientes o superficiales.

Un día despiertas y te das cuenta: no es que la IA falle, sino que tu flujo de trabajo está fallando.

La raíz del problema es estructural.

Cuando en Claude Code dices “haz esta función”, en realidad estás pidiendo a una IA que actúe como:

→ Analista de producto → Arquitecto → Ingeniero backend → Ingeniero frontend → Ingeniero de pruebas → Revisor de código

Todo en una sola conversación desordenada.

Las hipótesis incorrectas en el plan se convierten en modelos de base de datos equivocados. Modelos incorrectos generan API erróneas. API mal diseñadas producen UI equivocadas.

Y cuando te das cuenta, el error ya se ha propagado por todas partes.

Esto es lo que llaman vibe coding (programar por intuición).

Tiene un límite muy duro.

Giro: de Vibe Coding a Fábrica de Software

La clave que realmente cambia todo:

Un equipo de ingeniería real no trabaja en una sola conversación grande.

Cada persona tiene un rol diferente:

→ Alguien clarifica el problema del usuario → Otro piensa en la arquitectura → Otro escribe API → Otro diseña UI → Otro considera límites y casos extremos → Otro revisa

Cuando todos estos roles se condensan en una sola conversación con IA, los errores se acumulan silenciosamente.

La solución es dividir el trabajo en agentes especializados.

Cada agente recibe:

→ Una tarea enfocada → Un contexto limpio y específico → Solo las herramientas que necesita → Reglas estrictas sobre qué no puede tocar

Resultado: una fábrica de software.

Un desarrollador + siete agentes enfocados = un equipo coordinado.

Aquí están los siete agentes que hacen que esto funcione.

Los siete agentes

Agente 1: Investigador de código (Codebase Researcher)

¿Cuál es el error más grande al usar IA para desarrollo?

Pensar que “querer código” es el primer paso.

La IA recibe un prompt, hace conjeturas para rellenar vacíos y empieza a generar. Es en ese momento donde entra el diseño deficiente.

El investigador corrige esto.

Su única tarea: inspeccionar el repositorio y explicar el estado actual — antes de que se escriba una línea de código.

Qué hace:

• Marcar archivos relevantes y su rol
• Registrar patrones existentes
• Encontrar funciones similares ya implementadas
• Señalar riesgos (zona horaria, multiinquilino, lógica de reintentos)
• Listar qué pruebas necesitan actualización

Qué no puede hacer:

• Editar archivos (solo lectura)
• Ejecutar comandos que cambien estado
• Hacer suposiciones — debe preguntar

Herramientas: Read, Grep, Glob, solo eso.

Regla: Antes de empezar, explorar siempre.

El investigador siempre primero.

Agente 2: Escritor de historias (Story Writer)

La mayoría de los fallos no ocurren porque el código esté mal.

Sino porque el problema nunca se definió claramente.

El escritor de historias transforma una idea vaga en una historia de usuario real — antes de que se tomen decisiones técnicas.

Entrada:

• Tu descripción inicial de la función
• Resultados de la investigación

Salida:

• Una historia de usuario: “Como [rol], quiero [acción], para [resultado].”
• Criterios de aceptación: declaraciones verificables, camino feliz, caminos fallidos, reglas comerciales.
• Casos límite: límites, reintentos, consideraciones multiinquilino.
• Fuera de alcance: qué NO se hará explícitamente.
• Preguntas sin respuesta: cosas que realmente no sabe, sin inventar.

Qué no puede hacer:

• Inventar reglas comerciales
• Escribir código o diseño técnico
• Avanzar cuando hay incertidumbre real

Herramientas: Read, solo eso.

Regla: Debes leer y aprobar la historia antes de avanzar.

Este es el punto clave para que todo lo que venga después esté correcto — punto de revisión humano 1.

Agente 3: Redactor de especificaciones (Spec Writer)

Tras aprobar la historia, el especificador la convierte en un documento técnico.

Este documento será la guía para todos los agentes de construcción.

Entrada:

• La historia aprobada
• Resultados de la investigación
• Las reglas en CLAUDE.md

Salida:

• Cambios en el modelo de datos (campos, tipos, migraciones)
• Flujos de fondo / procesos
• Cambios en API (endpoints, request/response)
• Cambios en frontend (componentes, páginas, hooks)
• Pruebas necesarias (éxito, fallo, límites)
• Riesgos y preguntas sin respuesta
• Lista de archivos afectados

Qué no puede hacer:

• Editar archivos
• Inventar infraestructura (solo señalar)
• Omitir consideraciones de multiinquilino o zona horaria
• Dejar preguntas sin respuesta

Herramientas: Read, Grep, Glob, solo eso.

Regla: Este documento es punto de revisión humano 2.

Debes leer y aprobar antes de que cualquier archivo pase a la siguiente etapa.

Si ves “guardar ID en memoria” — eso es una bandera roja.

Ahora, detecta eso. No esperes a que se cambien 10 archivos.

Agente 4: Constructor backend (Backend Builder)

Aquí empieza la construcción.

El constructor backend implementa la “mitad backend” — solo esa parte.

Entrada:

• La especificación técnica aprobada
• Resultados de la investigación
• Tu CLAUDE.md

Construye:

• Rutas API
• Servicios y lógica de negocio
• Acceso a base de datos y migraciones
• Tareas en background
• Pruebas unitarias del código

No puede:

• Tocar componentes React, páginas o hooks del cliente (eso lo hace el agente 5)
• Inventar dependencias sin instrucciones
• Modificar archivos fuera del alcance
• Parar sin correr typecheck, lint y tests

Al terminar, devuelve un resumen: archivos nuevos o modificados, patrones reutilizados, observaciones sobre reglas en CLAUDE.md si las hay.

Herramientas: Read, Edit, Write, Bash — solo en la carpeta backend.

Clave: separar responsabilidades.

El constructor backend nunca debe romper el frontend.

Agente 5: Constructor frontend (Frontend Builder)

El constructor frontend implementa la UI — solo esa parte.

Recibe el resumen del backend.

Esto es crucial.

Usa la API del backend como está, sin inventar endpoints nuevos.

Si la forma de la API no encaja con la UI,lo reporta — no parchea.

Entrada:

• La especificación técnica aprobada
• Resultados de la investigación
• Resumen del backend (contrato API)

Construye:

• Componentes React y páginas
• Hooks y estado del cliente
• Estados de carga y error
• Pruebas unitarias y de componentes

No puede:

• Tocar servicios, rutas API, workers o migraciones (eso lo hace el agente 4)
• Inventar endpoints o formatos de respuesta
• Agregar dependencias sin instrucciones
• Parar sin typecheck, lint y tests

Al terminar, devuelve un resumen en la misma carpeta frontend.

Dos constructores, contextos limpios, sin riesgo de romperse mutuamente.

Agente 6: Verificador de pruebas (Test Verifier)

Ambos constructores escriben sus propias pruebas unitarias.

Pero eso no basta.

El verificador de pruebas hace una sola cosa: demostrar que la función realmente cumple la historia de usuario.

Escribe “pruebas de aceptación”, no solo unitarias.

Las pruebas de aceptación verifican la funcionalidad desde fuera — como un usuario real.

Entrada:

• La historia de usuario aprobada (con todos los criterios)
• La especificación técnica aprobada
• Resumen de los dos constructores

Salida:

• Un archivo de pruebas de aceptación que cubre todos los criterios
• Un informe: qué pasó, qué falló, qué no cubre bien

Qué no puede hacer:

• Modificar código backend o frontend
• Inventar soluciones para criterios no verificables
• Marcar como cubierto lo que no lo está

Si alguna prueba falla: la función no satisface la historia.

Se reporta qué criterio falló. No corrige código.

Las correcciones vuelven a los constructores correctos.

Herramientas: Read, Edit, Write (solo pruebas), Bash.

Regla: Hasta que las pruebas de aceptación pasen, la función no existe.**

Agente 7: Validador de implementación (Implementation Validator)

Este agente detecta lo que todos olvidan.

El validador compara la implementación actual con la historia y la especificación, y** reporta las diferencias**.

Nunca modifica nada. Solo dice la verdad.

Cada revisión verifica:

• ¿Faltan criterios de aceptación implementados?
• ¿Hay caminos sin cobertura de pruebas?
• ¿Hay problemas de seguridad: permisos, aislamiento, keys en logs, errores expuestos?
• ¿Archivos fuera del alcance modificados?
• ¿Patrones inconsistentes con CLAUDE.md o código existente?
• ¿Reuso de helpers en lugar de duplicar lógica?
• ¿Consideraciones de zona horaria o multiinquilino omitidas?

Salida agrupada por gravedad:

• Crítico — obligatorio antes de merge
• Importante — recomendable antes de merge
• Menor — opinión del revisor

Cada hallazgo incluye ruta y línea.

Si no hay problemas, simplemente dice “sin problemas”. No inventa problemas solo para parecer exhaustivo.

Herramientas: Read, Grep, Glob, solo eso.

Este agente es la razón por la que la fábrica es confiable.

Un reporte de autoevaluación sin valor. Solo un verificador que mira “qué hay en disco”, no “cómo está escrito”, es honesto.

Cómo funciona toda la cadena

Proceso completo — un prompt inicia todo:

Abres Claude Code, escribes:

“Haz la función ‘recordatorio de facturas no pagadas por más de 7 días’.”

Luego, no necesitas escribir más. Esto pasa así:

Paso 1: El investigador revisa facturas, pagos y código de email. Devuelve archivos relevantes, patrones existentes y riesgos.

Paso 2: El escritor de historias genera historia de usuario y criterios de aceptación.

⏸ Pausa: Lees y apruebas la historia.

Paso 3: El redactor de especificaciones convierte la historia en un documento técnico.

⏸ Pausa: Lees y apruebas el documento. (Aquí detecta “guardar ID en memoria” como error.)

Paso 4: El constructor backend implementa servicios, rutas API, tareas en BullMQ y pruebas unitarias. Devuelve cambios en archivos, patrones reutilizados, pruebas verdes.

Paso 5: El constructor frontend lee el resumen del backend, crea UI administrativa y botones de recordatorio, escribe pruebas. Todo en verde.

Paso 6: El verificador de pruebas escribe pruebas de aceptación para los 6 criterios. Reporta: 7 pasaron, 1 falló — por ejemplo, no verificar la propiedad del inquilino.

Paso 7: El validador detecta la falla. Reporta en nivel crítico, con archivos y líneas.

→ Regresa al constructor backend. Corrige. Los 8 criterios pasan. El validador vuelve a correr. Todo limpio.

⏸ Pausa: Revisas y haces PR.

Tres revisores humanos. Todo lo demás se autoejecuta.

Fundamentos: antes de que los agentes puedan operar, necesitas esto

CLAUDE.md — La memoria en cada conversación

Cada vez que abres Claude Code, empieza desde “cero”.

CLAUDE.md corrige esto.

Es un archivo Markdown en la raíz del repo, que se carga automáticamente al inicio de cada conversación.

Es el “hogar de los hechos permanentes del proyecto”:

• Tu stack técnico (Next.js App Router, Node.js, Prisma, BullMQ, Resend)
• Tus comandos (npm run dev, npm test, npx prisma migrate dev)
• Reglas de arquitectura (“Lógica de negocio en services. API delgada.”)
• Cosas que NO hacer (“No agregar cron — usar BullMQ. No guardar payloads de pagos en logs.”)
• Indicadores de documentación profunda (docs/billing.md, docs/architecture.md)

Manténlo entre 100 y 300 líneas.

Cada error sorprendente de la IA te invita a preguntarte: “¿Podría esto evitarse si tuviera una regla en CLAUDE.md?”

Agrega esa regla.

Semanas después, tu CLAUDE.md será un registro de “todas las suposiciones en las que la IA se equivocó” — y tus conversaciones mejorarán notablemente.

Desplazamiento de contexto — El asesino silencioso

La mayoría de las conversaciones con Claude Code no fallan dramáticamente.

Pero sí se desplazan.

Una hipótesis incorrecta entra en el contexto. El modelo sigue acumulando.

Quieres que Claude gestione “suscripción”. Diseñas: User → Subscription.

Luego recuerdas: la suscripción pertenece a la “empresa”, no al “usuario”.

Si solo dices “no, la suscripción es de la empresa”, — Claude parchea.

Y ahora tienes en paralelo user.subscriptionId y company.subscriptionId.

Reglas:

• ¿Error menor? Corrige inline.
• ¿Hipótesis equivocada? Descarta toda la conversación, empieza de nuevo, y fija la hipótesis correcta en el prompt inicial.

Una conversación limpia con la mentalidad correcta siempre supera a una parcheada.

Resultado: ¿qué cambia realmente?

Antes de la fábrica:

• Ciclo vibe coding: prompt → generación → error → parche → repetir
• Contexto lleno de ruido
• Hipótesis incorrectas acumuladas en funciones rotas
• Un ingeniero solo puede hacer una cosa a la vez
• Cada función espera a la persona adecuada

Después de la fábrica:

• Cadena estructurada: investigación → historia → especificación → construcción → validación → confirmación
• Cada agente con contexto limpio, solo lo que necesita
• Hipótesis incorrectas detectadas en “aprobación de especificación”, no después de 10 archivos
• Un ingeniero puede completar un corte vertical completo: backend, frontend, pruebas, validación
• El conocimiento del equipo vive en los agentes — no atrapado en “una sola persona”

Cambio real:

Un experto en pagos crea un agente payments-integration. Desde ese momento, cada ingeniero puede lanzar funciones con integración de pagos. Sin esperar, sin transferencia.

Los patrones de componentes del frontend lead, en frontend-builder. Los chequeos de CI de DevOps, en hooks. Las consideraciones de límites del QA, en test-verifier.

El conocimiento experto se comparte en agentes. No depende de “quién está disponible”.

Crea tu propia versión este fin de semana

Lista de 8 pasos:

2. Instala Claude Code → code.claude.com
3. Crea estructura de carpetas:
   • .claude/agents/
   • .claude/skills/feature-factory/
   • .claude/skills/build-with-tests/
   • .claude/hooks/
4. Escribe tu CLAUDE.md (100–300 líneas: stack, comandos, reglas, lista de NO hacer)
5. Usa el comando /agents en Claude Code para crear los 7 agentes. Describe sus roles. Claude crea archivos. Tú revisas y haces commit.
6. Crea la skill orchestrator de feature-factory. Pide a Claude que te ayude a escribirla — leerá tus 7 archivos de agentes y conectará toda la cadena.
7. Crea la skill build-with-tests. Describe cómo tu equipo construye: siguiendo patrones existentes, escribiendo código y pruebas en paralelo, y haciendo typecheck al final.
8. Añade un hook pre-commit. Para bloquear commits de .env, .key, .pem o secrets.json. En 5 minutos, evita desastres.
9. Ejecuta un flujo completo con una función pequeña. Observa dónde se atasca. Añade reglas. La fábrica ajustará automáticamente.

Tiempo total: 2–3 horas.

Prueba varias funciones. Después de 3–4, la fábrica entenderá tu código.

Tendrás menos supervisión, más decisiones sobre “qué hacer después”.

Los siete agentes — Referencia rápida

• Investigador (Researcher): Antes de crear, revisa código (solo lectura)
• Escritor de historias (Story Writer): Convierte ideas en historias y criterios (solo lectura)
• Redactor de especificaciones (Spec Writer): De historia a documento técnico (solo lectura)
• Constructor backend (Backend Builder): API, servicios, tareas, tests (solo en carpeta backend)
• Constructor frontend (Frontend Builder): Componentes, páginas, hooks, tests UI (solo en carpeta frontend)
• Verificador de pruebas (Test Verifier): Escribe pruebas de aceptación (solo en archivos de test)
• Validador (Validator): Compara implementación con historia y especificación, reporta diferencias (solo lectura)

3 revisores humanos:

→ Aprobar historia → Aprobar especificación → Aprobar PR

El resto se autoejecuta.

Muchos desarrolladores con Claude Code todavía usan vibe coding. Prompt → generación → parche → rezar.

No está mal. Pero tiene un techo.

La fábrica no te saca del proceso. Te saca de las partes donde “no necesitas juzgar”.

Te quedas en las partes donde “tu juicio es realmente importante”:

¿Es esto el problema correcto? ¿Es este el diseño correcto? ¿Es seguro lanzar esto?

Todo lo demás, lo manejan los agentes.

Eso es la diferencia entre “usar IA como un teclado más rápido” y “usar IA como un equipo coordinado”.

Autor original: @sairahul1