Example: Building a Software Feature

Scenario: Users are complaining that the analytics dashboard in your web app takes 8–12 seconds to load. A few have churned. Your PM has escalated it. You need to fix it.

[Research] → Plan → [Plan Validation ×2] → Build
  → [Build Validation] → [Review pre-ship] → Ship
  → [Review post-ship]

How to read this example

Each step shows what was given to an agent as an instruction, what the agent returned as output, and what the human decided based on that output. The agent can be you, a collaborator, or an AI — the structure is the same either way. Gates are where the human reads the output and decides whether to proceed. That decision is never skipped.

Step 1: Research gate

Instruction given to agent

What is actually causing the analytics dashboard to load in 8–12 seconds? What is the scope of the problem? Spend no more than 30 minutes.

Output from agent

The dashboard makes 4 separate database queries on load, each running a full table scan over an events table (>2M rows for some accounts)
No indexes on account_id + created_at columns — every query scans the full table
Queries are sequential, not concurrent — each waits for the previous to complete
The 8–12s range correlates to account size: small accounts (< 10k events) load in ~1s; large accounts (> 500k events) load in 10–14s
One query fetches a raw_payload column that is never displayed in the UI — leftover from an old feature
Root cause: missing indexes + sequential queries + an unused column being fetched
Adding indexes alone would likely cut load time 60–70% for large accounts

Human decision

The cause is understood. The fix is backend-only — no design or frontend work needed. Enough to write a Plan Brief. Proceed to Plan.

Step 2: Plan phase

Instruction given to agent

Using the research findings, write a Plan Brief for fixing the analytics dashboard load time.

Reference files: Research findings from Step 1

Output from agent

Plan Brief

Problem
The analytics dashboard loads in 8–12 seconds for accounts with large event volumes (> 100k events), causing user frustration and churn. Root cause: missing database indexes, sequential queries, and an unused column being fetched on every load.

Audience
Internal engineering team (implementing the fix) and the ~200 accounts with > 100k events experiencing the slowness.

Goal
Fix the analytics dashboard load time to under 2 seconds for all account sizes.

Appetite
One engineer, one week. If the fix can't be completed in that, scope it down — not extend the time.

Constraints

Backend-only fix — no design or frontend changes in this cycle
Must not break existing dashboard functionality
Needs a database migration (indexes) — must be safe to run on production without downtime
Staged rollout: deploy to 10% of accounts first, monitor for 24 hours before full rollout

Success criteria

Dashboard loads in under 2 seconds for accounts with > 100k events
Dashboard loads in under 1 second for accounts with < 10k events
All four dashboard queries are covered by indexes
The unused raw_payload column is removed from the query
No existing dashboard tests break

Core assumption
The load time problem is caused by missing indexes and sequential queries — not by a fundamental architecture issue that would require a larger rewrite.

Rabbit holes
Do not investigate why the legacy endpoint is slow — that is a separate system. Do not explore a caching layer — out of scope for this cycle.

Out of scope

Caching layer (may be a future improvement)
Frontend loading states or skeleton screens
Dashboard redesign
Performance improvements to any other part of the app

Human decision

The brief is solid but "under 2 seconds" is vague — 2 seconds measured how? Under what load? The success criteria need percentiles. Also: there is no rollback plan mentioned for the migration. Take this to Plan Validation before building.

Step 3: Plan Validation gate — Pass 1

Instruction given to agent

Review this Plan Brief. Is the problem correctly stated? Is the plan feasible? Is it specific enough to build from without asking clarifying questions?

Reference files: Plan Brief from Step 2

Output from agent

Is the problem correctly stated? Partially. The problem says "under 2 seconds" but that's vague — 2 seconds for who? On what hardware? Under what load? The success criteria need a percentile (e.g., P95 load time).
Is the plan feasible? Yes, given the research findings. The changes are well-scoped and the cause is understood.
Is it specific enough to build from? No. "Under 2 seconds" without a percentile is not measurable in a way that accounts for outliers. A single slow request could fail the criterion. Also: the migration rollback plan is not stated — it should be explicit.

Gaps identified:

Success criteria use absolute times without percentiles — not reliably measurable
No rollback plan for the database migration
No baseline stated — what is being compared against?

