Due settimane che hanno chiuso il dibattito sull’harness (e ne hanno aperto uno più grande) Two Weeks That Settled the Harness Debate (And Opened a Bigger One)

Cosa è successo

Il 31 marzo l’intero sorgente TypeScript di Claude Code v2.1.88 è finito per errore sul registry npm. 512.000 righe. Quando Anthropic l’ha rimosso, il file era già sul disco di ogni ricercatore.

Nel giro di dieci giorni sono conversi tre eventi.

Un gruppo della Mohamed bin Zayed University of Artificial Intelligence ha pubblicato su arXiv un’analisi di 46 pagine condotta direttamente sul sorgente. Il risultato principale: solo l’1,6% della codebase di Claude Code è quella che gli autori chiamano “logica decisionale AI”. Il restante 98,4% è harness operativo. Sistemi di permessi con sette modalità e un classificatore ML. Una pipeline di compattazione a cinque livelli per la gestione del contesto. Quattro meccanismi di estensibilità. Isolamento dei sub-agenti. Storage di sessione append-only. Difesa in profondità, sicurezza a strati, recupero controllato.

La stessa settimana Garry Tan ha pubblicato Thin Harness, Fat Skills. La tesi: ogni riga di logica che mettete nell’harness è ragionamento che togliete al modello. Spostate il giudizio sfumato dentro skill in markdown. Spostate le operazioni deterministiche dentro il codice. Tenete l’harness sottile, solo il loop. L’articolo ha superato il milione di visualizzazioni.

Era una replica a Your Harness, Your Memory di Harrison Chase, che sosteneva una forma diversa: harness ricco, con pianificazione, spawn di sub-agenti, middleware e hook, di proprietà del runtime.

Tre voci indipendenti, tutte convergenti sulla stessa parola. Ciascuna che lavora su un ambito diverso, ed è questa la parte a cui vale la pena prestare attenzione.

È la conversazione che porto avanti da due anni con i CTO enterprise europei. È appena diventata pubblica.

Una premessa prima dell’analisi

Prima di andare avanti, due dichiarazioni.

Sono un utente di gstack. Come founder che deve spedire in fretta, uso il setup di Tan. Gli ingranaggi cognitivi, gli slash command, i contesti ritagliati sui ruoli: quando scrivo codice a mezzanotte su FairMind stessa, è a questo che ricorro. Il framework fa esattamente quello che promette, e le stelle su GitHub non sono un caso.

Uso LangChain Deep Agents dal primo giorno. Quando Chase l’ha rilasciato l’ho provato nella stessa settimana. È stata una boccata d’aria fresca per quel tipo di prodotti ad agenti che hanno bisogno di orchestrazione ricca già pronta. Architettura davvero intelligente, e l’approccio runtime-owned risolve problemi che i loop sottili non riescono a raggiungere.

Quello che segue non è una critica a nessuno dei due framework. È il punto di vista di un quarto ambito, scritto da qualcuno che usa entrambi gli strumenti negli ambiti per cui sono stati progettati, e costruisce qualcosa di diverso nell’ambito per cui non lo sono.

Tre definizioni, tre ambiti

Mettete le tre posizioni una accanto all’altra e viene fuori uno schema.

Chase sostiene un harness ricco, pensato per chi costruisce prodotti ad agenti. LangChain Deep Agents mette pianificazione, memoria, hook e middleware dentro il runtime. Il modello riceve assistenza. L’harness possiede l’orchestrazione. Per chi integra agenti in prodotti con UX personalizzata e flussi cross-tool, è la forma giusta, e dal giorno in cui Deep Agents è uscito ci sto costruendo sopra.

Tan sostiene un harness sottile, pensato per il founder solo che deve spedire in fretta. gstack e gbrain spingono tutto all’esterno. Le skill in markdown. Il codice deterministico dentro funzioni. L’harness legge i file; non li possiede. Modelli come Opus 4 e GPT-5 non hanno bisogno di essere imboccati; hanno bisogno di stanze pulite. Per un singolo ingegnere che produce 10.000 righe al giorno, questa architettura è difficile da battere. La uso quotidianamente.

Il paper MBZUAI documenta un harness graduato dentro uno strumento da riga di comando. Claude Code non è né sottile né spesso. È stratificato. Sette stadi di permessi, cinque livelli di compattazione, quattro meccanismi di estensione a costi di contesto diversi. L’harness è costruito attorno a un principio che gli autori chiamano “valori invece di regole”: investire in infrastruttura deterministica che lasci al modello la libertà di decidere entro condizioni delimitate. Per una CLI usata da uno sviluppatore alla volta su un repository alla volta, questo design è rigorosamente motivato.

