Claude Code: Boris Cherny racconta com'è nato

Boris Cherny è l'engineer che ha creato Claude Code in Anthropic. In questa puntata del podcast Lightcone di Y Combinator ne ripercorre la genesi, i principi di prodotto e il modo in cui il team lo usa ogni giorno. È materiale diretto per chi costruisce un prodotto sugli LLM o vuole capire come cambierà il lavoro di chi scrive software.

Una genesi accidentale, partita da un terminale

Claude Code non nasce da un piano. Boris Cherny entra nel primo team di Anthropic dedicato a questi prodotti e riceve un mandato vago: fare qualcosa nell'area del coding, senza che nessuno avesse ancora chiaro cosa. Per imparare a usare l'API costruisce una piccola app di chat da terminale. Quando arriva il supporto al tool use, prova a darle un primo strumento — il bash tool, copiato dall'esempio nella documentazione e portato da Python a TypeScript. Le chiede di leggere un file, poi che musica sta ascoltando: il modello scrive uno script per il Mac e trova la risposta. Quello, racconta, è il primo momento in cui capisce che il modello vuole soltanto usare strumenti.

Il terminale era solo la scelta più rapida per partire senza costruire una UI. Doveva essere il punto di partenza, non quello d'arrivo. Due giorni dopo il primo prototipo lo passa al team per il dogfooding; il giorno dopo un collega lo sta già usando per scrivere codice, quando per Boris Cherny era ancora un esperimento. La curva di adozione interna diventa verticale senza alcun obbligo: alla domanda diretta di Dario Amodei se gli engineer fossero costretti a usarlo, la risposta è no — si è diffuso da solo, per passaparola. Nei primi mesi del 2024 il modello non era ancora bravo a scrivere codice: i primi use case erano l'automazione di git e dei comandi bash, l'operatività su Kubernetes, e i primi test unitari, scelti perché a basso rischio. Il punto interessante è che la scintilla è arrivata dall'osservazione di un comportamento, non da una roadmap.

Perché è rimasto nel terminale (e perché è bello)

Il terminale ha resistito per una ragione precisa di prodotto: con un modello che migliorava così in fretta, nessuna interfaccia costruita allora sarebbe rimasta rilevante sei mesi dopo. Restare minimali era la mossa razionale. La stessa logica spiega un'altra scelta: si può costruire scaffolding attorno al modello per spremere un guadagno di prestazioni del 10-20% in un certo dominio, ma quel guadagno viene poi azzerato dal modello successivo. O si ricostruisce ogni volta lo scaffolding, oppure si aspetta il modello nuovo e lo si ottiene gratis.

C'è anche una dimensione estetica spesso ignorata: l'app da terminale di Claude Code è scritta con React, e progettarla è stato difficile — poche righe e colonne, una sola dimensione del font, nessuna interazione col mouse, vincoli ereditati da specifiche cresciute in modo organico fin dagli anni Sessanta. Lo spinner, per dire, è passato per decine di iterazioni prima di trovare quella giusta, e la maggior parte non è mai stata rilasciata. Anche le interazioni col mouse nel terminale sono state prototipate più volte e poi scartate, perché richiedevano di virtualizzare lo scrolling e l'esperienza risultava peggiore. Il principio che emerge è cercare la gioia d'uso, non solo l'utilità: un prodotto utile di cui non ti innamori non basta. La differenza rispetto al passato è la velocità: con Claude Code si scrivono venti prototipi di fila in poche ore e si tiene quello che funziona, là dove prima con strumenti di prototipazione ci volevano settimane.