Human decision

The gaps are real and fixable. Update the Plan Brief and run a second pass — the migration involves production and the cost of a wrong assumption here is high.

Changes made to Plan Brief:

Success criteria updated to P95: "Dashboard loads in under 2 seconds (P95) for accounts with > 100k events, measured in production"
Added: "Migration includes a rollback script, tested in staging before production"
Added baseline: current P95 is 9.2s for large accounts, 1.0s for small accounts

Step 4: Plan Validation gate — Pass 2

Instruction given to agent

Read the updated Plan Brief. Tell me: what is being built, what does done look like, and what would you do first?

Reference files: Updated Plan Brief from Step 3

Output from agent

"You're adding indexes to the events table on account_id and created_at, running the dashboard queries concurrently, and removing raw_payload from the select. Done means P95 load time under 2s for large accounts, confirmed in production."
"I'd add the indexes first, measure the improvement, then tackle the concurrent queries."

Human decision

The agent's understanding matches exactly. Two people (or agents) reading this brief would make the same first decision. Ready to Build.

Step 5: Build phase

Instruction given to agent

Execute the Plan Brief. Build the fix in this order: (1) add indexes, (2) remove raw_payload, (3) refactor queries to run concurrently, (4) measure P95 in staging, (5) write and test rollback script.

Reference files: Updated Plan Brief, analytics/queries.js, db/schema.sql, tests/dashboard.test.js, staging environment credentials

Output from agent

Migration added: events(account_id, created_at) index. Tested in staging with EXPLAIN ANALYZE — index scan confirmed. Staging load time dropped from ~9s to ~3.5s for large accounts.
raw_payload removed from select — one-line change. Dropped load time another ~0.4s.
Dashboard queries refactored to run concurrently using Promise.all. Staging load time: ~1.1s for large accounts, ~0.4s for small accounts.
Staging P95 measurements: 1.1s for > 100k events, 0.4s for < 10k events. Both under target. Baseline was 9.2s and 1.0s respectively.
Rollback script written and tested — removes the indexes safely without data loss.

Blocker surfaced during Build: One of the four queries had a write dependency on the result of another — they were not truly independent. Concurrent execution caused a race condition in test. Restructure needed: run two queries concurrently, then a third sequentially, then the fourth.

Human decision — mid-build check

The race condition is real. The restructure is the right call — do not route around it. The result is still well within target (1.1s vs. the 2s goal). Update the Plan Brief to document this as a known limitation, not a failure.

Plan Brief updated: Added to Out of scope: "Query 2 and Query 3 have a sequential dependency — cannot be fully parallelized. Documented for future optimization."

Proceed to Build Validation.

Step 6: Build Validation gate

Instruction given to agent

Check the output against every success criterion in the Plan Brief. Flag any that are not met.

Reference files: Updated Plan Brief, staging P95 measurements, EXPLAIN ANALYZE output, test suite results

Output from agent

Success criterion	Status	Note
P95 < 2s for accounts > 100k events	Pass	Staging P95: 1.1s. Tested against 5 large accounts.
P95 < 1s for accounts < 10k events	Pass	Staging P95: 0.4s.
All four queries covered by indexes	Pass	Confirmed via `EXPLAIN ANALYZE` — all use index scan
`raw_payload` removed from query	Pass	Verified in code review
No existing dashboard tests break	Pass	Full test suite green

No criteria failed. Known limitation: queries 2 and 3 cannot be fully parallelized — documented in Plan Brief. Severity: low (target is met without it).

Human decision

All criteria met. No regressions. Known limitation is documented and deferred. Proceed to pre-ship Review.

Step 7: Review gate — pre-ship

Instruction given to agent

Does this result solve the problem stated in the Plan Brief? Would the affected users notice the improvement? What is the weakest part of this result?

Reference files: Plan Brief, Build Validation results

Output from agent

The problem was 8–12s load time causing churn. The fix brings it to 1.1s P95 for the most affected accounts — an 8x improvement. The problem is solved.
Users experiencing 10s loads will experience 1s loads after rollout. The improvement is large enough to notice without prompting.
Weakest part: the staged rollout means large-account users will get the fix at different times. Someone who churned last week won't be automatically retained.

