Harness Engineering: Costruire sistemi intorno agli agenti AI (2026)

TL;DR

Cos'è l'Harness Engineering?

L'harness engineering è la disciplina che consiste nel costruire sistemi, strumenti, vincoli e cicli di feedback attorno agli agenti di codifica AI per renderli affidabili e produttivi.

Il termine è stato coniato da Mitchell Hashimoto (co-fondatore di HashiCorp) e ha attirato l'attenzione generale quando OpenAI ha pubblicato il suo articolo su Codex all'inizio del 2026.

L'idea di base è semplice:

Agente = Modello + Harness

Il modello fornisce l'intelligenza. L'harness rende quell'intelligenza utile. Un harness migliore spesso conta più di un modello migliore.

Perché è importante oggi

Nel 2025, ogni team ha adottato agenti di codifica AI. Nel 2026, i team vincenti sono quelli che hanno progettato i propri ambienti per gli agenti (engineered their agent environments), non quelli che hanno semplicemente scelto il modello migliore.

Il principio guida di Mitchell Hashimoto:

"Ogni volta che scopri che un agente commette un errore, dedica del tempo a progettare una soluzione tecnica affinché l'agente non commetta mai più quell'errore."

Non si tratta di prompt engineering. È systems engineering per l'AI.

L'evidenza: Harness > Modello

LangChain ha condotto un esperimento controllato su Terminal Bench 2.0. Senza cambiare il modello sottostante, hanno migliorato l'accuratezza del loro agente di codifica dal 52,8% al 66,5% — un miglioramento del 26% — agendo solo sul miglioramento dell'harness.

Le modifiche includevano:

• Migliori file di contesto (AGENTS.md)


• Vincoli sull'output strutturato


• Cicli di auto-verifica


• Ottimizzazione degli strumenti (tool optimization)

I 7 componenti di un Harness

1. Context Engineering

Il context engineering è la fondazione. È qui che fornisci all'agente una mappa della tua codebase, delle tue convenzioni e dei tuoi vincoli.

• File CLAUDE.md / AGENTS.md nella root della tua repo
• Mappe delle directory e panoramiche dell'architettura
• Regole sullo stile di codifica e convenzioni di denominazione

# CLAUDE.md example
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. Vincoli Architetturali

Invece di sperare che l'agente scelga l'architettura corretta, imponila.

• Architetture a strati rigide validate da linter
• Test strutturali che falliscono se i pattern vengono violati
• Restrizioni sugli import tramite regole ESLint o script personalizzati

3. Strumenti e Server MCP

Gli agenti hanno bisogno di strumenti per essere efficaci. I migliori harness espongono il tooling interno tramite:

• Wrapper CLI — preferisci CLI note (git, docker, npm) rispetto a strumenti personalizzati
• Server MCP (Model Context Protocol) — permetti agli agenti di chiamare le tue API interne, database e servizi
• Accesso al file system — limitato a directory specifiche per prevenire danni accidentali

4. Sotto-agenti e Firewall di Contesto

Le sessioni degli agenti a lunga durata accumulano contesto che alla fine degrada le prestazioni — questo fenomeno è chiamato context rot.

La soluzione: sotto-agenti con firewall di contesto.

• Suddividi compiti complessi in sotto-task distinti
• Ogni sotto-task gira nella propria sessione con un contesto pulito
• Passa solo risultati strutturati tra gli agenti, non l'intera conversazione

1. Agente Inizializzatore — pianifica il lavoro, crea una lista di feature
2. Agente di Codifica — esegue ogni feature in isolamento

5. Hook e Back-Pressure

Cicli di feedback automatizzati che intercettano gli errori prima che si accumulino:

• Pre-commit hooks — controllo dei tipi, linting, formattazione
• Test runners — gli agenti dovrebbero eseguire i test dopo ogni modifica
• Verifica della build — fallimento rapido (fail fast) in caso di build interrotte

6. Cicli di Auto-Verifica

Costringi gli agenti a verificare il proprio lavoro prima di contrassegnare i task come completati:

• Eseguire la suite di test dopo le modifiche
• Verificare che la build passi
• Verificare che l'output corrisponda alle specifiche
• Fare uno screenshot e confrontarlo (per lavori sulla UI)

7. Documentazione del Progresso

