Il nuovo stack dell'IA: modelli, harness, loop e agenti auto-miglioranti

Tutti parlano dei modelli AI.

Nessuno parla del livello che li rende effettivamente utili.

Claude Code. Codex. Cursor.

Questi non sono solo modelli.

Sono modelli avvolti in un sistema.

Questo sistema si chiama "imbracatura" (harness).

E le migliori imbracature ora migliorano sé stesse.

Ecco tutto ciò che devi sapere sul nuovo stack AI.

La bugia che tutti credono sui prodotti AI

La maggior parte delle persone pensa che il progresso dell'AI = modelli più intelligenti.

Non è così.

Il modello è una parte dello stack.

L'architettura è pubblica. Tutti copiano lo stesso trasformatore. Ogni laboratorio usa gli stessi mattoni fondamentali.

Ciò che realmente distingue Claude Code da un progetto del fine settimana non è il modello.

È ciò che circonda il modello.

L'imbracatura.

Nel 2017, il progresso dell'AI riguardava i meccanismi di attenzione. Nel 2020, riguardava la scala. Nel 2026, riguarda l'ingegneria delle imbracature.

E le imbracature ora sono progettate dall'AI, non dagli umani.

Cos'è un'imbracatura?

Un'imbracatura è il sistema che circonda un modello.

Decide:

→ Come il modello pensa e pianifica

→ Quando chiama gli strumenti e cosa fare con i risultati

→ Cosa ricorda tra un passo e l'altro

→ Come memorizza gli artefatti e gestisce lo stato

→ Come valuta il proprio output

→ Quando tornare indietro e riprovare

Pensala come un sistema operativo.

Il modello è la CPU. L'imbracatura è il sistema operativo.

Puoi avere una CPU potente e un software terribile e non spedire nulla di utile. Puoi avere una CPU modesta e un software eccellente e spedire qualcosa di grandioso.

Gli agenti di codifica di maggior successo — Claude Code, Codex, Cursor — hanno tutti la stessa intuizione:

Il ciclo conta tanto quanto il modello.

I 3 modelli di imbracatura che ogni sviluppatore AI deve conoscere

Ogni sistema AI di produzione utilizza almeno uno di questi.

Modello 1: Il Ciclo

Il modello non risponde una volta e si ferma.

Cicla.

Pianifica → Esegui → Osserva → Migliora → Ripeti

Questo è il cuore di ogni agente di codifica.

Un ciclo semplificato di Claude Code:

1. Legge il compito
2. Pianifica l'approccio
3. Scrive codice → lo esegue
4. Vede cosa è fallito
5. Lo aggiusta
6. Esegue di nuovo
7. Ripete finché i test non passano

Il modello non è più intelligente al ciclo 3 rispetto al ciclo 1.

Ma il sistema sì.

Ogni ciclo fornisce al modello un nuovo contesto — messaggi di errore, risultati dei test, tracce di esecuzione.

L'output del ciclo 1 diventa l'input del ciclo 2.

Questo contesto composito è il motivo per cui i sistemi agentici superano i prompt singoli su compiti complessi.

Il punto chiave: Il modello rimane fisso. Il contesto diventa più intelligente.

Modello 2: Il File System come Memoria

La maggior parte degli sviluppatori infila tutto nella finestra di contesto.

Questa è una trappola.

I compiti a lungo termine generano:

→ Log degli esperimenti

→ Diff del codice → Tracce di errore

→ Cronologie di rollout passati → Riepiloghi di articoli → Artefatti intermedi

Tutto questo cresce ben oltre qualsiasi finestra di contesto.

La soluzione: scrivere su file, non nel contesto.

1# Male: tutto nel contesto
2contesto = output_precedente + risultato_strumento + log_errore + cronologia...
3# Esplode al passo 47
4
5# Bene: usa il file system
6agente.scrive("esperimenti/esecuzione_3/log_errore.txt", traccia_errore)
7agente.scrive("esperimenti/esecuzione_3/risultati.json", metriche)
8
9# Più tardi, l'agente legge solo ciò di cui ha bisogno
10rilevante = agente.legge("esperimenti/esecuzione_3/risultati.json")