Sono tre soluzioni diverse perché sono tre problemi diversi. Tan ottimizza la velocità del founder. Chase ottimizza la superficie di prodotto per sviluppatori. Il paper analizza uno strumento ottimizzato per le sessioni di coding individuali. Nessuno dei tre sbaglia, dentro il proprio ambito.

Il quarto ambito che vorrei aggiungere è l’SDLC enterprise: 200 ingegneri, più repository, cinque milioni di righe di codice legacy, compliance, governance e un’architettura che non è stata pensata per gli agenti. Non è una versione più sottile o più spessa di nessuna delle tre precedenti. È un deployment diverso, e i principi vanno tradotti, non trapiantati.

Che aspetto ha la traduzione

Tan, Chase e gli autori MBZUAI stanno facendo scelte solide per i rispettivi ambiti. Portare le stesse idee in enterprise genera problemi che loro non stavano affrontando, perché i loro ambiti non lo richiedevano.

Prendiamo le skill in markdown. È la scelta giusta quando chi scrive la skill e chi la usa sono la stessa persona. Tan scrive una skill per sé; ne è responsabile. Traducete la stessa cosa in un’organizzazione da 200 ingegneri e la domanda cambia: chi scrive la skill che tocca lo strato di autenticazione, chi la approva, chi la possiede quando l’architetto capo se ne va, qual è la policy di deprecazione. La skill non è più giudizio sfumato catturato da una persona; è conoscenza governata, con un ciclo di vita. Il principio (il markdown batte il middleware per il ragionamento sfumato) sopravvive alla traduzione. L’infrastruttura attorno cambia forma.

Prendiamo il codice deterministico per il resto. Tan ha ragione: le parti che devono essere corrette ogni volta vanno scritte come funzioni, non come prompt. In un progetto greenfield la funzione la scrivete. In una codebase brownfield con dodici anni di decisioni architetturali, metà non documentate, dovete prima scoprire i vincoli, poi codificarli, poi assicurarvi che ogni agente che tocca quella parte li rispetti. Lo strato deterministico c’è ancora; deve solo assorbire l’architettura esistente prima di poter imporre comportamenti nuovi.

Prendiamo il loop sottile che legge i file. Funziona alla perfezione per un agente. Fatene girare cinque specializzati in parallelo, ciascuno su uno strato diverso dello stesso sistema, e il loop da solo non riesce a coordinarli. Lo stato deve vivere da qualche parte. O ingrassate l’harness perché possieda il coordinamento (ed è anche per questo che Deep Agents ha preso la direzione runtime-rich per i casi d’uso di prodotto), oppure costruite uno strato di orchestrazione separato sopra i loop sottili. Il principio (tenete semplice il loop) sopravvive. Il sistema attorno cresce.

Prendiamo i valori invece delle regole. Il paper MBZUAI lo documenta magnificamente per una CLI monoutente. In un’azienda con obblighi normativi, i “valori” da soli non bastano: GDPR, AI Act e requisiti di audit impongono che alcune decisioni siano espresse come regole leggibili da un revisore. L’harness mantiene lo strato dei valori e aggiunge uno strato esplicito di governance di cui il sistema analizzato dal paper non aveva bisogno.

Niente di tutto questo contraddice i tre framework. Li estende a un contesto di deployment in cui compaiono vincoli nuovi.

Quattro pilastri, calibrati sul contesto

Abbiamo passato due anni a costruire tutto questo per clienti enterprise europei. Il framework a cui siamo arrivati sono quattro pilastri, ciascuno calibrato sul contesto di deployment.

Il context engineering è lo strato che Tan chiamerebbe skill, più quello che noi chiamiamo Project Context: un gemello digitale della codebase che gli agenti leggono ma non possiedono. Nei setup da singolo sviluppatore sono markdown più git, e gstack lo gestisce con eleganza. In una codebase legacy da 5 milioni di righe è un knowledge graph strutturato che cattura dipendenze, vincoli e storia alla granularità del file. Stesso principio, infrastruttura diversa.

I vincoli architetturali sono meccanici, non suggeriti nel prompt. Linter, layer di dipendenze, gate di CI, validazione della build. Nel mondo di Tan vivono nel codice deterministico. In enterprise vivono in una descrizione dell’architettura che ogni agente legge prima di agire e contro cui ogni modifica viene validata. Non una gabbia: una forzatura utile. L’agente diventa più veloce perché lo spazio di ricerca è più piccolo e il vincolo intercetta gli errori prima che si propaghino.

