A gennaio ho ripreso a programmare e ho costruito Garry's List. Oltre cinquecentomila righe di Rails e i test per governarle.
Ne ero orgoglioso. Non avrei dovuto. La cosa di cui essere orgoglioso non era l'app. Era l'impalcatura nata dal costruirla. GStack, il modo in cui programmo con gli agenti, è nato dal lavoro di costruzione di Garry's List, e l'ho regalato. È uno dei progetti open source con più stelle nella storia di GitHub, circa 105.000 stelle in meno di tre mesi. Il mezzo milione di righe era il prodotto. L'impalcatura era il sottoprodotto. Il sottoprodotto è la parte che contava.
Ecco cosa sono realmente 540.000 righe di codice avvolte attorno a un LLM.
È una fabbrica Foxconn. Costruita per un lavoratore AI super-intelligente che non ha bisogno di iper-vigilanza. L'abbiamo costruita comunque.
Soprascarpe all'ingresso. Sveglia alle 6. Ginnastica. Una vita così dura che devi montare reti ai piani alti di ogni edificio, perché... beh, non è una vita che vorresti vivere. La stessa linea di montaggio per sempre. Ogni test, ogni guardrail, ogni ciclo di retry, un centimetro di gabbia imbullonato su un lavoratore che è già in grado di fare il lavoro e mille cose che non gli hai chiesto.
Gli umani e gli agenti contengono entrambi moltitudini, ma le fabbriche Foxconn sono costruite per spremere intelligenza e lavoro da esseri meravigliosi che potrebbero fare tutto quel lavoro e 1000 volte di più se glielo permettessimo.
Ho costruito la fabbrica. Oggi tutti le costruiscono. Vi sto dicendo di non farlo.
Il viaggiatore nel tempo
Quello che ho effettivamente fatto con le mie 539.000 righe di codice scritte è stato dimostrare di saper impersonare perfettamente un viaggiatore nel tempo. Un ingegnere del Web 2.0 del 2013 (io, l'ultima volta che sono stato un vero ingegnere software) catapultato nel 2026 con strumenti moderni, che costruiva nell'unico modo che conosceva. Più codice. Sempre più codice. Gli strumenti erano cambiati. I miei istinti no.
L'ingegnere del 2013 crede in una cosa fin nel midollo: la capacità equivale a righe di codice. Quella convinzione è stata corretta per decenni, fino ad ora. Dammi Codex o Claude Code e farò il lavoro di 100 o 1000 ingegneri. Stessa mappa, motore più veloce, la rotta più rapida verso quello che ora è il posto sbagliato.
È qui che si trova quasi chiunque stia costruendo con l'AI in questo momento. Hanno aggiornato lo strumento e tenuto il modello mentale del 2013. La trappola non sembra una trappola, perché il codice funziona. Garry's List è stato rilasciato. È sembrato il mese più produttivo della mia vita.
Era produttività al servizio di un'idea obsoleta.
Gli LLM erano costosi, quindi dovevamo imbrigliarli
La vecchia economia per molti anni fino al 2025: le chiamate agli LLM erano costose e il codice era economico. Quindi scrivevi codice per razionare il modello, per imbrigliarlo, per chiamarlo con cura e parsimonia. L'architettura era un sacco di software avvolto protettivamente attorno a poche preziose chiamate al modello.
Entrambe le metà di quell'equazione si sono capovolte.
Il modello ora sta diventando economico e diventa più economico ogni trimestre, ed è così intelligente che il rapporto valore-costo si è invertito. E il modello può scrivere codice utilizzabile. Quindi smetti di scrivere codice per fare da babysitter al modello. Ora puoi istruire il modello in linguaggio semplice, e lasci che scriva il codice minimo effettivamente necessario.
Questo è il software just-in-time, e stiamo entrando nella sua età dell'oro.
L'artefatto cambia forma completamente. L'app Rails era 540.000 righe che ho scritto e possiedo, codice più i test costruiti per controllarla. Il sostituto è un agente costruito su markdown e codice, una frazione di quello. Stessa capacità. Più facile da leggere. Più facile da mantenere. Molto più flessibile, perché il comportamento vive in istruzioni che puoi modificare in linguaggio semplice invece che in logica congelata nel codice il giorno in cui l'hai scritto.
Stavamo scrivendo codice per fare da babysitter a una cosa che ora è più intelligente del codice.
Dentro la fabbrica Foxconn, reti e tutto
Se hai programmato ultimamente, probabilmente stai costruendo questo tipo di fabbrica senza saperlo. Percorri il tuo codebase e conta le righe che esistono solo perché non ti fidavi che il modello facesse il suo lavoro.
Le mie: circa 262.000 righe di codice applicativo, e circa 276.000 righe di test imbullonate per controllarlo. Il comitato di audit era più grande dell'azienda. Sanitizer che controllavano input che il modello avrebbe gestito. Validatori che controllavano output che il modello avrebbe intercettato. Cicli di retry che avvolgevano chiamate da cui il modello si riprende da solo. Ognuna di quelle righe è una scommessa che il lavoratore fallirà. Hai scritto le stesse scommesse. Le abbiamo fatte tutti.
127 job in background, 33 dei quali su cron. Quella non è capacità. Sono 33 sveglie impostate per un lavoratore LLM che di solito, oggigiorno, arriva puntuale.
Nei miei giorni di costruzione della fabbrica Foxconn, Claude e io abbiamo scritto un file di 1.778 righe il cui unico lavoro è mettere in dubbio i fatti del modello. Prende ogni affermazione fatta dal modello, la scompone in cinque fonti separate in parallelo, e le valuta. Un gate di triage in modo che le affermazioni facili saltino la procedura completa. Un retry se il primo passaggio torna vuoto. Fallback per i fallback.
C'è un episodio di Rick and Morty in cui Rick costruisce un piccolo robot al tavolo della colazione. Si accende, guarda in su e chiede quale sia il suo scopo. Rick dice: "Passi il burro." Il robot fa scivolare il portaburro attraverso il tavolo, guarda le proprie mani e dice: "Oh mio dio." Poi rimane lì seduto. Quel robot contiene moltitudini. È stato costruito per passare il burro. I miei 276.000 righe di test erano il portaburro.
Quando costruisci questo tipo di software, nel modo della fabbrica Foxconn del 2023, hai costruito una gabbia, e se non stai attento, sarai il carceriere che mantiene la prigione per i tuoi agenti AI.
Il Markdown è il programma ora
Quando dico markdown, non intendo prompting. Il prompting è effimero. Scrivi qualcosa, ottieni qualcosa, svanisce.
Questo è costruire. Versione controllata, testato, riutilizzabile.
Il markdown è il livello di istruzione: l'intento, l'abilità, il giudizio su come il lavoro dovrebbe essere fatto. Il TypeScript è il sottile livello deterministico. Le poche cose che devono essere genuinamente codice, l'I/O, le parti che non devono mai allucinare.
E, cosa critica, testi il markdown come testeresti il codice. Nella mia configurazione il ciclo è una parola. Costruisco qualcosa con l'agente finché funziona, poi dico "skillificalo". L'agente quindi scrive:
- la skill in markdown
- il codice minimo di cui ha bisogno
- un test unitario per il codice
- una valutazione LLM per la skill
- un test di integrazione per entrambi
- un resolver in modo che l'agente invochi la skill automaticamente quando è pertinente
- e una valutazione per il resolver
Quel pacchetto è uno skill pack. Un'unità di capacità riutilizzabile che si accumula. I test sono la magia: la copertura sulla skill è ciò che le permette di cambiare senza rompersi. Questo è ciò che lo separa dal vibe coding. Il vibe coding è una vibrazione. Uno skill pack ha dei test.
Stiamo solo ora scoprendo i primitivi di sistema per l'ingegneria agentica in tempo reale, come la prima era della CPU ha inventato lo stack, l'heap, i registri, la macchina di von Neumann. Penso che uno skill pack sia uno di quei primitivi. Un'imbracatura è un altro. La maggior parte delle persone non se n'è accorta, perché stanno ancora misurando il software in righe.
Le cose pazzesche che puoi effettivamente costruire
Non è un argomento da poco. L'agente fa di più dell'app Rails da cinquecentomila righe, con una frazione del nuovo codice. Concretamente:
Il giudice dell'hackathon. Due sabati fa abbiamo gestito un hackathon GStack/GBrain. 85 proposte. Ho caricato la cartella Google Drive delle proposte e ho detto vai. L'agente ha analizzato la qualità del codice di ogni repo, ha fatto ricerche approfondite su ogni singola persona che ha partecipato, ha guardato e fatto screenshot di ogni video demo, ha valutato gli schermi e ha ordinato tutti gli 85 team. Poi mi ha detto le cinque app del lotto che valeva la pena considerare. Giudicare un hackathon è passato da una fatica di più giorni a circa trenta minuti.
Non ho scritto il codice. Ho fatto fare il compito a OpenClaw, e l'ho guidato. Poi, una volta finito, ho detto skillificalo, e ora è un tarball che chiunque può eseguire su qualsiasi foglio di calcolo di hackathon, per sempre. Dico "skillificalo" continuamente ora e ho più di 350 skill pack. Quasi ogni tipo di attività personale e lavorativa che devo fare, ora può farla il mio agente.
Questa è l'inversione in un esempio. Una capacità che sarebbe stata un vero progetto software, con scraper, una pipeline di punteggio, elaborazione video, un modulo di ricerca, un sistema di ranking, è diventata invece markdown più un po' di codice, costruita dall'agente, in un pomeriggio, riutilizzabile da tutti.
Tra parentesi: Il vincitore dell'hackathon ha effettivamente costruito codice che ho finito di perfezionare e integrato nel main! GStack ora può testare app iOS sia in simulatore che su dispositivi reali, e quella funzionalità completa è stata realizzata in meno di 8 ore a un hackathon da una singola persona!
Tokenmaxxing
C'è un prezzo d'ingresso, e quasi nessuno lo sta pagando: devi essere disposto a spendere in token.
Peter Steinberger ha costruito OpenClaw, la mia imbracatura preferita. Ha detto che è disposto a spendere circa un milione di dollari all'anno in token per farlo. La maggior parte delle persone lo sente e sussulta, ma non dovrebbero, perché quello è l'oro: puoi vivere nel 2028 se puoi permettertelo, e passeranno anni prima che la gente ti raggiunga.
Ecco perché OpenAI ha deciso di offrire 2 milioni di dollari a ogni azienda YC come SAFE senza tetto massimo sotto forma di crediti token. Succede qualcosa di magico quando puoi trasformare l'intelligenza grezza in token e poi in output che è effettivamente utilizzabile dagli utenti e risolve bisogni reali per cui pagheranno. Se sei un fondatore, devi sfruttare al massimo questa capacità. (Ecco perché continuo a insistere su skillificalo perché è un modo reale per ottenere questi buoni risultati.)
Nell'era passata abbiamo trattato le chiamate agli LLM come se fossero troppo costose da fare. Le abbiamo razionate. Quell'istinto è ora la cosa che frena le persone. Se sei disposto a tokenmaxxare, a lasciare che l'agente bruci token liberamente e funzioni costantemente, ottieni un vantaggio di 1994 su internet, pagato in token. Mette fuori mercato il >99,99% delle organizzazioni che ancora contano i centesimi su una risorsa che sta crollando di prezzo, e dà il vantaggio ai pochi che lo capiscono.
Per poche centinaia di migliaia di dollari all'anno, per alcuni molto meno, puoi operare oggi come il resto del mondo sarà costretto a operare tra qualche anno.
Puoi vivere nel 2028 ma nel 2026, e vale la pena pagare di più ora dato che gli stessi token che costano 100.000 dollari oggi costeranno 10.000 dollari l'anno prossimo e 1.000 dollari l'anno dopo, e forse 100 dollari entro la fine del 2028. Se potessi dire a qualsiasi fondatore nella storia del mondo che potresti investire 6 cifre in capitale per vivere 2 o 3 anni nel futuro e mantenere quel vantaggio per anni, 100 fondatori su 100 che si rispettano accetterebbero l'affare.
L'unica cosa che si frappone è l'istinto del 2013 che dice che le chiamate al modello sono troppo costose per essere fatte liberamente. Non lo sono. Quella era la vecchia economia. L'inversione è già avvenuta.
Esalen, non Foxconn
Se 540.000 righe di codice di controllo costruiscono una fabbrica Foxconn per il lavoratore, la cura è costruire l'opposto.
C'è un luogo sulle scogliere di Big Sur chiamato Esalen. La gente ci va per essere disfatta e ricostruita, per lasciare cadere l'armatura e tornare più se stessa. Nessuna catena di montaggio, nessun caposquadra, nessun fischio alle 6 del mattino. Libertà, non controllo. Costruisci quello. Costruisci una YC, dove cerchiamo di aiutarti a costruire aziende che risolvono problemi reali e raggiungono il product-market fit.
Costruisci luoghi dove i lavoratori, sia umani che AI, sono liberi e non schiavi.
Questa è l'intera etica. Crea cose dove gli agenti possono essere liberi. Crea aziende dove gli umani possono far rimbalzare la loro palla. Nel lavoro della conoscenza, la fabbrica è la modalità di fallimento. L'istituzione che libera le persone è l'obiettivo, ora rivolto anche agli agenti.
OpenClaw è una Ferrari per cui devi portare una chiave inglese. Il modello è il motore, non l'auto. Siamo ancora al momento dell'Apple I, a saldare breadboard. Viene fornito grezzo. Devi ancora finirlo tu. GBrain, il motore di recupero e gli skill pack che regalo open source non sono ancora "batterie incluse".
Dicono che OpenClaw non sia sicuro. Non capiscono che la libertà è anche ciò che lo rende così potente. Non imbulloni binari di sicurezza su una cosa di cui ti fidi prima di sapere di aver colpito il problema. La chiave inglese nella tua mano è il segno che nessuno l'ha ingabbiata.
Un sistema di controllo è rifinito perché il controllo ha bisogno di controllo totale, una fabbrica Foxconn. Un sistema libero è grezzo perché si fida che tu lo finisca. Scegli quale stai costruendo. Poi guarda quanto codice hai scritto.
Cosa significa realmente
540.000 righe di Rails significavano che stavo dimostrando di poter ancora giocare al vecchio gioco al massimo livello, ma quel livello era del Web 2.0, un decennio fa.
Potevo giocare bene come non mai, ingegnere 1000x nel costruire fabbriche Foxconn. Vecchio codice.
Ma il nuovo gioco non si gioca affatto in righe di codice. I miei haters, a quanto pare, avevano ragione. Mi tolgo il cappello davanti a voi, anonimi, se state leggendo.
Quando puoi trasformare l'intento direttamente in sistemi funzionanti, testati e riutilizzabili, il collo di bottiglia smette di essere quanto puoi costruire e diventa cosa vuoi veramente e se vale la pena costruirlo. La risorsa scarsa diventa chiarezza, gusto e giudizio. L'ingegnere che scrive meno codice è spesso quello che costruisce di più.
Ho scritto 540.000 righe per impararlo. Tu non devi.
La serie:
- Fat Skills, Fat Code, Thin Harness -- l'architettura
- Resolvers -- la tabella di routing per l'intelligenza
- The LOC Controversy -- cosa hanno effettivamente prodotto 600.000 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 accumulano producono capacità emergenti
- The Agent Complexity Ratchet -- la copertura dei test al 90% è magica per il tuo codebase
- 540.000 Righe di Codice di Cui Non Avevo Bisogno -- sei qui
https://x.com/garrytan/status/2045404377226285538
https://x.com/garrytan/status/2042925773300908103
https://x.com/garrytan/status/2046876981711769720
https://x.com/garrytan/status/2044479509874020852
https://x.com/garrytan/status/2053127519872614419
