Dibattito su OpenAI Anthropic Harness: modelli più forti, scommesse ingegneristiche opposte
Gli ingegneri di OpenAI hanno riaperto una disputa rilevante con Anthropic: modelli AI più forti dovrebbero richiedere harness più leggeri, eppure le attività più impegnative continuano a beneficiare di una supervisione più intensa.
Quel dibattito sugli harness tra OpenAI e Anthropic non riguarda semplicemente prompt o preferenze di interfaccia. Riguarda il software che circonda un modello, inclusi strumenti, memoria, autorizzazioni, pianificazione, valutazione e approvazione umana.
OpenAI sostiene che un eccesso di impalcature possa codificare limitazioni che il modello successivo non avrà più. I recenti esperimenti di Anthropic sono giunti a una conclusione più condizionale. Modelli migliori hanno eliminato parte dell'orchestrazione, ma pianificatori e valutatori indipendenti sono rimasti preziosi quando le attività si avvicinavano ai limiti del modello.
Il disaccordo coinvolge più di Codex e Claude Code. Le aziende stanno trasformando modelli generalisti in agenti che modificano repository, usano browser, analizzano documenti e coordinano progetti prolungati. Ogni controllo aggiuntivo può migliorare l'affidabilità, ma aggiunge anche latenza, complessità e un'altra assunzione che può diventare obsoleta.
La questione centrale, quindi, non è se gli harness contino. Il lavoro ingegneristico di entrambe le aziende dimostra che contano. La domanda è se il progresso sposti il valore nel modello, verso l'harness, o ripetutamente tra entrambi i livelli.
Cosa hanno effettivamente cambiato OpenAI e Anthropic
Entrambe le aziende trattano ormai l'harness degli agenti come un livello che definisce il prodotto, ma non concordano su quanta intelligenza debba contenere quel livello.
Un harness per agenti è il runtime che collega un modello a strumenti, contesto, memoria, cicli di feedback e controlli utente. Il modello genera decisioni. L'harness determina quali informazioni vede, quali azioni può compiere e come vengono intercettati gli errori.
La posizione di OpenAI è emersa chiaramente nei resoconti di agosto sul suo impegno a estendere gli agenti oltre lo sviluppo software. I suoi ingegneri hanno descritto una buona harness engineering come la capacità di fornire a un modello gli strumenti e le informazioni precise di cui ha bisogno, senza circondarlo di regole superflue.
L'ingegnere Nick Gershenson ha dichiarato a TechCrunch che elaborate raccolte di logica condizionale e strumenti possono produrre guadagni nel breve periodo. Tuttavia, ha sostenuto che un nuovo modello può rendere tali aggiunte obsolete nel giro di pochi mesi. La sua direzione preferita è un'interfaccia sobria che permetta a un modello capace di risolvere autonomamente una quota maggiore del problema.
Quel principio richiama la bitter lesson, l'influente argomento di Rich Sutton secondo cui il calcolo generalizzato supera i sistemi costruiti attorno a un'estesa conoscenza umana. Applicata agli agenti, la lezione privilegia modelli ampiamente capaci rispetto a flussi di lavoro progettati manualmente per ogni possibile errore previsto.
OpenAI non ha abbandonato la harness engineering. Il suo resoconto su Codex engineering descrive repository, documentazione, test, cicli di feedback e piani leggibili dalle macchine come infrastruttura essenziale. L'azienda ha riportato una media di 3,5 pull request al giorno per ingegnere in un progetto interno.
La distinzione riguarda dove OpenAI vuole che risieda la complessità. I suoi ingegneri preferiscono ambienti leggibili e feedback chiari, anziché rami sempre più elaborati che prescrivano al modello come deve ragionare.
La ricerca di Anthropic del 24 marzo ha presentato un diverso stress test. Il ricercatore Prithvi Rajasekaran ha utilizzato un pianificatore, un generatore e un valutatore per creare applicazioni complete nel corso di sessioni autonome prolungate.
Il pianificatore traduceva una breve richiesta in una specifica strutturata. Il generatore implementava quel piano. Il valutatore utilizzava l'applicazione, verificava i criteri concordati e restituiva i difetti da correggere.
Il confronto iniziale di Anthropic ha rilevato che un'esecuzione con un singolo agente produceva un'applicazione la cui funzionalità di gioco principale non funzionava. L'harness multi-agente ha fornito un risultato più ampio e funzionale, pur con difetti residui.
Non era una prova che un sistema più pesante vinca sempre. Anthropic ha successivamente eliminato la scomposizione a livello di sprint quando Claude Opus 4.6 ha gestito il lavoro più lungo in modo più coerente. Tuttavia, il pianificatore e il valutatore hanno continuato a individuare funzionalità mancanti o superficiali.
L'evento rappresenta quindi al tempo stesso una convergenza e un disaccordo. OpenAI e Anthropic semplificano entrambe gli harness quando i modelli assorbono vecchie responsabilità. Differiscono sulla rapidità con cui gli sviluppatori dovrebbero fidarsi di quel trasferimento.
Perché il dibattito sugli harness tra OpenAI e Anthropic conta ora
La pressione deriva dagli agenti che si spostano oltre compiti di coding circoscritti verso lavori nei quali il successo è più difficile da definire e il fallimento più difficile da invertire.
Il coding ha fornito il primo ambiente favorevole agli agenti. I repository contengono file strutturati, i compilatori espongono gli errori e i test producono spesso segnali chiari di superamento o fallimento. Un harness può trasformare tali segnali in un nuovo tentativo del modello.
Il lavoro intellettuale generalista offre meno verifiche affidabili. Un memo strategico può sembrare coerente pur fondandosi su assunzioni deboli. Un foglio di calcolo può eseguire correttamente i calcoli rispondendo però alla domanda aziendale sbagliata. Un agente può completare una presentazione curata senza accorgersi che le sue prove sono obsolete.
OpenAI sta estendendo il proprio approccio agli agenti a queste situazioni meno strutturate. Questa mossa mette pressione sull'azienda affinché preservi la semplicità associata a modelli più forti, aggiungendo al tempo stesso i controlli richiesti dagli utenti comuni.
Anthropic affronta la pressione opposta. Claude Code ha costruito gran parte del proprio fascino attorno a progressi visibili, interazioni frequenti e coinvolgimento dell'utente. Questo approccio può sembrare più sicuro, ma domande e approvazioni ripetute aumentano il carico di lavoro dell'operatore.
La rivalità riflette due istinti di prodotto. OpenAI ha spesso perseguito l'esperienza di assegnare un obiettivo e ricevere un risultato finito. Anthropic ha generalmente reso più visibile il processo di ragionamento intermedio attraverso piani, alternative e richieste di autorizzazione.
Nessuno dei due istinti è universalmente migliore. L'autonomia diventa attraente quando l'obiettivo è chiaro e la verifica è economica. La collaborazione diventa preziosa quando le preferenze non sono espresse o le conseguenze sono difficili da misurare.
Questo spiega perché un'interfaccia può modificare la qualità apparente di un modello identico. Un harness controlla la selezione del contesto, le descrizioni degli strumenti, il comportamento dei tentativi ripetuti, l'accesso ai file e il momento dell'intervento dell'utente. Queste decisioni plasmano ogni azione compiuta dal modello.
I creatori di framework indipendenti hanno osservato la stessa dipendenza. LangChain ha riportato che profili di harness specifici per modello hanno prodotto miglioramenti da 10 a 20 punti su un sottoinsieme di tau2-bench rispetto alla sua configurazione predefinita. I suoi harness profiles regolano prompt, strumenti e middleware per diversi comportamenti dei modelli.
Questo risultato mette in discussione una versione semplice della tesi di OpenAI. Se l'harness fosse soltanto una stampella temporanea, modificarlo non dovrebbe creare grandi differenze di prestazione mentre il modello sottostante resta invariato.
Tuttavia, sostiene anche la critica di OpenAI all'astrazione non necessaria. LangChain non ha trovato un'unica architettura sempre più complicata in grado di migliorare ogni modello. Ha rilevato invece che modelli diversi rispondevano a configurazioni diverse.
La pressione pratica ricade sui team di prodotto. Devono decidere se ottimizzare strettamente per un singolo fornitore o mantenere un livello portabile tra diversi modelli.
Un'ottimizzazione ravvicinata può offrire risultati immediati migliori. Può anche creare dipendenza da strumenti, prompt e comportamenti di contesto specifici di un fornitore. La portabilità limita tale dipendenza, ma un harness generico può lasciare inutilizzata la capacità del modello.
Queste scelte diventano più rilevanti man mano che agli agenti vengono concesse autorizzazioni più ampie. Un assistente di coding che suggerisce una patch ha un ruolo circoscritto. Un agente che legge comunicazioni, modifica documenti condivisi e attiva sistemi aziendali attraversa diversi confini di fiducia.
I team che valutano questi prodotti dovrebbero quindi guardare oltre i benchmark dei modelli. Hanno bisogno di prove sulla combinazione completa di modello e harness, in condizioni realistiche di autorizzazioni, dati e fallimenti.
OpenAI vuole che sia il modello a guidare
L'argomento di OpenAI a favore di harness più leggeri sostiene che gli sviluppatori dovrebbero esporre chiaramente l'ambiente, lasciando poi al modello la maggior parte del comportamento adattivo.
Questa posizione non significa eliminare test, autorizzazioni o gestione del contesto. Significa resistere a procedure di ragionamento costruite manualmente che compensano limitazioni destinate a scomparire.
L'esperienza di OpenAI con la prima applicazione web di Codex aiuta a spiegare questa convinzione. Inizialmente, l'azienda aveva scommesso su un modello capace di completare le attività con un coinvolgimento minimo dell'utente. L'approccio più interattivo di Claude Code di Anthropic si è dimostrato più allineato a ciò che i modelli potevano fare in modo affidabile in quel momento.
OpenAI ha poi aggiunto più occasioni affinché gli utenti potessero guidare Codex. Un ingegnere ha riconosciuto che il prodotto precedente era andato oltre ciò che il suo modello e il suo harness potevano supportare.
Quella storia è importante perché mostra il pericolo da entrambi i lati. Un harness può contenere troppa logica rigida. Può anche presumere una competenza del modello maggiore di quella che gli utenti ricevono realmente.
L'approccio attuale di OpenAI cerca di evitare un altro disallineamento attraverso ambienti più chiari e feedback più forti. Il suo resoconto ingegneristico interno sottolinea documentazione strutturata, regole dei repository, piani e controlli automatizzati.
Questi elementi sono più leggeri di un flusso di lavoro che prescrive ogni passaggio del ragionamento. Tuttavia, rappresentano comunque un'ingegneria estesa. L'harness delega il giudizio, rendendo al contempo più facile ispezionare il successo.
L'approccio si adatta anche alle ambizioni di prodotto di OpenAI. Un agente generalista per il lavoro non può fare affidamento sul fatto che i progettisti prevedano ogni sequenza che un utente potrebbe richiedere. Lo spazio delle possibili attività è troppo ampio.
Un sistema guidato dal modello può scegliere strumenti e rivedere piani al cambiare delle condizioni. Questa flessibilità è attraente quando gli utenti passano dalla ricerca ai fogli di calcolo, ai messaggi, al codice e alle presentazioni all'interno di un unico incarico.
Tuttavia, un harness minimale trasferisce più responsabilità nel modello. Il modello deve rilevare l'ambiguità, richiedere informazioni mancanti e riconoscere quando un'azione merita conferma.
Questi comportamenti non sono garantiti dalla sola capacità generale. Un modello può diventare migliore nell'eseguire istruzioni senza migliorare altrettanto nel rilevare un obiettivo difettoso.
L'esperienza utente amplifica questo rischio. Ethan Mollick, professore della Wharton che studia l'AI sul posto di lavoro, ha contrapposto sistemi che tentano di completare immediatamente il lavoro a quelli che mostrano confronti e richiedono feedback.
Il design più autonomo riduce l'attrito quando l'agente interpreta correttamente l'obiettivo. Quando non lo fa, gli utenti possono scoprire l'errore soltanto dopo una lunga catena di lavoro coerente ma mal indirizzato.
Questo rende centrale la qualità del contesto. Un harness leggero funziona al meglio quando fornisce informazioni concise, pertinenti e aggiornate. Un contesto ampio e non filtrato può seppellire le priorità anche quando il modello supporta una lunga finestra di contesto.
Per i knowledge worker, organizzare tali prove resta un problema ingegneristico separato. Una knowledge base ricercabile può ridurre il rumore di recupero prima che un agente inizi ad agire.
La tesi di OpenAI è più forte per le attività con feedback automatico denso. Compilatori, suite di test, linter e controlli del browser permettono a un agente di valutare i progressi senza un giudizio umano costante.
Diventa più debole quando il completamento dipende dal gusto, dalla storia organizzativa o da aspettative non documentate. Un modello non può dedurre prove che non entrano mai nel suo contesto.
OpenAI sta quindi facendo una scommessa calcolata. Man mano che i modelli migliorano, gestiranno internamente più pianificazione e recupero. I progettisti di harness dovrebbero preservare la generalità invece di cristallizzare nei prodotti di domani i limiti dei modelli di ieri.
Anthropic afferma che il lavoro più difficile richiede ancora più struttura
Le prove di Anthropic sugli harness più pesanti mostrano che modelli più forti non eliminano l'orchestrazione; ne spostano il confine utile verso compiti più difficili.
Il harness per attività di lunga durata di Anthropic è partito da due debolezze ricorrenti. I modelli perdevano coerenza durante il lavoro prolungato e valutavano il proprio output con eccessiva generosità.
Il primo problema riguardava il contesto. Le attività lunghe accumulano decisioni, risultati degli strumenti, errori e implementazioni parziali. Anche quando una finestra di contesto può contenere quel materiale, la sua organizzazione influenza ciò che il modello nota.
Anthropic ha utilizzato reset del contesto con file di passaggio strutturati. Un reset offriva a una nuova sessione dell'agente uno stato di lavoro pulito, preservando al contempo i progressi essenziali e i passaggi successivi.
Il secondo problema era l'autovalutazione. Lo stesso modello che produceva un'applicazione spesso accettava risultati deboli, specialmente quando la qualità dipendeva dal giudizio progettuale.
Anthropic ha separato la creazione dalla revisione. Il suo valutatore ha usato criteri espliciti e automazione del browser per testare le funzionalità. Il generatore riceveva riscontri concreti e tentava le correzioni.
Il primo harness completo ha ampliato una richiesta di gioco di una frase in 16 funzionalità distribuite su dieci sprint. Il valutatore ha applicato contratti dettagliati a ogni sprint, inclusi 27 criteri per una fase dell'editor di livelli.
Anthropic ha riferito che il risultato multi-agente offriva funzionalità core operative che il tentativo a singolo agente non aveva. Tuttavia, ha richiesto un impiego sostanzialmente maggiore di tempo di esecuzione, orchestrazione e modelli.
Questo compromesso rende l'esperimento più utile di una semplice vittoria in benchmark. Mostra cosa può ottenere una struttura aggiuntiva, esponendo al contempo perché i team non possono aggiungere valutatori indiscriminatamente.
Anthropic ha poi ripetuto il processo con un modello più forte. Opus 4.6 ha sostenuto la build principale per oltre due ore senza la precedente scomposizione in sprint.
Questo ha sostenuto l'osservazione centrale di OpenAI. Una capacità un tempo fornita dall'harness era passata al modello, rendendo superflua parte dell'impalcatura.
Il valutatore ha comunque rilevato lacune rilevanti. Ha identificato funzionalità audio fondamentali presenti solo come elementi superficiali dell'interfaccia o segnaposto. Il generatore ha poi risolto diverse di queste omissioni.
La conclusione di Anthropic non era che ogni attività richieda tre agenti. Il valutatore ha prodotto il massimo valore quando il lavoro si trovava vicino al limite di ciò che il generatore poteva completare in modo affidabile.
Quel limite è dinamico. Una nuova release del modello lo sposta verso l'esterno. Un'attività più impegnativa lo riporta nuovamente verso l'interno.
Questo produce un'interpretazione diversa della bitter lesson. I modelli generali sostituiscono soluzioni artigianali per i problemi di ieri, ma rendono anche raggiungibili obiettivi prima impraticabili.
Quando i team tentano quegli obiettivi, emergono nuove modalità di fallimento. L'harness non scompare. Segue la frontiera delle capacità.
La posizione di Anthropic riconosce anche che la valutazione fa parte del prodotto. Un sistema che genera più output non è automaticamente più utile. Qualcuno o qualcosa deve stabilire se quell'output soddisfa il requisito effettivo.
Per gli sviluppatori, le suite di test possono fornire gran parte di quel giudizio. Per attività di progettazione, ricerca e gestione, i criteri devono spesso essere definiti prima che l'agente agisca.
Un'architettura pianificatore-valutatore rende esplicite tali aspettative. Può anche amplificare criteri sbagliati. Un valutatore applicherà il proxy misurabile che riceve, anche quando quel proxy non coglie ciò che gli utenti apprezzano.
Gli harness più pesanti creano quindi un proprio problema di governance. Più componenti significano più prompt, autorizzazioni, log, passaggi di consegna e percorsi di errore da mantenere.
Le prove di Anthropic sostengono una struttura selettiva, non una complessità permanente. Rimuovete ciò che un modello più forte ora può gestire, quindi reinvestite lo sforzo ingegneristico dove la verifica produce ancora un guadagno significativo.
Il test modello contro harness resta irrisolto
Nessuna delle due parti ha dimostrato che la propria architettura preferita vinca per tutti i modelli, le attività, i budget e i livelli di rischio.
Il dibattito sugli harness tra OpenAI e Anthropic si basa in larga misura su esperimenti interni e osservazioni sui prodotti. Queste fonti rivelano scelte ingegneristiche, ma non forniscono un confronto controllato tra Codex e Claude Code.
Il resoconto di OpenAI riflette i suoi modelli, repository e pratiche di team. Gli esempi di Anthropic utilizzano modelli Claude su attività selezionate di sviluppo applicativo. Ciascuna azienda ha scelto l'ambiente e i criteri di successo.
Persino il confronto dettagliato di Anthropic ha modificato diverse variabili contemporaneamente. Il sistema completo ha aggiunto pianificazione, valutazione, scomposizione, esecuzione più lunga e più chiamate al modello. Il risultato non può isolare quale componente abbia generato ciascun miglioramento.
L'azienda ha poi usato la rimozione dei componenti per comprendere questa domanda. Tuttavia, le sue conclusioni derivavano ancora da una piccola raccolta di dimostrazioni anziché da un'ampia replica indipendente.
I benchmark di terze parti aiutano, ma introducono ulteriori complicazioni. Un harness può ottenere buoni risultati perché il benchmark assomiglia al suo flusso di lavoro preferito. Un'altra configurazione può invece ottimizzare l'uso dei token, il tasso di superamento, la latenza o la recuperabilità.
Lo stesso punteggio può anche nascondere rischi operativi diversi. Un agente potrebbe fallire in modo visibile e fermarsi. Un altro potrebbe produrre un risultato plausibile ma errato che supera i controlli automatizzati.
La ricerca sui sistemi di coding in produzione tratta sempre più il modello e l'harness come un'unità combinata. Un recente studio sul codice sorgente ha esaminato 11 harness di coding, tra cui Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode e OpenHands.
Questa diversità indebolisce l'idea di un unico harness ottimale. Questi sistemi differiscono nella gestione del contesto, nei punti di estensione, nella pianificazione, nell'isolamento e nell'esecuzione degli strumenti perché i loro progettisti si rivolgono a utenti diversi.
La portabilità presenta un'altra questione irrisolta. Alcuni report hanno citato un confronto in cui l'harness open-source Pi ha superato Codex utilizzando lo stesso modello OpenAI.
Un risultato del genere suggerisce che il fornitore del modello non costruisca automaticamente l'ambiente migliore per ogni attività. Non dimostra che Pi vinca in senso ampio, poiché l'impostazione del benchmark e la configurazione restano decisive.
Gli harness aperti possono esporre tracce, uso dei token e dettagli di configurazione che i prodotti proprietari nascondono. Questa trasparenza aiuta i team a diagnosticare i fallimenti e a cambiare fornitore.
Gli harness controllati dai fornitori ricevono accesso anticipato a capacità specifiche del modello. I loro sviluppatori possono ottimizzare comportamenti non documentati e distribuire aggiornamenti coordinati.
Gli incentivi commerciali contano. Sia OpenAI sia Anthropic traggono vantaggio quando i clienti usano i loro modelli attraverso le loro interfacce. Possedere l'harness rafforza la distribuzione e può aumentare i costi di passaggio attraverso contesto memorizzato, integrazioni e flussi di lavoro appresi.
Questo non rende false le loro affermazioni ingegneristiche. Significa che i clienti dovrebbero separare le prove tecniche dalla strategia di piattaforma.
Il costo è un'altra incertezza, anche senza confrontare dati pubblici sui prezzi. La pianificazione e la valutazione multi-agente consumano token e tempo aggiuntivi. Un tasso di completamento più elevato può giustificare questo sovraccarico quando il fallimento è costoso.
Il contrario vale per il lavoro ordinario e reversibile. Eseguire un valutatore su ogni modifica minore può consumare più risorse della correzione dell'errore occasionale.
La sicurezza complica ulteriormente la tesi dell'harness più leggero. Modelli migliori possono eseguire sequenze di azioni più lunghe e usare gli strumenti in modo più efficace. Questi miglioramenti aumentano le conseguenze di istruzioni fraintese.
Limiti di autorizzazione, log di audit, sandboxing e conferme sono funzioni dell'harness. Una capacità maggiore può aumentarne l'importanza, pur riducendo il bisogno di impalcature di pianificazione.
I team dovrebbero quindi respingere test unidimensionali. Una valutazione utile deve misurare il completamento dell'attività, i difetti nascosti, il tempo di revisione umana, il consumo di risorse e il recupero dopo un fallimento.
Dovrebbe inoltre confrontare configurazioni con lo stesso modello. Altrimenti, un team potrebbe acquistare un modello più capace quando una modifica al contesto o agli strumenti avrebbe risolto il problema.
Le prove attuali sostengono una regola condizionale. Usate l'harness più leggero che soddisfi una soglia di affidabilità definita, quindi aggiungete struttura laddove i fallimenti osservati la giustifichino.
Questa regola sembra un compromesso, ma crea un lavoro operativo impegnativo. I team hanno bisogno di valutazioni ripetibili, ispezione delle tracce e configurazioni versionate per sapere quando un componente rimane utile.
Senza queste prove, “più leggero” diventa fede nel prossimo modello. “Più pesante” diventa folklore accumulato, codificato in prompt e rami del flusso di lavoro.
Tre segnali decideranno quale approccio vincerà
La prossima fase sarà decisa da prove comparative, non dalla descrizione preferita da ciascuna azienda della propria architettura.
Il primo segnale è la performance nello scambio degli harness. Ricercatori e costruttori di framework hanno bisogno di test controllati che mantengano costanti modello, attività, accesso agli strumenti e limiti di risorse.
Se harness di terze parti superano ripetutamente le interfacce dei fornitori usando lo stesso modello, il valore si sta spostando verso l'orchestrazione. Questo risultato indebolirebbe la convinzione che il progresso dei modelli assorba naturalmente la maggior parte della differenziazione del prodotto.
Se le differenze di prestazione si riducono tra harness ben progettati, la tesi di OpenAI acquista sostegno. Suggerirebbe che modelli più forti necessitano di meno interventi specializzati e possono operare attraverso ambienti più semplici e standardizzati.
Il secondo segnale è il modo in cui Anthropic e OpenAI semplificano i propri sistemi dopo ogni release del modello. Anthropic ha già mostrato una versione di questo test rimuovendo la scomposizione in sprint dai flussi di lavoro di Opus 4.6.
Osservate quali componenti spariranno in seguito. Pianificazione, reset del contesto, valutazione indipendente e approvazioni frequenti rappresentano ciascuno un'ipotesi diversa sui limiti dei modelli.
Rimuovere un componente senza ridurre la qualità dell'attività rafforza l'argomento dell'harness più leggero. Spostare quel componente a una classe di lavoro più difficile sostiene l'interpretazione della frontiera mobile di Anthropic.
Il terzo segnale è l'adozione al di fuori dell'ingegneria del software. Gli agenti di coding traggono vantaggio da repository, test e feedback digitalizzato. Il lavoro della conoscenza contiene segnali più deboli e preferenze più implicite.
Un agente guidato dal modello apparirà convincente se le persone accettano il lavoro completato senza correzioni estese. Un harness collaborativo apparirà più forte se gli utenti necessitano con costanza di anteprime, confronti e punti di approvazione.
La metrica di adozione più utile non sarà il numero di attività avviate. Sarà la quota completata correttamente dopo aver considerato revisione umana e rilavorazione.
Gli sviluppatori dovrebbero anche monitorare la gravità dei fallimenti. Un harness che completa meno attività ma si ferma in sicurezza può essere preferibile a uno che ne completa di più commettendo errori difficili da rilevare.
Gli acquirenti enterprise dovrebbero richiedere valutazioni basate sui propri documenti, autorizzazioni e flussi di lavoro. Le classifiche pubbliche non possono rappresentare definizioni di correttezza specifiche dell'organizzazione.
I knowledge worker possono condurre una versione più semplice di questo processo. Iniziate con un'attività familiare e reversibile e confrontate il risultato dell'agente con una baseline umana consolidata.
Registrate i punti in cui il modello non disponeva del contesto, ha scelto lo strumento sbagliato o ha avuto bisogno di una guida soggettiva. Queste osservazioni rivelano se il prossimo intervento debba riguardare istruzioni, recupero delle informazioni, regole di approvazione o revisione indipendente.
Il dibattito sulle harness di OpenAI e Anthropic non si concluderà con un’azienda che sceglie uno strato sottile e l’altra che ne costruisce uno spesso. Entrambe stanno già aggiungendo e rimuovendo componenti man mano che modelli e attività evolvono.
Il vantaggio duraturo andrà ai team capaci di misurare rapidamente questi cambiamenti. Sapranno quali vincoli continuano a prevenire i fallimenti e quali, invece, si limitano a preservare ipotesi nate con un modello precedente.
Per chiunque distribuisca agenti, l’azione immediata è semplice: testare insieme modello e harness, esaminare le tracce reali e definire il successo prima di concedere maggiore autonomia. Modelli più potenti modificano il confine dell’ingegneria, ma non eliminano la necessità di individuarlo.
