Domande di colloquio sull'harness engineering: 22 domande con risposte per l'ingegnere AI

Come prepararsi

I colloqui sull'harness engineering di solito procedono dal generale al particolare: che cos'è l'harness, di quali componenti si compone, come si diagnostica un problema, come si misura l'effetto. L'intervistatore cerca un pensiero ingegneristico: la capacità di distinguere un problema del modello da un problema dell'ambiente e di proporre una soluzione verificabile. Qui sotto trovi 22 domande con risposte, raggruppate per argomento.

Fondamenti

1. Che cos'è l'harness di un agente?

L'harness è l'intero ambiente in cui lavora l'agente AI, escluso il modello: istruzioni, strumenti, ambiente di esecuzione, memorizzazione dello stato e cicli di feedback. Il modello prende le decisioni, l'harness determina che cosa sa, che cosa può fare e come viene a sapere il risultato delle proprie azioni. Lo stesso modello, in harness diversi, mostra qualità molto diverse.

2. In cosa l'harness engineering si distingue dal prompt e dal context engineering?

Il prompt engineering lavora sulla formulazione di una richiesta, il context engineering su ciò che entra nella finestra del modello a ogni passo. L'harness engineering comprende entrambi e aggiunge ciò che non si risolve con il testo: accesso agli strumenti, ambiente riproducibile, stato tra le sessioni e verifica del risultato da parte di una macchina.

3. Elenca i cinque componenti dell'harness.

Istruzioni (AGENTS.md, CLAUDE.md, skills, documentazione), strumenti (shell, test, linter, browser, MCP), ambiente (dipendenze, runtime, Docker, worktree), stato (PROGRESS.md, elenco delle funzionalità, decisioni) e feedback (make check, E2E, hook, valutatore). La mancanza di un componente non produce un risultato "un po' peggiore", ma una classe sistematica di errori.

4. Perché sostituire il modello con uno più potente spesso non aiuta?

Perché molti guasti non dipendono dall'intelligenza del modello. Un modello più forte non può accedere a un comando che non gli è stato dato, non ricorda la sessione di ieri senza un file di stato e non si accorge di una migrazione rotta se nessuno l'ha eseguita. Le convenzioni di un team specifico, poi, il modello non le può indovinare.

Diagnosi

5. L'agente viola una regola scritta in CLAUDE.md. Cosa fai?

Prima verifico se l'agente vede la regola: un file lungo con decine di punti sfoca ciò che è importante. Riduco il file d'ingresso a un indice e sposto i dettagli in documenti caricati in base a una condizione. Se la regola è critica, la trasformo in una verifica eseguibile: linter, test, grep-guard o hook. Così la violazione diventa visibile alla macchina e non dipende dall'attenzione del modello.

6. Dai sintomi, come capisci quale componente è rotto?

Se si violano convenzioni note, le istruzioni. Se l'agente "vuole ma non può", gli strumenti. Se ogni sessione inizia riparando l'ambiente, l'ambiente. Se la nuova sessione non sa dove si era fermata, lo stato. Se "fatto" e realtà non coincidono, il feedback.

7. Da quale componente inizi a costruire l'harness, e perché?

Dal feedback. Senza un comando che dica alla macchina "funziona o non funziona", non puoi misurare l'effetto di nessun altro cambiamento. Di solito seguono istruzioni, stato, ambiente e strumenti, ma l'ordine è empirico e dipende dal componente che si è rotto di più.

8. Come misuri il contributo di un singolo componente dell'harness?

Con l'ablation: fisso modello e insieme di compiti, disattivo un componente alla volta e osservo il calo. Prima però conviene un registro dei fallimenti con i livelli annotati, che indica il collo di bottiglia più in fretta. Un calo nullo non significa che il componente sia inutile: forse i compiti scelti non lo toccano, o compensa il difetto di un altro componente.

Istruzioni e contesto

9. Come si struttura un buon AGENTS.md?

Come un router, non come un manuale: che cos'è il progetto, come si avvia, come si verifica, la Definition of Done e un breve elenco di vincoli obbligatori. I dettagli stanno in documenti separati, con link condizionali del tipo "leggere se il compito riguarda i pagamenti". Il file descrive invarianti ("i dati vengono validati ai confini"), senza dettare riga per riga implementazione o librerie.

10. A cosa servono i subagent?

All'isolamento del contesto. Un compito collaterale, come una ricerca nel codice, una revisione o una verifica, si svolge nel proprio contesto e restituisce solo il risultato. Il flusso principale non si sporca, e un subagent di verifica non eredita il ragionamento dell'esecutore, il che è importante per una valutazione onesta.

11. Che cos'è il "debito dell'harness"?

Lo scarto accumulato tra harness e realtà: regole superate, comandi che non funzionano più, documenti su moduli che non esistono più. Si accumula in silenzio, come il debito tecnico, e si paga con i guasti dell'agente. L'harness va revisionato regolarmente, non configurato una volta sola.

Stato e sessioni

