L'AI sta producendo donkey engineer?
L'impressione che sto avendo è che l'AI stia formando sviluppatori capaci di far uscire codice da uno strumento ma non di giudicarlo. Cos'era l'abc, e perché decide ancora chi risolve il guasto.
11 Sept 2026 · 4 min read · Read in English
L'impressione che sto avendo, e resta un'impressione perché non ho dati che lo dimostrino, è che l'AI stia producendo una categoria nuova di sviluppatori. Un nome ce l'ho: donkey engineer. La definizione è breve. Uno che sa far uscire del codice da uno strumento, ma non sa giudicare quello che ne esce.
Non è una categoria di incapaci. È gente che consegna, che chiude i ticket, che in molti casi lavora più in fretta di chi ha dieci anni di esperienza. Il punto è cosa succede quando quello che esce dallo strumento è sbagliato, perché lì in dieci minuti si vede chi ha capito quello che ha consegnato e chi no.
L'abc che è diventato opzionale
Ci sono cose che fino a tre anni fa erano il minimo sindacale per chiunque
scrivesse React o React Native. La sintassi di una useEffect e il perché
dell'array di dipendenze. Il fatto che un effect che apre qualcosa deve
chiuderlo. La differenza tra useMemo, che esegue quello che gli passi e
conserva il risultato, e useCallback, che non esegue niente e conserva la
funzione, per dare a chi la riceve sempre lo stesso riferimento.
Non è una finezza da specialisti, è la prima settimana di React. Oggi capita di
trovare persone con anni di esperienza dichiarata che ti dicono che
useCallback e useMemo fanno più o meno la stessa cosa, e che davanti a un
editor vuoto non riescono a scrivere un effect con la sintassi giusta. Non
perché l'abbiano dimenticata: perché non hanno mai avuto un motivo per guardarci
dentro, visto che quelle righe le ha sempre scritte qualcos'altro.
Cosa intendo per donkey engineer
Il nome è antipatico e me ne rendo conto. L'asino porta il peso, non sceglie la strada. Il donkey engineer trasporta codice da una parte all'altra senza decidere niente: prompt, output, incolla, il test passa, avanti. Finché il percorso è quello previsto arriva in fondo prima di tutti.
Non si applica a chi ha smesso di scrivere codice a mano ma sa esattamente cosa sta leggendo. Quello è un altro mestiere, è legittimo, ed è probabilmente il mestiere verso cui stiamo andando tutti. La differenza non sta in quanto codice scrivi di persona, sta in quanto ne capisci quando lo leggi.
La differenza si vede quando si rompe qualcosa
Il codice generato funziona quasi sempre. Il problema è il quasi. Un'app perde una subscription quando va in background, una lista si ridisegna a ogni tap e i telefoni di fascia bassa iniziano a scaldare, una race condition compare solo sotto rete lenta e solo per gli utenti che hanno il token quasi scaduto.
In quei casi il modello ti propone tre soluzioni plausibili. Sono scritte bene tutte e tre, e due sono sbagliate. Per scegliere serve sapere come funziona quella cosa sotto, e quella conoscenza non te la dà nessuno strumento nel momento in cui ti serve: o ce l'hai già, o passi la notte a provare alternative finché una smette di dare errore. Chi ha l'abc ci mette venti minuti. Chi non ce l'ha ci mette due giorni e spesso lascia dietro un altro problema.
Non è un discorso contro l'AI
Lavoro con un agente tutti i giorni e non ho nessuna intenzione di tornare indietro. La direzione è chiara e mi sembra pure giusta: il valore si sposta dallo scrivere il codice al saper guidare lo strumento che lo scrive, dal battere sui tasti al decidere cosa va costruito e come.
Solo che guidare uno strumento vuol dire giudicare quello che produce. Se non
distingui una useMemo messa lì per abitudine da una che sta evitando un
ricalcolo costoso, non stai revisionando un diff, lo stai accettando. Se non sai
perché un effect ha bisogno di un cleanup, il giorno che l'app perde memoria non
hai neanche il vocabolario per formulare il problema. Il modello scrive più in
fretta di chiunque, ma la responsabilità di quello che va in produzione resta di
chi firma la pull request.
Come si evita
Tre cose che continuo a fare io, senza nessuna pretesa di metodo.
Leggo il diff prima di accettarlo, sempre, anche quando ho fretta e soprattutto quando ho fretta. Se non capisco una riga mi fermo su quella riga.
Chiedo al modello perché, non solo cosa. La risposta la controllo, perché a volte è inventata, ma la domanda mi costringe a formulare il dubbio invece di saltarlo.
Ogni tanto scrivo qualcosa a mano, senza completamento e senza chat, guardando solo la documentazione. Non per disciplina, ma perché è l'unico modo che conosco per misurare quanto mi sto arrugginendo.
Che l'AI ci sostituisca non mi preoccupa più di tanto. Mi preoccupa di più l'idea di una generazione che impara a produrre senza imparare a capire, e che ce ne accorgiamo il giorno in cui si rompe qualcosa di grosso e in stanza non c'è più nessuno capace di spiegare perché.


