Sommario
Intelligenza Artificiale
Architetture AI on-premise, LLM locali, RAG, agenti autonomi. Progettazione di harness e sistemi agentici governati.
Scopri →
Cloud & Web Apps
Sviluppo software moderno: CI/CD, test, osservabilità. L’ambiente attorno all’agente prima ancora del codice.
Scopri →
Admina Enterprise
Governance AI Open Source: audit trail, PII redaction, policy bidirezionali ALLOW/BLOCK/REDACT su ogni chiamata e tool.
Scopri Admina →
Ricerca & Sviluppo
Ricerca applicata su agenti di coding, orchestrazione, valutazione e affidabilità.
Scopri →
Cos’è la harness engineering
C’è una verità che quasi tutti imparano nel modo più duro: il modello più forte del mondo fallisce sui compiti reali se non gli si costruisce attorno un ambiente adeguato. Lo hai probabilmente visto: dai un compito a Claude o a GPT nel tuo repository, parte bene, poi salta un passaggio, rompe un test, dichiara “fatto” quando non funziona nulla, e passi più tempo a rimediare che se l’avessi fatto a mano. Non è un problema del modello. È un problema di harness.
La harness engineering è la disciplina che affronta esattamente questo: costruire l’ambiente completo attorno al modello perché produca risultati affidabili. Non scrivere prompt migliori, ma progettare il sistema in cui il modello opera. In una riga: il modello decide cosa scrivere, l’harness governa quando, dove e come, e l’agente si ferma solo quando la verifica passa. Negli ultimi mesi il termine si è consolidato con contributi di OpenAI, di Anthropic e con un corso open source (licenza MIT) interamente dedicato al tema.
La prova più netta l’ha portata Anthropic con un esperimento controllato: stesso modello (Claude Opus 4.5), stesso prompt (“crea un editor di giochi retro 2D”). Da solo, senza harness, l’agente ha speso circa 9 dollari in 20 minuti e prodotto qualcosa che non funzionava. Con un harness completo (un’architettura a tre agenti: planner, generator, evaluator), ha speso circa 200 dollari in 6 ore e costruito un gioco davvero giocabile, con sedici funzionalità distribuite su dieci sprint. Il modello non è cambiato. L’harness sì.
Le cinque parti di un harness
Un harness ben fatto è composto da cinque sottosistemi, ciascuno con un compito preciso (vedi il diagramma qui sopra):
- Istruzioni: dicono all’agente cosa fare, in che ordine, cosa leggere prima di iniziare. Non un unico file enorme, ma una struttura a disclosure progressiva che l’agente naviga su richiesta.
- Stato: traccia cosa è stato fatto, cosa è in corso, cosa manca. Persistito su disco (un file di progresso, la storia di git) così che la sessione successiva riprenda esattamente dove la precedente si è fermata.
- Verifica: solo una suite di test che passa conta come prova. L’agente non può dichiarare vittoria senza evidenza eseguibile.
- Ambito: vincola l’agente a una funzionalità alla volta. Niente overreach, niente tre cose lasciate a metà, niente riscrivere la lista delle feature per nascondere il lavoro incompleto.
- Ciclo di vita: inizializza all’avvio (
init.sh), pulisce alla fine, lascia un percorso di ripartenza pulito per la sessione successiva.
Il bello è che non serve un framework: per iniziare bastano quattro file nel repository (AGENTS.md, init.sh, feature_list.json, un file di progresso). Poche righe, e le sessioni dell’agente sono già molto più stabili che a colpi di prompt.
Il caso OpenAI: un prodotto senza una riga scritta a mano
L’esperimento più radicale lo racconta OpenAI. Per cinque mesi un piccolo team ha costruito e messo in produzione un prodotto software interno con zero righe di codice scritte a mano: ogni riga (logica applicativa, test, configurazione CI, documentazione, osservabilità, tooling) è stata scritta da Codex. Risultato: circa un milione di righe di codice, 1.500 pull request con tre ingegneri (poi sette), una media di 3,5 PR per ingegnere al giorno, e un prodotto usato da centinaia di utenti interni. Stimano di averlo costruito in circa un decimo del tempo che sarebbe servito a mano.
Il punto interessante non è la quantità, ma il cambio di mestiere. Quando qualcosa falliva, la soluzione non era mai “insisti col prompt”, ma: quale capacità manca all’agente, e come la rendo leggibile e verificabile per lui? Il lavoro dell’ingegnere si sposta dallo scrivere codice al progettare ambienti, specificare l’intento e costruire feedback loop. Alcune lezioni concrete:
- Il contesto è una mappa, non un manuale da mille pagine. Il singolo, gigantesco
AGENTS.mdfallisce: soffoca il compito, invecchia in fretta, diventa un cimitero di regole stantie. Meglio unAGENTS.mdbreve (un centinaio di righe) come indice, che punta a una cartelladocs/trattata come sistema di record, con progressive disclosure. E linter, CI e un “agente giardiniere” che apre PR per rimuovere la documentazione obsoleta. - Ciò che l’agente non vede in contesto, per lui non esiste. La conoscenza che vive in Google Docs, nei thread di chat o nelle teste delle persone è invisibile all’agente esattamente come lo sarebbe per un nuovo assunto. Va spinta nel repository, versionata e leggibile.
- Rendere il mondo ispezionabile dall’agente. Hanno reso l’app avviabile per singolo git worktree, cablato il Chrome DevTools Protocol nel runtime (screenshot, navigazione del DOM), esposto log e metriche interrogabili (LogQL, PromQL). Così prompt come “lo startup del servizio deve stare sotto gli 800 ms” diventano trattabili, e la review passa da umana ad agente-su-agente. Singole run arrivano a lavorare sei ore di fila.
- Imporre invarianti, non implementazioni. Un’architettura rigida a layer (con direzioni di dipendenza validate meccanicamente da linter custom, generati da Codex stesso) è ciò che permette velocità senza deriva. È il tipo di disciplina che di solito rimandi a quando hai centinaia di ingegneri: con gli agenti diventa un prerequisito iniziale.
L’harness cambia con il modello
Un’ultima lezione, la più sottile, arriva ancora da Anthropic. Ogni componente di un harness codifica un’assunzione su ciò che il modello non sa fare da solo, e quelle assunzioni invecchiano man mano che i modelli migliorano. Con Sonnet 4.5 servivano i reset di contesto per gestire la “context anxiety”; Opus 4.5 li ha resi superflui; con Opus 4.6 l’harness si è semplificato ancora (via gli sprint, l’evaluator ridotto a un solo passaggio finale). L’evaluator non è un interruttore fisso: il suo valore dipende da dove sta il compito rispetto a ciò che il modello fa già bene da solo.
La morale operativa: a ogni nuovo modello, riesamina l’harness, togli i pezzi che non reggono più il peso e aggiungi quelli che ora sono possibili. E, in generale, “trova la soluzione più semplice possibile, aumenta la complessità solo quando serve”. La verifica, però, resta il cuore: l’evaluator di Anthropic naviga l’app con Playwright come farebbe un utente, e prima di ogni sprint concorda con il generator un “contratto” su cosa significhi done. Solo un test che passa vale come “fatto”.
Cosa ne pensiamo
Se avete letto la nostra serie sull’agentic loop, questo suona familiare: è la stessa tesi, resa disciplina. Il modello decide, ma affidabilità, sicurezza e governance vivono nel codice attorno, cioè nell’harness. La harness engineering ne è la formalizzazione, e ribalta il ruolo dell’ingegnere: meno atto di scrivere codice, più progettazione di ambienti, invarianti e feedback loop.
Quattro punti ci parlano direttamente, dal nostro lavoro su AI, cybersecurity e software:
- Verifica prima di “fatto”. Solo prove eseguibili (test, end-to-end) contano. È il cuore del software affidabile, con o senza AI, ed è la stessa logica dell’osservabilità di cui abbiamo scritto per gli agenti in contesto, pattern e multi-agente.
- Il contesto come sistema di record versionato. Ciò che non è ispezionabile, per l’agente non esiste. Lo stesso vale per governance e audit: quello che conta va reso leggibile e verificabile a runtime, il senso di Admina e, sul versante interpretabilità, di strumenti come il J-lens di Anthropic.
- Invarianti applicati meccanicamente. Linter, CI, policy: la qualità e la sicurezza non si chiedono al modello, si impongono nell’ambiente. È il principio “la sicurezza vive nell’harness, non nel prompt”.
- Sovranità. Un harness è codice tuo: versionato, ispezionabile, tuo. È la parte dello stack che puoi possedere anche quando il modello è di terzi, e si sposa con l’idea di possedere il pavimento operativo con modelli a pesi aperti on-premise (GLM 5.2, DwarfStar 4) e con il paradigma Open Intelligence, Secure Governance.
Una nota di realismo: è ancora artigianato costoso (nell’esperimento retro-game l’harness costava oltre venti volte tanto), il confine di ciò che vale la pena mettere nell’ambiente si sposta a ogni release, e “tecnologia noiosa” più architetture rigide non sono gratis. Ma la direzione è netta: il valore ingegneristico si sposta dallo scrivere codice al progettare l’ambiente in cui l’AI lo scrive, in modo affidabile e verificabile. Chi costruisce software con l’AI, prima o poi, costruisce harness.