Perche il Tuo Setup AI e 50 Volte Piu Lento di Quanto Dovrebbe Essere

Il divario tra uno sviluppatore che ottiene un valore 2x dagli strumenti AI e uno che ottiene 100x non dipende dal modello che usa. Dipende dall'architettura che avvolge quel modello. Steve Yegge ha sostenuto all'inizio del 2026 che le persone che usano agenti di codice AI sono da 10x a 100x piu produttive di quelle che usano ancora interfacce chat e autocomplete. Stessi modelli. Stessa intelligenza di fondo. La variabile e la struttura.

In una sola settimana nell'aprile 2026, cinque builder indipendenti hanno pubblicato framework per l'architettura degli agenti AI. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler e un repository community che ha raggiunto 19.700 stelle su GitHub sono convergiti sulla stessa tesi centrale: metti l'intelligenza in file markdown portabili, mantieni l'infrastruttura di orchestrazione il piu snella possibile, lascia che il modello faccia il ragionamento. Questo articolo analizza su cosa sono d'accordo, dove divergono e cosa significa per chiunque stia costruendo con l'AI.

Punti Chiave

• L'intelligenza appartiene ai file skill in markdown, non al codice del framework. Le skill sono portabili, versionabili e migliorano automaticamente quando il modello migliora.

• L'harness deve fare quattro cose e nient'altro. Eseguire il modello in un loop, leggere e scrivere file, gestire il contesto, applicare la sicurezza. Ogni funzione aggiunta oltre questo consuma contesto e rallenta il ragionamento.

