Preguntas de entrevista sobre harness engineering: 22 preguntas con respuestas para un ingeniero de IA

Cómo prepararse

Las preguntas de entrevista sobre harness engineering suelen ir de lo general a lo particular: qué es un harness, de qué se compone, cómo diagnostica un problema, cómo mide el efecto de un cambio. El entrevistador busca pensamiento de ingeniería: la capacidad de distinguir un problema del modelo de un problema del entorno y de proponer una solución verificable. A continuación encontrará 22 preguntas con respuestas, agrupadas por temas.

Fundamentos

1. ¿Qué es el harness de un agente?

El harness es todo el entorno en el que trabaja un agente de IA, salvo el propio modelo: instrucciones, herramientas, entorno de ejecución, almacenamiento del estado y bucles de retroalimentación. El modelo toma las decisiones, mientras que el harness determina qué sabe, qué puede hacer y cómo se entera del resultado. El mismo modelo muestra una calidad muy distinta según el harness en el que trabaje.

2. ¿En qué se diferencia el harness engineering del prompt engineering y del context engineering?

El prompt engineering trabaja con la formulación de una petición, y el context engineering con lo que entra en la ventana del modelo en cada paso. El harness engineering incluye ambos y añade lo que no se resuelve con texto: acceso a herramientas, un entorno reproducible, estado entre sesiones y comprobación automática del resultado.

3. Enumere los cinco subsistemas del harness.

Instrucciones (AGENTS.md, CLAUDE.md, skills, documentación), herramientas (shell, pruebas, linter, navegador, MCP), entorno (dependencias, runtime, Docker, worktree), estado (PROGRESS.md, lista de funcionalidades, decisiones) y retroalimentación (make check, E2E, hooks, evaluador). La ausencia de cualquiera de ellos no produce resultados «algo peores», sino una clase sistemática de fallos.

4. ¿Por qué cambiar el modelo por uno más potente a menudo no basta?

Porque muchos fallos no tienen que ver con la inteligencia del modelo. Un modelo más potente no obtendrá acceso a un comando que no se le dio, no recordará la sesión de ayer sin un archivo de estado y no se enterará de que una migración está rota si nadie la ejecutó. Tampoco adivinará las convenciones concretas de un equipo.

Diagnóstico

5. El agente incumple una regla escrita en CLAUDE.md. ¿Qué hace?

Primero comprobar si el agente encuentra la regla: un archivo largo con decenas de puntos diluye la importante. Reduzca el archivo de entrada a un índice y saque los detalles a documentos que se carguen bajo condición. Si la regla es crítica, conviértala en una comprobación ejecutable —linter, prueba, guardia grep o hook—, para que la infracción sea visible por máquina y no dependa de la atención del modelo.

6. ¿Cómo sabe, a partir de un síntoma, qué subsistema está roto?

Incumplir convenciones conocidas apunta a las instrucciones. Que el agente «quiera pero no pueda» apunta a las herramientas. Que cada sesión empiece reparando el entorno apunta al entorno. Que una sesión nueva no sepa por dónde iba apunta al estado. Un «listo» que no coincide con la realidad apunta a la retroalimentación.

7. ¿Con qué subsistema empieza a construir el harness y por qué?

Con la retroalimentación. Mientras no exista un comando que responda por máquina «funciona o no», no se puede medir el efecto de ningún otro cambio. Después suelen venir las instrucciones, el estado, el entorno y las herramientas, pero el orden es empírico y depende de lo que esté más roto.

8. ¿Cómo mide la contribución de un componente concreto del harness?

Mediante ablación: se fija el modelo y el conjunto de tareas, se desactiva un subsistema cada vez y se observa la caída. Pero es mejor empezar por un registro de fallos etiquetado por capas: señala el cuello de botella más deprisa. Una caída nula no significa que el componente sea inútil: puede que estas tareas no lo necesiten o que sea redundante.

Instrucciones y contexto

9. ¿Cómo se organiza un buen AGENTS.md?

Como un enrutador, no como un manual: qué es el proyecto, cómo se levanta, cómo se verifica, la definición de Done y una lista corta de restricciones obligatorias. Los detalles van en documentos aparte, con enlaces del tipo «leer si la tarea afecta a los pagos». El archivo enuncia invariantes («los datos se validan en el límite») en lugar de dictar la implementación y las bibliotecas línea por línea.

10. ¿Para qué sirven los subagentes?

Para aislar el contexto. Una subtarea —buscar en la base de código, revisar, comprobar— se ejecuta en un contexto propio y devuelve solo su resultado. La sesión principal no se ensucia, y un subagente verificador no hereda el razonamiento del ejecutor, lo que es importante para una evaluación honesta.

11. ¿Qué es la deuda del harness?

La divergencia acumulada del harness respecto de la realidad: reglas obsoletas, comandos que ya no funcionan, documentos sobre módulos que ya no existen. Se comporta como la deuda técnica: crece sin que se note y se paga con fallos del agente. El harness debe revisarse con regularidad, no configurarse una sola vez.

