Ho programmato con l'IA per tutto l'ultimo anno. Non solo prompt: ho costruito software vero. Due progetti open-source: GStack, che migliora gli agenti di coding IA, e GBrain, che trasforma tutto ciò che leggi e scrivi in una knowledge base ricercabile utilizzabile dalla tua IA. Insieme, circa 970.000 righe di codice e 665 file di test. Praticamente tutto scritto da Claude Code e Codex sotto la mia direzione (15 sessioni Conductor simultanee la maggior parte del tempo).
La settimana scorsa ho unito quattordici pull request in 72 ore. Quasi 29.000 righe di nuovo codice. Ogni rilascio era meglio testato del precedente.
Dovrebbe essere impossibile. Si suppone che velocità e qualità siano in contrapposizione. Rilascia in fretta, rompi le cose. Vai piano, rilascia bene. Scegli.
Non devi più scegliere. La chiave è la copertura dei test al 90% — e gli agenti IA l'hanno resa gratuita. Per cinquant'anni, quel livello di verifica è costato troppa forza di volontà umana per essere sostenuto. Ora l'agente scrive i test insieme al codice. Il risultato è ciò che chiamo il complexity ratchet: un sistema che può solo migliorare, mai peggiorare.
(Questo è il settimo di una serie sul costruire con l'IA: 1 2 3 4 5 6
Il software era fragile
Per cinquant'anni, l'intera disciplina dell'ingegneria del software è stata organizzata attorno a un'idea: prevenire gli errori, perché gli errori sono catastrofici.
Dovevi scrivere il codice giusto al primo colpo. Ti perdevi un caso limite e andavi in crash in produzione. Rilasciavi una migrazione di database sbagliata e perdevi i dati dei clienti. Scrivevi una funzione che faceva qualcosa di sottile, e quando l'unica persona che la capiva se ne andava, nessuno sapeva perché funzionasse. L'intero sistema dipendeva da esseri umani attenti, e gli esseri umani non sono attenti. Così abbiamo costruito processi elaborati — revisioni del codice, ambienti di staging, team di QA, treni di rilascio — tutti progettati per catturare gli errori prima che raggiungessero gli utenti.
In un certo senso funzionava. Ma era lento. E significava che la complessità di qualsiasi sistema software aveva un tetto duro: il numero di cose che un singolo team poteva tenere a mente contemporaneamente.
Ora il software è malleabile
Non intendo sciatto. Intendo resiliente in un modo che prima non era possibile.
Quando dico "i modelli sono qui", intendo che gli agenti di coding IA — Claude, GPT, Codex e l'ecosistema che cresce attorno a loro — ora possono leggere codice, comprendere il contesto, diagnosticare errori e scrivere correzioni. Non perfettamente. Ma abbastanza bene che il modello di errore per il software è cambiato.
La migrazione si rompe? L'agente legge il messaggio di errore, capisce la storia dello schema del database attraverso 45 versioni, scrive la correzione, scrive il test. La sincronizzazione dei file si blocca su un milione di symlink? L'agente diagnostica il timeout del parser, lo limita a 30 secondi, rilascia la correzione con i test. Una pipeline di estrazione ha un bug di attribuzione? Una valutazione cross-model lo rileva, il prompt viene iterato, l'applicazione viene aggiunta a livello di database.
Per la maggior parte degli errori a livello di codice — bug logici, fallimenti di parsing, casi limite rotti — gli agenti ora possono diagnosticarli e risolverli al turno successivo. Questo è genuinamente nuovo. Gli errori che rimangono catastrofici sono quelli che distruggono lo stato: migrazioni sbagliate sui dati di produzione, falle di sicurezza sfruttate prima del rilevamento, fughe di privacy che non possono essere annullate. Il ratchet aiuta anche qui (i buoni test catturano la maggior parte di questi prima della produzione), ma il vero cambiamento è che la stragrande maggioranza degli errori in un codebase sono del tipo risolvibile.
Questa è una transizione di fase per come viene costruito il software. Ma funziona solo se hai il ratchet.
Il *Complexity Ratchet* dell'Agente
Un ratchet (cricchetto) è un meccanismo che permette il movimento in una sola direzione. Una chiave a cricchetto gira un bullone in avanti e impedisce che torni indietro. Questa è la metafora.
Nel software codificato da agenti, ogni sessione di coding con un agente IA aggiunge tre cose al codebase:
- Test che codificano cosa significa "corretto" — controlli automatizzati che vengono eseguiti ogni volta che qualcuno modifica il codice e falliscono rumorosamente se la modifica rompe qualcosa
- Documentazione che registra perché sono state prese le decisioni — non solo cosa fa il codice, ma il ragionamento e i compromessi dietro di esso
- Risultati di valutazione che stabiliscono soglie di qualità — valutazioni strutturate della qualità dell'output con punteggi, così sai se la versione successiva è migliore o peggiore
La prossima volta che un agente lavora sul codebase, carica tutti e tre nel suo contesto (il testo che l'IA può vedere e su cui ragionare). Non può regredire al di sotto della suite di test — i test fallirebbero. Non può ignorare la documentazione — è proprio lì nel contesto. Non può rilasciare qualità al di sotto della baseline di valutazione — i punteggi sono registrati.
Il pavimento di qualità sale ad ogni turno. Movimento solo in avanti. Questo è il ratchet.
Come appare in pratica
Lo rendo concreto. GBrain è un sistema di conoscenza che sto costruendo — dà agli agenti IA una memoria a lungo termine memorizzando, indicizzando e cercando attraverso appunti, riunioni, conversazioni e ricerche di una persona. Pensalo come un secondo cervello che il tuo assistente IA può effettivamente leggere.
Una delle sue caratteristiche è l'estrazione epistemologica: legge migliaia di pagine ed estrae chi crede cosa, con quale confidenza, nel tempo. "Garry pensa che Bitcoin raggiungerà $300K (confidenza: 0.45)." "Jared pensa che questa startup abbia una forte retention (confidenza: 0.80)." Così, ma su 28.000 pagine.
La prima esecuzione di estrazione ha estratto 100.720 affermazioni. Ho usato una valutazione cross-model per valutare la qualità — ho fatto valutare l'output indipendentemente da GPT-5.5 e Claude. Complessivamente: 6.8 su 10.
Il problema più grande? Qualcosa che chiamo confusione del detentore. Prendi l'affermazione "L'IA sostituirà l'80% degli ingegneri software entro il 2027." Chi detiene quella convinzione? È la persona che l'ha scritta? È qualcuno che stanno citando? O è il motore di analisi del sistema, che l'ha dedotta da una trascrizione di podcast? La versione 1 sbagliava questa distinzione il 35% delle volte. Questo è importante — se stai costruendo un sistema che traccia ciò che le persone credono, devi sapere CHI lo crede.
Così i risultati della valutazione sono stati documentati. Sei specifiche modalità di fallimento sono state identificate. Il prompt della versione 2 ha affrontato tutte e sei. L'arrotondamento dei pesi (i punteggi di confidenza) è stato imposto a livello di database — niente più falsa precisione come 0.74 quando 0.75 è la risposta onesta. Diciassette test hanno bloccato il contratto.
Ora nessuna versione futura dell'estrazione può essere rilasciata senza che quei 17 test siano superati. Nessuno deve ricordare perché l'arrotondamento dei pesi è importante o cosa sia la confusione del detentore. I test lo ricordano.
Il pavimento di qualità è salito permanentemente. Questo è un giro del ratchet.
Perché la maggior parte dei progetti *vibecoded* muore
"Vibecoding" è il termine di Andrej Karpathy per programmare con l'IA descrivendo ciò che vuoi in linguaggio naturale e lasciando che il modello generi il codice. È potente ed è così che costruisco io. Ma da ciò che ho visto nelle applicazioni YC e nei repository open-source, la maggior parte dei progetti vibecoded che saltano i test iniziano a crollare una volta raggiunta una complessità moderata — poche migliaia di righe, una manciata di funzionalità interagenti.
Saltano il ratchet. Niente test, niente documentazione, niente valutazioni. L'agente aggiunge complessità ma nulla impedisce la regressione. Ogni nuova funzionalità ha la possibilità di romperne una vecchia, e senza test, non lo scopri finché un utente non lo segnala. Entro la versione 0.5 il codebase è una casa infestata dove ogni modifica rompe qualcosa di inaspettato. Poi lo sviluppatore scrive un post sul blog su come il coding IA non funziona.
Il coding IA funziona benissimo. Semplicemente non hanno costruito il ratchet.
Si potrebbe sostenere che il tipo di persona che scrive test è anche il tipo che scrive una buona architettura in primo luogo. Giusto. Ma il meccanismo del ratchet non riguarda la persona — riguarda ciò che accade al turno successivo. Quando un nuovo contributore apre una PR, o quando una versione del modello cambia, o quando stai programmando alle 2 del mattino e il tuo giudizio è compromesso, i test catturano le regressioni indipendentemente da chi le ha scritte. Il ratchet funziona anche quando l'umano non è al meglio. Questo è il punto.
Senza test, il miglioramento è un processo rumoroso — gli agenti cercano di migliorare le cose, ma senza segnali di regressione, i cambiamenti buoni e quelli cattivi sono ugualmente invisibili. Con una suite di test densa, ottieni un ratchet sulla superficie testata: la qualità può solo aumentare per i comportamenti che hai codificato. Questa è la maggior parte del sistema, non tutto. Ma è abbastanza per sostenere il movimento in avanti alla velocità.
I test come memoria istituzionale
Nelle aziende software tradizionali, la memoria istituzionale vive negli umani. L'ingegnere senior che sa perché esiste quel livello di caching. L'architetto che ricorda la migrazione che ha quasi distrutto il database. Il tech lead che può spiegare lo strano caso limite nel sistema di fatturazione.
Gli umani se ne vanno. Vanno in pensione, vengono sottratti, si esauriscono. Quando se ne vanno, la conoscenza va con loro. Ogni azienda software ha avuto l'esperienza di aprire un file critico e trovare un commento che dice // NON MODIFICARE QUESTO — chiedi a Dave e Dave se n'è andato tre anni fa.
Il contesto dell'agente non si dimette. Non viene sottratto. Non dimentica. Quando la suite di test codifica "l'arrotondamento dei pesi deve usare incrementi di 0.05" e la documentazione spiega "perché la valutazione cross-model ha mostrato che la falsa precisione degrada la fiducia nei punteggi di confidenza", quella conoscenza è durevole. Qualsiasi agente, qualsiasi modello, in qualsiasi momento può caricare quel contesto e comprendere il vincolo.
I test sono memoria istituzionale che sopravvive al turnover dei dipendenti. Per un progetto di una singola persona, sono ancora più critici — sono l'unica memoria istituzionale che hai.
Tutto ciò che è imbrigliabile è testabile
Il ratchet non funziona solo per il codice tradizionale. Funziona per tutto ciò che un computer può osservare.
Pensa ai livelli di un sistema moderno. Il sistema operativo ti dà alberi di processi, stato del filesystem, socket di rete, pianificazioni cron. Il terminale ti dà ogni tasto premuto, ogni riga di output, ogni prompt interattivo. Il browser ti dà pagine renderizzate, stati dei pulsanti, eventi di navigazione. Le API ti danno risposte strutturate che puoi analizzare e validare. E gli agenti IA ti danno comportamento osservabile — cosa dicono, quali strumenti chiamano, in quale ordine fanno le cose, se chiedono prima di agire.
Tutti questi sono imbrigliabili. E se puoi imbrigliarlo, puoi osservarlo. Se puoi osservarlo, puoi fare asserzioni su di esso. Se puoi fare asserzioni, puoi applicare il ratchet.
Questa è un'area di superficie molto più ampia dei tradizionali test unitari. Lascia che ti mostri.
GStack è il mio framework open-source per agenti di coding — 93.000 stelle GitHub, 701.000 righe di codice, 46 skill. Una delle sue caratteristiche principali è la revisione interattiva del piano: gli chiedi di rivedere la tua architettura, e lui esamina il piano sezione per sezione, facendo domande, sondando i casi limite, sfidando le tue ipotesi. Come avere un engineering manager che legge effettivamente il codice.
Il problema: Claude Code a volte saltava l'intera parte interattiva. Leggeva il file del piano, scaricava tutti i risultati in un colpo solo e usciva — senza fare una singola domanda all'utente. L'intero scopo della revisione è il dialogo avanti e indietro. Saltarlo vanifica lo scopo.
Come si testa anche solo questo? Non puoi fare un test unitario su "l'IA ha avuto una conversazione." Nessun framework di test tradizionale copre questo.
Così ho usato la funzionalità TTY di Bun per costruire un test harness (PR #1354) che letteralmente genera Claude Code all'interno di un pseudo-terminale, gli fornisce uno scenario di repository specifico, attiva la skill di revisione e osserva l'output del terminale in tempo reale. Il test osserva se l'agente lancia una domanda interattiva prima di finire. Se scarica i risultati ed esce senza chiedere nulla, il test fallisce.
Questo non è testare il codice. Questo è testare se un agente IA segue un contratto comportamentale. A livello TTY. Osservandolo letteralmente mentre lavora.
La risposta del ratchet è stata a tre livelli:
- Cancelli STOP nelle istruzioni della skill — regole esplicite che dicono "DEVI chiedere all'utente prima di procedere alla sezione successiva", con clausole anti-razionalizzazione che nominano la specifica modalità di fallimento in modo che il modello non possa convincersi a saltare
- Clausola anti-scorciatoia — "il file del piano è l'OUTPUT della revisione interattiva, non un suo sostituto." Una frase che chiude l'esatta scappatoia che il modello continuava a sfruttare.
- Test del pavimento a livello di cancello — i test del TTY harness che generano Claude Code in scenari controllati e falliscono se l'agente non fa almeno una domanda interattiva
Ora quando Anthropic rilascia una nuova versione del modello, o quando cambio un prompt di una skill, la suite di test cattura qualsiasi regressione nel contratto interattivo. L'agente non può smettere silenziosamente di fare domande. Il test osserva il terminale e controlla.
O prendi la PR #880, che ha rilasciato un nuovo plugin OpenClaw. Il test non controlla solo che il codice compili. Costruisce il plugin dal sorgente, genera una vera istanza di OpenClaw in un profilo isolato, installa il plugin tramite CLI, esegue plugins inspect per verificare che il runtime lo abbia caricato, imposta lo slot di configurazione, valida la configurazione ed esegue plugins doctor per confermare zero diagnostiche. Un percorso completo end-to-end attraverso due programmi separati. 359 righe di codice di test. Il tipo di test che un umano non scriverebbe quasi mai a mano perché la configurazione è troppo noiosa. Claude lo ha scritto in circa cinque minuti. Questo è il muro dello sforzo che scompare in tempo reale.
Il principio si generalizza. Puoi testare a livello di sistema operativo: la migrazione ha creato le tabelle giuste, il cron job è partito, il processo è ancora vivo? A livello di browser: la pagina è stata renderizzata, l'agente ha compilato correttamente il modulo. A livello di API: il modello ha restituito JSON valido con lo schema giusto. A livello comportamentale: l'agente ha seguito il protocollo, ha chiesto prima di cancellare, si è fermato quando gli è stato detto di fermarsi.
L'intero stack è testabile. Il ratchet si applica a tutto. La maggior parte delle persone non lo ha ancora realizzato perché stanno ancora pensando alla copertura dei test come "la mia funzione ha restituito il numero giusto." La vera superficie di test è tutto ciò che il computer può vedere.
Il numero 90%
Quindi cosa ti compra effettivamente una copertura dei test del 90%?
Capers Jones ha studiato oltre 10.000 progetti software e misurato l'efficienza di rimozione dei difetti (DRE) — la percentuale di bug catturati prima che raggiungano gli utenti. I suoi dati da Applied Software Measurement mostrano una curva non lineare: al di sotto del 70% di copertura, la DRE si aggira intorno al 65-75%. All'85-95% di copertura, la DRE sale al 92-97%. La relazione non è lineare. C'è un ginocchio nella curva intorno all'85% dove le fughe di difetti diminuiscono drasticamente.
L'industria aeronautica lo ha capito decenni fa. DO-178C, lo standard FAA per il software critico per il volo, richiede la copertura delle condizioni/decisioni modificate (MC/DC) per i sistemi di Livello A — quelli in cui un bug significa un incidente aereo. La sola copertura dei rami perde il 10-20% dei guasti. MC/DC, che è più severa della copertura delle righe, raggiunge >99% di DRE. Non lo impongono perché ai burocrati piace la burocrazia. Lo impongono perché i dati hanno mostrato che al di sotto di certe soglie di copertura, i difetti critici scappano a tassi incompatibili con il non uccidere persone.
Il parallelo con l'ingegneria dell'affidabilità è pulito. Le fabbriche usano un sistema chiamato Six Sigma per misurare la qualità. L'idea: conta quanti difetti ottieni per milione di unità prodotte, poi esprimilo come "livello sigma" — sigma più alto significa meno difetti. Un processo a 3 sigma produce circa 67.000 difetti per milione (piuttosto male). Un processo a 4 sigma produce circa 6.200 (dieci volte meglio). Un processo a 5 sigma produce 233 (un altro 27x meglio). Il salto da 4 a 5 sigma non è un miglioramento incrementale. È un cambiamento di fase.
La copertura dei test segue la stessa curva. Passare dal 70% al 90% di copertura non è il 30% meglio. È un ordine di grandezza in meno di fughe. I difetti che scivolano attraverso al 70% si nascondono nel 30% di codice non testato. Al 90%, i nascondigli si riducono al 10% e la maggior parte dei percorsi pericolosi sono bloccati.
Ora, devo essere onesto su ciò che la ricerca mostra anche. Mockus, Nagappan e Dinh-Trong hanno studiato Windows Vista e hanno scoperto che mentre la copertura è correlata a meno difetti post-rilascio, lo sforzo per raggiungere il 90%+ aumenta bruscamente. L'ultimo 20% di copertura richiede sproporzionatamente più lavoro del primo 70%. Questo è stato vero per decenni. È il motivo per cui la maggior parte dei team si ferma al 70-80% e lo considera abbastanza buono.
Ma qualcosa è cambiato: gli agenti di coding IA non sperimentano lo sforzo.
Non si annoiano a scrivere il quattordicesimo test per un caso limite. Non tagliano gli angoli alle 17:00 di venerdì. Non guardano un test di integrazione spinoso e pensano "tornerò più tardi." La curva di sforzo che fermava i team umani al 70% non si applica agli agenti. Puoi chiedere a Claude di scrivere test per ogni caso limite in un modulo e lo farà allegramente, accuratamente, alle 2 del mattino, senza lamentarsi. Il brutale ultimo 20% che rendeva la copertura del 90% impraticabile per i team umani è esattamente il tipo di lavoro in cui gli agenti IA sono migliori.
Questa è la vera chiave. Non è che l'IA ti permetta di scrivere codice più velocemente. Molte persone lo hanno notato. È che l'IA ti permette di verificare a un livello che prima era troppo costoso da sostenere. La soglia del 90% che i dati dicono essere magica? Costava troppa forza di volontà umana per essere raggiunta. Ora è gratuita.
Questa è la distinzione chiave. Il ratchet non riguarda la copertura delle righe come metrica di vanità. Riguarda test che codificano contratti comportamentali — il test della confusione del detentore, il test dell'arrotondamento dei pesi, il cancello della revisione interattiva. Ogni test blocca una lezione specifica appresa. La copertura è il proxy che ti dice quanto del comportamento del sistema è sotto contratto. Al 90%, quasi ogni cambiamento di comportamento attiva un segnale di test. L'agente o passa (sicuro da rilasciare) o rompe un test (catturato immediatamente).
Il restante 10% sono punti di integrazione, infrastruttura di plumbing e casi limite che sono genuinamente difficili da testare. Va bene. Il 90% è ciò che trasforma il caos in un ratchet.
Raggiungere il 90% era uno sforzo eroico. Ora è un martedì. Questo è il cambiamento del gioco.
Prova di concetto
Ho iniziato entrambi i progetti da solo. Non sono più solitari.
GStack ora ha 37 contributori. v1.30 ha incorporato 21 PR della comunità in un singolo rilascio. GBrain ha 25 contributori. v0.31.1.1 ha portato 22 correzioni della comunità in una singola PR — flusso di autenticazione, bootstrap dello schema, sincronizzazione, privacy.
Il ratchet è ciò che rende tutto questo sicuro. Ogni PR esterna deve superare la suite di test esistente. Un nuovo contributore non ha bisogno di capire l'intero sistema. Deve solo far passare i test.
I rilasci di GBrain della scorsa settimana raccontano la storia:
- v0.31.0: una nuova tabella dei fatti per la memoria in tempo reale, più una fase di consolidamento dei sogni che promuove i ricordi a breve termine in conoscenza a lungo termine
- v0.31.1: corretti 25 comandi CLI che instradavano silenziosamente a un database locale vuoto invece che al cervello reale dell'utente
- v0.31.1.1: ventidue correzioni segnalate dalla comunità in una singola PR
- v0.31.2: corretta una sincronizzazione del codice che si bloccava per sempre su repository grandi con symlink aggiungendo un timeout di 30 secondi
Ogni rilascio è stato spedito con più test del precedente. L'agente scrive i test insieme al codice. La copertura non scivola perché lo sforzo per mantenerla non è più un peso umano.
Il nuovo tetto di complessità
Il tetto di complessità per il software è appena diventato molto più alto.
Prima era limitato dalla capacità di un singolo team di tenere il sistema a mente. Ora è limitato da una persona più agenti che possono caricare l'intero codebase, la storia dello schema, la suite di test e la documentazione nel contesto.
Questo è un numero molto più grande. E continua a crescere man mano che le finestre di contesto diventano più grandi e i modelli migliorano nel ragionare sul codice.
Ogni azienda software che non adotta questo modello — agenti più gusto più una suite di test che sale solo — sta già rilasciando più lentamente e con meno qualità di una singola persona che lo fa.
Gli strumenti sono qui. Il codice è aperto. I test sono il ratchet. Copertura al 90%, ogni PR, nessuna eccezione.
Per cinquant'anni, la copertura al 90% è stata un lusso riservato all'aviazione e ai dispositivi medici — team con il budget per buttare ore umane contro il muro dello sforzo. Gli agenti IA hanno demolito quel muro. La soglia di copertura che rende il software affidabile non è più costosa. È solo un'impostazione. La domanda non è se puoi permetterti il 90%. È se puoi permetterti di non farlo.
Il ratchet, le skill e l'intero sistema di conoscenza sono open source e gratuiti su GitHub. Vai a costruire.
I miei progetti open source con licenza MIT:
- GStack — rende Claude Code drammaticamente migliore. 93K stelle. Gratuito.
- GBrain — il tuo secondo cervello per agenti IA. 14K stelle. Gratuito.
La serie AI Explainer:
- Fat Skills, Fat Code, Thin Harness — l'architettura
- Resolvers — la tabella di routing per l'intelligenza
- The LOC Controversy — cosa hanno effettivamente prodotto 600K righe
- Naked Models Are Stupider — il modello è il motore, non l'auto
- The Skillify Manifesto — ogni flusso di lavoro diventa una skill testabile
- Meta-Meta-Prompting — le skill che si combinano producono capacità emergenti
- The Agent Complexity Ratchet — sei qui
https://x.com/garrytan/status/2054055071017538028
https://x.com/garrytan/status/2042925773300908103
https://x.com/garrytan/status/2044479509874020852
https://x.com/garrytan/status/2045404377226285538
https://x.com/garrytan/status/2045798603059548364
https://x.com/garrytan/status/2046876981711769720
