Writing Source Code in the AI Era

1. Come cambia il ruolo dello sviluppatore

In un team AI-first, lo sviluppatore scrive sempre meno codice da zero e sempre più specifiche eseguibili. Il rapporto col codice cambia: si legge di più, si scrive di meno, si verifica di più, si decide di più.

Le quattro attività che crescono

• Specifica. Saper descrivere un cambiamento in modo chiaro, non ambiguo, con vincoli e criteri di accettazione. È la stessa competenza di un buon user story, applicata più spesso.
• Lettura del codice. Valutare un diff prodotto da un agente richiede di leggere bene: capire intent, spot bug sottili, verificare assunzioni. Questa è la competenza che separa un senior che sfrutta l'AI da uno che viene sfruttato dall'AI.
• Verifica. Eseguire, testare, osservare comportamenti. Un developer AI-first passa più tempo nel debugger e nei test di quanto facesse prima.
• Decisione. Scelte architetturali, trade-off, priorità. L'AI genera opzioni; l'ingegnere sceglie.

Le due attività che calano

• Boilerplate. Setup, scaffolding, conversioni di formato, glue code. Letteralmente dimezzato nella pratica.
• Ricordo a memoria di sintassi. Nessuno dovrebbe più memorizzare firme di API: è un uso sbagliato del cervello umano.

2. Editor e ambienti AI-first

Il mercato si è assestato su alcune categorie ben distinte. Per ogni categoria valutiamo pro, contro e criteri aziendali di adozione.

VS Code + GitHub Copilot

La soluzione mainstream, più matura sul lato enterprise (licensing, policy, audit). Copilot integra autocompletion, chat, agent mode, code review assistita, generazione di commit messages. Per un ambiente Microsoft/Azure DevOps è il percorso a minor attrito. Trattato in dettaglio nel modulo 8.

VS Code + Claude Code (CLI o estensione)

Claude Code è un coding agent che vive in terminale o dentro VS Code, può leggere il tuo repo, eseguire comandi, lanciare test, aprire PR. Più orientato al lavoro "a task" che all'autocompletion. Eccellente per refactoring e feature complete. Trattato in dettaglio nel modulo 7.

Cursor

Fork di VS Code ripensato attorno all'AI. Autocompletion molto forte, chat "agent mode", supporto di rules file, indicizzazione del repo nativa. Ottimo rapporto qualità/velocità per molti scenari; la scelta aziendale va pesata con attenzione per policy e modelli supportati.

JetBrains AI Assistant / Junie

Se il team usa già IntelliJ, Rider, WebStorm, la soluzione nativa JetBrains copre la maggior parte dei casi d'uso con minor attrito. Junie è la loro linea "agent" che compete con Claude Code / Copilot Agent.

CLI-only agents

Alcuni team preferiscono agenti puramente da terminale (es. Claude Code standalone, Aider, OpenAI Codex CLI). Utili per lavori batch, automazioni, headless in CI. Non sostituiscono l'editor ma lo affiancano.

Tabella riassuntiva

3. Workflow tipici e pattern emergenti

Il ciclo "Plan, Apply, Verify"

Il workflow che emerge come standard nei team seri:

1. Plan. Descrivi il task, l'agente produce un piano di modifica (file toccati, step). L'umano approva o corregge.
2. Apply. L'agente esegue il piano passo passo, fermandosi dove il permission model richiede conferma (es. comandi shell distruttivi).
3. Verify. Test, build, review del diff. Nuovo giro se qualcosa non va.

Il ciclo "Tight loop con test"

Esiste un test che esprime cosa deve succedere. L'agente lavora in loop finché il test non passa. Massimo ROI su bug fix e feature ben specificate.

Pair programming con un agente

Lo sviluppatore guida, l'agente propone. Funziona bene per lavori esplorativi, code review, analisi di codice sconosciuto. Non richiede permessi scrittura: l'agente è consultivo.

Parallelismo con subagents

Un agente "principale" delega parti del lavoro a sub-agenti specializzati (es. un agente di ricerca nel codebase, uno di scrittura test, uno di analisi di sicurezza). Pattern potente ma da maneggiare con cura: moltiplica costi e richiede un orchestratore competente.

4. Qualità, code review e disciplina di team

Code review di codice generato da AI

La review non cambia forma — cambia scala e frequenza. Un team AI-first fa più review, più piccole, più spesso. Alcuni principi:

• Trattare i diff AI come qualsiasi altro diff: stesso processo, stessa severità.
• Richiedere sempre test: se l'AI ha scritto la feature, ha scritto anche i test.
• Attenzione alle "regressions sottili": l'AI ama "pulire" codice e può cambiare comportamenti.
• Verificare le assunzioni: API usate, parametri, return values.

Convenzioni e file di configurazione di team

Tutti gli strumenti moderni supportano file di configurazione versionati nel repo:

• CLAUDE.md per Claude Code
• .cursorrules / .cursor/rules/ per Cursor
• .github/copilot-instructions.md per GitHub Copilot
• Prompt library in /.ai/prompts/ (pattern condiviso, non legato a un tool)

Codificare lì dentro: lingua della documentazione, stile di codice, framework di test, librerie permesse, nomi convenzionali, vincoli di sicurezza. Sono file di team, devono stare in PR.

Metriche che contano

• Lead time per cambiamento (dal commit al deploy).
• Tasso di regressione post-merge (bug catturati dopo il merge).
• Tempo medio di review.
• Copertura di test sulle aree toccate da AI.

Non guardare "righe di codice generate". È una metrica inutile, rischia di premiare comportamenti sbagliati.

5. Criteri di adozione aziendale

Quando un team valuta se adottare uno strumento AI-first, le domande non sono "quanto è bello?". Sono queste:

Licensing e costi

• Modello di licenza (per-user, per-seat, per-token)?
• Costi previsti per team di N persone?
• Esistono tier enterprise con SSO e audit?

Sicurezza e privacy

• Dove vanno i prompt e i frammenti di codice inviati?
• Vengono usati per training? È disattivabile?
• Supporto a SSO / SCIM / audit log?
• Gestione di segreti: come prevenire leak di credenziali nei prompt?

Integrazione con l'esistente

• Integrazione con Azure DevOps (PR, work items, pipeline)?
• Supporto agli stack Blulink?
• Funziona dietro proxy / VPN aziendale?

Policy di adozione graduale

Nessun team dovrebbe adottare uno strumento AI-first "dall'oggi al domani su tutto il codice". Il pattern consigliato:

1. Pilot su un team volontario, 4–6 settimane, con metriche chiare.
2. Scrittura di una usage policy interna: cosa si può e cosa no.
3. Rollout progressivo ai team interessati.
4. Retrospettiva mensile sui primi 3 mesi.

Accountability

Il codice generato da AI resta responsabilità di chi lo committa. Non esistono "errori dell'AI": esistono scelte dell'ingegnere che l'ha accettato. Questo principio va scritto chiaramente nella policy.