Introduzione: la frase sbagliata che sta circolando

“Gli sviluppatori non serviranno più.”

È una frase efficace, ma tecnicamente imprecisa. Il problema non è che gli sviluppatori spariscono: il problema è che una certa idea di sviluppatore è già superata.

Se entriamo in aula oggi e chiediamo a uno studente cosa significa “saper programmare”, la risposta tipica è: conoscere un linguaggio, scrivere funzioni, risolvere bug. Questo modello è stato valido per decenni. Oggi non lo è più.

Strumenti come GitHub Copilot e ChatGPT hanno spostato il baricentro: la scrittura del codice non è più il collo di bottiglia.

Il collo di bottiglia è diventato un altro: capire cosa costruire e come orchestrarlo.

---

Lezione 1 — Evoluzione reale del ruolo

Immaginiamo tre sviluppatori.

Il primo è quello “classico”. Scrive tutto da zero, conosce bene la sintassi, è veloce nel debugging. Il suo valore è proporzionale alla quantità e qualità del codice che produce.

Il secondo è quello “assistito”. Usa l’AI per accelerare. Non scrive più tutto, ma sa chiedere, correggere, rifinire. Produce di più, più velocemente.

Il terzo è quello che ci interessa davvero: non parte dal codice, ma dal sistema. Quando affronta un problema non si chiede “che funzione devo scrivere?”, ma “che flusso devo progettare?”.

Questo terzo sviluppatore lavora in modo completamente diverso. Se deve costruire un sistema di risposta automatica, non apre subito l’IDE. Si ferma prima. Definisce il contesto, i vincoli, le regole, i rischi. Solo dopo entra nel codice, e spesso delega gran parte della scrittura all’AI.

Quello che cambia non è lo strumento. È il punto di partenza mentale.

---

Lezione 2 — Il limite strutturale dell’AI (e perché sei ancora necessario)

C’è un equivoco pericoloso: pensare che l’AI “capisca”.

In realtà, sistemi come GPT-4 funzionano per probabilità, non per comprensione. Producono output plausibili, non necessariamente veri o corretti.

Questo significa che possono generare codice funzionante, ma non sanno se quel codice è adatto al contesto in cui verrà usato.

Facciamo un esempio concreto. Chiedi a un modello AI di creare una funzione per validare un input utente. Ottieni qualcosa di tecnicamente corretto. Ma quel codice non sa nulla di:

• normative (es. GDPR)
• implicazioni legali
• rischi di sicurezza specifici del tuo sistema
• priorità di business

L’AI produce una risposta. Tu devi stabilire se è utilizzabile.

Qui avviene il passaggio chiave: il developer non è più chi scrive, ma chi decide cosa è accettabile.

---

Lezione 3 — Dal codice al sistema

Ora dobbiamo affrontare il vero cambio mentale.

Uno sviluppatore tradizionale lavora per unità isolate: funzione, classe, endpoint. Risolve problemi locali.

Uno sviluppatore evoluto lavora per sistemi: flussi, interazioni, dipendenze.

Prendiamo un caso concreto: un chatbot aziendale.

Un approccio tradizionale si concentrerebbe su come ricevere input e restituire output. Un approccio moderno inizia da domande completamente diverse:

-Cosa deve sapere il sistema?
-Qual è il contesto informativo?
-Quali errori non sono accettabili?
-Quando il sistema deve fermarsi invece di rispondere?

A questo punto emerge una struttura implicita:

l’utente scrive → il sistema interpreta → recupera contesto → genera risposta → valida → restituisce

Questo non è più codice. È progettazione di comportamento.

Il codice diventa uno strumento secondario, spesso delegabile.

---

Lezione 4 — L’AI come infrastruttura

Per capire davvero il cambiamento, bisogna fare un parallelo storico.

Un tempo il database era un componente opzionale. Poi è diventato centrale. Oggi nessuno progetta un sistema senza pensare al database.

Lo stesso sta accadendo con l’AI.

Non è più un “extra”. È un layer infrastrutturale.

Quando progetti un sistema moderno, stai implicitamente decidendo:

• dove entra l’AI
• che ruolo ha
• quanto è autonoma
• come viene controllata

Immaginiamo un assistente legale automatizzato. Senza AI, il sistema sarebbe rigido, basato su regole statiche. Con l’AI, può interpretare linguaggio naturale, adattarsi, generare risposte complesse.

Ma questa flessibilità introduce rischio. E il rischio deve essere progettato.

Ecco perché il developer diventa architetto: non gestisce solo funzionalità, ma equilibri tra potenza e controllo.

---

Lezione 5 — Dove si crea valore oggi

Qui bisogna essere molto chiari, anche se può risultare scomodo.

Scrivere codice, di per sé, sta diventando una commodity.

Se una competenza può essere automatizzata facilmente, il suo valore di mercato tende a diminuire. Non sparisce, ma si ridimensiona.

Il valore si sposta altrove.

Si sposta nella capacità di capire il problema prima di risolverlo. Si sposta nella progettazione di sistemi robusti. Si sposta nella gestione dell’incertezza introdotta dall’AI.

Immaginiamo due sviluppatori.

Il primo scrive tutto manualmente, con precisione e competenza. Il secondo usa l’AI per generare gran parte del codice, ma dedica il suo tempo a progettare, validare, migliorare il sistema.

Nel breve periodo possono sembrare equivalenti. Nel medio periodo, il secondo diventa insostituibile.

Non perché sa usare meglio uno strumento, ma perché lavora a un livello più alto.

---

Esercizio guidato (da fare seriamente)