Estado y sesiones

12. ¿Cómo se combate la amnesia del agente entre sesiones?

Guardando el estado en el repositorio: PROGRESS.md (situación, lo hecho, bloqueos, siguientes pasos), DECISIONS.md (decisión, motivo, opciones descartadas), una lista de funcionalidades con su estado y commits frecuentes. En las instrucciones se fija el orden de arranque: leer el progreso, ejecutar el script de comprobación del entorno y tomar la funcionalidad activa.

13. ¿Para qué sirve la regla WIP=1?

Cuando el agente empieza varias funcionalidades a la vez, el estado se dispersa: ninguna está terminada, los cambios se mezclan y la reversión se complica. Una sola funcionalidad activa ofrece un punto de control claro, commits limpios y una recuperación sencilla tras una caída.

14. ¿Qué es una prueba de arranque en frío?

Es comprobar si una sesión nueva, sin indicaciones humanas, puede responder a preguntas básicas: qué proyecto es, dónde se quedó el trabajo, qué funcionalidad está activa, cómo se comprueba que todo está bien. Si el agente responde a partir de los archivos sin adivinar, el subsistema de estado funciona.

Verificación

15. ¿Por qué las pruebas unitarias en verde no demuestran que la funcionalidad funcione?

La prueba unitaria aísla un módulo y simula sus dependencias, así que no ve las uniones: interfaces incompatibles, propagación del estado (el esquema cambió, la caché está desfasada), fugas de recursos, problemas de configuración y de entorno. Los defectos que detectan las pruebas unitarias son un subconjunto de los que detectan las de integración, y estas, un subconjunto de lo que revela el E2E.

16. ¿Qué es la brecha de verificación y cómo se calcula?

Es la proporción de tareas que el agente declaró terminadas y que una verificación independiente no confirmó. Se toman 10 tareas seguidas y se anotan ambos hechos en cada una. La métrica da una línea base: tras los cambios en el harness, se recalcula sobre un conjunto parecido de tareas.

17. ¿Cómo se escribe una definición de Done para un agente?

En AGENTS.md, como lista de puntos verificables: los comandos de comprobación terminaron con código 0, existe una prueba E2E para el escenario, las migraciones se aplican, el progreso está actualizado. Conviene dejar explícito qué no cuenta como terminado: «tiene buena pinta», «las pruebas unitarias pasan», «en mi máquina funciona».

18. ¿Por qué el agente no debe asignarse por sí mismo el estado «listo»?

Los modelos tienden a sobrevalorar su propio trabajo, y la autoevaluación ocurre en el mismo contexto en el que se tomó la decisión. El estado passing debe asignarlo un script de verificación según los resultados de las ejecuciones, registrando el hash del commit como prueba.

19. ¿Cómo se monta un evaluador independiente?

Como un agente o una sesión aparte que solo ve el requisito, el diff y los resultados de las ejecuciones, pero no el razonamiento del ejecutor. Evalúa según una lista de criterios (corrección, arquitectura, pruebas, gestión de errores) y cada valoración remite a un archivo, una línea o un registro. Lo ideal es usar otro modelo, para que no coincidan los puntos ciegos.

20. ¿Cómo se convierte una regla de arquitectura en algo ejecutable?

En tres niveles: guardia grep (rápida, basada en patrones), regla de linter que entiende el grafo de importaciones (import-linter, dependency-cruiser) y prueba de arquitectura en CI. Todos se integran en make check, fallan con un código de salida distinto de cero e imprimen POR QUÉ y CORRECCIÓN, para que el agente corrija la infracción por sí mismo. El disparador de una comprobación nueva es el segundo comentario idéntico en una revisión.

Trabajo autónomo

21. ¿Qué se necesita para dejar trabajar a un agente durante horas?

Un objetivo inequívoco, una métrica de progreso monótona (por ejemplo, el número de funcionalidades en passing), un presupuesto por funcionalidad en tiempo y en intentos, una reversión automática ante regresiones y una lista de acciones que requieren a una persona: migraciones, infraestructura, dinero. Y además aislamiento: un entorno aislado o un git worktree propio, para que un error no afecte al entorno de trabajo.

22. ¿Cuándo no basta un solo ciclo de agente y cómo se diseña un grafo de roles?

Cuando el ejecutor empieza a comprobarse a sí mismo y se atasca. Entonces la tarea se divide en roles: implementación, revisión, pruebas, fusión. La revisión recibe un contexto limpio y una lista de criterios, y la fusión la ejecuta el código cuando review == pass. Si la revisión falla, la funcionalidad vuelve a la implementación; tras varios fallos se relanza con un contexto limpio, lo que indica que el problema está en la comprensión de la tarea y no en el código.

Resumen

En las entrevistas sobre harness engineering convence más quien habla de lo verificable: qué archivos, qué comandos, qué métrica. Tenga presentes los cinco subsistemas, la brecha de verificación y la regla «el estado lo asigna un script». Todos estos temas se unen en un harness único sobre un proyecto de extremo a extremo en el curso de harness engineering.