Come trasformare Claude Code nel tuo AI engineering team

Il collo di bottiglia non è il modello, è lo scaffolding

Gary Tan, presidente di Y Combinator, parte da una tesi netta che ribalta il dibattito tipico sulle capacità degli agent: i modelli sono già abbastanza intelligenti per fare lavoro straordinario su qualsiasi codebase. Quello che manca è il contorno. Senza configurazione l'agent vaga, non conosce i tuoi dati, tira a indovinare, e a quella scala il guessing produce codice plausibile che si rompe in silenzio. Tan ha le credenziali per dirlo: ha studiato computer systems engineering a Stanford, è stato dipendente numero 10 a Palantir come engineer, designer e product manager insieme, ha co-fondato Posterous (poi venduta a Twitter), e ha scritto la prima versione di Bookface, la piattaforma interna di YC. Negli ultimi due mesi ha scritto più codice di quanto ne avesse scritto nel 2013, l'ultima volta in cui aveva lavorato come engineer a tempo pieno.

La sua tesi è che siamo entrati in una nuova era del software, l'agent era, e che il modo per far funzionare gli agent è lo stesso con cui hanno sempre funzionato i team umani: ruoli, processo, review. La soluzione, secondo Tan, è quindi invertire la logica del prodotto: harness leggero, skill ricche. Lo scaffolding deve essere sottile, le competenze devono essere profonde.

Per dimostrarlo ha costruito GStack, un repo open-source che in tre settimane ha superato Ruby on Rails per numero di stelle e oggi sfiora le 70.000. GStack non è un wrapper attorno a Claude Code: è un set di skill che trasformano Claude Code in un team di specialisti, ognuno con un ruolo definito. Office hours, plan CEO review, design shotgun, review, ship. Sono 28 comandi che riproducono il modo in cui un team umano lavora davvero. Tan racconta che molti utenti gli scrivono di passare l'80-90% del tempo in soli tre comandi: office hours, plan CEO review e auto plan.

Office hours: sei domande prima di scrivere codice

Lo skill che Tan considera il cuore di GStack è office hours, la versione distillata delle migliaia di ore che i sedici partner di YC hanno passato con i founder. Lo definisce una versione al 10% della loro intensità reale, ma sufficiente a fare la differenza prima ancora di incontrare un partner umano. Prima di toccare codice, l'agent fa sei domande di framing. La più importante è quella che secondo Tan determina tutto il resto: qual è la prova più forte che qualcuno voglia davvero questo prodotto?

Nel workshop Tan costruisce in diretta una tax app che recupera i moduli 1099 dalla Gmail e dai portali bancari. L'office hours non si limita a raccogliere requirement: spinge indietro sul perché il problema non è già risolto da TurboTax o H&R Block, fa notare che Plaid si collega già alle banche, mette in dubbio il modello di business. Quando Tan ammette che il problema gli costa solo fastidio e qualche email seccata del commercialista, l'agent lo riformula in una direzione più ambiziosa: un wedge verso il marketplace dei commercialisti, dove invece di addebitare due-cinque dollari l'anno per l'aggregazione documenti puoi prendere una percentuale sulla transazione fiscale, potenzialmente dieci volte tanto.

Il risultato è che invece di partire da una specifica grezza si arriva a tre approcci alternativi (A, B, C) con effort e risk stimati per ognuno: una versione minimal con solo Gmail OAuth e checklist, una full-stack con automation browser e marketplace CPA, una flip del go-to-market che parte dai commercialisti. Tan sceglie un mix tra B e C, propone di usare la browser automation per evitare del tutto Google OAuth e procede. Lo definisce non un workflow on rails ma una conversazione con il modello, e ammette che una volta su tre arriva alla fine di office hours e si rende conto che l'idea non sta in piedi. Anche questo è un risultato.

Adversarial review e design shotgun