Human decision

The weakness is real but it is not a problem with the fix — it is a property of the staged rollout, which exists to reduce production risk. Accept. Ready to Ship.

Step 8: Ship phase

Instruction given to agent

Deploy the migration to 10% of production accounts. Monitor error rates, query durations, and P95 load times for 24 hours. Report back.

Reference files: Rollback script, deployment runbook, monitoring dashboard

Output from agent

Migration deployed to 10% of production accounts
Monitored for 24 hours: no errors, no regressions
Production P95 for large accounts: 0.9s (slightly better than staging)

Human decision

Signal is clear. No regressions. Full rollout approved.

Full rollout deployed. Confirmed live: opened dashboard as a large-account user — loads in under 1 second. Internal update posted: "Analytics dashboard performance fix shipped. P95 load time down from 9.2s to 0.9s for large accounts."

Step 9: Review gate — post-ship

Instruction given to agent

10 days after full rollout: measure actual production outcomes against every success criterion. What worked, what didn't, and what should feed into the next cycle?

Reference files: Production monitoring data (10-day window), Plan Brief, notes from Build

Output from agent

Success criterion	Result	Evidence
P95 < 2s for accounts > 100k events	Met	Production P95: 0.9s (10-day average)
P95 < 1s for accounts < 10k events	Met	Production P95: 0.35s (10-day average)
All four queries covered by indexes	Met	Confirmed in production query explain plans
`raw_payload` removed from query	Met	No `raw_payload` selects in production query logs
No existing dashboard tests break	Met	No new test failures or production errors in 10 days

What worked: Running Research before Plan redirected the entire approach — the obvious alternative (a caching layer) would have been more complex and wouldn't have addressed the root cause (missing indexes). The two-pass Plan Validation loop caught the "under 2 seconds" vagueness before it became ambiguous during Build.

What didn't work: The query dependency (queries 2 and 3) was a surprise — Research didn't surface it. A deeper code review before planning would have caught it.

Feed forward:

Queries 2 and 3 have a sequential dependency worth a dedicated investigation cycle
The 24-hour monitoring window felt long — signal was clear within 2 hours. Could reduce to 4–6 hours for non-data-destructive migrations
Two churned accounts reactivated after the fix, cited dashboard speed in support threads

Human decision

Results are better than the target. The cycle is complete. Feed the query dependency and monitoring window findings into the next Plan.

What this example demonstrates

Principle	Where it showed up
Clarity before action	Research identified root cause before planning. Plan Validation made success criteria measurable (P95, not "under 2 seconds").
Build to learn	The sequential dependency between queries 2 and 3 only surfaced during Build — handled and documented without derailing the cycle.
Reality is the only validator	Staging showed 1.1s. Production showed 0.9s. The plan predicted improvement; only shipping produced the real number.
Gates reduce cost, not momentum	Two passes of Plan Validation added ~2 hours. They prevented building against a vague target and ensured the migration had a rollback path.
The brief is your compass	When the query dependency was found, the Plan Brief was updated to document it — not silently accepted.
AI executes. Human decides.	At every gate, the human read the output and made the call — proceed, iterate, or cut. The race condition blocker was surfaced and decided on mid-build, not worked around.

The full cycle at a glance

[Research] → Plan → [Plan Validation ×2] → Build → [Build Validation] → [Review pre-ship] → Ship → [Review post-ship]

Each arrow is a human decision: read the output, judge it, decide what comes next.

Escenario: Los usuarios se quejan de que el panel de análisis en tu aplicación web tarda 8–12 segundos en cargar. Algunos han cancelado. Tu PM lo ha escalado. Necesitas corregirlo.

[Research] → Plan → [Plan Validation ×2] → Build
  → [Build Validation] → [Review pre-ship] → Ship
  → [Review post-ship]

Cómo leer este ejemplo

Cada paso muestra qué se le dio a un agente como instrucción, qué devolvió el agente como resultado, y qué decidió el humano basándose en ese resultado. El agente puede ser tú, un colaborador, o una IA — la estructura es la misma en cualquier caso. Las compuertas son donde el humano lee el resultado y decide si proceder. Esa decisión nunca se omite.

