English · Español

05 — Behavioral y Storytelling: STAR + 10 Anécdotas de lynx-cortex¶

Plantilla STAR + 10 anécdotas pre-escritas desde el viaje de lynx-cortex. Convierte el currículo en historias concretas con tradeoffs explícitos, listas para entrevistas en Anthropic, OpenAI, etc.

La plantilla STAR¶

Situation:   1-2 frases. ¿Cuál era el contexto? Plantea las apuestas.
Task:        1 frase. ¿Qué intentabas hacer específicamente?
Action:      3-5 frases. ¿Qué hiciste TÚ? Primera persona; concreto; profundidad técnica.
Result:      1-2 frases. ¿Qué cambió de forma medible? Cuantifica si es posible.
Reflection:  1 frase. ¿Qué harías diferente? (A menudo saltada — añade señal de seniority.)

Calibración¶

Longitud total: 60-90 segundos hablados. Practica con temporizador.
"Yo" no "nosotros". Los entrevistadores sondearán ownership. Si dices "nosotros" preguntarán "qué hiciste tú específicamente".
Un número concreto por historia. (Latencia, coste en dólares, % de mejora, líneas de código, etc.)
La reflection es la señal de ingeniero senior. Los candidatos junior la saltan; los senior abren con ella.

Cómo el viaje de lynx-cortex apoya behavioral¶

El currículo de 41 fases es un proyecto de ingeniería profundo, bien documentado, multi-mes anclado a especificaciones escritas (LYNX_CORTEX.md), reportes por fase (PHASE_NN_REPORT.md), y documentos explícitos de tradeoff (PROPOSAL_REVIEW.md, LYNX_CORTEX_ADDENDUM.md). Cada pregunta behavioral tiene una respuesta anclada a una fase con recibos (un archivo de reporte que puedes citar).

Los recibos hacen la diferencia entre "confía en mí, tío" y "tengo los artefactos".

Anécdota 1 — "Cuéntame de un sistema complejo que construyeras end-to-end."¶

Gancho. "Construí un transformer desde primeros principios en 41 fases a lo largo de [N] meses — desde representación binaria de floats hasta RLHF en un adaptador LoRA fine-tuneado."

Situation. Quería internalizar transformers a una profundidad que la lectura de papers y el seguimiento de tutoriales no podían darme. Así que diseñé un currículo de 41 fases (LYNX_CORTEX.md) — cada fase tiene una spec escrita, una build, un segmento teach, y un report. Los artefactos están en docs/phase-NN-*/.

Task. Construir cada componente desde representación binaria de float hasta agentes y MLOps, sin trampas de alcance. Los anti-goals eran explícitos: sin langchain, sin transformers antes de la fase 24, sin PyTorch antes de la fase 24. NumPy primero, hand-built segundo, framework al final.

Action. Cerré cada fase tras un ritual per-phase: plan, aprobación, build, teach, run, report, reflect. Cada fase terminaba con un PHASE_NN_REPORT.md escrito. Cuando necesitaba expandir o restringir alcance, lo escribía en LYNX_CORTEX_ADDENDUM.md — nunca edité la spec. Construí un tutor de gramática de alcance microscópico como el artefacto corriente, así cada fase producía algo usable sobre el mismo juguete.

Result. 41 fases de artefactos, cada una con manifests de reproducibilidad (experiments/<date>-<topic>/manifest.json — semilla + versiones + config). Puedo mostrar el archivo de reporte de cualquier fase como evidencia.

Reflection. La lección más grande fue disciplina de alcance. Pivoté el alcance de "9 funciones C de strings" a "tutor de gramática inglesa de 20 verbos" a mitad de programa (§A13 en el addendum) porque el alcance original no ejercitaba tokenización. Documentar el por qué en el addendum, en vez de reescribir silenciosamente la spec, mantuvo el audit trail intacto.

→ Cita: LYNX_CORTEX.md, LYNX_CORTEX_ADDENDUM.md, ROADMAP.md.

Anécdota 2 — "Cuéntame de una vez que depuraste algo difícil."¶

Gancho. "Fase 19 — training dynamics. Tuve un pico de pérdida que resultó ser un overflow de softmax enterrado bajo tres capas de mixed-precision."