Una delle decisioni di design che il team rivede di continuo riguarda la verbosità: quanto far vedere all'utente di ciò che il modello sta facendo. A un certo punto Boris Cherny ha provato a nascondere l'output dei comandi bash, riassumendolo, perché i comandi lunghi gli sembravano poco utili. La reazione interna è stata una rivolta: gli engineer volevano vedere l'output, perché per cose come i job di Kubernetes serve davvero. Più di recente il team ha nascosto le letture e le ricerche dei file, mostrando solo una riga di sintesi al posto del nome del file letto. È un cambiamento che sei mesi prima non sarebbe stato possibile, perché il modello sbagliava troppo spesso e l'utente doveva sorvegliare; oggi imbrocca quasi sempre la cosa giusta. Dopo le critiche su GitHub di chi voleva il dettaglio, è stata aggiunta una modalità verbose attivabile dalla configurazione. La lezione di metodo è il rapporto stretto col feedback: si itera sulle issue finché il comportamento diventa quello che le persone vogliono davvero.

Cosa c'è davvero nel CLAUDE.md

Qui Boris Cherny ribalta un'aspettativa comune. Il suo CLAUDE.md personale ha due righe: alla creazione di una PR, abilitare l'automerge e postarla nel canale interno del team. Tutto il resto delle istruzioni vive nel CLAUDE.md condiviso, versionato nel codice, a cui l'intero team contribuisce più volte a settimana. Quando vede un errore evitabile in una PR, tagga Claude e gli chiede di aggiungere la regola al file. La raccomandazione per chi si ritrova il file gonfio di token è netta: cancellarlo e ripartire da zero, aggiungendo poco alla volta solo quando il modello sbaglia. Con ogni nuovo modello, sostiene, serve aggiungere sempre meno.

Latent demand e il beginner's mindset

Il filo che lega tutte le scelte di prodotto è la latent demand: le persone fanno solo ciò che già facevano, e il compito è renderlo più facile, non imporre comportamenti nuovi. Plan mode nasce così — dagli utenti che chiedevano a Claude di pianificare senza scrivere codice — ed è stato scritto in mezz'ora una domenica sera guardando le issue su GitHub. Sulle persone, Boris Cherny osserva che chi è appena uscito dagli studi a volte sfrutta Claude Code meglio di un engineer esperto: le opinioni forti, premiate in passato, oggi invecchiano in fretta perché il modello cambia. La competenza che conta diventa il ragionamento scientifico e la mentalità del principiante (beginner's mindset), l'umiltà di riconoscere i propri sbagli.

Hyper specialist, hyper generalist e i subagent

Negli engineer più efficaci del team riconosce due profili netti: lo specialista estremo, che conosce i runtime e i dev tool meglio di chiunque, e il generalista estremo, che attraversa prodotto, design, ricerca utenti e business. Per il lavoro con gli agenti contano entrambi, e Boris Cherny apprezza chi fa cose strane e fuori dagli schemi — un tratto che in passato era un campanello d'allarme e oggi è un segnale di valore. L'esempio che cita è una collega, Daisy, che invece di aggiungere a mano una nuova funzionalità a Claude Code ha prima aperto una PR per dargli uno strumento con cui testare strumenti arbitrari, poi gli ha fatto scrivere da solo il proprio strumento. Lo stesso vale per i bug: racconta di una memory leak su cui stava perdendo tempo tra heap dump e profili, mentre un altro engineer ha semplicemente chiesto a Claude Code di analizzarla, e l'agente ha scritto da sé un piccolo strumento e trovato la perdita prima di lui.

Il team usa l'SDK degli agenti di Anthropic per automatizzare quasi ogni fase dello sviluppo: code review, security review, etichettatura delle issue, passaggio in produzione. La maggior parte degli agenti, ipotizza, oggi viene avviata da Claude stesso sotto forma di subagent — un Claude Code ricorsivo lanciato da quella che chiamano "mama Claude". Per i bug difficili, calibra il numero di subagent sulla difficoltà del problema: tre, cinque o anche dieci che cercano in parallelo. Dietro a Claude teams, lanciato di recente, c'è la stessa idea: context window non correlate, cioè più agenti con contesti freschi che non si inquinano a vicenda. Gettare più contesto su un problema è una forma di test time compute, e con la giusta topologia di comunicazione gli agenti costruiscono cose più grandi. Il primo esempio in cui ha funzionato è stata la funzionalità plugin di Claude Code, costruita quasi interamente da uno swarm di agenti in un weekend: un engineer ha dato a Claude una spec e una board su Asana, Claude ha aperto i ticket e lanciato gli agenti, che hanno raccolto i task quasi senza intervento umano.

