La situazione
Da aprile 2026 sono l'AI Adoption Leader per Claude Code a Intarget: decido con chi aprire l'accesso, formo le persone e rispondo di costi e benefici. Se fosse per me, Claude Code lo darei a tutti. Attivarlo però non risolve niente da solo. Il rischio vero è scalare gli errori, cioè fare le stesse cose sbagliate il doppio delle volte al giorno.
Cosa ho fatto
Ho trasformato l'accesso in un percorso. Ogni colloquio chiude con un compito reale, i suoi input, cosa vuol dire riuscirci, chi può giudicarlo e quando ne riparliamo. Nei controlli successivi chiedo l'ultima cosa rilasciata, com'è la qualità e dove serve una mano. Le regole di lavoro le ho messe in un repository condiviso, scritto per le persone e soprattutto per l'agente, così Claude Code le trova ogni volta che parte.
Ogni settimana c'è il Laboratorio Generative AI. Lo prepara e lo conduce Andrea Zennaro, io seguo la parte tecnica, faccio le demo e raccolgo quello che non funziona per sistemarlo. Al lab anche chi non scrive codice trasforma il proprio lavoro ripetitivo in skill.
Cosa è cambiato
L'adozione è in corso e cresce un team alla volta, intorno a una persona di riferimento che ha già portato a termine un compito rappresentativo. L'autonomia si allarga man mano che le persone dimostrano giudizio. Chi non programma oggi costruisce skill per report e controlli, e il tempo che recupera lo spende in analisi più approfondite. Una collega lo chiama tempo guadagnato.
Cosa ho imparato
Io Claude Code lo uso per tutto e ormai non scrivo più codice a mano. Eppure su codebase grandi mi ha combinato dei casini, ed è lì che ho cominciato a scrivere i test prima del codice. Se succede a chi lo usa tutto il giorno, un corso base non passa all'agente la responsabilità del design, anche se finirlo dà la sensazione di saper supervisionare qualsiasi lavoro. Per questo l'accesso passa da un colloquio che chiude con un compito vero e con qualcuno in grado di giudicarlo, e per ogni modifica che conta chiedo a chi la lancia di saperne spiegare il design e verificare il comportamento.
Quello che non può rimpiazzare è il systems design
Una collega salvava il prompt di ogni tentativo e lo migliorava ogni volta. Quando il metodo si è stabilizzato, l'ha fatto generalizzare in tre parti: il metodo, il brief del cliente e l'elenco dei file da usare. Lo stesso metodo è passato da un cliente all'altro cambiando solo brief e file. Una specifica scritta da zero, a tavolino, sembra il punto di partenza più ordinato, e perde le correzioni tacite che fanno funzionare un metodo. La conversazione riuscita le conserva. Da allora al laboratorio propongo di partire da lì: prima un lavoro riuscito, poi la skill estratta da quella conversazione.
Durante una demo al laboratorio, la stessa collega ha richiamato la skill aggiungendo una lunga lista di istruzioni su come fare il lavoro, e la chat è andata in confusione. Ne ha aperta un'altra con i file già caricati e ha premuto invio per sbaglio, quasi senza testo. L'output era praticamente perfetto. Il metodo stava già nella skill, e riscriverlo in chat lo metteva in competizione con sé stesso. Da allora a una skill provata passiamo gli input e le eccezioni, e quando qualcuno sente il bisogno di ripetere il metodo in chat, lo prendiamo come il segnale che va corretta la skill.
Una collega che non scrive codice ha costruito tante skill piccole, una per operazione, al posto di una sola che fa tutto il lavoro di un cliente. Al laboratorio ha mostrato l'output: incrociava i dati e in più le indicava subito dove guardare, come un ordine reso solo in parte. Dall'automazione per chi non programma ci si aspetta meno clic e report più veloci. Il valore che lei descriveva stava nell'anomalia segnalata e nella decisione che ne seguiva. Oggi è la prima domanda che faccio quando qualcuno vuole trasformare un controllo in skill: quale eccezione merita la sua attenzione, e per quale decisione.