El Developer: Implementacion Guiada

El Developer: Focused Executor

El Developer es el quinto agente en el flujo de BMAD. Su rol es implementar codigo siguiendo estrictamente las especificaciones de cada story. No toma decisiones de arquitectura, no agrega features y no improvisa.

Se le llama Focused Executor porque ejecuta exactamente lo que la story dice. Ni mas, ni menos.

Principio clave: una story a la vez

Esta es la regla fundamental del Developer en BMAD:

El Developer no lee el PRD completo. No lee todas las stories. Solo lee la story que tiene asignada.

Esto es Context Sharding en accion. El Developer carga en su contexto unicamente:

1. El archivo story-XXX.md actual
2. Los archivos relevantes listados en la story
3. El codigo existente del proyecto

No necesita saber que viene despues. No necesita entender el panorama completo. Su trabajo es implementar lo que dice la story y asegurarse de que los criterios de aceptacion se cumplan.

Como carga el Developer una story

En tu IDE agentico, la carga se ve asi:

En Claude Code:

Implementa @docs/stories/story-001.md siguiendo las subtareas en orden.
Consulta @docs/ARCHITECTURE.md y @docs/db-schema.md solo las
secciones indicadas en la story.

En Cursor:

@story-001.md Implementa esta story. Sigue las subtareas en orden.
Archivos de referencia: @ARCHITECTURE.md @db-schema.md

El punto critico es que solo referencias los archivos que la story indica en su seccion “Archivos Relevantes”. No le das mas contexto del necesario.

Flujo de implementacion

El Developer sigue un flujo disciplinado para cada story:

graph TD
    A[Leer story completa] --> B[Verificar prerequisitos]
    B --> C[Crear/modificar archivos]
    C --> D[Instalar dependencias aprobadas]
    D --> E[Implementar subtareas en orden]
    E --> F[Escribir tests]
    F --> G[Ejecutar lint]
    G --> H{Tests pasan?}
    H -->|No| E
    H -->|Si| I[Commit atomico]
    I --> J[Marcar story como DONE]

Cada paso tiene un proposito:

1. Leer story completa: entender el alcance antes de escribir codigo
2. Verificar prerequisitos: confirmar que las dependencias estan en DONE
3. Crear archivos: siguiendo la estructura de directorios del Architect
4. Instalar dependencias: solo las aprobadas en tech-stack.md
5. Implementar subtareas: en el orden listado, una a una
6. Tests: cada subtarea debe ser verificable
7. Lint: codigo limpio antes de commitear
8. Commit atomico: un commit por story, mensaje descriptivo

Ejemplo: Implementando story-001

Veamos como el Developer aborda la primera story del Kanban.

Lo que el Developer lee:

story-001.md
├── Descripcion: setup proyecto + DB
├── Subtareas: 7 items concretos
├── Criterios: 4 verificaciones
└── Archivos relevantes:
    ├── docs/tech-stack.md (todo)
    ├── docs/ARCHITECTURE.md (estructura)
    └── docs/db-schema.md (esquema)

Lo que el Developer genera:

Sigue las subtareas en orden estricto:

Subtarea 1: Crear estructura de directorios

El Developer consulta ARCHITECTURE.md y crea la estructura:

kanban/
  backend/
    src/
      modules/
      middleware/
      prisma/
      app.ts
      server.ts
    package.json
    tsconfig.json
  frontend/
    src/
    package.json
  docker-compose.yml

Subtarea 2-3: Inicializar backend y frontend

Ejecuta los comandos de scaffolding con las tecnologias aprobadas en tech-stack.md. No usa Create React App si tech-stack.md dice Vite. No usa yarn si dice npm.

Subtarea 4: Configurar Prisma

Consulta db-schema.md y traduce el esquema a Prisma:

model User {
  id           String   @id @default(uuid())
  email        String   @unique
  passwordHash String   @map("password_hash")
  name         String
  createdAt    DateTime @default(now()) @map("created_at")
  boards       Board[]
  cards        Card[]   @relation("assigned_cards")
}

Cada tabla del schema se convierte en un model de Prisma, respetando tipos, relaciones y convenciones definidas por el Architect.

Subtarea 5-6: Docker y migracion

Crea docker-compose.yml con PostgreSQL y ejecuta la migracion:

docker-compose up -d
npx prisma migrate dev --name init

Subtarea 7: Health check

Implementa un endpoint minimo para verificar la conexion:

GET /api/health → { "status": "ok", "db": "connected" }

Como valida:

