Lección 01 · AI Staff Engineer @ Fever
Análisis de error
La maniobra que convierte «he construido un harness» en «sé exactamente en qué falla mi harness, y en qué porcentaje». Esa frase es la diferencia entre Senior y Staff.
Tu developer-skills ya hace model routing por complejidad, aislamiento en worktrees y review gating. Tu cc-remote ya son ephemeral environments on demand. La oferta de Fever pide ambas cosas casi con esas palabras. No tienes un problema de capacidad: tienes un problema de instrumentación. Cuando un entrevistador te pregunte «¿y funciona?», hoy solo puedes responder «sí, me ha abierto PRs». Al final de esta lección podrás responder con una tabla.
«Los equipos que fracasan con IA casi siempre comparten una causa raíz: no construyeron un sistema de evaluación robusto. Igual que en ingeniería de software, el éxito depende de la velocidad a la que puedes iterar.»
Hamel Husain, Your AI Product Needs EvalsEl conocimiento (5 minutos)
El error que comete casi todo el mundo al «poner evals» es empezar por arriba: elegir un LLM-as-judge, escribir un rubric con cinco criterios bonitos (utilidad, corrección, tono…) y sacar una puntuación media de 4,2 sobre 5. Esa cifra no sirve para nada. No te dice qué arreglar el lunes.
El análisis de error va al revés: de abajo arriba, desde trazas reales. Es un préstamo directo de la investigación cualitativa, y tiene tres movimientos.
| Movimiento | Qué haces | Qué produce |
|---|---|---|
| Open coding | Lees trazas reales una a una y escribes, en lenguaje natural y sin categorías previas, qué ha ido mal. Una frase por traza. Sin miedo a repetirte ni a ser específico. | Notas crudas. Desordenadas a propósito. |
| Axial coding | Agrupas esas notas en un puñado de modos de fallo (idealmente 5–8). Las categorías emergen de los datos; no las traes de fuera. | Una taxonomía. Tuya, de tu sistema. |
| Conteo | Cuentas cuántas trazas caen en cada modo. Ordenas por frecuencia. | Una lista priorizada. Esto es lo que arreglas. |
Sólo después de esto escribes evals — y los escribes contra los modos de fallo que realmente ocurren, no contra los que imaginabas. Un eval sin análisis de error previo es un test para un bug que nunca has visto. (Metodología: Husain & Shankar)
La cifra que buscas no es «mi harness acierta el 73%». Es «el 41% de mis fallos son de una sola causa, y esa causa la puedo arreglar». La primera cifra es vanidad; la segunda es un plan de trabajo. En una entrevista de Staff, la segunda te contrata.
La habilidad (10 minutos)
Vamos a practicar el axial coding, que es el movimiento difícil. Abajo hay cinco trazas de un pipeline issue→PR como el tuyo. Asigna cada una a un modo de fallo.
Aviso importante, y no es retórico: esta taxonomía te la doy yo, y por tanto está mal. Las taxonomías buenas no se heredan, se derivan de tus propias trazas. Lo que practicas aquí es el gesto de separar el síntoma de la causa — no estas cuatro etiquetas.
Si has fallado alguna, mira por qué: casi siempre es porque el síntoma más visible (un test que pasa, una tool que responde) apunta a una categoría y la causa real vive en otra capa. Eso es exactamente lo que hace difícil el axial coding, y por eso no se puede automatizar del todo.
Retención
El trabajo real
Lo anterior era el ensayo. Esto es la función. Haz análisis de error sobre developer-skills, con tus trazas.
Paso 1 · Consigue las trazas
Necesitas entre 20 y 30 ejecuciones reales. Si no las tienes guardadas, esta es la primera lección de verdad: un harness que no persiste sus trazas no se puede evaluar, y eso ya es un hallazgo que contar en la entrevista. Genera un lote lanzando tu pipeline contra issues reales de un repo de prueba con variedad deliberada: tareas triviales, tareas ambiguas, tareas que tocan varios ficheros, tareas imposibles.
Paso 2 · Open coding, a mano
Una hoja de cálculo. Una fila por ejecución. Columnas: issue, ¿PR abierto?, ¿mergeable?, ¿hizo lo que pedía?, y una columna libre: «qué ha ido mal, en una frase». Resiste la tentación de categorizar mientras lees. A mano, sin agente. Sí, es tedioso; el tedio es el ejercicio — Hamel es tajante en esto, y tiene razón: el que lee las trazas es el que entiende el sistema.
Paso 3 · Axial coding
Ahora sí, agrupa. Busca 5–8 modos de fallo que emerjan de tus notas. Nombra cada uno con una frase que apunte a la causa y no al síntoma. Cuenta. Ordena por frecuencia.
Paso 4 · La frase
Escribe una sola frase con esta forma, rellenada con tus números:
«Analicé N ejecuciones de mi pipeline autónomo issue→PR.
El X% terminó en un PR mergeable. El modo de fallo dominante
fue <causa>, con el Y% de los fallos — lo mitigué con <cambio>,
y la tasa subió al Z%.»Esa frase es tu candidatura. Vale más que los dos repos juntos, porque los repos demuestran que sabes construir y la frase demuestra que sabes medir. Fever contrata lo segundo: la oferta dice literalmente «establish measurement frameworks with baselines» y «evaluation and verification mechanisms».
Tráemelo. Revisamos juntos tu taxonomía — criticarla es la mitad del valor — y en la Lección 2 convertimos los dos modos de fallo más frecuentes en evals automatizados que corran en tu CI. Ahí es donde el bucle se cierra y donde aparece la primera cifra que puedes defender.