Paso 1: Compuerta de Investigación

Instrucción dada al agente

¿Qué está causando realmente que el panel de análisis cargue en 8–12 segundos? ¿Cuál es el alcance del problema? Dedica no más de 30 minutos.

Resultado del agente

El panel hace 4 consultas de base de datos separadas al cargar, cada una realizando un escaneo completo de la tabla events (>2M filas para algunas cuentas)
Sin índices en las columnas account_id + created_at — cada consulta escanea la tabla completa
Las consultas son secuenciales, no concurrentes — cada una espera a que la anterior se complete
El rango de 8–12s se correlaciona con el tamaño de la cuenta: cuentas pequeñas (< 10k eventos) cargan en ~1s; cuentas grandes (> 500k eventos) cargan en 10–14s
Una consulta obtiene una columna raw_payload que nunca se muestra en la UI — resto de una funcionalidad antigua
Causa raíz: índices faltantes + consultas secuenciales + una columna no utilizada que se obtiene
Agregar índices solo probablemente reduciría el tiempo de carga un 60–70% para cuentas grandes

Decisión humana

La causa está entendida. La corrección es solo backend — no se necesita diseño ni trabajo de frontend. Suficiente para escribir un Plan Brief. Proceder a Planificar.

Paso 2: Fase de Planificar

Instrucción dada al agente

Usando los hallazgos de la investigación, escribe un Plan Brief para corregir el tiempo de carga del panel de análisis.

Archivos de referencia: Hallazgos de investigación del Paso 1

Resultado del agente

Plan Brief

Problema
El panel de análisis carga en 8–12 segundos para cuentas con grandes volúmenes de eventos (> 100k eventos), causando frustración del usuario y cancelaciones. Causa raíz: índices de base de datos faltantes, consultas secuenciales y una columna no utilizada que se obtiene en cada carga.

Audiencia
Equipo de ingeniería interno (implementando la corrección) y las ~200 cuentas con > 100k eventos que experimentan la lentitud.

Objetivo
Corregir el tiempo de carga del panel de análisis a menos de 2 segundos para todos los tamaños de cuenta.

Apetito
Un ingeniero, una semana. Si la corrección no puede completarse en ese tiempo, reducir el alcance — no extender el tiempo.

Restricciones

Corrección solo de backend — sin cambios de diseño o frontend en este ciclo
No debe romper la funcionalidad existente del panel
Necesita una migración de base de datos (índices) — debe ser segura para ejecutar en producción sin tiempo de inactividad
Lanzamiento por fases: desplegar al 10% de las cuentas primero, monitorear durante 24 horas antes del lanzamiento completo

Criterios de éxito

El panel carga en menos de 2 segundos para cuentas con > 100k eventos
El panel carga en menos de 1 segundo para cuentas con < 10k eventos
Las cuatro consultas del panel están cubiertas por índices
La columna raw_payload no utilizada se elimina de la consulta
No fallan pruebas existentes del panel

Suposición central
El problema de tiempo de carga es causado por índices faltantes y consultas secuenciales — no por un problema fundamental de arquitectura que requeriría una reescritura mayor.

Trampas a evitar
No investigar por qué el endpoint heredado es lento — ese es un sistema separado. No explorar una capa de caché — fuera del alcance para este ciclo.

Fuera de alcance

Capa de caché (puede ser una mejora futura)
Estados de carga de frontend o pantallas de esqueleto
Rediseño del panel
Mejoras de rendimiento a cualquier otra parte de la aplicación

Decisión humana

El brief es sólido pero "menos de 2 segundos" es vago — ¿2 segundos medidos cómo? ¿Bajo qué carga? Los criterios de éxito necesitan percentiles. Además: no se menciona ningún plan de reversión para la migración. Llevar esto a Validación del Plan antes de construir.

Paso 3: Compuerta de Validación del Plan — Pasada 1

Instrucción dada al agente

Revisa este Plan Brief. ¿El problema está correctamente planteado? ¿El plan es factible? ¿Es lo suficientemente específico para construir a partir de él sin hacer preguntas de aclaración?

Archivos de referencia: Plan Brief del Paso 2

Resultado del agente

