Sfida il piano

L'agente arriva col piano già pronto e ti chiede se può procedere. Il tuo mestiere comincia lì.

La scena la conosci. Dai un compito all'agente, lui si legge i requisiti e la codebase, e dopo un po' ti presenta un piano: ordinato, numerato, ragionevole. Sotto, la domanda: procedo? E lì c'è il bivio del mestiere nuovo. Premere yes e andare a farsi un caffè, oppure leggere quel piano come leggeresti il design di un collega che conosci da tre giorni.

Il piano nasce da due ingredienti: i requisiti, che ce li hai messi tu, e la codebase, che è la storia di tutte le scorciatoie prese prima di oggi. Da lì può uscire qualcosa di ragionevolissimo e sbagliato. Ragionevole e giusto si somigliano parecchio, sulla carta. La differenza la vede soltanto chi conosce il dominio. E di voi due, quello che lo conosce sei tu.

Ti racconto com'è andata a me. All'inizio i piani li sfidavo per diffidenza: leggevo, mi arrabbiavo, correggevo. Poi un giorno, su una di queste arrabbiature, ho fatto la fatica di seguirlo fino in fondo, e ho scoperto che era arrivato dove sarei arrivato io, solo prima di me. Da lì il rapporto è cambiato: ho smesso di trattarlo da assistente indisciplinato e ho iniziato a trattarlo da collega con cui discutere. Sfidare il piano funziona in tutte e due le direzioni: a volte ha torto lui, a volte ce l'hai tu. In entrambi i casi, la discussione ti lascia più ricco di com'eri.

Sfidare, in pratica, vuol dire tre mosse. La prima: pretendi che il piano contenga il modo di verificarsi da solo. Quando chiedo i test, aggiungo "con almeno l'80% di coverage": gli ho dato un criterio, e adesso può controllarsi mentre lavora. Boris Cherny, che guida Claude Code in Anthropic, sostiene che aggiungere criteri di verifica moltiplica la qualità dell'output per due o tre volte, e la mia esperienza dice lo stesso. La seconda: stabilisci prima cosa scala su di te. Da noi anche le review si possono delegare, ma certi file no: chi tocca il pricing passa da un umano, sempre, ed è scritto nei criteri. La terza: dagli fondamenta su cui pianificare. Un piano costruito su una codebase muta e senza documentazione è un piano costruito sui sospetti; un README onesto e le regole scritte cambiano la qualità di quello che ti propone.

E per tenerti onesto valgono le solite tre domande, usate come diagnostica: capisci perché il piano funziona, o ti sembra soltanto solido? Stai delegando per efficienza, o per pigrizia? Cosa hai imparato dalla discussione? Se le risposte ti piacciono poco, eri fuori dal giro e premevi yes.

Il piano lo scrive lui, e lo scrive in trenta secondi. Il mestiere, adesso, è sfidarlo. Ed è un mestiere che si fa col dominio in testa, perché al piano plausibile ci arriva chiunque. A quello giusto ci si arriva in due.

Questo è solo un pezzo di Racing with Raymond, il secondo talk della serie. Se vuoi la versione intera per la tua community o il tuo team, scrivimi.