Ingegneri alle prime armi: scrivete il vostro codice prima che lo faccia l'IA

23 luglio 2026 · 8 min di lettura

Di recente ho costruito app native per iOS e Android in poche settimane, rivedendo ogni riga scritta dall'IA e tenendo l'agente dentro paletti rigidi. Entrambe le app funzionano oggi, anche se nessuna delle due è ancora stata pubblicata. Quello che non mi sono portato a casa è una vera padronanza delle piattaforme.

Quel vuoto è l'argomento centrale di questo articolo, ed è rivolto soprattutto a chi è agli inizi di carriera. Un agente ti consegna un risultato funzionante più in fretta di quanto riusciresti a costruirlo da solo. La velocità non è il problema. Il problema è quello che salti per arrivarci.

Ho rivisto ogni riga. Le piattaforme non le ho imparate lo stesso.

Non era il mio primo progetto mobile. Anni fa avevo pubblicato app per Windows Phone, e intorno al 2015 avevo lavorato con Xamarin, Ionic e React Native. Niente di tutto ciò, però, era iOS o Android nativo, ed era comunque un decennio indietro rispetto a strumenti che nel frattempo sono passati per SwiftUI, Jetpack Compose e il modello async/await di Swift. Quando un progetto recente ha richiesto app native su entrambe le piattaforme, da costruire in poche settimane, sapevo che quel divario si sarebbe colmato quasi del tutto grazie a un agente IA per la scrittura di codice.

Non l'ho fatto con leggerezza. Sapevo bene cosa rischi quando lasci un agente libero su una codebase. Così ho rivisto ogni diff riga per riga e ho costruito paletti rigidi per tenere sotto controllo il suo raggio d'azione e il suo output. Il risultato ha retto: entrambe le app hanno raggiunto uno stato funzionante e hanno fatto quello che dovevano fare.

Quello che ho davvero imparato si è diviso nettamente in due. Ogni volta che l'agente azzeccava un'API al primo o al secondo tentativo, rivedevo il codice, capivo cosa faceva, e andavo avanti, senza che quella API diventasse mai davvero mia. Ogni volta che si bloccava, su una manciata di chiamate che nessun prompt riusciva a sistemare, aprivo io stesso la documentazione della piattaforma e le risolvevo alla vecchia maniera. Quelle API ora le conosco a memoria. Le altre riesco ancora a spiegarle, ma non saprei riscriverle senza guardare la documentazione.

Poi si è unito al progetto uno sviluppatore che scriveva Swift in produzione da anni. Ha fatto buone domande quasi da subito, del tipo che una revisione da sola non fa emergere:

• quale pattern fosse idiomatico e non solo funzionante
• dove una chiamata costava prestazioni senza che si notasse
• cosa la piattaforma dava per scontato ma il codice non dichiarava mai

Nel giro di pochi giorni aveva migliorato le prestazioni più di quanto avesse fatto il mio processo di revisione in settimane.

Questa è stata la prova: la revisione affina il giudizio, ma solo lo sforzo diretto costruisce padronanza, e io sono uscito padrone solo delle poche cose in cui l'agente non è riuscito a salvarmi. Per il resto, ero competente da revisore: un risultato reale, ma non quello che costruisce conoscenza della piattaforma.

È la fatica a far attecchire la comprensione

Questa divisione combacia con quello che ho osservato in più di dieci anni alla guida di team di ingegneria: le persone imparano nel punto in cui le cose smettono di essere facili, non prima. So quello che so come ingegnere perché me lo sono conquistato con la fatica, non perché mi è arrivato già assemblato. Ogni ingegnere forte con cui ho lavorato è arrivato lì per la stessa strada: sbattere contro il muro, fallire, e solo dopo capire perché il muro aveva quella forma.

Lo psicologo cognitivo Robert Bjork ha un nome per questo: desirable difficulty. Le sue ricerche hanno scoperto che le condizioni di apprendimento facili (risposte rapide, percorsi lisci, nessun attrito) producono spesso la ritenzione a lungo termine più debole. È lo sforzo di recuperare o costruire da soli una risposta a farla restare. Ricevere la risposta bell'e pronta è ciò che la fa evaporare entro giovedì.

Un agente IA elimina esattamente quell'attrito. Chiedigli di scrivere la funzione, spiegare lo stack trace o abbozzare l'intera feature, e lo fa, in modo pulito, al primo tentativo, quasi sempre. Per chi è già senior nel dominio in cui l'agente lavora, questo soprattutto fa risparmiare tempo: il giudizio esiste già, quindi l'agente si limita a eseguirlo più in fretta. Per chi quel giudizio lo sta ancora costruendo in quel dominio, la stessa facilità elimina l'unico meccanismo che l'avrebbe costruito. Su questo progetto, indipendentemente dagli anni accumulati altrove, io ero il secondo tipo di persona.