Per task a lunga durata (oltre 30 minuti):

• Mantieni un file di progresso che traccia i passaggi completati
• Esegui commit frequenti così le sessioni successive possono continuare
• Usa liste di task strutturate, non note libere

Risultati nel mondo reale

Team OpenAI Codex

3 ingegneri hanno prodotto una codebase da un milione di righe con zero codice scritto manualmente in 5 mesi. Hanno mantenuto una media di 3,5 PR mergiate per ingegnere al giorno — un rendimento impossibile senza un harness maturo.

Il loro harness includeva: convenzioni di commit rigorose, test automatizzati su ogni PR e pipeline di CI/CD progettate per gli agenti.

I "Minions" di Stripe

Il sistema interno di Stripe produce oltre 1.000 PR mergiate a settimana utilizzando agenti AI. Il loro harness include:

• Definizioni di task con perimetro ristretto
• Code review obbligatoria da parte di umani
• Test di regressione automatizzati
• Automazione del rollback

Architettura a due agenti di Anthropic

Anthropic ha pubblicato il proprio approccio per harness efficaci per agenti a lunga durata:

• Liste di feature strutturate come formato di handoff tra gli agenti
• Tracciamento del progresso basato su Git così gli agenti possono riprendere dopo un'interruzione
• Criteri di uscita espliciti così gli agenti sanno quando fermarsi

Come iniziare a costruire il tuo Harness

Step 1: Crea il tuo file di contesto

Aggiungi un CLAUDE.md (o AGENTS.md) nella root del tuo progetto:

# Project: [Your Project]

## Stack
[Framework, language, database, hosting]

## Architecture
[Directory structure with one-line descriptions]

## Rules
[5-10 hard rules the agent must follow]

## Common Tasks
[How to run tests, build, deploy]

Step 2: Aggiungi vincoli strutturali

# Esempio: regola ESLint che impedisce import diretti del DB nei componenti
# .eslintrc — regola no-restricted-imports

Imposta pre-commit hook che applichino le tue regole automaticamente.

Step 3: Costruisci cicli di verifica della build

Assicurati che il tuo agente possa:

1. Eseguire test (npm test, pytest, etc.)


2. Controllare i tipi (tsc --noEmit, mypy)


3. Eseguire il linting (eslint ., ruff check)

Step 4: Delimita le sessioni dell'agente

Non dare a un agente l'intero backlog. Invece:

• Una feature per sessione
• Un bug fix per sessione
• Criteri di accettazione chiari per ogni task

Step 5: Itera sull'Harness

Ogni volta che un agente commette un errore:

1. Identifica la causa radice
2. Aggiungi una regola, un vincolo o un hook che lo prevenga
3. Testa la soluzione

Harness Engineering vs. Prompt Engineering

Il prompt engineering è ancora utile, ma è solo una piccola parte del quadro generale. L'harness engineering è il moltiplicatore.

Il ruolo emergente: L'Harness Engineer

L'ingegneria si sta dividendo in due metà:

1. Environment Building — creare strutture, strumenti, vincoli e cicli di feedback
2. Work Management — pianificare, revisionare e orchestrare sessioni di agenti in parallelo

Da non confondere con: Harness.io

Se hai cercato "Harness Engineering" cercando la piattaforma DevOps — Harness.io è una cosa completamente diversa. È una piattaforma CI/CD basata su AI valutata 5,5 miliardi di dollari (a dicembre 2025) che offre integrazione continua, distribuzione, feature flags, gestione dei costi cloud e test di sicurezza.

Sebbene Harness.io e l'harness engineering condividano il nome, risolvono problemi diversi. Tuttavia, c'è una sovrapposizione interessante: il DevOps potenziato dall'AI di Harness.io è, a conti fatti, un'applicazione dei principi di harness engineering alla pipeline di deployment.

In sintesi

Il modello è il motore. L'harness è l'auto. Nessuno vince una gara con solo un motore.

Se usi agenti di codifica AI nel 2026 e non investi nel tuo harness, stai lasciando gran parte del valore sul tavolo. Inizia con un file di contesto, aggiungi vincoli, costruisci cicli di verifica e itera ogni volta che qualcosa si rompe.

I team che rilasciano software più velocemente non usano modelli migliori. Usano harness migliori.