Il termine "harness" designa tutto ciò che circonda un modello IA all'interno di un agente. Birgitta Böckeler propone un framework concettuale specifico per gli utenti di agenti di coding, distinguendo l'harness interno (costruito dal creatore dell'agente) dall'harness esterno (che gli utenti costruiscono per il proprio contesto).
Il modello è organizzato attorno a due meccanismi complementari. Le guide (controlli feedforward) anticipano il comportamento dell'agente e lo orientano prima che agisca: convenzioni di codifica, specifiche, skill, server MCP. I sensori (controlli feedback) osservano dopo l'azione e permettono all'agente di autocorreggersi: linter, test, analisi statica, revisioni del codice basate su IA. Ogni meccanismo può essere computazionale (deterministico, veloce, affidabile) o inferenziale (semantico, più costoso, non deterministico). Entrambi sono necessari: senza feedback, l'agente ripete i propri errori; senza feedforward, codifica regole senza sapere se funzionano.
L'articolo applica il principio dello shift left: distribuire i controlli il più presto possibile nel ciclo di sviluppo. I controlli rapidi (linter, test unitari) vengono eseguiti prima del commit, mentre quelli più costosi (mutation testing, revisione architetturale) vengono eseguiti nella pipeline di integrazione. I sensori continui monitorano la deriva del codice e le metriche di produzione.
Vengono identificate tre categorie di regolazione. L'harness di manutenibilità è il più maturo, basandosi sugli strumenti esistenti (linter, analizzatori di complessità, copertura dei test). L'harness di fitness architetturale riutilizza il concetto di fitness function per le caratteristiche non funzionali. L'harness di comportamento rimane la sfida principale: come verificare che l'applicazione faccia ciò che dovrebbe fare? Le suite di test generate dall'IA non sono ancora sufficientemente affidabili.
Il concetto di harnessability sottolinea che non tutte le codebase si prestano allo stesso modo all'harnessing. Linguaggi tipizzati, framework astratti e architetture modulari offrono maggiore presa. La legge cibernetica di Ashby giustifica i template di harness: riducendo la varietà delle topologie possibili (dashboard, CRUD, processore di eventi), un harness completo diventa più raggiungibile.
L'autrice conclude che l'esperienza umana rimane un "harness implicito" insostituibile. L'obiettivo non è eliminare l'essere umano ma indirizzarne l'attenzione verso ciò che conta di più. L'harness engineering è una pratica ingegneristica continua, non una configurazione una tantum, e molte domande restano aperte riguardo alla coerenza, alla valutazione e all'orchestrazione degli harness.