Fondamenti AI per lo sviluppo software

1. Generative AI e LLM: come funzionano ad alto livello

Un Large Language Model (LLM) è una rete neurale addestrata su enormi quantità di testo per prevedere il token successivo data una sequenza in ingresso. Detta così è un'affermazione modesta, ma da questa capacità apparentemente semplice emergono comportamenti complessi: completamento di codice, traduzione, sintesi, ragionamento a catena, uso di strumenti.

I pezzi fondamentali da conoscere

• Tokenizer. Il testo viene spezzato in unità subverbali (token). Un token non è una parola: nelle lingue latine un token medio è ~4 caratteri. Tutto ciò che entra o esce dal modello si misura in token, e i costi si calcolano in token.
• Context window. Il numero massimo di token che il modello può "vedere" in una singola chiamata. I modelli moderni arrivano a 200k–2M token. È il vincolo fisico principale del prompting.
• Parametri. I "pesi" del modello, imparati in training. Sono il cervello — ma sono anche ciò che rende impossibile cambiare fatti dopo il training senza retraining o fine-tuning.
• Temperatura e sampling. Parametri che controllano la casualità dell'output. Temperatura 0 → output quasi deterministico (ideale per coding); temperatura alta → output più creativo.
• System prompt. Istruzioni di alto livello che definiscono ruolo e vincoli del modello per l'intera conversazione. È il punto dove si codificano standard di team.

Training in due fasi

I modelli conversazionali moderni sono il risultato di due fasi:

1. Pre-training: il modello impara dal testo grezzo a predire il prossimo token. Da qui viene la conoscenza di linguaggio, fatti, strutture di codice.
2. Post-training: fine-tuning supervisionato e reinforcement learning from human feedback (RLHF) o tecniche simili, che trasformano il modello in un assistente utile e allineato. Da qui viene la capacità di seguire istruzioni.

Per chi sviluppa software, la conseguenza pratica è: il modello "sa" codice e linguaggi fino al suo knowledge cutoff. Per librerie nuove, API cambiate o stack proprietari, serve contesto esterno (documentazione in prompt, retrieval, tool use), non "sperare che lo sappia".

2. Limiti intrinseci, rischio e controllo

La differenza tra un'adozione di successo e una frustrazione diffusa sta spesso nel capire dove gli LLM sbagliano sistematicamente.

Allucinazioni

Un LLM genera testo plausibile, non testo vero. Quando non ha informazioni sufficienti, produce comunque qualcosa che "suona giusto". In coding questo si manifesta come: API inventate, import che non esistono, firme di funzioni sbagliate, parametri di configurazione plausibili ma inesistenti.

Mitigazione: fornire documentazione in contesto, esigere citazioni, far eseguire test, lasciare che gli agenti possano leggere i file invece di "immaginarne" il contenuto.

Knowledge cutoff e bias temporale

Ogni modello ha una data limite oltre la quale non ha informazioni. Per librerie come React, .NET, framework di test, ORM, anche 6 mesi sono sufficienti a rendere alcune risposte sbagliate. Mitigazione: retrieval, MCP server che leggono docs aggiornate, pattern di RAG.

Non sono deterministici

Lo stesso prompt può produrre output diversi. Mitigazione: temperatura bassa, prompt molto vincolati, validazione dell'output con test/schema, idempotenza nei tool.

Non ragionano "davvero"

I modelli moderni con reasoning (pensiero esteso, chain-of-thought interno) migliorano molto la qualità, ma restano sensibili a come il problema viene presentato. Un problema difficile mal inquadrato resta sbagliato. Mitigazione: scomposizione del task, pianificazione esplicita, verifiche intermedie.

Privacy e data leakage

Ogni token che esce dal perimetro aziendale è un potenziale rischio. Serve una policy chiara su cosa può andare in cloud, cosa richiede tenant dedicato, cosa deve restare on-prem/self-hosted. Il modulo 3 affronta questo tema in dettaglio.

3. Agenti e automazione: planning, execution, feedback loop

Un agente è un LLM messo in grado di osservare uno stato, pianificare, eseguire azioni attraverso strumenti (tools) e iterare fino al raggiungimento di un obiettivo. Dal punto di vista architetturale è un ciclo:

loop:
  osservazione (stato, risultato azione precedente)
  pianificazione (cosa fare prossimo)
  selezione tool + argomenti
  esecuzione tool
  aggiornamento contesto
  se obiettivo raggiunto → stop