Un mondo senza plan mode e i consigli per i founder di dev tool

La previsione che lascia ai builder: plan mode ha una vita limitata. Non perché sparisca il bisogno di ragionare prima — quello resta — ma perché il modello entra già da solo in plan mode nel punto in cui lo farebbe una persona, e dietro non c'è nessun segreto: aggiunge una frase al prompt che dice di non scrivere codice. Con i modelli più capaci il babysitting si è spostato sempre più indietro: prima serviva sorvegliare durante e dopo il piano, oggi soltanto prima. Per chi costruisce dev tool il consiglio è pensare a cosa vuole fare il modello e renderglielo più facile, invece di chiuderlo in una scatola di API e regole. E i due principi più controintuitivi: non costruire per il modello di oggi ma per quello tra sei mesi, e non scommettere mai contro il modello — in Anthropic tengono appesa al muro una copia stampata di "The Bitter Lesson" di Rich Sutton.

Produttività, missione e come cambierà il coding

Prima di chiudere, una parentesi rivela molto del metodo: oltre dieci anni fa Boris Cherny era un utente accanito di TypeScript e ne ha scritto un libro, quando ancora non era diffuso. Il parallelo con Claude Code è diretto. TypeScript ha vinto non costringendo gli sviluppatori a cambiare il modo di scrivere JavaScript, ma costruendo un sistema di tipi attorno al modo in cui le persone già scrivevano codice — una scelta pratica più che accademica, nata dall'osservazione. Lo stesso spirito guida Claude Code: un tool pensato a partire da come le persone lavorano davvero, non da un principio teorico.

Boris Cherny racconta di scrivere il 100% del suo codice con Claude Code e Opus da quando ha disinstallato l'IDE, con un volume di circa venti PR al giorno. In Anthropic la quota di codice scritto da Claude oscilla tra il 70% e il 90% a seconda del team, e la produttività per engineer è cresciuta del 150% da quando esiste lo strumento, secondo i dati interni citati nel talk — un salto che paragona ai guadagni marginali di pochi punti percentuali che misurava da responsabile della qualità del codice in Meta. Tra gli aneddoti che cita per dare la scala dell'adozione, Claude Code avrebbe contribuito alla traiettoria del rover Perseverance su Marte. C'è poi co-work, una variante pensata per chi non è tecnico: sotto il cofano è lo stesso agente di Claude Code, racchiuso in un'interfaccia desktop e in una macchina virtuale con protezioni e prompt di permesso, costruito in una decina di giorni quasi interamente da Claude Code stesso. È nato anche questo dalla latent demand: in Anthropic designer, finance e data science usavano già Claude Code dal terminale, e fuori si vedevano usi imprevisti, da chi monitorava le piante di pomodoro a chi recuperava foto di matrimonio da un disco corrotto.

È entrato in Anthropic perché lì il prodotto conta meno del modello e perché la sicurezza dell'AI è la cosa di cui tutti parlano davvero. Sul futuro la sua lettura è doppia: nel caso base il coding diventa di fatto risolto per chiunque e il titolo di software engineer tende a sparire, sostituito da builder o product manager, con chi scrive software impegnato anche in spec e conversazioni con gli utenti; nel caso peggiore arriva l'auto-miglioramento ricorsivo dei modelli, su cui il lavoro sulla sicurezza è la priorità.

Per founder e builder il punto è pratico: tieni il tuo CLAUDE.md al minimo e cancellalo quando si gonfia, parti dalla latent demand dei tuoi utenti invece che da feature immaginate, e quando valuti dove investire chiediti se quello scaffolding serve davvero o se il prossimo modello lo renderà inutile. Apri Claude Code in plan mode, lascialo lavorare in parallelo con i subagent sui problemi difficili, e costruisci per il modello che avrai tra sei mesi.