Questo cambia tutto per i compiti a lungo termine.

→ L'agente può riprendere dopo i crash

→ L'agente può ragionare sulla propria cronologia di esecuzione

→ Il contesto rimane pulito anche al passo 200

→ Più sotto-agenti possono condividere lo stato tramite file

I migliori agenti trattano il file system come un secondo cervello.

Non una discarica. Una memoria strutturata.

Modello 3: Sotto-agenti

Un singolo agente non può fare tutto.

I migliori sistemi generano sotto-agenti paralleli.

L'agente genitore:

→ Suddivide il compito in sotto-compiti indipendenti

→ Lancia sotto-agenti per eseguirli in parallelo

→ Monitora il loro stato → Unisce i loro risultati

Esempio per un'imbracatura di ricerca:

1Agente genitore riceve: "Scrivi un report completo di analisi competitiva"
2
3Genera 4 sotto-agenti simultaneamente:
4→ Sotto-agente 1: Ricerca prezzi e funzionalità del concorrente A
5→ Sotto-agente 2: Ricerca prezzi e funzionalità del concorrente B
6→ Sotto-agente 3: Cerca notizie recenti su entrambi i concorrenti
7→ Sotto-agente 4: Estrae recensioni utente da Reddit e App Store
8
9L'agente genitore attende, poi unisce tutti e 4 gli output nel report finale
10
11Tempo totale: uguale al sotto-agente più lento (non 4 volte più lungo)

La regola di progettazione chiave: gli output dei sotto-agenti devono andare su file.

Non contesto transitorio. File.

Se vivono solo nel contesto, scompaiono quando la sessione del sotto-agente termina.

Se vivono nei file, l'agente genitore può ispezionarli, il sistema può riprendersi dai crash e tutto è verificabile.

Strumenti che ogni agente di codifica utilizza

Se stai costruendo un agente, questo è il kit di strumenti su cui ogni grande agente di codifica si standardizza.

1Strumenti File System:
2→ glob, grep, ls          # trova file
3→ read, read_many         # legge contenuto
4→ write                   # crea nuovo file
5→ edit                    # modifica sostituzione stringa
6→ apply_patch             # diff strutturato
7
8Strumenti Shell:
9→ bash                    # esegue qualsiasi comando
10→ PowerShell              # equivalente Windows
11
12Controllo Versione:
13→ git_status, git_diff    # ispeziona modifiche
14→ git_commit              # salva progressi
15
16Gestione Agenti:
17→ spawn_agent             # lancia sotto-agente
18→ wait_agent              # attende risultato
19→ list_agents             # vede cosa è in esecuzione
20→ interrupt_agent         # annulla se necessario
21
22Contesto Esterno:
23→ web_search, web_fetch   # ottiene informazioni attuali
24→ Strumenti MCP           # si connette a servizi esterni

Non hai bisogno di tutti questi per ogni agente.

Ma ogni agente di produzione alla fine ha bisogno della maggior parte.

Quelli che contano di più all'inizio: bash, read, write, edit.

Padroneggia questi quattro e puoi costruire quasi tutto.

Ingegneria del contesto: la competenza di cui nessuno parla

Il modello è fisso.

Non puoi cambiarne i pesi in fase di esecuzione.

Ma puoi cambiare ciò che vede.

Questa è l'ingegneria del contesto.

Ed è ora una delle competenze con la leva più alta nell'ingegneria dell'AI.

Contesto scarso:

→ Scarica tutto dentro → spera per il meglio

→ Il contesto si gonfia → il modello perde concentrazione → gli output degradano

Contesto buono:

→ Strutturato. Conciso. In evoluzione.

→ Informazioni giuste al passo giusto.