A questo punto, invece di aggiungere teoria, è necessario forzare il cambio mentale.

Immagina di dover costruire un sistema che risponde automaticamente alle email.

Se il tuo primo impulso è pensare a funzioni o librerie, sei ancora nel modello vecchio.

Fermati prima.

Pensa a cosa deve succedere davvero. Un’email arriva. Deve essere classificata. Deve essere interpretata. Deve essere generata una risposta coerente con il tono aziendale. Devono essere evitati errori critici. Deve esserci un controllo finale.

Stai già progettando un sistema, anche senza scrivere una riga di codice.

Questo è il punto di svolta.

---

Conclusione del modulo

Il cambiamento non è tecnico. È cognitivo.

Non ti viene richiesto di sapere di più codice. Ti viene richiesto di pensare in modo diverso.

Se continui a identificarti come “chi scrive codice”, l’AI ti mette in difficoltà.

Se inizi a vederti come “chi progetta sistemi intelligenti”, l’AI diventa il tuo moltiplicatore.

Questo modulo serve esattamente a questo: spostarti di livello.

CASI STUDIO REALI (AI Developer Mindset)

---

🔎 Caso Studio 1 — Chatbot aziendale che “funziona”… finché non rompe tutto

Contesto

Un’azienda implementa un chatbot per rispondere ai clienti usando ChatGPT.

Il developer realizza:

• endpoint API
• integrazione con il modello
• UI base

Il sistema viene messo online in pochi giorni.

Problema reale (dopo 2 settimane)

• Il chatbot inventa informazioni sui prodotti
• Promette sconti inesistenti
• Risponde con tono incoerente rispetto al brand

Analisi tecnica (quella che uno sviluppatore evoluto deve fare)

Il problema NON è nel codice.

Il problema è che:

• non esiste un contesto controllato
• non esistono regole di risposta
• non esiste validazione dell’output
• non esiste gestione degli errori AI

Dove ha fallito il developer

Ha pensato in termini di:
👉 “integrazione API funzionante”

Invece doveva pensare:
👉 “sistema affidabile”

Come si sarebbe progettato correttamente

Uno sviluppatore evoluto avrebbe definito:

• fonti di verità (catalogo prodotti)
• limiti del modello (non può inventare)
• regole (se non sai → non rispondere)
• validazione (controllo su output)

Insight didattico

👉 L’AI senza architettura è pericolosa
👉 Il codice funzionante non significa sistema corretto

---

⚖️ Caso Studio 2 — Assistente legale automatizzato

Contesto

Startup vuole creare un sistema che risponde a domande legali.

Usa GPT-4 per generare risposte.

Approccio iniziale (sbagliato)

• input utente → AI → risposta → output

Semplice, veloce… e completamente rischioso.

Problema reale

Il sistema:

• cita normative inesistenti
• interpreta male casi complessi
• dà consigli non validi legalmente

Qui il punto è critico

Nel dominio legale:
👉 l’errore non è tollerabile

---

Come ragiona un AI Developer

Non si chiede:
👉 “come genero la risposta?”

Si chiede:
👉 “quando NON devo generarla?”

Quindi progetta:

• sistema di recupero fonti (documenti reali)
• citazione obbligatoria
• soglia di confidenza
• fallback umano

---

Architettura corretta (semplificata)

utente → interpretazione → recupero documenti → AI → validazione → output

---

Insight didattico

👉 Più il dominio è critico, più il developer è centrale
👉 L’AI non sostituisce responsabilità

---

🏢 Caso Studio 3 — Automazione email aziendale

Contesto

Azienda vuole automatizzare risposte email.

Un developer crea:

• script parsing email
• risposta generata da AI

Funziona perfettamente nei test.

---

Problema reale (produzione)

• risposte troppo informali
• email ambigue interpretate male
• clienti insoddisfatti

---

Errore concettuale

Il developer ha progettato:
👉 una funzione

Non ha progettato:
👉 un comportamento

---

Come si progetta davvero

Uno sviluppatore evoluto definisce:

• classificazione email (richiesta, reclamo, info)
• tono aziendale
• escalation (quando serve umano)
• limiti di autonomia

---

Insight didattico

👉 L’AI non sbaglia codice
👉 Sbaglia contesto

---

🧠 MINI TEST DI VERIFICA (livello developer)

Non sono domande nozionistiche. Servono a verificare il cambio mentale.

---

TEST 1 — Comprensione del ruolo

Domanda:

Un sistema AI genera codice perfettamente funzionante ma non adatto al contesto aziendale.

Chi è responsabile?

A) L’AI
B) Il modello
C) Il developer
D) Nessuno

---

TEST 2 — Pensiero sistemico

Scenario:

Devi progettare un sistema AI per customer support.

Qual è la prima cosa da fare?

A) Scegliere il modello AI
B) Scrivere le API
C) Definire il flusso e i vincoli
D) Creare il database

---

TEST 3 — Individuazione errore

Scenario:

Sistema:
utente → AI → risposta → output

Il sistema genera risposte sbagliate.

Dove è il problema principale?

A) Codice backend
B) Modello AI
C) Mancanza di validazione e contesto
D) UI

---

TEST 4 — Mentalità

Domanda aperta:

Spiega la differenza tra:
“scrivere codice che funziona”
 “progettare un sistema affidabile”

 

---

TEST 5 — Caso pratico

Scenario:

Un chatbot risponde sempre, anche quando non ha informazioni.

Cosa implementi?

(non una sola risposta corretta, ma deve includere:)

• fallback
• “non so” gestito
• controllo output
• limiti AI