¿El problema está correctamente planteado? Parcialmente. El problema dice "menos de 2 segundos" pero eso es vago — ¿2 segundos para quién? ¿En qué hardware? ¿Bajo qué carga? Los criterios de éxito necesitan un percentil (ej., tiempo de carga P95).
¿El plan es factible? Sí, dados los hallazgos de la investigación. Los cambios están bien delimitados y la causa está entendida.
¿Es lo suficientemente específico para construir a partir de él? No. "Menos de 2 segundos" sin un percentil no es medible de una manera que considere los valores atípicos. Una sola solicitud lenta podría fallar el criterio. Además: el plan de reversión de la migración no está declarado — debería ser explícito.

Brechas identificadas:

Los criterios de éxito usan tiempos absolutos sin percentiles — no medibles de forma confiable
Sin plan de reversión para la migración de base de datos
Sin línea base declarada — ¿con qué se está comparando?

Decisión humana

Las brechas son reales y reparables. Actualizar el Plan Brief y ejecutar una segunda pasada — la migración involucra producción y el costo de una suposición incorrecta aquí es alto.

Cambios realizados al Plan Brief:

Criterios de éxito actualizados a P95: "El panel carga en menos de 2 segundos (P95) para cuentas con > 100k eventos, medido en producción"
Agregado: "La migración incluye un script de reversión, probado en staging antes de producción"
Línea base agregada: el P95 actual es 9.2s para cuentas grandes, 1.0s para cuentas pequeñas

Paso 4: Compuerta de Validación del Plan — Pasada 2

Instrucción dada al agente

Lee el Plan Brief actualizado. Dime: ¿qué se está construyendo, cómo se ve el resultado final, y qué harías primero?

Archivos de referencia: Plan Brief actualizado del Paso 3

Resultado del agente

"Estás agregando índices a la tabla de eventos en account_id y created_at, ejecutando las consultas del panel de forma concurrente, y eliminando raw_payload del select. Listo significa tiempo de carga P95 bajo 2s para cuentas grandes, confirmado en producción."
"Agregaría los índices primero, mediría la mejora, luego abordaría las consultas concurrentes."

Decisión humana

El entendimiento del agente coincide exactamente. Dos personas (o agentes) leyendo este brief tomarían la misma primera decisión. Listo para Construir.

Paso 5: Fase de Construir

Instrucción dada al agente

Ejecuta el Plan Brief. Construye la corrección en este orden: (1) agregar índices, (2) eliminar raw_payload, (3) refactorizar consultas para ejecutarse de forma concurrente, (4) medir P95 en staging, (5) escribir y probar el script de reversión.

Archivos de referencia: Plan Brief actualizado, analytics/queries.js, db/schema.sql, tests/dashboard.test.js, credenciales del entorno de staging

Resultado del agente

Migración agregada: índice events(account_id, created_at). Probado en staging con EXPLAIN ANALYZE — escaneo de índice confirmado. El tiempo de carga en staging bajó de ~9s a ~3.5s para cuentas grandes.
raw_payload eliminado del select — cambio de una línea. Bajó el tiempo de carga otros ~0.4s.
Consultas del panel refactorizadas para ejecutarse de forma concurrente usando Promise.all. Tiempo de carga en staging: ~1.1s para cuentas grandes, ~0.4s para cuentas pequeñas.
Mediciones P95 en staging: 1.1s para > 100k eventos, 0.4s para < 10k eventos. Ambas por debajo del objetivo. La línea base era 9.2s y 1.0s respectivamente.
Script de reversión escrito y probado — elimina los índices de forma segura sin pérdida de datos.

Bloqueador encontrado durante la Construcción: Una de las cuatro consultas tenía una dependencia de escritura en el resultado de otra — no eran verdaderamente independientes. La ejecución concurrente causó una condición de carrera en las pruebas. Se necesita reestructuración: ejecutar dos consultas de forma concurrente, luego una tercera de forma secuencial, luego la cuarta.

Decisión humana — verificación a mitad de construcción

La condición de carrera es real. La reestructuración es la decisión correcta — no rodear el problema. El resultado sigue estando bien dentro del objetivo (1.1s vs. el objetivo de 2s). Actualizar el Plan Brief para documentar esto como una limitación conocida, no un fracaso.