I feedback loop sono il modo in cui l’harness verifica quello che l’agente ha prodotto. Per un singolo sviluppatore sono test rapidi e autocorrezione nella stessa sessione. In enterprise si estendono ad ambienti di staging, scansioni di sicurezza, regressioni di performance, controlli di compliance. Il loop è più lento, ma il costo di saltarlo è più alto.

La garbage collection è il pilastro di cui ho visto discutere meno. Il codice generato dall’AI si accumula più in fretta di quanto la review umana riesca a ripulirlo. In un sistema da singolo sviluppatore fate /retro e rifattorizzate a mano, e gstack lo fa bene. In enterprise vi serve un processo continuo che rilevi duplicazioni, derive e codice orfano introdotto dagli agenti stessi. Senza, il guadagno di produttività diventa un debito che si compone tra i team.

Questi quattro non sono intercambiabili. Rendetene uno troppo spesso e mettete un tetto al modello. Rendetene uno troppo sottile e perdete una rete di sicurezza che quel deployment richiede. La risposta giusta è graduata, calibrata sul contesto ed esplicita su quale vincolo protegge cosa.

Cosa ha colto il paper

L’analisi MBZUAI di Claude Code è il documento più rigoroso che abbiamo sull’architettura di un agente di coding in produzione. Il rapporto 1,6% / 98,4% è un numero su cui vale la pena fermarsi. La pipeline di compattazione a cinque livelli è davvero elegante. Il modello di permessi deny-first con sette modalità è la risposta giusta per uno strumento da riga di comando che gira sulla macchina di uno sviluppatore.

Quello che il paper riconosce nella Sezione 12 sulle direzioni future è che “lo spazio delle combinazioni interessanti di harness non si restringe man mano che i modelli migliorano. Si sposta.” Gli autori citano il team di ingegneria di Anthropic su questo punto. Contesti di deployment diversi producono harness diversi. Il paper confronta Claude Code con OpenClaw, un gateway multicanale per assistenti personali, e mostra che le stesse domande ricorrenti su sicurezza, contesto ed estensibilità producono risposte architetturali diverse.

Quel confronto è la chiave di lettura più utile per quello che sta succedendo adesso in pubblico. La velocità del founder solo è un deployment. La superficie di prodotto per sviluppatori è un altro. La sessione di coding da CLI è un terzo. L’SDLC enterprise con legacy e compliance è un quarto. Ognuno produrrà un harness modellato dai propri vincoli. La conversazione si sta muovendo verso una tassonomia, non verso una risposta unica.

Cosa viene adesso

Da due anni ripeto che il modello è una commodity e l’harness è il vantaggio competitivo. La reazione era di solito un consenso educato, a volte scetticismo. Nelle ultime due settimane un paper accademico, il presidente di YC e il fondatore di LangChain hanno detto in pubblico varianti della stessa cosa, dai palchi più grandi che hanno.

La conversazione si è spostata. Il dibattito non è più se l’harness conti. È che forma debba prendere nel vostro specifico contesto di deployment.

Per i founder soli la risposta di Tan è giusta e i dati gli danno ragione. Uso il suo framework. Per i team che fanno prodotti per sviluppatori, l’approccio runtime-rich di Chase ha senso quando la superficie lo giustifica. Costruisco con Deep Agents dal primo giorno. Per le sessioni di coding da CLI, l’architettura graduata documentata in Claude Code è il riferimento rigoroso. Per l’SDLC enterprise con sistemi legacy, compliance e agenti specializzati orchestrati, la risposta sono quattro pilastri, calibrati sul contesto, con governance esplicita.

Se state portando gli agenti dentro un’organizzazione di ingegneria da 200 persone, “sottile o spesso” è un ingrediente della vostra decisione, non la decisione. La domanda è: quale pilastro protegge cosa, e quanto spesso deve essere ciascuno per il vostro specifico deployment.

Quella conversazione è appena iniziata. Vale la pena farla in pubblico, come sta ora avvenendo per la precedente.

Riferimenti

Garry Tan, Thin Harness, Fat Skills: x.com/garrytan/status/2042925773300908103

Harrison Chase, Your Harness, Your Memory: x.com/hwchase17/status/2042978500567609738

Jiacheng Liu, Xiaohan Zhao, Xinyi Shang, Zhiqiang Shen, Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems, arXiv:2604.14228: arxiv.org/pdf/2604.14228

What Just Happened

On March 31, the entire TypeScript source of Claude Code v2.1.88 was published to the npm registry by mistake. 512,000 lines. By the time Anthropic pulled it, the file was on every researcher’s disk.

Within ten days, three things converged.