Situation. Durante la Fase 19, mi mini-GPT entrenando en el corpus de gramática §A13 producía pérdida NaN en el paso ~800. Reiniciando desde el checkpoint previo, con la misma semilla y la misma data, reproducía el NaN en el mismo paso — así que era determinista.

Task. Encontrar la causa raíz sin bajar la tasa de aprendizaje a ciegas. (Bajar el LR es la respuesta "resolver síntoma"; el entrevistador está testeando la respuesta "resolver causa".)

Action. Bisecté. Primero confirmé que el NaN aparecía en las activaciones antes que en los gradientes — usando un forward hook en cada bloque transformer. El primer bloque en NaN-ear fue el output de attention de la capa 4. Dentro de ese bloque, logueé los inputs del softmax: el logit máximo era ~94, territorio de overflow fp16 (exp(94) > 65504). Incluso con el truco estándar softmax(x - x.max()), la sustracción era en fp16 y perdía demasiada precisión en la cola larga. El fix: cast el softmax a fp32 para esa op, downcast después.

Result. El entrenamiento siguió limpiamente pasado el paso 800; el pico nunca reapareció. Documenté esto como una nota de estabilidad numérica en phase-19-training-dynamics/PHASE_19_REPORT.md y añadí un test de regresión que inyecta logits extremos y asegura no NaN.

Reflection. La lección real fue el valor de la reproducibilidad determinista. Sin fijar la semilla y same-batch replay, habría gastado una semana persiguiendo un Heisenbug. La disciplina seed_everything(seed) + manifest (CLAUDE.md §0.5) se pagó sola en esta única sesión de debug.

→ Cita: phase-19-training-dynamics/PHASE_19_REPORT.md.

Anécdota 3 — "Cuéntame de un tradeoff que hicieras."¶

Gancho. "Pivoté el alcance de mi proyecto de 9 funciones C de strings a un tutor de gramática inglesa de 20 verbos — y escribí por qué."

Situation. La spec original LYNX_CORTEX.md clavaba el proyecto a un "alcance microscópico": replicar un subconjunto de 9 funciones de strings de la biblioteca estándar C como el universo del modelo. La intención era controlabilidad extrema para enseñanza.

Task. Usar este alcance hasta tokenización (Fase 11) y más allá. El problema emergió en la Fase 12 (diseño de corpus) — no había estructura lingüística significativa en data estilo strcpy(x, y). El tokenizer BPE aprendería merges triviales; los embeddings y attention subsiguientes no tendrían nada interesante que modelar.

Action. Consideré tres alternativas. (a) Expandir a toda la stdlib de C (demasiada superficie, contradice microscópico). (b) Mantener las 9 funciones pero augmentar con documentación inglesa (más limpio pero difumina el alcance). © Pivotar a un pequeño dominio de lenguaje natural: 20 verbos, 5 tiempos, 3 personas en inglés + español. Elegí © y lo escribí como LYNX_CORTEX_ADDENDUM.md §A13 — supersedes §A1, con un rationale explícito y hard rules sin cambiar (aún microscópico, aún sin framework antes de la Fase 24).

Result. El alcance del tutor-de-gramática desbloqueó cada fase subsiguiente. La Fase 11 (BPE) tuvo estructura de subword significativa. La Fase 17 (mini-GPT) podía entrenarse en un corpus bilingüe de conjugaciones. La Fase 32 (agentes) tuvo un capstone sensato — un tutor de corrección gramatical. El addendum es ahora el alcance operativo; la spec original se preserva sin cambios como un registro histórico.

Reflection. La lección es que el scope creep es peligroso, pero el pivot de alcance documentado en un addendum está bien. La disciplina de escribir el addendum en vez de editar silenciosamente la spec es lo que hace el pivot legítimo.

→ Cita: LYNX_CORTEX_ADDENDUM.md §A13.

Anécdota 4 — "Cuéntame de una vez que hicieras pushback a un stakeholder."¶

Gancho. "Decliné añadir langchain al proyecto — y puse el rechazo por escrito."

Situation. Temprano en el currículo, consideré añadir langchain y llama-index para acelerar las fases de agentes y RAG. Son las herramientas estándar; usarlas habría ahorrado semanas.

Task. Decidir si los ahorros de tiempo valían el coste de abstracción, dado el objetivo de aprendizaje declarado del proyecto de construir desde primeros principios.