Questo ciclo è ciò che rende agenti come Claude Code o gli agenti di Cursor qualitativamente diversi da un semplice chat assistant: possono leggere il tuo repo, lanciare i test, vedere gli errori e correggersi.

Planning

Un agente moderno decompone un task in passi. La qualità del plan determina la qualità del risultato. Alcuni agenti espongono il plan all'utente per approvazione prima di eseguire (pattern molto utile nel workflow enterprise). Vedremo questo pattern in dettaglio nel modulo 7.

Tool use

I tools sono funzioni che l'agente può invocare: leggere file, scrivere file, eseguire comandi shell, interrogare database, chiamare API, aprire work item Azure DevOps. Ogni tool ha uno schema e confini. Il permission model sui tool è il vero punto di governance degli agenti.

Feedback loop

Un agente che lancia i test e vede fallire qualcosa può correggersi. Un agente che non lancia i test "spera". La regola di base: più il loop di feedback è stretto e oggettivo (test, tipi, build), più la qualità dell'agente cresce.

Tipi di agente rilevanti per lo sviluppo software

4. NLP, Computer Vision e Information Extraction applicati a casi reali

L'AI non è solo LLM. Anche se in questo corso l'asse principale è Generative AI per il coding, per fare scelte corrette è fondamentale sapere cosa esiste accanto.

NLP classico vs NLP con LLM

Prima degli LLM, il Natural Language Processing era fatto di pipeline: tokenizzazione, POS tagging, named entity recognition, sentiment, classificazione. Oggi molti di quei task sono risolti "in linguaggio naturale" da un LLM con un prompt. Ma non sempre è la scelta giusta: per task massivi, ripetitivi e ben definiti, un modello piccolo specializzato (o una pipeline spaCy/Stanza) è più economico e più preciso.

Computer Vision

Include OCR, riconoscimento oggetti, segmentazione, analisi di documenti scannerizzati. I modelli multimodali (GPT-4o/5, Claude, Gemini) possono "vedere" immagini e ragionare su di esse: utili per screenshot di UI, analisi di mockup, estrazione dati da documenti. Per task ad alto volume restano competitivi modelli dedicati (Azure Document Intelligence, Google Document AI).

Information Extraction

Estrarre dati strutturati da testo non strutturato (email, PDF, contratti, log). È uno dei casi d'uso immediatamente utili in molti contesti enterprise: gli LLM con structured output (schema JSON forzato, function calling) permettono di costruire estrattori robusti in poche ore, cosa che prima richiedeva settimane di regex e training.

Agentic AI

Il termine ombrello per tutto ciò che abbiamo descritto al punto 3: modelli che agiscono sul mondo, non solo che generano testo. È la frontiera più attiva e quella che avrà l'impatto maggiore sul lavoro di un developer enterprise nei prossimi 18–24 mesi.

5. Esempi reali di applicazione enterprise

Caso 1: estrazione dati da email clienti

Problema: un flusso di email clienti con richieste commerciali miste (preventivi, supporto, contestazioni). Serve smistare e prepopolare il CRM.
Soluzione AI: un LLM con structured output che per ogni email produce un JSON con categoria, urgenza, entità menzionate, azione suggerita. Il JSON alimenta direttamente un work item in Azure DevOps o un record CRM.
Perché funziona: task ripetitivo, schema chiaro, tolleranza all'errore gestibile con review umana.

Caso 2: refactoring assistito di un modulo legacy

Problema: un modulo .NET scritto da persone non più in azienda, pieno di codice ripetuto e con pochissimi test.
Soluzione AI: un coding agent che prima legge tutto il modulo, propone un piano di refactoring a step, scrive test di caratterizzazione per bloccare il comportamento attuale, e poi esegue i refactoring uno alla volta, rilanciando i test dopo ogni step.
Perché funziona: il loop di feedback è oggettivo (test verdi/rossi) e il piano è approvabile a priori dal team lead.

Caso 3: documentazione tecnica always-up-to-date

Problema: la documentazione interna è sempre in ritardo rispetto al codice.
Soluzione AI: una pipeline che, a ogni merge su main, riscansiona i file modificati, aggiorna le sezioni di docs rilevanti e apre una PR di documentazione. Un umano fa review della PR — non scrive le docs da zero.
Perché funziona: trasforma un lavoro che nessuno voleva fare in una review di 5 minuti. Approfondimento completo nel modulo 2.