First Draft · Marco Mariotti

Imparare a guidare, non a correre

Marco Mariotti — Fri, 24 Jul 2026 00:00:00 GMT

C'è una cosa che, da quando l'AI è entrata nel mio lavoro quotidiano, faccio più fatica a tenere a freno: la voglia di fare di più. La feature in più che nessuno aveva chiesto, il refactor che rimandiamo da mesi e che "già che ci sono" potrei sistemare adesso, il pezzo di architettura che potrei rendere più elegante. Non è pigrizia, è l'opposto: è il desiderio di costruire, di lasciare le cose meglio di come le ho trovate. Una spinta buona, ed è proprio per questo che è difficile da governare: non voglio spegnerla, voglio darle una direzione.

Il rischio, per me, non è scrivere codice cattivo. È lavorare senza struttura: inseguire ogni buona idea nell'istante in cui mi viene, aprire tre fronti mentre ne stavo chiudendo uno, e ritrovarmi a fine giornata più veloce ma senza aver deciso davvero dove stavo andando. Così si spreca proprio lo slancio che l'AI mi aveva regalato.

Mi viene in mente l'immagine di una slitta trainata dai cani. Cinque cani in formazione ti portano a destinazione a una velocità che a piedi non ti sogni. Il problema non sono mai i cani: sono forti, veloci, hanno voglia di correre. Il problema è se nessuno, dietro, decide dove andare. Allora ognuno tira dove vuole, e tutta quella potenza non ti porta da nessuna parte: ti trascina in giro. La velocità c'è, la direzione no.

L'AI mi ha messo cinque cani davanti alla slitta. Non devo rallentarli, e non voglio: sarebbe sprecarli. La questione, adesso, non è più correre. È decidere dove, e tenere il muso di tutti puntato lì.

E se la spinta la sento io, che ho qualche anno di mestiere alle spalle, nei colleghi più giovani vedo qualcosa di più insidioso.

In una review, tempo fa, mi trovo davanti parecchio codice nuovo per un componente. Era stato introdotto un pattern di hydration, gestito nel seguente modo: il componente figlio, a ogni aggiornamento, restituiva i suoi dati al padre attraverso una callback, e il padre li reidratava. Funzionava. Stava in piedi. Ed era completamente inutile: per ottenere lo stesso risultato bastava passare dal padre al figlio una semplice ref e usare quella. Tre righe al posto di un pattern.

Perché tanto codice per così poco? Perché la soluzione l'aveva proposta l'AI, e l'aveva proposta bene: coerente, plausibile, funzionante. Il collega l'aveva provata, girava, i test erano verdi. Quello che non aveva fatto era fermarsi a chiedersi qual era la cosa più semplice che risolveva il problema. Se lo avesse fatto, la ref sarebbe saltata fuori da sola. Ma la macchina gli aveva già dato una risposta completa, e una risposta completa toglie la voglia di cercarne una più semplice. Era stata accettata perché sembrava giusta, non perché fosse stata capita.

L'ho chiamato. Gli ho chiesto due cose: di spiegarmi il pattern, e poi di spiegarmi perché lo aveva scelto. Sulla prima domanda era pronto, il pattern lo sapeva raccontare. Sulla seconda si è fermato. È venuto fuori che non lo aveva scelto: lo aveva proposto l'AI, e lui lo aveva preso. "Funzionare funziona," gli ho detto, "ma qui è inutile. Con una ref togliamo una ventina di righe da cinque componenti, e non dobbiamo più metterci mano tutti e cinque ogni volta che cambia qualcosa a monte. Meno codice da leggere, meno da mantenere." Non era una correzione di stile. Era tornare insieme al cuore del problema, quello che la risposta completa aveva coperto.

È qui che mi accorgo che sta cambiando il modo stesso in cui si cresce. Il collega non era incapace: si era fermato in superficie. E fermarsi in superficie, oggi, sembra non costare niente. L'AI ti dà una risposta che funziona, tu la prendi, vai avanti. Ma ogni volta che demando alla macchina non la scrittura, quella va benissimo, ma la comprensione, perdo un pezzo di ownership sul codice che porta il mio nome.

E la comprensione persa non si recupera da sola. Un componente che non capisco fino in fondo ne chiama un altro che non capisco, che a sua volta ne chiama un altro. Scatole dentro scatole, una matrioska di black box. Finché tutto funziona nessuno la apre, e sembra perfino un vantaggio: guarda quanto andiamo veloci. Il conto arriva dopo, tutto insieme. Il giorno che qualcosa si rompe scopri che nessuno, in tutta la catena, sa più cosa c'è dentro: non il collega che l'ha accettata, non io che l'ho lasciata passare, non la macchina, che non sa di aver risposto. E da lì non si esce con un'altra domanda all'AI: si esce solo tornando a capire, cioè rifacendo tutto in una volta e sotto pressione il lavoro che si era saltato un pezzo alla volta.