Action. Escribí el pushback en PROPOSAL_REVIEW.md §10 ("anti-goals"): sin langchain, sin llama-index, jamás. La razón: estas bibliotecas esconden los mecanismos exactos (ensamblado de prompts, dispatch de herramientas, pipelines de retrieval) que el currículo supone enseñar. Construí RAG (Fase 29) y agentes (Fase 32) directamente sobre mis propias primitivas — vector store, MCP tool router, memoria de conversación — unas 600 líneas de código escrito a mano en vez de 20 líneas de llamadas a framework.

Result. El stack RAG y de agentes hand-built es más lento de desarrollar pero transparente: cuando algo falla puedo recorrerlo paso a paso. Importante, cuando un entrevistador pregunta "explica cómo funciona RAG" puedo describir los pasos reales, no "llamé a langchain.RAG.run()".

Reflection. Los frameworks son útiles en la fase correcta de un proyecto — scaling de producción, no profundidad pedagógica. Hacer pushback temprano, con justificación escrita, fue la llamada correcta. La disciplina vino de autorización explícita para hacer pushback (MEMORY.md → feedback_pushback_authorized.md).

→ Cita: PROPOSAL_REVIEW.md §10, CLAUDE.md §0.4.

Anécdota 5 — "Cuéntame de una vez que rompiste algo a propósito."¶

Gancho. "Cada fase de lynx-cortex tuvo un ritual /break — introducir intencionalmente un bug para aprender el modo de fallo."

Situation. Siguiendo el slash command /break (en .claude/commands/break.md en la raíz del repo), cada fase incluía un ejercicio donde rompía un componente funcional para estudiar cómo fallaba. Ejemplo de la Fase 15: corromper el factor de escalado sqrt(d_k) en attention.

Task. Predecir el modo de fallo antes de romper, luego verificar.

Action. Hipótesis: quitar el término sqrt(d_k) haría que el softmax saturara conforme d_k crece, matando gradientes. Ejecuté una comparación de entrenamiento con d_k = 64 y el escalado toggle-ado. Con escalado: la pérdida decreció suavemente. Sin: la pérdida se estancó — e inspeccionar las distribuciones del softmax confirmó que eran one-hot en inicialización, gradientes desapareciendo.

Result. Ahora tengo una intuición concreta del por qué el escalado está en la fórmula, no solo de que lo está. La ruptura está documentada en las notas de lab de la Fase 15.

Reflection. Romper a propósito es un hábito. Los incidentes de producción son raros; el músculo para diagnosticarlos se construye simulándolos. Ahora hago esto rutinariamente en cualquier sistema nuevo con el que trabajo — elijo un modo de fallo, hipotetizo, rompo, verifico.

→ Cita: .claude/commands/break.md, phase-15-attention/.

Anécdota 6 — "Cuéntame de una vez que enseñaras a alguien algo difícil."¶

Gancho. "El segmento de teaching del currículo me fuerza a explicar cada fase a un colega antes de que me permitan marcarla como hecha."

Situation. El ritual per-phase (LYNX_CORTEX.md §7) requiere un paso "Teach": tengo que ser capaz de explicar el contenido de la fase como si fuera a un colega que conoce las fases previas pero nada de esta. La Fase 8 (tensor autograd) fue la más difícil.

Task. Explicar diferenciación automática reverse-mode, gradientes broadcasting-aware, y la diferencia entre scalar y tensor autograd, en 30 minutos.

Action. Escribí un único ejemplo trabajado: un MLP de 2 capas forward y backward a mano, en papel, mostrando cada shape intermedio. La idea clave que enfaticé: el broadcasting debe revertirse en el backward pass (sum-reduce en el eje broadcasteado) — este es el único bug que pilla a todos la primera vez. Dibujé las anotaciones de shape explícitamente. Usé un ejercicio "predice el shape antes de computar".

Result. Mi audiencia (Borja, el learner activo) fue capaz de reimplementar el motor de autograd juguete en una sesión follow-up sin referirse de vuelta a mis notas.

Reflection. El acto de enseñar me forzó a encontrar el modelo mental más limpio posible. Varias veces pillé mi propio malentendido durante la pasada de teaching — "pensé que entendía esto hasta que intenté decirlo en voz alta" es una experiencia universal. Por esto el paso Teach es no saltable en el currículo.

