Coding Agents · flujo architect → spec → conductor
El flujo real de ALDC para desarrollo. Tres roles que no se superponen. Tres subagentes que orquesta el conductor. TDD en siete pasos con HITL entre fases. No-self-review como regla no negociable.
Niveles de madurez · ¿dónde estás hoy?
Antes de entrar en el flujo, conviene ubicar el listón. La mayoría de equipos de BC ha pasado por los tres niveles — pero no todos en el mismo orden, y muchos se quedan atascados en el segundo.
Copilot asistido
Tab-completion. Preguntas puntuales. El dev escribe, el agente ayuda.
Copilot dirigido
Prompts estructurados, prompt files, skills. El dev dirige, el agente ejecuta piezas.
Coding agents
El agente orquesta. El dev valida en gates. Spec-driven + HITL + evidencia.
El Bloque 3 es el salto del segundo al tercero. No es cuestión de usar un modelo más grande — es cuestión de arquitectura.
Flujo real de ALDC · 3 momentos, 1 workflow entre ellos
architect DISEÑA · el workflow DETALLA · conductor EJECUTA con 3 subagentes bajo supervisión humana
Los 3 roles principales · no se superponen
architecture.md con ADRs y Skills Applied al top.spec.md.LOW vs MEDIUM-HIGH · el flujo se adapta a la complejidad
LOW complexity · fast path
Para cambios aislados, evolutivos pequeños, fixes con alcance claro.
- Se salta
al-architecty el workflowal-spec.create - Va directo al
al-developero al conductor con plan mínimo - HITL reducido a un único gate final (PR)
Cuándo: <50 líneas, sin tablas nuevas, sin integraciones externas.
MEDIUM-HIGH complexity · full path
Para nuevas features, integraciones, cambios con impacto transversal.
- Ciclo completo:
architect→spec.create→conductor - Plan approval + phase commit + PR · 3 HITL gates mínimo
- Skills Evidencing obligatorio en los 3 subagentes
Cuándo: cualquier cosa que toque más de 2 objetos o exponga API.
El triage lo hace el humano al iniciar la sesión, o el al-architect si hay duda. La regla conservadora es escalar: ante la duda, full path.
Los 3 subagentes del conductor
El conductor no genera código. Coordina tres subagentes especializados que sí lo hacen, cada uno con una responsabilidad acotada.
al-planning
Lee la spec. Produce plan de ejecución en fases. Identifica dependencias entre objetos. Marca HITL gates. Emite plan.md.
al-implement
Ejecuta una fase del plan. Escribe código AL. Carga skills relevantes y lo declara en la Phase Summary. Emite phase-N.md.
al-review
Revisa la fase que el implementador acaba de escribir. Compliance check contra el contrato. Tabla Skills Compliance. Emite review en phase-N.review.md.
TDD en 7 pasos · el bucle que ejecuta el conductor
El bucle se repite por cada fase del plan. Al final de cada fase hay un gate HITL: el humano aprueba o pide cambios. El conductor no avanza sin aprobación.
Skills Compliance Check · cómo audita al-review
Al cerrar cada fase, al-review produce una tabla que cruza skills declaradas por el implementador con skills efectivamente aplicadas en el código. Si hay disparidad, se flaggea.
| Skill declarada | Patrón esperado | Evidencia en código | Estado |
|---|---|---|---|
| skill-api | API page v2.0 + bound actions | /api/v2.0 · POST /incidents/{id}/Microsoft.NAV.resolve | ✓ PASS |
| skill-performance | SetLoadFields en queries repetitivas | CalcFormula en flowfield, sin SetLoadFields en loops | ✗ FAIL · Major |
| skill-permissions | Permission set por objeto nuevo | CEB Barista Incidents Basic + Full presentes | ✓ PASS |
| skill-events | OnBefore/OnAfter en lugar de modificación directa | Publisher declarado, integration event tipado | ✓ PASS |
La tabla viaja al phase-complete.md del conductor. Si hay FAIL, el HITL gate no se pasa — el humano ve el detalle, decide si aceptar, pedir refactor, o reajustar la spec.
Mini-demo · al-architect sobre Barista Incidents
Para cerrar el bloque, el al-architect entra sobre una página y media de contexto de negocio — el futuro caso práctico del Bloque 4. Solo arquitectura, nada de código. El objetivo es ver el output real y cómo mapea a skills.
Prompt al architect
Load al-architect.
Context:
Barista Incidents is an extension for a coffee shop chain running BC.
Baristas report incidents (machine breakdown, supply shortage, customer
complaint) from a simple Card page. Incidents have severity levels, are
auto-assigned to a technician queue, and trigger notifications. Once
resolved, they feed a weekly KPI report shown on a Role Center tile.
Task: Produce {barista-incidents}.architecture.md at MEDIUM-HIGH complexity.
Include: ADRs, data model, APIs exposed, events, permissions strategy,
Skills applied at the top.
Qué debería salir del architect
- Skills applied al inicio del documento · previsibles:
skill-api,skill-events,skill-pages,skill-permissions, opcionalmenteskill-copilotsi el architect decide incluir asistencia natural - ADRs numerados · "Decidimos X porque Y, alternativas consideradas Z"
- Data model · Incident, Incident Severity, Incident Assignment, Incident KPI
- APIs · POST /incidents, POST /incidents/{id}/resolve (bound action), GET /incidents (query)
- Events · OnIncidentCreated, OnIncidentResolved (para que otros módulos se enganchen)
- Permissions · dos permission sets (Basic para baristas, Full para técnicos/managers)
Observar cómo opera el architect en vuestra pantalla
Quien tenga el workspace abierto puede replicar en paralelo. El objetivo no es producir exactamente el mismo output — es ver cómo el architect carga las skills por sí solo y cómo su propia descripción lo convierte en un agente invocable.
- Abrid
.github/agents/al-architect.agent.mdantes de lanzar. Buscad la sección Responsibilities y Skills Evidencing. - Pegad el prompt completo en Copilot Chat.
- Observad cómo el output empieza por
> **Skills applied**:— esa línea es Skills Evidencing operando. - Comparad las skills que el architect declara con las que aparecen en nuestra lista esperada.
al-spec.create + al-conductor para implementarla — pero ya vosotros.
Qué cubre este bloque
Niveles de madurez
Copilot asistido · Copilot dirigido · Coding agents. Dónde está el salto real.
Flujo de ALDC
architect → spec.create → conductor con 3 subagentes. Roles que no se superponen.
LOW vs MEDIUM-HIGH
Fast path para cambios aislados · full path para cualquier cosa con impacto.
TDD de 7 pasos
Bucle del conductor con HITL al final de cada fase. No-self-review.
Skills Compliance Check
La tabla que audita skills declaradas vs aplicadas en el código.
Mini-demo architect
Arquitectura de Barista Incidents generada en vivo. Antesala del Bloque 4.