• Cinque builder hanno pubblicato indipendentemente la stessa tesi in tre giorni (dal 12 al 15 aprile 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler e un repo community con 19.700 stelle. Quella convergenza e il segnale.

• LangChain non e d'accordo e ha benchmark per dimostrarlo. Harrison Chase sostiene che l'harness E il prodotto. La risposta potrebbe dipendere dal fatto che si stia costruendo strumenti consumer o pipeline enterprise.

• Le istruzioni prescrittive scadono. Il contesto no. Ogni procedura passo-passo che scrivi per un'AI degrada con la prossima versione del modello. Il contesto su chi sei e cosa vuoi si accumula nel tempo.

L'Intera Architettura Sta su un Biglietto da Visita

Il 31 marzo 2026, Anthropic ha accidentalmente pubblicato l'intero codice sorgente di Claude Code sul registro npm. 512.000 righe. Garry Tan lo ha letto. Cio che ha trovato ha confermato un pattern che insegnava a Y Combinator da mesi: il divario di produttivita non riguarda l'intelligenza del modello. Riguarda cio che avvolge il modello.

Tan ha distillato l'architettura in tre livelli:

Il principio e direzionale. Spingi l'intelligenza verso l'alto nelle skill. Spingi l'esecuzione verso il basso negli strumenti deterministici. Mantieni l'harness snello. Il 90% del valore vive nel livello delle skill. L'harness e un conduttore che legge file. Non li possiede.

L'esperienza personale di Tan lo dimostra. Il suo CLAUDE.md personale era partito da 20.000 righe. Ogni quirk, ogni convenzione, ogni lezione mai incontrata. Il risultato: l'attenzione di Claude Code degradava. Il modello gli ha detto letteralmente di ridurlo. La sua soluzione e stata 200 righe di puntatori a documenti che si caricano su richiesta. Le 20.000 righe complete di conoscenza esistono ancora. Si caricano semplicemente quando sono rilevanti invece di inquinare la finestra di contesto ad ogni turno.

Se stai costruendo strumenti o workflow basati su AI per la tua azienda, impostare l'architettura correttamente fin dall'inizio determina se finisci con una demo che impressiona o un sistema che va in produzione.

Cinque Definizioni Separano i Builder al 100x da Tutti gli Altri

L'architettura si basa su cinque concetti. Tralascia anche solo uno e il sistema sottoperforma.

1. File skill

Una skill e un documento markdown riutilizzabile che insegna al modello come fare qualcosa. Non cosa fare. L'utente fornisce il compito. La skill fornisce il processo. Funziona come una chiamata a metodo: stessa procedura, argomenti diversi, output radicalmente diversi.

L'esempio di Tan: una skill chiamata /investigate ha sette passaggi (definire il dataset, costruire una timeline, dirarizzare ogni documento, sintetizzare, argomentare entrambi i lati, citare le fonti). Puntala su uno scienziato della sicurezza e 2,1 milioni di email di discovery e ottieni un analista di ricerca medica. Puntala su una shell company e i documenti FEC e ottieni un investigatore forense. Stessi sette passaggi. E l'invocazione a fornire il contesto.

2. Resolver

Un resolver e una tabella di routing per il contesto. Quando appare il tipo di task X, carica prima il documento Y. Senza un resolver, uno sviluppatore modifica un prompt e lo pubblica. Con un resolver, il modello legge prima la documentazione della suite di valutazione, esegue i benchmark e fa il rollback se l'accuratezza scende di piu del 2%. Lo sviluppatore non sapeva che la suite di valutazione esistesse. Il resolver ha caricato il contesto giusto al momento giusto.

3. Latente vs. deterministico

Ogni passaggio in un sistema e uno o l'altro. Confonderli e l'errore piu comune nel design degli agenti. Un LLM puo disporre 8 persone attorno a un tavolo da cena, tenendo conto delle personalita. Chiedigli di disporne 800 e allucinera una disposizione che sembra plausibile ma e completamente sbagliata. Questo e un problema deterministico forzato nello spazio latente. I migliori sistemi sono spietati riguardo a questa distinzione.

4. Diarizzazione

Il modello legge tutto su un soggetto e scrive un profilo strutturato. Nessuna query SQL produce questo. Nessuna pipeline RAG produce questo. Il modello deve leggere, tenere in mente le contraddizioni, notare cosa e cambiato e quando, e sintetizzare intelligence strutturata.

Il team di Tan ha costruito un sistema per YC Startup School che gestisce 6.000 profili di fondatori in questo modo. L'output della diarizzazione cattura cose che nessuna ricerca per parole chiave potrebbe trovare: una fondatrice che dice "Datadog per agenti AI" ma i cui commit su GitHub sono all'80% codice di billing. Sta costruendo uno strumento FinOps mascherato da observability. Quel divario tra "dice" e "sta costruendo davvero" richiede di leggere simultaneamente la cronologia dei commit, la candidatura e la trascrizione dell'advisor. Nessuna ricerca per similarita di embedding lo trova.

5. Aggiornamenti permanenti

L'istruzione di Tan alla sua AI: "Se ti chiedo di fare qualcosa ed e il tipo di cosa che dovra accadere di nuovo, codificala in un file skill. Se deve girare automaticamente, mettila in un cron. Se devo chiederti qualcosa due volte, hai fallito." Ogni skill scritta e un aggiornamento permanente. Non degrada mai. Quando esce il prossimo modello, ogni skill migliora istantaneamente. Il sistema si accumula.

Cinque Framework Pubblicati in Una Settimana Dicono Tutti la Stessa Cosa

La convergenza e il segnale piu forte. Questi cinque corpus di lavoro sono emersi indipendentemente tra il 12 e il 15 aprile 2026. Nessuno di questi builder sta collaborando. Sono arrivati alla stessa architettura da punti di partenza diversi.

Tan e arrivato qui dopo aver pubblicato 600.000 righe di codice di produzione in 60 giorni con gstack (oltre 23.000 stelle GitHub nella prima settimana). Karpathy e arrivato dal debug dei tre modalita di fallimento persistenti degli assistenti di codice AI. Trivedy e arrivato dall'iterazione sul design dell'harness attraverso oltre 30 versioni. Miessler e arrivato dall'applicazione della bitter lesson di Richard Sutton agli strumenti AI.

Quando cinque fonti indipendenti convergono sulla stessa architettura in 72 ore, l'architettura e probabilmente corretta.

LangChain Non e d'Accordo e Ha Benchmark per Dimostrarlo

Harrison Chase (CEO di LangChain) ha pubblicato Deep Agents la stessa settimana sostenendo l'opposto: l'harness E il prodotto. Pianificazione dei task integrata, spawning di sub-agenti, middleware, hook, infrastruttura di orchestrazione completa. La sua evidenza: cambiare solo l'harness ha portato DeepAgent di LangChain dall'esterno della top 30 alla top 5 su TerminalBench 2.0.

Non e un'obiezione marginale. LangChain elabora milioni di chiamate agente al giorno. I loro benchmark sono pubblici. La vera divisione: la posizione di Tan e che ogni pezzo di logica nell'harness limita il ragionamento che il modello avrebbe potuto fare. Piu il modello migliora, piu l'harness dovrebbe essere snello. La posizione di Chase e che l'ingegneria dell'harness estende la capacita del modello invece di sostituirla.

Entrambe le posizioni possono essere corrette per contesti diversi. Gli agenti consumer e personali (dove portabilita e longevita contano) favoriscono un harness snello. Le pipeline enterprise (dove contano affidabilita e auditabilita) possono giustificare un harness pesante. Nessuna delle due parti contesta che le skill debbano essere fat. La domanda per il tuo progetto non e quale campo abbia ragione. E da quale parte della linea si colloca il tuo caso d'uso.

La maggior parte delle aziende che costruisce funzionalita AI per la prima volta dovrebbe iniziare snella e aggiungere infrastruttura solo quando si scontra con specifici muri di affidabilita. Non sai dove si colloca il tuo progetto? Parla con il nostro team su quale architettura si adatta.

Le Tue Istruzioni Scadranno. Il Tuo Contesto No.

Daniel Miessler ha pubblicato la diagnosi piu acuta della settimana. La chiama il bitter lesson engineering audit, ispirata all'osservazione di Richard Sutton del 2019 secondo cui gli approcci generali scalati con la computazione battono costantemente gli approcci codificati a mano nel lungo periodo.

Applicato agli strumenti AI: la cattiva ingegneria dell'harness e fatta di istruzioni prescrittive. "Prima copia questo file, poi carica questo, poi fai questo, poi fai quello." Microgestione passo-passo dell'esecuzione dell'AI. Questo approccio degrada man mano che i modelli diventano piu intelligenti. Passaggi troppo rigidi impediscono al modello di applicare il proprio ragionamento.

La buona ingegneria dell'harness e contestuale. Chi sei, su cosa stai lavorando, cosa stai cercando di realizzare, come appare il bene e il male. Identita, gusto, standard, obiettivi. Il modello capisce il come.

La diagnostica di Miessler e semplice. Se la tua configurazione si legge come una ricetta (passo 1, passo 2, passo 3), stai facendo cattiva ingegneria dell'harness. Se si legge come un documento di briefing (ecco chi sono, ecco cosa conta, ecco gli strumenti), stai facendo buona ingegneria dell'harness. Il contesto su chi sei non scade mai. Le istruzioni prescrittive diventano obsolete ad ogni miglioramento del modello.

L'architettura non e complicata. Fat skills, thin harness, separazione spietata tra lavoro latente e deterministico. La parte difficile e la disciplina: codificare il giudizio in skill riutilizzabili invece di fare lavoro una tantum, mantenere l'harness snello quando la tentazione e aggiungere funzionalita, e fidarsi del modello per capire il "come" quando gli dai il giusto "cosa" e "perche".

Da webvise, costruiamo sistemi basati su AI seguendo questi principi architetturali. Che tu abbia bisogno di un workflow agente, di una pipeline automatizzata o di un'integrazione AI di livello produttivo, l'architettura conta piu del modello.