Plan Brief actualizado: Agregado a Fuera de alcance: "Las consultas 2 y 3 tienen una dependencia secuencial — no se pueden paralelizar completamente. Documentado para optimización futura."

Proceder a Validación de la Construcción.

Paso 6: Compuerta de Validación de la Construcción

Instrucción dada al agente

Verifica el resultado contra cada criterio de éxito del Plan Brief. Señala cualquiera que no se cumpla.

Archivos de referencia: Plan Brief actualizado, mediciones P95 de staging, resultado de EXPLAIN ANALYZE, resultados del conjunto de pruebas

Resultado del agente

Criterio de éxito	Estado	Nota
P95 < 2s para cuentas > 100k eventos	Pasa	P95 en staging: 1.1s. Probado contra 5 cuentas grandes.
P95 < 1s para cuentas < 10k eventos	Pasa	P95 en staging: 0.4s.
Las cuatro consultas cubiertas por índices	Pasa	Confirmado via `EXPLAIN ANALYZE` — todas usan escaneo de índice
`raw_payload` eliminado de la consulta	Pasa	Verificado en revisión de código
No fallan pruebas existentes del panel	Pasa	Suite de pruebas completa en verde

Ningún criterio falló. Limitación conocida: las consultas 2 y 3 no se pueden paralelizar completamente — documentado en Plan Brief. Severidad: baja (el objetivo se cumple sin ello).

Decisión humana

Todos los criterios cumplidos. Sin regresiones. La limitación conocida está documentada y diferida. Proceder a la Revisión pre-lanzamiento.

Paso 7: Compuerta de Revisión — pre-lanzamiento

Instrucción dada al agente

¿Este resultado resuelve el problema planteado en el Plan Brief? ¿Los usuarios afectados notarían la mejora? ¿Cuál es la parte más débil de este resultado?

Archivos de referencia: Plan Brief, resultados de Validación de la Construcción

Resultado del agente

El problema era un tiempo de carga de 8–12s que causaba cancelaciones. La corrección lo lleva a 1.1s P95 para las cuentas más afectadas — una mejora de 8x. El problema está resuelto.
Los usuarios que experimentan cargas de 10s experimentarán cargas de 1s después del lanzamiento. La mejora es lo suficientemente grande como para notarla sin necesidad de informar.
Parte más débil: el lanzamiento por fases significa que los usuarios de cuentas grandes obtendrán la corrección en diferentes momentos. Alguien que canceló la semana pasada no será retenido automáticamente.

Decisión humana

La debilidad es real pero no es un problema con la corrección — es una propiedad del lanzamiento por fases, que existe para reducir el riesgo de producción. Aceptar. Listo para Lanzar.

Paso 8: Fase de Lanzar

Instrucción dada al agente

Despliega la migración al 10% de las cuentas de producción. Monitorea tasas de error, duraciones de consultas y tiempos de carga P95 durante 24 horas. Reporta.

Archivos de referencia: Script de reversión, manual de despliegue, panel de monitoreo

Resultado del agente

Migración desplegada al 10% de las cuentas de producción
Monitoreado durante 24 horas: sin errores, sin regresiones
P95 de producción para cuentas grandes: 0.9s (ligeramente mejor que staging)

Decisión humana

La señal es clara. Sin regresiones. Lanzamiento completo aprobado.

Lanzamiento completo desplegado. Confirmado en vivo: abrió el panel como un usuario de cuenta grande — carga en menos de 1 segundo. Actualización interna publicada: "Corrección de rendimiento del panel de análisis lanzada. Tiempo de carga P95 bajó de 9.2s a 0.9s para cuentas grandes."

Paso 9: Compuerta de Revisión — post-lanzamiento

Instrucción dada al agente

10 días después del lanzamiento completo: mide los resultados reales de producción contra cada criterio de éxito. ¿Qué funcionó, qué no, y qué debería alimentar el próximo ciclo?

Archivos de referencia: Datos de monitoreo de producción (ventana de 10 días), Plan Brief, notas de la Construcción

Resultado del agente