Di fronte a questo ho cambiato quello che chiedo, soprattutto ai più giovani. Prima il metro era il codice: quanto ne produci, quanto in fretta. Adesso il metro è il problema: quanto a fondo lo capisci. La domanda che ho imparato a fare non è "cosa fa questo codice?", a quella risponde già la macchina, ma "perché proprio questo, e non qualcosa di più semplice?". È la stessa che avevo fatto al collega al telefono, solo spostata prima: non in review, quando il codice c'è già, ma mentre lo si sta ancora pensando.

In concreto, questo vuol dire non partire dal codice. A un junior chiedo di partire dall'analisi: segnarsi tutte le parti coinvolte, identificare il dominio che la story tocca, disegnare un flusso, e solo da lì cominciare a scrivere. Sembra molto più lento, e probabilmente lo è. Ma è l'unico modo in cui si impara davvero, ed è quello che gli permetterà, un domani, di gestire story molto più complesse senza perdersi in un bicchier d'acqua. Quella lentezza non è tempo perso: è la mappa che gli eviterà di girare a vuoto dopo.

Quello che provo a insegnare è semplice da dire e difficile da fare: il nostro mestiere non è evitare la complessità, è conviverci. Accettarla, prima di tutto. Poi conoscerla, andando a fondo: il perché di una cosa, il come, lo scopo che serve davvero. E infine gestirla. Arrivare al cuore di un problema significa conoscerlo, e conoscerlo è l'unico modo per risolverlo invece di girarci intorno. Quella ref al posto del pattern di hydration non era una scorciatoia: era il cuore del problema, e si vedeva solo a chi al cuore c'era arrivato.

Torno alla slitta. I cani sono la potenza, e l'AI ne mette cinque. Ma la slitta ha bisogno di qualcuno che stia dietro e decida la direzione, e quel qualcuno non corre: progetta. Guarda la mappa, sceglie la rotta, tiene i cani allineati. Crescere, nell'era del codice generato, non vuol dire imparare a correre più forte. I cani corrono già. Vuol dire imparare a guidare.

Perché la velocità, in fondo, non è lo scopo dell'AI. È il prodotto di scarto di un buon design e di una buona progettazione. Arriva da sola, quando hai capito dove stai andando.

Le opinioni e le esperienze condivise in questo articolo sono personali e non rappresentano posizioni ufficiali del mio datore di lavoro. I casi descritti sono volutamente generici e anonimizzati, a scopo divulgativo.

Nell'era dell'AI si legge più di quanto si scrive

Marco Mariotti — Tue, 14 Jul 2026 00:00:00 GMT

C'era una story semplice: scambiare il payload di due endpoint, cioè far sì che due servizi si scambiassero i dati che ricevono in ingresso. Due righe di descrizione, mezza giornata di lavoro se andava lunga. Apro la pull request per la review e trovo cinquanta file modificati. Cosa sta succedendo?

Il primo lavoro non è stato leggere il codice. È stato capire perché una story da due righe era esplosa in cinquanta file.

La story era una riga: scambia A con B. Nella pull request, quella riga c'era. Intorno le si era formata una fetta di sistema intera: un nuovo endpoint di validazione mai chiesto, e dietro di lui i suoi tipi, i suoi errori, le sue traduzioni, il suo aggancio alla pagina. Un "già che ci sono" era diventato una dozzina di file. Più in là, un refactor che rendeva più pulite le chiamate ne aveva aperto un altro: cambiando il modo di inviare i dati, certi campi obbligatori potevano ora mancare, e serviva nuovo codice per gestirli. Nessuno l'aveva chiesto, e quel refactor si era fabbricato da solo un problema nuovo da risolvere.

Niente di tutto questo è pigrizia, e il collega è tutt'altro che incapace: è valido, si è solo lasciato prendere la mano. È la risposta razionale a un costo che è crollato. Quando aggiungere una cosa costava mezz'ora, il "ne vale la pena?" te lo ponevi da solo. Quando costa il tempo di scrivere una frase all'AI, la domanda non scatta più, e ogni "già che ci sono" sembra giustificato. Sotto l'economia c'è qualcosa di più umano: la voglia di fare, di essere veloci e produttivi davanti a tutti, che a costo quasi zero non trova più argine. Ed è proprio quella spinta, buona in sé, che a volte ci fa perdere di vista ciò che conta davvero.

L'attrito che il collega non ha incontrato scrivendo non è sparito. Ha solo cambiato stanza. Ogni file che lui ha aggiunto senza chiederselo, io me lo sono dovuto chiedere in review: serve? c'entra con la story? cosa rompe? Fare quello che la story chiedeva davvero erano quindici minuti di lavoro. Rivedere quella pull request mi è costato quattro ore. Non quattro ore a scrivere: a leggere, a ricostruire, a decidere cosa fosse story e cosa rumore.