Una volta definito il piano, parte una multi-step adversarial review automatica. Il documento di design viene messo alla prova in più round: l'agent identifica problemi concreti (failure handling mancante, sezione privacy assente, handoff 2FA senza soluzione proposta) e prova a riempirli da solo. Quello che non riesce a coprire viene lasciato come issue residue da decidere a mano. Nel demo il design doc passa da 6/10 a 8/10 con sedici issue auto-corrette in due round, e tre questioni residue messe da parte per dopo. È review automatica al servizio del founder, non al posto suo.

Poi entra in scena design shotgun, uno skill che Tan definisce tra i suoi preferiti. Invece di disegnare un'unica UI, l'agent delega a Codex la generazione di tre varianti visive con image gen, e in circa sessanta secondi torna con tre direzioni alternative: command center, friendly progress, split view. Tan le valuta in diretta, le commenta una per una (la versione command center è perfetta per un Linux hacker, ma per utenti normali serve un approccio più accessibile), sceglie la B con il card-based layout e procede. L'opzione di rigenerare passando feedback in linguaggio naturale è sempre lì, ma il punto è generare options per scegliere, non chiedere all'agent di indovinare la migliore in un colpo solo.

Su come orchestrare tutto questo, Tan offre una metafora che è quasi una checklist mentale: di default Claude Code lavora con Claude (Tan parla di Opus come del CEO con ADHD, brillante ma dispersivo), e quando il problema si fa duro si chiama in causa Codex come CTO che chiude le code path complesse. È una divisione del lavoro tra modelli che ricalca la divisione del lavoro tra ruoli umani.

Il workflow parallelo: 10-15 sessioni Claude Code in contemporanea

Il punto di arrivo non è una sessione che fila liscia: è un sistema di lavoro a sessioni parallele. Tan lavora con Conductor aprendo dieci-quindici Claude Code in contemporanea, ognuna su un worktree separato. Ogni nuova idea, bug report o segnalazione su X diventa un nuovo work item: click sul pulsante più in Conductor, nuovo worktree, run di office hours, CEO review, end review, adversarial review, e via. Una sessione fa office hours su una nuova idea, due gestiscono le PR open-source della community per fare triage in arrivo (Tan ha più di 400 PR aperte in attesa di review), le altre sviluppano feature in parallelo su branch indipendenti che convergono su main quasi simultaneamente.

Su questo aspetto Tan è esplicito sui rischi. Cita i supply chain attack come una delle cose che lo preoccupano di più nell'AI coding del 2026, e dice di essere paranoico al riguardo. La sua difesa è proprio GStack: la review automatica funziona da filtro su tutto quello che entra dal community prima di toccare main. La paranoia non è opzionale, è parte del processo.

Il QA, che Tan definisce la parte meno divertente del software development, è automatizzato dagli skill /qa e /browse. Tan racconta di avere wrappato Playwright a livello CLI dopo che il Claude in Chrome MCP si era rivelato ingestibile per via del context bloat e della latenza: ogni azione richiedeva due-tre secondi quando funzionava, e spesso non funzionava per niente. Adesso ogni agent può aprire un browser headed o headless, fare screenshot, click, fill di form, download di media, fino a regression test completi e fix di bug CSS o JavaScript veri. C'è anche uno ship tool come ultimo controllo prima di fare merge su main. Tan dice che con questo setup chiude tra 10 e 50 PR al giorno, a seconda dei meeting in agenda.

Cosa portarti a casa come builder

Il messaggio operativo è semplice: non aspettare di trovare il prompt perfetto. Investi nello scaffolding. Definisci ruoli, processo, review come faresti per un team umano. Tan parla di un livello 8 ideale di software factory, un punto in cui il founder solo orchestra agent in pipeline completamente autonome. GStack, per sua stessa ammissione, ti porta al livello sette, non oltre. Ma il livello sette è già abbastanza per costruire in due mesi quello che a Posterous era costato due anni, dieci milioni di dollari e dieci engineer.

Per Tan questa è l'agent era e il barrier to building è collassato. Per chi legge questo da founder e da builder italiani, la lezione è che il salto di produttività non si gioca più sul prompt engineering raffinato ma sulla disciplina di processo che imponi all'agent. La domanda che resta in piedi è solo cosa costruire. GStack è disponibile su github.com/gritan/GStack se vuoi provarlo direttamente.