Criterio de éxito	Resultado	Evidencia
P95 < 2s para cuentas > 100k eventos	Cumplido	P95 de producción: 0.9s (promedio de 10 días)
P95 < 1s para cuentas < 10k eventos	Cumplido	P95 de producción: 0.35s (promedio de 10 días)
Las cuatro consultas cubiertas por índices	Cumplido	Confirmado en los planes de explicación de consultas de producción
`raw_payload` eliminado de la consulta	Cumplido	Sin selects de `raw_payload` en los logs de consultas de producción
No fallan pruebas existentes del panel	Cumplido	Sin nuevas fallas de pruebas o errores de producción en 10 días

Lo que funcionó: Ejecutar Investigación antes de Planificar redirigió todo el enfoque — la alternativa obvia (una capa de caché) habría sido más compleja y no habría abordado la causa raíz (índices faltantes). El ciclo de Validación del Plan en dos pasadas detectó la vaguedad de "menos de 2 segundos" antes de que se volviera ambigua durante la Construcción.

Lo que no funcionó: La dependencia de consultas (consultas 2 y 3) fue una sorpresa — la Investigación no la descubrió. Una revisión de código más profunda antes de planificar la habría detectado.

Retroalimentación hacia adelante:

Las consultas 2 y 3 tienen una dependencia secuencial que merece un ciclo de investigación dedicado
La ventana de monitoreo de 24 horas se sintió larga — la señal fue clara dentro de las 2 horas. Podría reducirse a 4–6 horas para migraciones no destructivas de datos
Dos cuentas canceladas se reactivaron después de la corrección, citando la velocidad del panel en hilos de soporte

Decisión humana

Los resultados superan el objetivo. El ciclo está completo. Alimentar los hallazgos sobre la dependencia de consultas y la ventana de monitoreo en el próximo Plan.

Qué demuestra este ejemplo

Principio	Dónde apareció
Claridad antes de acción	La Investigación identificó la causa raíz antes de planificar. La Validación del Plan hizo los criterios de éxito medibles (P95, no "menos de 2 segundos").
Construir para aprender	La dependencia secuencial entre las consultas 2 y 3 solo apareció durante la Construcción — manejada y documentada sin descarrilar el ciclo.
La realidad es el único validador	Staging mostró 1.1s. Producción mostró 0.9s. El plan predijo mejora; solo lanzar produjo el número real.
Las compuertas reducen el costo, no el impulso	Dos pasadas de Validación del Plan agregaron ~2 horas. Evitaron construir contra un objetivo vago y aseguraron que la migración tuviera un camino de reversión.
El brief es tu brújula	Cuando se encontró la dependencia de consultas, el Plan Brief se actualizó para documentarla — no se aceptó silenciosamente.
La IA ejecuta. El humano decide.	En cada compuerta, el humano leyó el resultado y tomó la decisión — proceder, iterar o cortar. El bloqueador de la condición de carrera se descubrió y decidió a mitad de construcción, no se eludió.

El ciclo completo de un vistazo

[Research] → Plan → [Plan Validation ×2] → Build → [Build Validation] → [Review pre-ship] → Ship → [Review post-ship]

Cada flecha es una decisión humana: leer el resultado, juzgarlo, decidir qué viene después.

Building a Software Feature

Step 1: Research gate

Step 2: Plan phase

Step 3: Plan Validation gate — Pass 1

Step 4: Plan Validation gate — Pass 2

Step 5: Build phase

Step 6: Build Validation gate

Step 7: Review gate — pre-ship

Step 8: Ship phase

Step 9: Review gate — post-ship

What this example demonstrates

The full cycle at a glance

Construir una Funcionalidad de Software

Paso 1: Compuerta de Investigación

Paso 2: Fase de Planificar

Paso 3: Compuerta de Validación del Plan — Pasada 1

Paso 4: Compuerta de Validación del Plan — Pasada 2

Paso 5: Fase de Construir

Paso 6: Compuerta de Validación de la Construcción

Paso 7: Compuerta de Revisión — pre-lanzamiento

Paso 8: Fase de Lanzar

Paso 9: Compuerta de Revisión — post-lanzamiento

Qué demuestra este ejemplo

El ciclo completo de un vistazo