→ Cita: phase-08-tensor-autograd/, learners/borja/journal/.

Anécdota 7 — "Cuéntame de una deadline ajustada."¶

Gancho. "Tuve 48 horas para enviar el mini-GPT de la Fase 17 antes de perder mi ventana de motivación. Envié una versión funcional pero fea, luego refactoricé durante la semana siguiente."

Situation. La Fase 17 (mini-GPT) es el clímax de la primera mitad del currículo. Llevaba semanas construyendo hacia ella y sentía la energía para empujar, pero tiempo concentrado limitado.

Task. Sacar un mini-GPT entrenable end-to-end en el corpus de tutor-de-gramática, con pérdida decreciendo, en 48 horas.

Action. Violé deliberadamente el ritual per-phase — sin BLUEPRINT.md, sin tests-first. Solo el forward pass, una pérdida, un optimizer, un loop de entrenamiento. 600 líneas en dos días. El código era horrible: globales, números mágicos, sin type hints. La pérdida bajó. Lo committeé con el mensaje "Phase 17 mini-GPT — ugly but trainable".

Result. Mini-GPT funcionando en 48 horas. Durante la semana siguiente seguí el ritual apropiado retrospectivamente: escribí BLUEPRINT, añadí tests, refactoricé, añadí mypy strict, documenté en PHASE_17_REPORT.md.

Reflection. La lección es que el ritual existe para mantenerme honesto a velocidad normal, pero en un sprint, enviar va primero y la disciplina sigue. Lo opuesto — disciplina estricta que nunca envía — es un modo de fallo común. El truco es ser honesto sobre en qué modo estás. (Anoté esto explícitamente en la sección de reflection del reporte de la Fase 17.)

→ Cita: phase-17-mini-gpt/PHASE_17_REPORT.md.

Anécdota 8 — "Cuéntame de un modelo que se comportara mal."¶

Gancho. (Favorita de Anthropic — ver 06-company-specific-prep.md). "Mi tutor de gramática se negaba a corregir frases cuando el verbo era 'kill' — estaba sobre-generalizando seguridad desde el entrenamiento RLHF."

Situation. Durante el módulo X3 (RLHF/DPO), ajusté finamente el tutor de gramática con data de preferencia. La data de preferencia incluía rechazos de completados tóxicos. Inesperadamente, el modelo comenzó a rechazar corregir gramática en frases que contenían cualquier verbo en un campo semántico violento.

Task. Diagnosticar: ¿era esto (a) artefacto del reward model, (b) etiquetado de preferencia sobre-conservador, © sobre-rechazo emergente por presión KL?

Action. Instrumenté el modelo para exponer su distribución de log-prob sobre correcciones vs rechazos en un test held-out con prompts controlados. Varié una sola variable — el campo semántico del verbo — manteniendo errores gramaticales constantes. La tasa de rechazo era ~90% en verbos violentos, ~5% en verbos neutros. El KL-a-referencia era ajustado (beta=0.5), así que no era drift. Mirando el dataset de preferencia, encontré que los etiquetadores habían marcado cualquier "frase corregida conteniendo violencia" como rechazada, sin importar la corrección gramatical — el reward model había aprendido "violencia → malo" en vez de "error gramatical → malo".

Result. Reescribí las guidelines de etiquetado de preferencia para separar explícitamente "corrección gramatical" de "seguridad de contenido". Tras re-entrenar el RM y re-ejecutar DPO, la tasa de rechazo en frases violentas-pero-benignas cayó a ~10%, sin regresión en contenido realmente dañino.

Reflection. La lección más profunda: la data de alineamiento es una spec, y specs poco claras causan spec-misalignment. El trabajo de limpieza no es model-tuning — es claridad de guideline de etiquetado. Esto es lo que Anthropic llama "claridad constitucional" en la literatura CAI.

→ Cita: extension-track/X3-rlhf-dpo/lab/01-dpo-on-grammar-tutor.md.

Anécdota 9 — "Cuéntame de una vez que llevaras un outage / incidente."¶

Gancho. (Para el capstone de la Fase 40; si te preguntan antes de esa fase, encuádralo como 'un near-miss en desarrollo'.) "Durante el load testing de la Fase 33 (inference serving), causé un thermal throttle en mi propio portátil que reveló un bug de queue-depth."