12. Come si affronta l'amnesia dell'agente tra una sessione e l'altra?

Conservando lo stato nel repository: PROGRESS.md (stato, lavoro svolto, blocchi, prossimi passi), DECISIONS.md (decisione, motivazione, alternative scartate), un elenco di funzionalità con stati e commit frequenti. Nelle istruzioni si fissa la sequenza di avvio: leggere l'avanzamento, eseguire lo script di controllo dell'ambiente, prendere la funzionalità attiva.

13. A cosa serve la regola WIP=1?

Quando l'agente avvia più funzionalità insieme, lo stato si disperde: nessuna viene completata, le modifiche si mescolano, il rollback diventa difficile. Una sola funzionalità attiva dà un punto di verifica chiaro, commit puliti e un ripristino semplice dopo un guasto.

14. Che cos'è il "test di avvio a freddo"?

È verificare se una nuova sessione, senza suggerimenti umani, sa rispondere alle domande di base: di quale progetto si tratta, dove ci si era fermati, quale funzionalità è attiva, come si controlla che tutto sia a posto. Se l'agente risponde basandosi sui file senza tirare a indovinare, il componente di stato funziona.

Verifica

15. Perché i test unitari verdi non dimostrano che la funzionalità funziona?

Lo unit test isola un modulo e sostituisce le dipendenze con mock, quindi non vede i collegamenti: disallineamento delle interfacce, propagazione dello stato (lo schema è cambiato, la cache no), perdite di risorse, problemi di configurazione e di ambiente. I difetti catturati dagli unit test sono un sottoinsieme di quelli catturati dagli integration test, e questi ultimi sono un sottoinsieme di quelli catturati dall'E2E.

16. Che cos'è il verification gap e come si calcola?

È la quota di compiti che l'agente ha dichiarato completati ma che la verifica indipendente non ha confermato. Si prendono 10 compiti consecutivi e per ciascuno si registrano i due fatti. La metrica fornisce una base di partenza: dopo le modifiche all'harness si ricalcola su un insieme di compiti simili.

17. Come si scrive una Definition of Done per l'agente?

In AGENTS.md, come elenco di punti verificabili: i comandi di verifica terminano con codice 0, esiste un E2E per la funzionalità, le migrazioni si applicano, l'avanzamento è aggiornato. È utile dichiarare anche ciò che non conta come completamento: "sembra corretto", "gli unit test passano", "in locale funziona".

18. Perché l'agente non deve mettere da solo il segno di "fatto"?

Il modello tende a sopravvalutare il proprio lavoro, e questa autovalutazione avviene nello stesso contesto in cui è stata presa la decisione. Il segno di passing deve metterlo lo script di verifica, in base ai risultati delle esecuzioni, registrando l'hash del commit come prova.

19. Come si costruisce un valutatore indipendente?

Un agente o una sessione separati, che vedono solo il requisito, il diff e i risultati delle esecuzioni, ma non il ragionamento dell'esecutore. Valutano con una rubrica (correttezza, architettura, test, gestione degli errori) e ogni giudizio cita un file, una riga o un log. Se possibile si usa un altro modello, perché i punti ciechi non coincidano.

20. Come si rende eseguibile una regola architetturale?

Su tre livelli: grep-guard (veloce, basato su pattern), una regola del linter che conosce il grafo degli import (import-linter, dependency-cruiser) e un test architetturale in CI. Tutti e tre entrano nel make check, falliscono con un codice diverso da zero e stampano WHY e FIX, così l'agente corregge da solo la violazione. Il trigger per aggiungere un nuovo controllo è quando lo stesso commento di revisione compare una seconda volta.

Lavoro autonomo

21. Che cosa serve per lasciare l'agente al lavoro per ore?

Un obiettivo univoco, una metrica di avanzamento monotona (per esempio il numero di funzionalità in stato passing), un budget di tempo e di tentativi per funzionalità, rollback automatico in caso di regressione e un elenco di ciò che spetta alle persone: migrazioni, infrastruttura, denaro. Inoltre l'isolamento: una sandbox o un git worktree separato, perché un errore non raggiunga l'ambiente di lavoro.

22. Quando un solo ciclo dell'agente non basta, e come si costruisce un grafo di ruoli?

Quando l'esecutore comincia a controllare se stesso e si blocca. Allora il compito si divide in ruoli: implementazione, revisione, test, merge. La revisione riceve un contesto pulito e una rubrica, e il merge viene eseguito solo quando review == pass. Se la revisione fallisce, la funzionalità torna all'implementazione; dopo diversi insuccessi viene riavviata da un contesto pulito, perché in quel caso il problema è nella comprensione del compito, non nel codice.

Conclusione

Nei colloqui sull'harness engineering risponde meglio chi parla di ciò che si può verificare: quali file, quali comandi, quale metrica. Tieni a mente i cinque componenti, il verification gap e la regola "il segno di completamento lo mette lo script". Tutti questi temi si ricompongono in un unico harness su un progetto reale, e vengono insegnati in pratica in un corso.