È qui che si vede la verità dietro una frase che sembra uno slogan: oggi si legge più di quanto si scrive. Non perché leggere sia diventato un gesto nobile. Perché scrivere è diventato gratis, e ciò che è gratis produrre è caro da verificare. Il lavoro non è calato, e non si è nemmeno solo spostato dalle dita agli occhi: si è moltiplicato lungo il tragitto. Quindici minuti da un lato, quattro ore dall'altro.

Leggere, adesso, somiglia al lavoro del frate amanuense: leggere, catalogare e tramandare il significato di un testo perché non vada perso né frainteso. Con un rovescio. L'amanuense era lento perché copiava a mano, e quella lentezza era fedeltà. Oggi la macchina scrive in un lampo, e la lentezza è tornata dove serve capire, non dove serve produrre. Il mio compito non era ricopiare quel codice: era ritrovare, sotto cinquanta file, quale fosse davvero il testo, e salvarne il senso.

In pratica vuol dire separare ciò che è intenzionale da ciò che è soltanto capitato: la story voluta da una parte, l'accumulo dell'entusiasmo dall'altra. E vuol dire pesare il rischio nascosto. Quelle cinquecento righe in più non sono neutre: sono cinquecento righe che nessuno ha chiesto e che possono rompersi, ognuna una piccola esposizione a un bug che la story non prevedeva. Leggere non è più chiedersi se una riga fa quello che dice, perché quello lo verificano il linter, i test, la stessa AI. È chiedersi quali righe portano un'intenzione e quali un incidente, e quanto ci costa l'incidente.

E l'incidente, qui, un conto ce l'aveva. Non solo tempo: un ritardo reale rispetto a quanto la story era stimata, e qualcosa di più silenzioso, un po' di controllo sul codice che scivola via, cinquecento righe entrate in un modulo nuovo senza che nessuno le avesse davvero volute. Quanto pesa tutto questo quando si ripete e si accumula, è un'altra storia. Per ora basta la prima: leggere è tornato a essere il lavoro lento, e il lavoro lento è tornato a essere il mestiere.

I test c'erano, e passavano. Ma coprivano la parte facile, quella comoda, e lasciavano fuori diverse modifiche e alcune parti nuove per intero. Il verde, qui, è una bugia sottile: non certifica un mondo sbagliato, tace su quello che non ha guardato. Copre il sottoinsieme comodo, e su tutto il resto non dice niente. E un verde parziale, sullo schermo, si legge esattamente come un verde pieno.

Sotto quel verde non c'era una mappa. Nessun elenco di cosa andasse testato e come: solo un muro di codice tenuto insieme da promesse, promesse che se si sgretolano possono far crollare tutto. Quelle promesse erano gli assunti impliciti che le parti non testate funzionassero. Mancava la cosa che serviva più di ogni test: la dichiarazione di cosa quel codice toccava davvero.

Perché una lista di test è prima di tutto la dichiarazione di un dominio. Chi scrive dice: ecco cosa ho toccato, ecco i confini di ciò che cambia, ecco come lo si verifica. Senza quel confine io, in review, non posso controllare la copertura contro l'intento, perché l'intento non è mai stato scritto da nessuna parte.

La responsabilità, qui, è condivisa, ma ha un ordine. Prima è di chi sviluppa: individuare il dominio, esplicitarlo, darne indicazione, così che chi revisiona e chi fa QA possano verificarlo e testarlo a dovere. Poi è di chi fa review: controllare che il dominio dichiarato sia davvero quello, e che non ci siano falle o storpiature. La prima responsabilità disegna la mappa, la seconda la confronta col territorio.

Così la review ha smesso di essere l'ultimo controllo prima del merge ed è diventata un'altra cosa: il punto in cui rimetto l'attrito che l'AI aveva tolto. Non ho corretto virgole. Ho catalogato le modifiche per sapere cosa toccava cosa. Ho chiamato il collega, non per rimproverarlo ma per farmi aiutare a segnare le aree a rischio, perché quel codice ce l'aveva in testa lui. E ho riorganizzato quel blocco unico in story separate, ognuna col suo dominio, ognuna testabile una alla volta.

Quello che ho fatto, in fondo, è stato ridare allo sviluppo la resistenza che la generazione gli aveva risparmiato: rimettere il freno del "questo appartiene alla story? questo che rischio porta? questo come si testa?", una domanda alla volta.

