Da qualche anno, a chiunque abbia a che fare con il software capita di sentire due frasi opposte. La prima: "Con l'intelligenza artificiale ormai il software si scrive da solo, gli sviluppatori non servono più". La seconda: "È una moda, non cambia niente". Entrambe sono sbagliate, e prendere decisioni aziendali basate su una delle due costa caro.
Questa guida è per chi non programma ma deve decidere: titolari di PMI, direttori, responsabili di reparto, project manager. Spiega in modo concreto cosa fa bene l'intelligenza artificiale (IA) nello sviluppo di software, dove sbaglia, quali ruoli umani restano indispensabili e come usarla in azienda senza pagarne le conseguenze. Non è una guida contro l'IA: è una guida per usarla con la testa.
Che cosa intendiamo per "IA che scrive codice"
Quando si parla di IA nello sviluppo software si intende, di solito, un assistente di programmazione: un programma che, dato un testo in italiano o in inglese ("scrivi una funzione che calcola lo sconto in base al listino"), produce il codice corrispondente. Questi assistenti vivono dentro gli strumenti di lavoro degli sviluppatori oppure in chat, e sono basati su modelli che hanno letto enormi quantità di codice.
Vale la pena capire come "pensano", perché da lì discende tutto il resto. Un assistente non conosce la vostra azienda, non ha parlato con i vostri operatori, non sa quali sono le eccezioni che avete accumulato in vent'anni di lavoro. Produce la risposta più probabile in base a ciò che ha visto in passato. Quando la vostra richiesta somiglia a qualcosa di molto comune, la risposta è spesso ottima. Quando è specifica, ambigua o piena di eccezioni, la risposta può essere plausibile e sbagliata allo stesso tempo, scritta con la stessa sicurezza.
Cosa sa fare bene
Sarebbe disonesto negarlo: gli assistenti di programmazione sono strumenti molto utili, e un buon professionista oggi li usa quotidianamente. Funzionano bene su compiti circoscritti, ripetitivi e ben noti:
- Codice ripetitivo. Schermate di inserimento dati, funzioni che leggono e scrivono su un database, strutture standard. Quello che prima richiedeva ore, spesso richiede minuti.
- Prime bozze. Un punto di partenza da rivedere è più veloce di una pagina bianca.
- Spiegazioni. Capire un pezzo di codice scritto da altri, o un messaggio di errore, diventa molto più rapido.
- Traduzioni da un linguaggio all'altro, trasformazioni di formato, conversioni di dati.
- Test. Generare una prima serie di prove automatiche da affinare.
- Documentazione. Descrivere cosa fa un blocco di codice, preparare note tecniche.
Per le aziende questo significa che alcune attività costano meno e vanno più veloci. È un vantaggio reale. Il punto è capire dove si ferma.
Dove sbaglia (e perché è un problema)
Non conosce il contesto
Un gestionale non è un insieme di funzioni indipendenti: ogni parte dipende dalle altre e dalle regole dell'azienda. Un assistente può scrivere una funzione corretta in astratto, ma sbagliata per il vostro caso, perché non sapeva che i resi si gestiscono in un certo modo, o che quel cliente ha uno sconto speciale. Sapere cosa chiedere, e accorgersi che manca qualcosa, è un lavoro umano.
Inventa con sicurezza
Gli assistenti possono produrre risposte che sembrano corrette e non lo sono: funzioni che non esistono, comandi che non fanno ciò che dicono, soluzioni che funzionano nell'esempio e si rompono con i dati reali. Gli addetti ai lavori le chiamano "allucinazioni". Per chi non sa leggere il codice, l'errore è invisibile finché non causa un danno.
Trascura sicurezza e casi limite
Il codice generato tende a risolvere il caso normale. Sicurezza, gestione degli errori, comportamento sotto carico, dati inattesi sono spesso trascurati, perché nessuno li ha chiesti. È il genere di difetto che non si vede in una dimostrazione e si vede in produzione, magari dopo mesi, magari con un cliente arrabbiato.
Non mantiene coerenza nel tempo
Un software è un organismo che cresce per anni. Se ogni pezzo viene prodotto da richieste diverse, senza una regia, il risultato è un insieme di parti scritte in stili diversi, con soluzioni duplicate e dipendenze nascoste. Funziona il primo giorno, e diventa sempre più difficile da modificare. È il cosiddetto debito tecnico: un costo differito, che si paga con gli interessi.
Non risponde di nulla
Quando il software sbaglia e un ordine parte con il prezzo errato, o i dati di un cliente vengono esposti, qualcuno deve risponderne: a voi, ai vostri clienti, a volte a un'autorità. Un'IA non firma un contratto, non ha una responsabilità professionale, non risponde di un danno. Questo da solo basterebbe a chiarire chi non può essere sostituito.
Il fenomeno del "vibe coding" e perché le aziende lo scoprono caro
Negli ultimi tempi si è diffusa una pratica chiamata, con un certo understatement, vibe coding: descrivere a un'IA ciò che si vuole e accettare il risultato senza leggerlo, andando "a sensazione". Per un prototipo, una demo, un esperimento personale può essere divertente e persino utile. Il problema nasce quando quel prototipo diventa, per inerzia, il software con cui l'azienda lavora.
Lo scenario si ripete con una certa regolarità:
- Una persona non tecnica, o un team senza esperienza, costruisce un'applicazione con un assistente. Dopo pochi giorni "funziona".
- Viene messa in uso. Le prime settimane vanno bene.
- Arrivano i casi reali: dati sporchi, utenti che fanno cose inattese, richieste di modifica.
- Ogni modifica rompe qualcosa. Nessuno sa come è fatto il sistema. L'assistente, a cui si chiede di correggere, produce correzioni che ne creano altre.
- Si chiama un professionista, che trova codice disordinato e dati a rischio, e deve decidere se ripulire o rifare da zero.
In questa fase il costo è spesso superiore a quello di un progetto fatto bene all'inizio, perché a quello che si doveva fare si somma ciò che si deve disfare. Non è un fenomeno da demonizzare: è il prezzo di aver saltato le fasi che non si vedono, cioè progettazione, verifica, regia.
Un esempio concreto: due strade per lo stesso progetto
Prendiamo un'azienda che vuole un'area riservata dove i clienti consultano ordini e documenti.
Prima strada: "facciamolo con l'IA, da soli". Un collaboratore volenteroso descrive a un assistente ciò che vuole. In due giorni c'è una schermata di accesso, un elenco ordini, qualche documento scaricabile. L'entusiasmo è alto. Poi emergono i problemi: un cliente riesce a vedere gli ordini di un altro cambiando un numero nell'indirizzo; la password è salvata in modo non sicuro; i documenti sono accessibili a chiunque abbia il link; nessuno ha previsto cosa fare quando un utente cambia email. Il collaboratore non sa come correggere e le soluzioni proposte dall'assistente peggiorano il quadro. Dopo tre mesi, l'area è sospesa.
Seconda strada: persone del mestiere, con l'IA come strumento. Un analista passa due giornate con voi per capire chi sono i clienti, cosa devono vedere, come si gestiscono i documenti. Un progettista disegna i dati e i permessi. Uno sviluppatore senior costruisce il sistema usando un assistente per le parti ripetitive e controllando ogni riga che finisce in produzione. Un tester prova gli scenari difficili, tra cui "cosa succede se cambio il numero nell'indirizzo". Un coordinatore tiene insieme tempi e comunicazione. L'area costa di più nei primi giorni e meno nei mesi successivi, e il costo complessivo è inferiore, perché non ci sono demolizioni.
Nella seconda strada l'IA c'è, ed è utile: ha ridotto il tempo di scrittura. Ma è un utensile nelle mani di chi sa cosa deve costruire.
Chi fa cosa: i ruoli che restano insostituibili
Un progetto software richiede, secondo la dimensione, alcune figure distinte. A volte una persona ne ricopre più di una, ma le funzioni restano.
L'analista
Ascolta le persone, osserva come si lavora davvero, individua i problemi e le eccezioni, e li trasforma in requisiti scritti. È il ruolo che separa "un software che fa cose" da "un software che serve". Un'IA può aiutare a organizzare appunti e a redigere documenti, ma non siede nel vostro ufficio, non si accorge che l'operatore in magazzino aggira il processo ufficiale perché è troppo lento, non sa cosa non le viene detto.
Il progettista (o architetto)
Decide come è fatto il sistema: quali parti, come comunicano, dove stanno i dati, come si protegge ciò che è sensibile, come si potrà modificare in futuro. Sono decisioni con conseguenze di anni. Un'IA può proporre alternative, ma sceglierne una richiede di conoscere i vincoli reali del progetto: budget, competenze del team, tempi, rischi.
Lo sviluppatore
Scrive il software, oggi spesso con l'aiuto dell'IA. Il suo valore sta meno nella velocità di digitazione e più nel giudizio: capire cosa chiedere all'assistente, riconoscere un errore plausibile, rifiutare una soluzione fragile, mantenere il codice coerente. Per questo gli sviluppatori esperti restano molto richiesti, mentre il lavoro puramente esecutivo si è ridotto. Chi cerca un profilo di questo tipo può cercare in elenchi dedicati, come i profili di LancerJob, che indicano stack, esperienza e disponibilità.
Il tester e lo specialista di sicurezza
Pensano come un utente maldestro e come un malintenzionato. Verificano ciò che nessuno ha chiesto: dati strani, accessi non autorizzati, carichi elevati. L'IA può generare scenari di prova, ma qualcuno deve decidere quali contano e interpretare i risultati.
Il project manager
Tiene insieme persone, tempi e priorità; negozia le modifiche; fa emergere i problemi prima che diventino crisi; è l'interlocutore del cliente. L'IA può redigere verbali e aggiornare elenchi di attività. Non può negoziare con voi, né prendere una decisione difficile quando due richieste confliggono.
Il responsabile del risultato
In ogni progetto serio c'è una persona o un'azienda che risponde del lavoro: lo dichiara nel contratto, si assume i rischi, interviene quando qualcosa va storto. È la ragione per cui, in ultima analisi, si paga un professionista e non solo un risultato.
Cosa sta davvero cambiando nel mercato
Sarebbe scorretto dire che nulla è cambiato. Alcune cose sono cambiate e vale la pena conoscerle:
- Il lavoro ripetitivo costa meno e richiede meno tempo. Chi vendeva soprattutto codice standard sente la pressione.
- Il valore si sposta verso progettazione, verifica e responsabilità. Capire il problema e garantire la qualità pesano di più sul totale.
- Cresce il lavoro di integrazione e di recupero. Molte aziende hanno bisogno di inserire funzioni di IA nei propri sistemi in modo sicuro, e altre devono mettere ordine in software prodotti con troppa leggerezza.
- Le competenze di un professionista esperto valgono di più, perché sono quelle che permettono di usare bene l'IA e di accorgersi quando sbaglia.
Chi sostiene che "lo sviluppatore non serve più" confonde la scrittura del codice, che si è accelerata, con lo sviluppo di software, che è un lavoro più ampio.
Come usare bene l'IA in un progetto aziendale: otto regole
Se siete un'azienda che commissiona o sviluppa software, queste regole vi evitano la maggior parte dei problemi.
- Usatela come strumento di chi sa, non come sostituto di chi non c'è. L'IA amplifica la competenza esistente; se manca la competenza, amplifica l'errore.
- Mai codice in produzione senza revisione umana. Ogni riga che finisce in un sistema reale deve essere letta e compresa da una persona.
- Non date dati riservati agli assistenti senza verificare le condizioni d'uso. Dati dei clienti, segreti commerciali, credenziali: capite dove vanno e come vengono trattati, anche per il GDPR.
- Mantenete test automatici. Sono la rete di sicurezza che permette di cambiare il software senza paura. Con l'IA che scrive più codice, i test diventano più importanti, non meno.
- Tenete una regia unica. Qualcuno deve conoscere l'insieme del sistema e decidere come cresce.
- Documentate le decisioni. Il perché di una scelta vale più del codice che ne deriva.
- Pretendete di avere accesso al codice e alla documentazione. Siete voi i proprietari del sistema che usate.
- Misurate i risultati. Se un fornitore dichiara di essere più veloce grazie all'IA, chiedete che questo si veda in tempi, qualità e costi.
Dieci domande da fare a un fornitore sull'uso dell'IA
Quando valutate un fornitore, un freelance o un'agenzia, chiedete:
- In quali fasi usate assistenti di IA, e in quali no?
- Chi controlla il codice prodotto con l'IA, e come?
- Quali dati nostri passano per strumenti di IA, e a quali condizioni?
- Come garantite la qualità, oltre al fatto che "funziona nella demo"?
- Quali test automatici prevedete?
- Come gestite la sicurezza del codice generato?
- Chi è il responsabile tecnico del progetto?
- Il codice sarà documentato e comprensibile a un altro professionista?
- Come si riflette l'uso dell'IA sul preventivo? Dove vedo il risparmio?
- Cosa succede se un componente generato dall'IA risulta difettoso dopo la consegna?
Le risposte contano meno del modo in cui vengono date. Un professionista serio le affronta con naturalezza; chi le elude, o promette che l'IA "fa tutto", non ha una risposta.
L'IA e i costi: cosa aspettarsi
Un punto che interessa a tutti: l'IA abbassa il prezzo del software? In parte, sì, e soprattutto sulla fase di scrittura del codice. In una ripartizione tipica di un progetto, questa fase pesa grosso modo il 40% del totale; il resto è analisi, progettazione, test, coordinamento, migrazione dei dati, formazione. Se anche la scrittura del codice costasse un terzo in meno, il risparmio sul totale resterebbe a una cifra contenuta, e solo se il progetto è fatto di lavoro ripetitivo.
Per questo, diffidate di chi vi propone un software complesso a una frazione del prezzo di mercato in nome dell'IA: o sta tagliando le fasi che non si vedono, o sta preparando il terreno per una seconda fattura. Per capire come si compone il costo di un progetto, leggete Quanto costa sviluppare un gestionale su misura.
Per chi lavora nel software: dove posizionarsi
Se siete sviluppatori o professionisti del software, il messaggio non è "avete poco da fare", ma "il valore è altrove". Le competenze che il mercato premia oggi sono quelle che l'IA non fornisce da sola:
- capire il problema del cliente e tradurlo in requisiti;
- progettare sistemi che reggano nel tempo;
- verificare ciò che l'IA produce, e saperlo correggere;
- conoscere un dominio (logistica, sanità, produzione) e le sue regole;
- comunicare in modo chiaro con persone non tecniche;
- assumersi la responsabilità del risultato.
Il profilo che emerge è meno quello dell'esecutore e più quello del consulente tecnico. Curare il proprio profilo professionale per rendere visibili queste competenze è parte del lavoro: ne parliamo in Come curare il profilo di un freelance .NET.
Domande frequenti
L'IA sostituirà gli sviluppatori? Sta cambiando il loro lavoro, non lo sta eliminando. Riduce il tempo dedicato al codice ripetitivo e aumenta il peso di progettazione, verifica e responsabilità. I professionisti che sanno usarla bene sono più produttivi; quelli che si limitavano a eseguire compiti standard sentono più pressione.
Posso far costruire il mio gestionale a un assistente di IA? Potete ottenere un prototipo, utile per capire cosa volete. Per un sistema che gestisce ordini, dati dei clienti e processi reali, serve la regia di persone competenti, con progettazione, verifica e responsabilità.
Quanto risparmio usando l'IA? Dipende dal progetto. Il risparmio è reale sulle parti ripetitive, ma limitato sul totale, perché la maggior parte del costo sta in attività che richiedono persone. Diffidate delle promesse di riduzioni drastiche.
Se il codice lo scrive l'IA, di chi è? Dipende dal contratto con il fornitore e dalle condizioni d'uso dello strumento. È una domanda da porre prima di iniziare e da far chiarire per iscritto, preferibilmente con un consulente legale.
Come capisco se un fornitore usa l'IA bene? Dal modo in cui parla di verifica, test e responsabilità. Chi la presenta come strumento sotto controllo umano è più affidabile di chi la presenta come sostituto di tutto.
Serve ancora un project manager se c'è l'IA? Sì. Coordinare persone, negoziare priorità e gestire le aspettative sono attività che richiedono un interlocutore umano responsabile.
In sintesi
- L'IA è un acceleratore molto utile per il codice ripetitivo, le bozze, i test e la documentazione.
- Non conosce la vostra azienda, può inventare con sicurezza, trascura sicurezza e casi limite, e non risponde di nulla.
- Il "vibe coding" produce prototipi, non sistemi: portarlo in produzione senza regia costa più di farlo bene fin dall'inizio.
- I ruoli di analista, progettista, sviluppatore, tester, project manager e responsabile del risultato restano necessari.
- Il risparmio dell'IA sul costo totale è reale ma parziale: la scrittura del codice è solo una parte del lavoro.
- Per usarla bene: revisione umana, test automatici, regia unica, attenzione ai dati e codice di vostra proprietà.
Se cercate persone del mestiere per un progetto .NET, o volete farvi trovare come professionista, iscrivetevi alla waitlist di LancerJob: è il marketplace italiano dedicato solo allo stack Microsoft.