El Developer recorre los criterios de aceptacion uno por uno:

• docker-compose up levanta PostgreSQL — ejecuta y verifica
• npx prisma migrate dev sin errores — ejecuta y verifica
• GET /api/health responde ok — curl y verifica
• Las 4 tablas existen — consulta DB y verifica

Solo cuando todos pasan, hace el commit:

git add .
git commit -m "feat: setup proyecto con Express, React, Prisma y PostgreSQL"

El Control Manifest

El Control Manifest es un conjunto de guardrails que el Developer debe respetar en todo momento. Se define en la configuracion de BMAD y contiene:

Librerias permitidas:

Solo se pueden instalar las librerias listadas en tech-stack.md. Si el Developer necesita algo no aprobado, debe detenerse y escalar al Architect.

Permitido: express, prisma, bcrypt, jsonwebtoken, @dnd-kit/core
Prohibido: cualquier otra libreria no listada

Restricciones de performance:

- Maximo 150 lineas por archivo
- Funciones de maximo 30 lineas
- No queries N+1 (usar include/join)
- No logica de negocio en controllers

Zonas prohibidas:

- No modificar schema.prisma sin aprobacion del Architect
- No crear endpoints no listados en api-spec.json
- No agregar campos a la DB sin documentar en db-schema.md

El Control Manifest evita que el Developer tome atajos o agregue funcionalidad no especificada. Es la diferencia entre un agente disciplinado y un agente que improvisa.

BMAD vs Vibe Coding

La diferencia entre implementar con BMAD y el “vibe coding” es la diferencia entre construccion y improvisacion:

Vibe Coding:

"Hazme una app de Kanban con auth, drag & drop y base de datos"
→ El agente decide todo: tech stack, estructura, DB schema, API
→ Genera 2,000 lineas de codigo en un solo prompt
→ Sin tests, sin documentacion, sin estructura predecible
→ Funciona a medias, dificil de mantener o extender

BMAD:

"Implementa story-003: CRUD de tableros"
→ El agente sigue subtareas definidas
→ Usa el tech stack aprobado
→ Respeta la estructura del Architect
→ Genera tests que verifican criterios de aceptacion
→ Commit atomico, trazable al requisito FR-02

La tabla comparativa:

Aspecto	Vibe Coding	BMAD
Contexto	Todo junto, saturado	Fragmentado por story
Decisiones	Las toma el LLM	Las tomo el humano (via PM/Architect)
Trazabilidad	Ninguna	Story → Epic → Requisito
Tests	Opcionales	Obligatorios por story
Escalabilidad	Se rompe en proyectos medianos	Funciona en proyectos grandes
Costo en tokens	Alto (contexto repetido)	Bajo (Context Sharding)

BMAD no es mas lento. Es mas predecible. El tiempo que “ahorras” con vibe coding lo pagas despues depurando codigo sin estructura.

Cuando pedir ayuda

El Developer no es autonomo al 100%. Hay escenarios donde debe detenerse y escalar:

Volver al Architect cuando:

• La story requiere una libreria no listada en tech-stack.md
• Descubre que el schema de DB necesita un campo adicional
• La estructura de directorios no encaja con lo que necesita
• Un endpoint necesita un formato de respuesta diferente

Volver al PM cuando:

• Un criterio de aceptacion es ambiguo
• Descubre un caso borde no contemplado en las user stories
• La story parece cubrir mas de un dia de trabajo

Volver al Scrum Master cuando:

• Las dependencias de la story no estan completas
• Una subtarea es demasiado grande y deberia dividirse
• El workflow-status.md tiene inconsistencias

Este ciclo de feedback es intencional. BMAD no pretende que todo fluya sin friccion. Los puntos de escalacion garantizan que los problemas se detecten temprano, no cuando ya hay 5,000 lineas de codigo construidas sobre un cimiento fragil.

Ciclo completo de una story

Resumiendo el flujo del Developer para una story:

1. Leer story-XXX.md
2. Verificar que dependencias estan en DONE
3. Cargar solo los archivos relevantes
4. Implementar subtareas en orden
5. Escribir tests por cada subtarea
6. Ejecutar lint y corregir
7. Verificar criterios de aceptacion
8. Commit atomico
9. Actualizar workflow-status.md → DONE
10. Siguiente story

Cada story completada es un incremento verificable del producto. Al finalizar las 8 stories del Kanban, tienes un producto funcional construido con disciplina y trazabilidad completa.

---

← Capitulo 6: El Scrum Master | Capitulo 8: El QA →