Ed è qui la cosa che è cambiata davvero. L'attrito, prima, era una proprietà del mezzo: scrivere costava, e siccome costava ti autolimitavi da solo, riga per riga. Adesso scrivere non costa più niente, e quel freno non è più nel mezzo. Se lo vogliamo, deve diventare il compito di qualcuno. Il reviewer non è più chi dà l'ultima occhiata: è la persona che rimette, a mano, ciò che la macchina ha tolto. La code review non è più un controllo di fine linea, è il luogo dove si ridefinisce lo scopo.

Resta da dire una cosa onesta: rimettere l'attrito a valle, in review, costa più che averlo a monte. Quattro ore mie contro i quindici minuti di uno sviluppo tenuto nei suoi confini. Il reviewer-attrito è una toppa, non lo stato ideale. Il rimedio vero è farlo tornare dove serve, in chi scrive: dichiarare il dominio, restare nella story, limitarsi da soli. Ma perché torni lì non basta uno strumento, serve un modo di lavorare. E quello si insegna.

Leggere e giudicare, adesso, sono i nostri guardrail. Nel migliore dei casi ci accompagnano lungo la strada, a lato del campo visivo, e quasi non li notiamo. Nel peggiore, ci salvano da un brutto incidente. Ma la nostra responsabilità è agire sul guidatore. Perché agire sul guidatore vuol dire una cosa sola: che giudicare smetta di essere il mestiere di chi revisiona a valle, e diventi il modo di scrivere di chiunque, fin dalla prima riga. I guardrail serviranno sempre, e vanno tenuti solidi. Il punto è far sì che le scelte di chi sta alla guida riducano al minimo le volte in cui devono entrare in azione.

Elogio dell'idea grezza

Marco Mariotti — Sat, 04 Jul 2026 00:00:00 GMT

Passo troppo tempo a scorrere articoli che sembrano scritti tutti dalla stessa mano. Titoli che promettono, paragrafi levigati, e alla fine niente: nessuna idea che resti, nessun punto di vista, nessuno che si sia davvero esposto. Contenuto prodotto per riempire, a una frequenza che nessun pensiero vero riesce a tenere. È un rumore di fondo che cresce, e più cresce meno stiamo dicendo.

The First Draft nasce come reazione a tutto questo. Non un altro contenitore di articoli ottimizzati, ma uno spazio dove le idee arrivano nel loro stato grezzo (la prima bozza, appunto), pronte per essere scritte, discusse, corrette, affinate. Non fingiamo di avere la risposta definitiva: mostriamo il pensiero mentre prende forma.

L'ho creato perché credo che il valore, oggi, non stia nella risposta levigata ma nel ragionamento onesto: quello che parte da un'esperienza reale, ammette i dubbi e si lascia mettere alla prova. Ogni articolo qui nasce da un'esigenza o un'esperienza concreta di chi lo scrive. All'inizio quella voce sarà soprattutto la mia, ma The First Draft nasce per diventare uno sforzo corale, di persone con background professionali, culturali e personali diversi: più teste sullo stesso problema producono attrito, e l'attrito è esattamente ciò che manca al contenuto sfornato in serie.

Di cosa parleremo? Di tutto ciò che merita un ragionamento fatto per bene. Temi tecnici e questioni filosofiche, studio e hobby, l'esperimento e il risultato che ne esce (o che non ne esce). Un articolo può nascere dal codice di un progetto reale e finire col chiedersi cosa significhi delegare una decisione a una macchina. So già, per esempio, che presto un collaboratore scriverà di AI ed etica e un altro di AI e musica: due modi molto diversi di guardare la stessa tecnologia. La regola è una sola: portare al lettore riflessioni, esperienze e risultati veri, non parole messe in fila.

E qui c'è il filo che tiene insieme tutto: tech, human & AI. Tre sguardi che sembrano in tensione e che invece, messi nella stessa stanza, si spiegano a vicenda. La tecnologia come strumento e come vincolo. L'umano che decide, sbaglia, dà un senso. L'AI che accelera, imita, a volte illumina e a volte confonde. Su ogni tema proveremo a tenere aperti tutti e tre, perché è nel loro contrasto che nascono le domande interessanti, quelle che un contenuto costruito per compiacere l'algoritmo non si pone mai.

Parto da un impegno concreto: un articolo ogni dieci giorni, con l'obiettivo di arrivare a una cadenza settimanale man mano che il progetto cresce. Coordinare più persone verso una pubblicazione costante non è semplice, ma è esattamente il tipo di sforzo che vale la pena fare.

Il resto dipende anche da te. The First Draft è una fucina aperta: torna a leggere, commenta, contraddici, porta la tua esperienza. E se hai un'idea che merita di essere scritta per bene, c'è posto anche per la tua voce. Ogni articolo uscirà anche su LinkedIn, dove il tavolo di discussione è già apparecchiato. Le idee migliori, del resto, raramente restano come le avevi scritte la prima volta.

Benvenuto sulla prima bozza. Vediamo dove arriva.