English · Español

02 — Supervivencia de decisiones: ¿qué elecciones arquitectónicas aguantaron?

Cuarenta fases significan cientos de pequeñas decisiones. ¿Cuáles aguantaron sin revisión? ¿Cuáles se revisaron una vez? ¿Cuáles murieron? Es una medida objetiva de la calidad del juicio temprano.

La hipótesis

Un proyecto de 40 fases genera aproximadamente 50-200 decisiones arquitectónicas — estructura de archivos, elección de librería, elección de algoritmo, frontera de abstracción. Algunas aguantaron sin revisión; algunas se revisaron silenciosamente cuando la siguiente fase lo necesitó; algunas se desmontaron explícitamente.

Tasa de supervivencia = (decisiones que aguantaron sin revisión) / (decisiones totales).

Una tasa alta de supervivencia es sospechosa — o no estabas asumiendo suficiente riesgo, o no estabas siendo honesto sobre las revisiones. Una tasa baja está bien si puedes articular por qué — significa que aprendías. La forma de la curva de supervivencia a lo largo del tiempo te dice algo sobre la trayectoria de tu juicio.

La fuente de datos

PROPOSAL_REVIEW.md en la raíz del proyecto es el libro mayor. Cada propuesta arquitectónica que necesitó una etiqueta "Claude debería revisar esto" aterrizó allí. Igual que cada entrada "Borja decidió revisar X".

Además: el Revisions log (§8) al final de cada PHASE_NN_PLAN.md.

Además: las entradas de diario en learners/borja/journal/ donde el formato incluye un campo decisions:.

Los cuatro estados

Clasifica cada decisión en uno de cuatro estados:

1. Mantenida (H) — se tomó, nunca se revisó, sigue vigente en la Fase 40.
2. Revisada una vez (R1) — se tomó, se revisó exactamente una vez en una fase posterior.
3. Revisada muchas (RN) — revisada 2+ veces a lo largo del proyecto.
4. Descartada (D) — explícitamente revertida; el sistema en la Fase 40 se ve como si esta decisión nunca se hubiera tomado.

Para cada decisión, anota también:

• Cuándo se tomó — la fase.
• Alcance — a nivel de archivo, de módulo, de proyecto.
• Qué forzó la revisión (si aplica) — una restricción posterior, un bug, un aprendizaje, un cambio de corpus.

Ejemplos de clasificaciones

Decisión	Tomada en	Estado	Por qué
Usar uv en vez de pip	Fase 00	H	Se mantuvo vigente; sin fricción.
9 funciones de C-strings como corpus	Fase 12 (orig)	D	Descartada en la enmienda A13 por el corpus de gramática verbal.
Pre-LN sobre Post-LN transformer	Fase 17	H	Mantenida; la estabilidad del gradiente coincidió con las expectativas.
Autograd hecho a mano en Fases 07-08 antes de PyTorch	Fase 00	H	La decisión que definió todo el currículo.
Sampleo sin KV cache en la Fase 21	Fase 21	R1	Reemplazado en la Fase 22; el hueco era intencional (pedagogía).
FastAPI mono-proceso para serving	Fase 33	H	Multi-proceso se discutió y rechazó; se mantuvo.
Usar Pydantic v1 (fases tempranas)	Fase 06	R1	Migrado a Pydantic v2 en la Fase 30 (por características de JSONSchema).
Memoria del aprendiz solo en memoria	Fase 32	H	Mantenida; persistencia aparcada al capstone de Fase 39 (fuera de alcance).

Cómo podría verse la curva de supervivencia

Si dibujas tasa de supervivencia vs fase de la decisión original:

• Las decisiones tomadas pronto (Fases 0-5) suelen tener mayor supervivencia porque son fundacionales (herramientas, elección de lenguaje).
• Las decisiones tomadas en el medio (Fases 10-25) tienen la menor supervivencia — es cuando el currículo se dobla para encajar con la realidad.
• Las decisiones tomadas tarde (Fases 30-39) tienden a tener supervivencia artificialmente alta porque no ha habido tiempo para revisarlas.

Un patrón "sano": ~70-90% de supervivencia en herramientas, ~40-60% en arquitectura, ~20-50% en elecciones de algoritmo.

Leer los factores contribuyentes

Para cada decisión revisada, escribe 1-2 frases:

• Qué información nueva forzó la revisión? ("El KV cache de la Fase 22 dejó obsoleto el sampler de la Fase 21 por diseño").
• ¿Estaba la revisión en el plan original? ("Sí — la Fase 21 anotó explícitamente 'sin cache aquí; la Fase 22 lo arregla'").
• Nivel de sorpresa (1-5): 1 = esperado; 5 = chocante.

La distribución de sorpresa es más útil que la tasa de supervivencia. Las revisiones de alta sorpresa son donde tu modelo del sistema estaba equivocado. Esas son las lecciones a extraer para proyectos futuros.

El sesgo a vigilar

La gente tiende a sobre-clasificar decisiones como Mantenidas porque:

• Olvidan las pequeñas revisiones.
• Prefieren pensar que tenían razón.
• Confunden "el espíritu de la decisión se mantuvo" con "la decisión literal se mantuvo".

Contra-sesgo: escanea la historia de git. Si un archivo ha cambiado más de 5 veces a lo largo de las fases, las decisiones que ese archivo encarna no están Mantenidas.

El sesgo contrario a vigilar

La gente tiende a sobre-clasificar decisiones como Revisadas porque:

• Cada pequeño retoque parece una revisión en el momento.
• La retrospectiva hace que las decisiones tempranas parezcan ingenuas.

Contra-sesgo: solo cuenta revisiones que cambiaron el contrato de un módulo o la interfaz de una API. Renombrar una variable no cuenta.

La salida

Para el lab 02 de la Fase 40, este análisis va en el postmortem (§3 factores contribuyentes) como una tabla pequeña o un gráfico en cascada. No te excedas — clasificar 10-20 decisiones es suficiente. El objetivo es ver el patrón, no ser exhaustivo.

Para qué este análisis no es bueno

• Predecir qué necesitará revisar el siguiente proyecto. Cada proyecto tiene su propio patrón.
• Juzgar si el currículo estaba bien diseñado. Una tasa alta de revisión podría significar que el diseño era malo o que el viaje fue honesto sobre el aprendizaje.
• Comparar la calidad de las decisiones de Borja con las de cualquier otra persona. Es una medida intra-proyecto solamente.

Lo que este archivo NO cubre

• Las decisiones específicas a clasificar. Eso es contenido del lab.
• La forma de la aceptación de riesgo residual. Siguiente archivo.

Siguiente: 03-residual-risk-and-offramps.md