Situation. Lab de la Fase 33 (inference serving): construir un continuous batcher en el tutor de gramática §A13. Ejecutando un load test sintético en mi portátil i5-8250U, el throughput cayó 70% a mitad de test.

Task. Identificar el cuello de botella.

Action. Hipótesis inicial: saturación de cola. Revisé profundidades de cola — estaban bien. Segunda hipótesis: pausa de GC. El módulo gc de Python no reportó pico. Tercera hipótesis: en realidad, revisé sensors — la CPU estaba haciendo thermal throttle de 3.4 GHz bajando a 1.0 GHz bajo carga sostenida. El comportamiento de throttle interactuaba con mi batcher: requests que tomaban más de lo esperado en procesarse causaban que la política de admisión de cola sobre-admitiera, lo que hacía el siguiente batch aún más lento, causando más throttling. Un loop de feedback positivo en latencia.

Result. Añadí un tracker de latencia con media móvil y una política de admisión que cede cuando la latencia sube. El issue térmico se volvió no-issue porque el sistema aceptaba elegantemente menor throughput en vez de colapsar.

Reflection. La reflection (documentada en el reporte de la Fase 33): modos de fallo de producción sobre los que solo había leído — thermal throttling, térmico de GPU en entornos cloud, deadlocks NCCL — se volvieron reales porque realmente ejecuté carga contra mi propio hardware. La disciplina de lab de "testea en el hardware más pequeño que tengas" sacó a la superficie un bug que de otra forma habría enviado.

→ Cita: phase-33-inference-serving/PHASE_33_REPORT.md (esperado).

Anécdota 10 — "¿Por qué Anthropic / OpenAI / etc.?"¶

Gancho. (Personaliza por empresa; esta es la versión de Anthropic.) "Porque la aproximación constitucional al alineamiento es la que construiría desde primeros principios, y vuestra investigación publicada es la que realmente puedo re-derivar — lo que el módulo X3 de mi proyecto demuestra."

Situation. Evalué aproximaciones de investigación de alineamiento mientras construía el módulo X3 RLHF/DPO. Leí el paper de InstructGPT, el paper de DPO, el paper de Constitutional AI, y las ablations relevantes.

Task. Decidir qué encuentro más intelectualmente honesto. (Esto no es "qué está más de moda" — es "en qué querría trabajar".)

Action. Implementé las tres (DPO, RLHF regularizado con KL, un pequeño loop de revisión CAI) en el tutor de gramática. La propiedad distintiva de CAI es que la constitución es texto auditable — cualquiera puede leerla y discrepar. Esa propiedad hace el alineamiento depurable de una forma que los reward models opacos no lo son. Encuentro esto convincente porque coincide con mi propio sesgo: cuando discrepo con el comportamiento de un modelo, quiero leer un documento, no interpretar una matriz de pesos.

Result. (Para contexto de entrevista.) Estoy aplicando a Anthropic específicamente porque alignment-by-debuggable-document es la aproximación a la que apuesto. Otros labs tienen trabajo de alineamiento que admiro, pero CAI es la metodología que encuentro más intelectualmente honesta.

Reflection. Esta no es una visión terminada. Esperaría actualizar en contacto con el trabajo día-a-día real de Anthropic. Pero es una opinión derivada de implementar, no de leer notas de prensa — que es el único tipo de opinión que vale la pena traer a la entrevista.

→ Cita: extension-track/X3-rlhf-dpo/theory/05-constitutional-ai-and-rlaif.md.

Protocolo de drill¶

Grábate contando cada anécdota en asciinema (audio + transcript).
Cronometra cada historia. Corta cualquier cosa pasada los 90 segundos.
Pide a un amigo que te pregunte la pregunta "twist" tras cada una — comunes:
"¿Qué diría el otro equipo / visión opuesta?"
"¿Cuál fue la cosa más tonta que intentaste primero?"
"¿Qué pensó tu manager?"
"¿Cómo lo harías diferente con recursos infinitos?"
Itera hasta que cada historia tenga un "elevator" de 30 segundos, un "full" de 90 segundos, y un "deep dive" de 3 minutos con al menos un número en cada versión.

→ Siguiente: 06-company-specific-prep.md