Il codice funzionante non dimostra che tu lo capisca

Questo non è un argomento contro l'uso dell'IA per andare veloci. Le app che ho costruito funzionano. Il progetto ha ottenuto quello di cui aveva bisogno, nei tempi richiesti, anche se la pubblicazione resta ancora da fare. Un agente ha reso possibile tutto questo in poche settimane, invece del tempo che mi sarebbe servito per imparare a mano due piattaforme mobile prima di iniziare. Se la consegna è l'unico obiettivo, l'IA vale tutto l'investimento che ci metti.

Ma consegna e competenza sono due valute diverse, e l'IA paga solo nella prima. Quando non fallisce apertamente, nasconde la complessità invece di insegnarla. Che un pattern sia idiomatico o solo funzionante, che una chiamata costi più di un'altra senza che si veda: tutto si risolve dentro il modello, fuori dalla vista, e non diventa mai tuo. È lo stesso punto cieco che permette a un agente di generare un sostituto pulito che non sa spiegare per codice che non aveva mai capito fin dall'inizio.

C'è una controargomentazione onesta a tutto questo: guidare bene un agente è una competenza a sé, e i junior potrebbero essere nella posizione migliore per svilupparla, meglio dei senior. Non hanno passato anni a formarsi opinioni su come dovrebbe apparire una codebase, quindi uno strumento nuovo incontra meno resistenza in loro che in chi deve disimparare vecchie abitudini. È un punto vero, ed è una ragione per mettere gli agenti nelle mani dei junior, non per tenerli lontani dagli strumenti.

Ma è anche una competenza diversa da quella di cui parla questo articolo. Guidare bene un agente ti dà in fretta un risultato funzionante. Non ti insegna perché una chiamata costa più di un'altra, o quale pattern la piattaforma si aspetti davvero, come quello sviluppatore Swift sapeva dire nel giro di pochi giorni. I junior che imparano in fretta lo strumento hanno comunque bisogno di quella seconda competenza, ed essere veloci con lo strumento non gliela consegna più in fretta.

Se ami già questo mestiere abbastanza da sporcarti le mani comunque, l'IA moltiplica quello che riesci a costruire. Se invece ci ricorri perché l'alternativa sembra troppo faticosa, stai scegliendo la strada che ha la garanzia di non renderti migliore nel lavoro per cui vieni pagato.

Cosa dovrebbe fare invece chi è agli inizi di carriera?

Niente di tutto questo significa evitare l'IA, o razionarla dietro una qualche quota arbitraria di fatica. Significa non farne la prima mossa. Tre cose funzionano, e i risultati migliori vengono dal combinarle.

1. Parlane prima con un'IA che si limita a fare domande invece di rispondertele, finché non emergono i vuoti nel tuo ragionamento.
2. Datti il problema prima di aprire un assistente: prova a risolverlo da solo, con un cronometro, e chiama in causa l'IA solo quando hai raggiunto il tuo limite.
3. Oppure apri semplicemente l'editor e inizia a scrivere codice, male, prima di chiedere qualsiasi cosa. La fatica del file vuoto non è tempo sprecato. È l'allenamento.

Roba semplice. Quello che conta è l'ordine: prima la fatica, poi l'agente, non il contrario. Chiedi la risposta solo dopo aver passato abbastanza tempo con il problema da riconoscere quella giusta quando la vedi.

Il settore ha ancora bisogno di junior che diventino senior

Questo va oltre la curva di crescita di un singolo ingegnere. Negli ultimi due anni ho visto responsabili delle assunzioni tagliare pesantemente i ruoli junior, sulla teoria che senior più IA potessero coprire il vuoto. Il settore sta ora riscoprendo un fatto semplice: alcuni dei migliori senior di oggi se lo sono guadagnato con anni di esattamente questo tipo di fatica. Se oggi nessuno fa quel lavoro, domani non ci sarà nessun senior a prendere il loro posto.

Se l'IA riesce già a produrre in poche settimane quello che ha richiesto anni per imparare a fare a mano, continua a usarla. Assicurati solo di aver costruito a mano anche una parte di quello che rilasci. I junior qui hanno già un vantaggio: meno opinioni consolidate, più velocità nell'adottare uno strumento nuovo. Quella stessa apertura funziona altrettanto bene su una piattaforma nuova, quando il prompt esaurisce le risposte. Investine un po' anche nell'editor, non solo nell'agente, e tra dieci anni sarai ancora capace di fare quel lavoro anche senza.