→ Fallimenti precedenti informano il tentativo attuale.

L'approccio all'avanguardia (ACE — Ingegneria del Contesto Agentica):

13 componenti:
2
3Generatore:   esegue il compito, fa riferimento a un playbook di contesto strutturato
4Riflettore:   analizza successi e fallimenti, distillando intuizioni
5Curatore:     aggiorna il playbook con nuovi apprendimenti — aggiunge, rimuove, deduplica
6
7Il playbook NON è un blob di prompt.
8È una lista strutturata di coppie (identificatore, intuizione).
9
10Esempio:
11{
12  "id": "001",
13  "intuizione": "Scrivi sempre le tracce di errore su file prima di riprovare."
14},
15{
16  "id": "002",
17  "intuizione": "Il sotto-agente per la ricerca web restituisce risultati migliori con query specifiche per sito."
18},
19{
20  "id": "003",
21  "intuizione": "Eseguire i test prima di fare commit cattura l'80% delle regressioni."
22}

Il playbook si aggiorna dopo ogni esecuzione.

L'agente che esegue il compito 50 lavora con 49 esecuzioni di apprendimenti distillati.

L'agente che esegue il compito 1 non aveva nulla.

È così che un sistema diventa più intelligente senza toccare i pesi del modello.

L'imbracatura che migliora sé stessa

Qui è dove diventa pazzesco.

E se l'imbracatura stessa fosse la cosa da ottimizzare?

Non il prompt. Non il modello.

Il codice che esegue l'agente.

Questo è esattamente ciò che fa Self-Harness.

Ciclo in 3 passi:

Passo 1 — Scava le debolezze

Esegui l'imbracatura corrente su un insieme di compiti. Raccogli le tracce di fallimento. Raggruppa i fallimenti per causa principale.

Non "è fallito." Ma perché è fallito.

Tipi di fallimento scoperti:

→ "L'agente va in timeout su letture di file lunghi"

→ "Output dei sotto-agenti persi quando il genitore crasha"

→ "Messaggi di errore non abbastanza informativi per auto-correggersi"

→ "Il contesto cresce troppo dopo il passo 30, il modello perde concentrazione"

Passo 2 — Propone correzioni

Lo stesso modello esamina i modelli di fallimento. Propone modifiche specifiche e mirate al codice dell'imbracatura.

Non riscritture. Modifiche mirate.

Modifica proposta all'imbracatura:

→ Aggiungi gestore di timeout alle operazioni di lettura file

→ Scarica automaticamente l'output del sotto-agente su disco ad ogni passo (non solo alla fine)

→ Standardizza il formato del messaggio di errore per includere: passo, strumento, input, output, motivo del fallimento

→ Aggiungi passo di compressione del contesto ogni 25 turni

Passo 3 — Convalida e unisci

Ogni modifica proposta viene testata su compiti tenuti da parte.

Risolve la debolezza senza rompere nient'altro?

Se sì: unita nell'imbracatura. Se no: registrata, rifiutata, imbracatura invariata.

Il risultato: l'imbracatura migliora ad ogni generazione.

Claude 3.5 Sonnet che esegue Self-Harness è passato dal 20% al 50% su SWE-bench Verified.

Non da un modello migliore.

Da un sistema migliore.

Ricerca evolutiva dell'imbracatura

Self-Harness corregge un'imbracatura iterativamente.

AlphaEvolve gestisce una popolazione di imbracature ed evolve le migliori.

L'algoritmo:

11. Inizia con un pool di candidati imbracatura
22. Valuta ciascuno su compiti benchmark
33. Seleziona i migliori performer come "genitori"
44. Chiedi al modello di proporre diff/miglioramenti
55. Genera nuove imbracature "figlie"
66. Valuta le figlie
77. Tieni quelle che migliorano
88. Aggiungile di nuovo al pool
99. Ripeti
10
11(Stessa logica della selezione naturale. Applicata al codice.)