A team at the Mohamed bin Zayed University of Artificial Intelligence published a 46-page source-level analysis on arXiv. Their headline finding: only 1.6% of Claude Code’s codebase is what they call “AI decision logic.” The other 98.4% is the operational harness. Permission systems with seven modes and an ML classifier. A five-layer compaction pipeline for context management. Four extensibility mechanisms. Subagent isolation. Append-only session storage. Defense in depth, layered safety, graceful recovery.

The same week, Garry Tan published Thin Harness, Fat Skills. The thesis: every line of logic you put in the harness is reasoning you take away from the model. Push fuzzy judgment into markdown skills. Push deterministic operations into code. Keep the harness thin, just the loop. The article hit a million views.

It was a counter to Harrison Chase’s Your Harness, Your Memory, which had argued for a different shape: rich harness with planning, sub-agent spawning, middleware, hooks, owned by the runtime.

Three independent voices, all converging on the same word. Each working in a different scope, and that is the part worth paying attention to.

This is the conversation I have been having for two years with European enterprise CTOs. It just went public.

A Note Before the Analysis

Before going further, two disclosures.

I am a gstack user. As a founder shipping fast, I run Tan’s setup. The cognitive gears, the slash commands, the role-scoped contexts: when I am writing code at midnight on FairMind itself, this is what I reach for. The framework works exactly as advertised, and the GitHub stars are not an accident.

I have been using LangChain Deep Agents since day one. When Chase shipped it, I tried it the same week. It was a breath of fresh air for the kind of agent products that need rich orchestration out of the box. Genuinely clever architecture, and the runtime-owned approach solves problems that thin loops cannot reach.

What follows is not a critique of either framework. It is the view from a fourth scope, written by someone who uses both tools in the scopes they were designed for, and builds something different in the scope they were not.

Three Definitions, Three Scopes

Read the three positions side by side and a pattern shows up.

Chase argues for a rich harness aimed at developers building agent products. LangChain Deep Agents put planning, memory, hooks, and middleware inside the runtime. The model gets help. The harness owns orchestration. For developers wiring agents into products with custom UX and cross-tool flows, this is the right shape, and from the day Deep Agents shipped I have been building with it.

Tan argues for a thin harness aimed at the single founder shipping fast. gstack and gbrain push everything out. Skills in markdown. Deterministic code in functions. The harness reads files; it doesn’t own them. Models like Opus 4 and GPT-5 don’t need babysitting; they need clean rooms. For one engineer producing 10,000 lines a day, this architecture is hard to beat. I run it daily.

The MBZUAI paper documents a graduated harness in a CLI tool. Claude Code is neither thin nor fat. It is layered. Seven permission stages, five compaction shapers, four extension mechanisms at different context costs. The harness is built around a principle the authors call “values over rules”: invest in deterministic infrastructure that lets the model decide freely within bounded conditions. For a CLI used by one developer at a time on one repo, this design is rigorously justified.

These are three different solutions because they are three different problems. Tan is optimizing founder velocity. Chase is optimizing developer product surface. The paper analyzes a tool optimized for individual coding sessions. None of them is wrong inside its own scope.

The fourth scope I’d like to add is enterprise SDLC: 200 engineers, multiple repos, five million lines of legacy code, compliance, governance, and an architecture that was not designed with agents in mind. This is not a thinner or fatter version of any of the three above. It is a different deployment, and the principles need to be translated, not transplanted.

What Translation Looks Like

Tan, Chase, and the MBZUAI authors are each making sound calls for their scopes. Carrying the same ideas across to enterprise produces problems they were not addressing, because their scopes did not require them to.

Take skills in markdown. This is the right call when the skill author and the skill consumer are the same person. Tan writes a skill for himself; he is accountable for it. Translate this to a 200-engineer organization and the question changes: who writes the skill that touches the auth layer, who approves it, who owns it when the lead architect leaves, what is the deprecation policy. The skill is no longer fuzzy judgment captured by one person; it is governed knowledge with a lifecycle. The principle (markdown beats middleware for fuzzy reasoning) survives the translation. The infrastructure around it changes shape.

Take deterministic code for the rest. Tan is right: the parts that need to be correct every time should be functions, not prompts. In a greenfield project, you write the function. In a brownfield codebase with twelve years of architectural decisions, half undocumented, you have to discover the constraints first, encode them, and ensure every agent that touches that part of the codebase respects them. The deterministic layer is still there; it just has to absorb existing architecture before it can enforce new behavior.

Take the thin loop that reads files. This works perfectly for one agent. Run five specialized agents in parallel, each working on a different layer of the same system, and the loop alone cannot coordinate them. State has to live somewhere. Either you fatten the harness to own coordination (which is part of why Deep Agents went the runtime-rich direction for product use cases), or you build a separate orchestration layer above the thin loops. The principle (keep the loop simple) survives. The system around it grows.