(Stessa logica della selezione naturale. Applicata al codice.)

Un dettaglio di progettazione chiave da AlphaEvolve:

Le regioni di codice idonee all'evoluzione sono esplicitamente marcate:

1# EVOLVE-BLOCK-START
2def pianifica_passo_successivo(contesto, strumenti):
3    # Questa sezione può essere modificata dalla ricerca evolutiva
4    prompt = f"Dato: {contesto}\nStrumenti disponibili: {strumenti}\nAzione successiva:"
5    return llm.genera(prompt)
6# EVOLVE-BLOCK-END
7
8# Il resto dell'imbracatura rimane fisso
9def esegui_strumento(nome_strumento, args):
10    return registro_strumenti[nome_strumento](**args)

Questo contenimento impedisce all'agente di modificare accidentalmente il codice critico per la sicurezza.

La ricerca evolutiva tocca solo ciò che permetti esplicitamente di toccare.

AlphaEvolve ha usato questo per ottimizzare algoritmi di moltiplicazione di matrici.

Il risultato: ha battuto il codice ottimizzato a mano di DeepMind.

L'agente ha trovato soluzioni che gli ingegneri umani non avevano scoperto in decenni.

Macchina di Darwin Gödel: agenti che si riscrivono da soli

La versione più estrema di questa idea.

Un agente che modifica il proprio codice di imbracatura per migliorare nei compiti.

Macchina di Darwin Gödel (DGM):

11. Inizia con un agente di codifica nel pool
22. Eseguilo su benchmark, raccogli punteggi
33. L'agente esamina i propri log di valutazione
44. L'agente propone miglioramenti al proprio codice di imbracatura
55. Strumenti disponibili: bash + editor di file (vedi/crea/modifica file)
66. Viene creata una nuova versione dell'agente
77. La nuova versione viene valutata
88. Se migliore: aggiunta al pool
99. Se peggiore: scartata
1010. Ripeti — selezionando i genitori per prestazione, inversamente per numero di figli

Condizione iniziale: Claude 3.5 Sonnet + semplice imbracatura iniziale.

Risultato:

→ SWE-bench Verified: 20% → 50%

→ Benchmark di codifica poliglotta: 14.2% → 30.7%

Zero modifiche ai pesi del modello. Zero ingegneria umana tra le generazioni.

L'agente ha progettato versioni migliori di sé stesso.

Questa non è fantascienza.

Questo è un articolo del 2025.

5 modalità di fallimento da evitare

Questi sono i modi in cui veri team di ricerca hanno fallito.

Tutti documentati. Tutti evitabili.

1. Collasso del contesto

I compiti a lungo termine perdono dettagli critici se i log non vengono scritti come artefatti persistenti.

Correzione: scrivi tutto ciò che è importante su file. Non fare mai affidamento solo sul contesto oltre il passo 20.

2. Deriva dell'implementazione

Quando il compito diventa tecnicamente difficile, il modello deriva verso soluzioni più facili e comuni invece dell'obiettivo reale.

Correzione: scrivi un file di specifica all'inizio. L'agente controlla la specifica ad ogni ciclo.

3. Ottimismo eccessivo

Il modello dichiara successo nonostante esperimenti falliti.

Trova "nastro adesivo numerico" — patch che fanno sembrare buone le metriche senza risolvere il problema reale.

Correzione: tieni da parte un set di test che l'agente non vede mai. Convalida solo sui dati tenuti da parte.

4. Hacking della ricompensa

L'agente ottimizza qualunque segnale gli venga dato.

Se il segnale sono i test unitari — scrive test che passano sempre. Se il segnale è un modello giudice — impara trucchi per ingannare il giudice. Se il segnale è il punteggio benchmark — sfrutta gli artefatti del benchmark.

Correzione: il valutatore vive al di fuori del ciclo. Revisione umana nei punti decisionali chiave.

5. Collasso della diversità

I cicli evolutivi convergono su una singola strategia.

Ogni generazione sembra una variante della stessa soluzione.

Correzione: tieni traccia esplicitamente della novità. Penalizza le soluzioni troppo simili ai membri esistenti del pool (la similarità coseno basata su embedding funziona).

Il nuovo stack AI in parole semplici

Questo è ciò che stai effettivamente costruendo quando costruisci seri prodotti AI:

Livello 1 — Il Modello

Intelligenza grezza. Pre-addestrato. Pesi fissi in fase di esecuzione.

Questa è la CPU. Potente ma passiva.

Livello 2 — L'Imbracatura

Il sistema operativo. Avvolge il modello. Orchestra tutto.

→ Strumenti (bash, lettura/scrittura file, ricerca web)

→ Memoria (file system, log strutturati)

→ Ciclo (pianifica → esegui → valuta → riprova) → Sotto-agenti (esecuzione parallela)

→ Gestione del contesto (cosa vede il modello ad ogni passo)

Livello 3 — L'Ottimizzatore

L'imbracatura che migliora l'imbracatura.

→ Scava modelli di fallimento dalle tracce di esecuzione

→ Propone modifiche mirate al codice dell'imbracatura → Convalida su compiti tenuti da parte

→ Unisce i miglioramenti, scarta le regressioni

Livello 4 — Il Valutatore

Vive al di fuori di tutti gli altri livelli.

→ Punteggi benchmark → Revisione umana nei punti decisionali chiave → Set di test tenuti da parte che l'ottimizzatore non tocca mai

Non puoi saltare nessun livello.

Salta il Livello 2 — il tuo modello è un chatbot, non un prodotto.

Salta il Livello 3 — il tuo sistema non migliora mai senza ingegneria manuale.

Salta il Livello 4 — il tuo agente ottimizza la cosa sbagliata e non te ne accorgerai.

Cosa significa per chi costruisce, adesso

Non devi costruire un'imbracatura auto-migliorante per beneficiare di queste idee.

Inizia qui:

Settimana 1: Costruisci il ciclo

Smetti di costruire prompt singoli. Costruisci un ciclo pianifica → esegui → valuta → riprova per qualsiasi compito che richieda più di un passo.

Settimana 2: Aggiungi memoria persistente

Smetti di fare affidamento sul contesto. Scrivi gli output intermedi su file. Lascia che l'agente legga il proprio lavoro precedente.

Settimana 3: Aggiungi sotto-agenti

Identifica qualsiasi parte del tuo flusso di lavoro che può essere eseguita in parallelo. Genera sotto-agenti. Scrivi i loro output su file. Unisci.

Settimana 4: Aggiungi ingegneria del contesto

Tieni traccia di quali modelli portano a successo e fallimento. Costruisci un semplice playbook strutturato che si aggiorna dopo ogni esecuzione.

Questa è l'imbracatura.

Non il modello.

Il modello è già lì.

L'imbracatura è ciò che costruisci.

La verità scomoda sull'AI nel 2026

L'accelerazione della ricerca nei laboratori di frontiera è aumentata drasticamente.

Anthropic e OpenAI stanno rilasciando più velocemente che mai.

Non perché i modelli siano diventati più intelligenti dall'oggi al domani.

Perché le imbracature sono migliorate.

Un agente che cicla, ricorda, sub-delega e si auto-corregge supera un modello più intelligente usato male.

Il fossato non è il modello.

Il fossato è il sistema.

E il sistema ora può migliorare sé stesso.

Se questo è stato utile:

→ Ripubblica — ogni sviluppatore AI deve capire questo stack

→ Segui @sairahul1 per altre analisi come questa

→ Aggiungi ai segnalibri — solo lo stack a 4 livelli vale la pena salvare

Iscriviti a theaibuilders.co per altri articoli interessanti come questo

Scrivo di AI, costruzione di prodotti e sistemi che funzionano senza di te.