Take values over rules. The MBZUAI paper documents this beautifully for a single-user CLI. In an enterprise with regulatory obligations, “values” alone is insufficient: GDPR, AI Act, and audit requirements force some decisions to be expressed as rules an auditor can read. The harness keeps the values layer, and adds an explicit governance layer the paper’s analyzed system did not need to have.

None of this contradicts the three frameworks. It extends them into a deployment context where new constraints appear.

Four Pillars, Calibrated to Context

We have spent two years building this for European enterprise clients. The framework we ended up with is four pillars, each calibrated to the deployment context.

Context engineering is the layer Tan would call skills, plus what we call Project Context: a digital twin of the codebase that the agents read but do not own. In single-developer setups, this is markdown plus git, and gstack handles it elegantly. In a 5-million-line legacy codebase, it is a structured knowledge graph that captures dependencies, constraints, and history at file granularity. Same principle, different infrastructure.

Architectural constraints are mechanical, not prompted. Linters, dependency layers, CI gates, build validation. In Tan’s world, these live in deterministic code. In enterprise, they live in an architecture description that every agent reads before acting and every change is validated against. Not a cage, a forcing function. The agent gets faster because the search space is smaller and the constraint catches errors before they propagate.

Feedback loops are how the harness verifies what the agent produced. For a single developer, this is fast tests and self-correction in the same session. For enterprise, it extends to staging environments, security scans, performance regressions, compliance checks. The loop is slower, but the cost of skipping it is higher.

Garbage collection is the pillar I have not seen discussed enough. AI-generated code accumulates faster than human review can clean it. In a single-developer system, you /retro and refactor manually, and gstack does this well. In enterprise, you need a continuous process that detects duplication, drift, and orphaned code introduced by the agents themselves. Without it, the productivity gain becomes a debt that compounds across teams.

These four are not interchangeable. Make any one too thick and you cap the model. Make any one too thin and you lose a safety net the deployment requires. The right answer is graduated, calibrated to context, and explicit about which constraint protects what.

What the Paper Got Right

The MBZUAI analysis of Claude Code is the most rigorous document we have on the architecture of a production coding agent. The 1.6% / 98.4% ratio is a number worth sitting with. The five-layer compaction pipeline is genuinely elegant. The deny-first permission model with seven modes is the right answer for a CLI tool that runs on a developer’s machine.

What the paper acknowledges in its Section 12 on future directions is that “the space of interesting harness combinations does not shrink as models improve. It moves.” The authors quote Anthropic’s own engineering team on this. Different deployment contexts produce different harnesses. The paper compares Claude Code against OpenClaw, a multi-channel personal assistant gateway, and shows that the same recurring questions about safety, context, and extensibility produce different architectural answers.

That comparison is the most useful frame for what is happening right now in public. Single-founder velocity is one deployment. Developer product surface is another. CLI coding session is a third. Enterprise SDLC with legacy and compliance is a fourth. Each will produce a harness shaped by its own constraints. The conversation is moving toward a taxonomy, not a single answer.

What Comes Next

For two years I have been saying the model is commodity and the harness is the moat. The reaction was usually polite agreement, sometimes skepticism. In the last two weeks, an academic paper, the YC president, and the founder of LangChain all said variants of the same thing in public, on the largest stages they have.

The conversation moved. The debate is no longer whether the harness matters. It is what shape it should take in your specific deployment context.

For single founders, Tan’s answer is right and the data backs him. I use his framework. For developer product teams, Chase’s runtime-rich approach has merit when the surface area justifies it. I have been building with Deep Agents from day one. For CLI coding sessions, the graduated architecture documented in Claude Code is the rigorous reference. For enterprise SDLC with legacy systems, compliance, and orchestrated specialized agents, the answer is four pillars, calibrated to context, with explicit governance.

If you are building agents into a 200-person engineering org, “thin vs fat” is one input to your decision, not the decision itself. The question is: which pillar protects what, and how thick does each one need to be for your specific deployment.

That conversation is just starting. Worth having in public, the way the previous one is now being had.

References

Garry Tan, Thin Harness, Fat Skills: x.com/garrytan/status/2042925773300908103

Harrison Chase, Your Harness, Your Memory: x.com/hwchase17/status/2042978500567609738

Jiacheng Liu, Xiaohan Zhao, Xinyi Shang, Zhiqiang Shen, Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems, arXiv:2604.14228: arxiv.org/pdf/2604.14228