Diciamocelo chiaramente: la programmazione "artigianale" fatta solo di dita sulla tastiera e documentazione aperta sul secondo monitor è morta. Se oggi non integri i Code Agent nel tuo flusso di lavoro, non sei solo leggermente più lento. Sei 30 volte indietro rispetto a chi ha imparato a orchestrare l'intelligenza artificiale con competenza.

Per decenni, il ciclo di sviluppo del software è rimasto sostanzialmente lo stesso: scrivere codice, eseguire test, leggere gli errori, correggere il codice, ripetere. Lo sviluppatore era la costante in quel ciclo.

Fino a un paio di anni fa, l'IA nel coding era principalmente copilota. Oggi siamo passati da LLM che completa testo ad agente che risolve problemi. Un agente entra nel tuo repository, legge l'architettura, propone una strategia, lancia i test, corregge, ed esegue. Non si tratta di completamento automatico. È un'IA che opera sul codice come farebbe uno sviluppatore, ma senza fermarsi a chiedere il permesso ad ogni passo.

Dall’artigiano al direttore creativo del codice

Il salto non è solo tecnologico, è ontologico.

In questa nuova era, le skill si stanno spostando dal "saper scrivere" al "saper orchestrare". Dobbiamo cambiare il modo in cui ci vediamo e usare l’AI per abbattere i tempi di produzione, ma mantenere la responsabilità su architettura, sicurezza e validazione.

Man mano che l'agente si occupa delle operazioni di routine, come i CRUD o il codice ripetitivo, lo sviluppatore evolve in un orchestratore che opera su tre livelli critici:

1. Inquadrare il problema: Definire un intento chiaro e azionabile. Se non sai spiegare il problema, l'agente risolverà la cosa sbagliata in modo impeccabile.
2. Integrazione di sistema: Assemblare i componenti generati dall'IA in sistemi coesi e funzionali. L'agente vede il file, tu vedi l'ecosistema.
3. Design Architetturale: Focalizzarsi sull'alto livello, sulla scalabilità e sulla sicurezza. L'IA è eccellente nell'esecuzione tattica, ma spesso miope sulla strategia a lungo termine.

 

Delegare l'esecuzione non significa delegare la comprensione. L'occhio umano è l'ultima linea di difesa per tre motivi fondamentali:

• Debugging e Verifica: Serve un occhio esperto per scovare leak di memoria o vulnerabilità che un agente potrebbe ignorare.

• Pensiero Critico e Creatività: Risolvere problemi che non esistono nei dati di training. L'innovazione vera nasce dove finiscono i pattern già visti.

• Comprensione del Contesto: L'agente non conosce i tuoi obiettivi di business, le esigenze reali degli utenti o le implicazioni etiche. Quel contesto lo porti tu.

Non basta imparare un nuovo framework, bisogna sviluppare nuove competenze trasversali:

• Fluency IA & Prompt Engineering: Capire come ragiona il modello, i suoi limiti e come collaborare senza farsi trascinare in loop infiniti.
• Expertise di Dominio: Comprendere profondamente il settore in cui operi. Più il codice diventa una commodity, più il valore si sposta sulla conoscenza specifica del problema.
• Mentalità da Code Reviewer: Evolvere in un mentore che valida costantemente il lavoro, che sia scritto da un junior o da un agente.

Il cambio di prospettiva tra Junior e Senior

Questo shift impatta tutti, ma in modo diverso.

• I Junior Developer non possono permettersi di saltare le basi sperando nel "vibe coding". Al contrario, devono studiare i fondamentali ancora più duramente per costruire i modelli mentali necessari a valutare l'output dell'IA.
• I Senior Developer si trasformano in architetti. Il loro diventa progettare sistemi complessi e gestire flotte di agenti che ne realizzano i dettagli.

La programmazione agentica non elimina la necessità del giudizio ingegneristico, ma lo trasferisce altrove.

L'ingegneria del software quindi è morta? La risposta onesta è che il ruolo sta cambiando, non scomparendo, ma il cambiamento è reale e più rapido di quanto la maggior parte delle persone avessero previsto.

Gli sviluppatori che stanno avendo successo sono quelli che hanno smesso di considerare l'output dell'agente come qualcosa di cui diffidare e hanno iniziato a trattarlo come qualcosa da indirizzare bene.

Cosa significa “programmazione agentica”?

La programmazione agentica è uno sviluppo software in cui un modello di IA esegue autonomamente azioni articolate in più fasi: leggere file, scrivere codice, eseguire test, gestire gli errori, richiamare strumenti e iterare; il tutto senza richiedere un comando umano per ogni singolo passaggio.

Il termine agentic deriva da IA agentica, un modello in grado di perseguire obiettivi, prendere decisioni, utilizzare strumenti e adattarsi in base ai risultati. Applicato alla programmazione, significa che il modello non si limita a rispondere a una richiesta, ma lavora per risolvere un problema.

Un assistente di programmazione AI standard potrebbe aiutarti a scrivere una funzione quando glielo chiedi. Un sistema di programmazione agentico può:

• Accettare un compito di alto livello (“aggiungi il login OAuth a questa app”)
• Leggere i file rilevanti nel tuo codice
• Scrivere le modifiche di codice richieste su più file
• Eseguire la suite di test
• Correggere eventuali test falliti
• Confermare le modifiche e aprire una pull request

Ciclo di sviluppo software tradizionale

Per capire cosa sostituisce la programmazione agentica, è utile specificare quale ciclo essa interrompe.

Normalmente:

• Lo sviluppatore legge un ticket o le specifiche
• Lo sviluppatore scrive il codice
• Lo sviluppatore esegue i test in locale
• I test falliscono; lo sviluppatore legge l'output di errore
• Lo sviluppatore esegue il debug e modifica il codice
• Ripetere i passaggi 3–5 fino al superamento dei test
• Lo sviluppatore apre una PR e attende la revisione

Ogni fase di quel ciclo è un lavoro cognitivo: leggere il contesto, prendere decisioni, generare output.

Il ciclo di vita della programmazione agentica:

• Lo sviluppatore (o il sistema) assegna un compito al modello
• Il modello legge il contesto rilevante (file, documenti, test esistenti)
• Il modello scrive il codice
• Il modello esegue i test tramite chiamate agli strumenti
• Il modello legge l'output, identifica cosa non ha funzionato
• Il modello corregge il codice e lo riesegue
• Il modello apre una PR quando i test vengono superati

Il ciclo ha la stessa forma ma è l'agente a guidarlo.

Cosa NON è la programmazione agentica

Il termine viene spesso usato in modo improprio.

Non è vibe coding. Il vibe coding consiste nel fornire un prompt a un'IA, accettare qualsiasi cosa generi e andare avanti senza verificare nulla. I due approcci possono sembrare simili, ma producono profili di affidabilità diversi.

Non è magia. Al momento il limite per la finestra di contesto è 1M di token. I modelli possono fare supposizioni errate. Gli agenti a esecuzione prolungata accumulano deriva, un problema noto come “context rot”, in cui le prestazioni degradano man mano che il contesto diventa grande o rumoroso. I buoni sistemi agentici sono progettati tenendo conto di questo vincolo, non negandolo.

Perché e quando usare un agente

Il motivo principale per cui usiamo i Code Agent non è solo la pura velocità.

Gli agenti servono a gestire la complessità laterale, quella serie di task che sai fare ma che ti portano via tempo e focus dal design e dalle scelte importanti.

Casi d'uso

• Refactoring massivi: L'agente aggiorna 40 file e verifica la coerenza dei tipi mentre tu sorseggi un caffè.
• Legacy Migration: Convertire JS in TypeScript analizzando l'uso reale degli oggetti.
• Ciclo "Green-to-Green": L'agente scrive il test, lo lancia, legge l'errore e corregge il codice finché non passa.
• Root Cause Analysis: Passa lo stack trace all'agente; lui troverà il commit colpevole e ti proporrà la fix basata sui log.

Quando non usarli

Se stai esplorando una nuova libreria e vuoi impararne le basi, non usare l'agente.

Ti serve il "sudore" della documentazione per fissare i concetti. Usa l'agente quando sai esattamente cosa vuoi ottenere, ma non hai voglia di scrivere codice per le prossime due ore.

I padroni della scena: Claude Code vs GitHub Copilot

In questo momento, il mercato degli agenti è dominato da due entità che rappresentano filosofie divergenti, pur puntando allo stesso obiettivo: eliminare l'attrito tra l'intenzione dello sviluppatore e l'esecuzione del codice. Non usarli significa ignorare lo stato dell'arte.

Scegliere tra i due è una questione di requisiti:

• Se lavori in un’organizzazione, Copilot è lo standard per un motivo preciso: governance. Permette di gestire limiti, configurazioni di sicurezza e policy di accesso.
• Claude Code è potenza pura. È indicato per lo sviluppatore che cerca l'autonomia operativa totale.

Claude Code

Si distingue per un'analisi contestuale profunda, coerenza e precisione del ragionamento multi-file: non si limita a suggerire codice, ma analizza l'intero grafo delle dipendenze per garantire che ogni modifica sia coerente con l'architettura globale del progetto.

GitHub Copilot

Il suo punto di forza è l'onnipresenza essendo integrato nativamente in VS Code e nell'ecosistema GitHub agendo come una colla intelligente tra le diverse fasi del ciclo di vita del software. Inoltre, non ti vincola a un singolo fornitore, è un orchestratore di modelli permettendo di switchare il cervello dell'agente in base al task.

OpenCode, Open-source model-neutral

Se Claude e Copilot sono i giganti, OpenCode è la porta d'accesso alla libertà tecnica ed economica.

La sua forza principale è il costo decisamente accessibile unito alla possibilità di utilizzare modelli Open Source (OSS). A parità di capacità logica con modelli come Claude, ti permette potenzialmente di consumare molti più token mantenendo performance elevate.

Dove scrivere il codice: IDE e Terminale

La scelta dell'ambiente di sviluppo è diventata una questione di workflow e, spesso, di puro gusto personale. Non esiste una regola ma strumenti nati con filosofie diverse.

IDE Native: Cursor, Anti Gravity e Zed

• Cursor: Il fork di VS Code che ha mostrato cosa significa mettere l'IA al centro. La funzione "Composer" è il gold standard.
• Anti Gravity (Google): Introduce la "Manager Surface", permettendoti di monitorare più agenti che lavorano in parallelo su diverse parti del sistema.
• Zed: Per chi cerca la velocità pura. Scritto in Rust, è incredibilmente reattivo e integra flussi agentici nativi senza il lag di Electron.

VS Code

VS Code con le giuste estensioni è un mostro di potenza. Se hai passato anni a configurare il tuo ambiente, le estensioni moderne ti permettono di avere poteri agentici quasi identici a quelli di Cursor.

Spesso, quindi, si riduce a una preferenza personale.

La bussola dei comandi

Abbiamo capito che usare un agente non significa solo scrivere in una chat.

/btw e ask

A volte hai solo bisogno di un chiarimento veloce, non vuoi che l'IA scansioni nuovamente file e inquini il contesto.

• Claude Code (/btw): È il comando per i pensieri laterali.

  • Personalmente lo uso quando voglio chiedere "Perché hai scelto questa libreria?" senza interrompere il flusso di lavoro dell'agente.

• Nota a margine che non sporca la cronologia dei task attivi.

• GitHub Copilot (ask): È la modalità consultiva, utile per spiegazioni teoriche o per farsi spiegare un pezzo di codice legacy che hai appena evidenziato.

Plan e Ultraplan

Dovresti sempre obbligare un modello ad agire su un piano invece di scrivere direttamente. Quando un agente entra in Plan Mode crea una barriera tra il "cosa fare" e il "come farlo".

• Pensalo come un PLAN.md generato dall'IA

Questo approccio riduce drasticamente i loop di allucinazione, però presuppone che tu sappia già cosa vuoi costruire. Se l'agente inizia a scrivere subito, rischia di accorgersi di un errore architettonico quando ha già scritto finendo per "patchare" il suo stesso errore e creando debito tecnico istantaneo.

Con un piano, l'agente:

1. Identifica ogni singolo file che deve essere toccato.
2. Mappa le dipendenze circolari che potrebbero rompersi.

C'è però un passo che viene prima, la specifica di definizione.

• Cosa stai effettivamente realizzando e perché?
• Cosa non puoi toccare?
• Come si presenta il “completato” in termini che puoi testare?

In SDD, questo risiede in un vero e proprio file di specifica. Senza è come chiedere all'agente di scegliere la destinazione e guidare allo stesso tempo. Una precisazione di 30 secondi nelle specifiche può farti risparmiare un'ora di scambi di messaggi.

Quando usare la modalità plan?

• Correggere un bug semplice con un caso di riproducibile chiaro
• Aggiungere un campo
• Refactoring in cui i test raccontano tutto

Una specifica guadagna importanza quando c'è una ambiguità: funzionalità con punti aperti, modifiche trasversali, etc..

Il "ragionamento" è l'attività più costosa. Puoi usare il modello più potente e intelligente (come Opus) per questa fase. Una volta che il piano è validato, deleghi l'esecuzione a un modello più economico (come Sonnet).

La funzione Ultraplan di Claude Code sposta l'asticella ancora più in alto. Quando lanci un Ultraplan il task viene passato a una sessione web di Claude in cloud. Mentre l'IA elabora la strategia complessa nel cloud, tu continui a lavorare nel tuo terminale. Una volta pronto, apri il piano nel browser, lo commenti, chiedi revisioni e decidi dove eseguirlo. Il vantaggio tecnico è enorme: non sporchi il contesto locale. Tutta la fase di "esplorazione" e discussione avviene sul web, risparmiando token nella tua finestra di contesto locale, che rimane pulita e dedicata interamente all'esecuzione del codice.

 

Passiamo alla fase esecutiva. Claude Code opera con due modalità:

1. Default Mode: È il sistema di sicurezza standard, ti mostra i diff e ti chiede conferma prima di ogni modifica.
2. Auto-accept Mode: Applica automaticamente i cambiamenti suggeriti senza interruzioni.

 

La modalità Agent di Copilot è più esplorativa, tende a muoversi in autonomia per cercare la soluzione. L'Agent Mode è progettata per risolvere task, non per chiacchierare. Si basa su un ciclo di ragionamento iterativo (Think, Act, Observe).

Copilot può inoltre delegare l'esecuzione a un runner ospitato su GitHub. Questo significa che l'agente può analizzare il codice, lanciare build e test in un ambiente isolato nel cloud senza pesare sulla tua macchina locale.

La forza del parallelo

Il vero moltiplicatore di produttività non arriva solo dall'intelligenza del singolo agente, ma dalla possibilità di farli lavorare in parallelo.

Claude Code può attivare degli "sciami" di agenti. Invece di un unico modello che cerca di risolvere un problema enorme (rischiando l'allucinazione), il sistema lancia più agenti specializzati che lavorano in concerto.

Le skills

Usare un agente AI senza configurarlo è come assumere un consulente senza fargli un briefing.

Una skill è una capacità modulare e riutilizzabile che un agente può invocare quando serve. Non ha autonomia propria: è un pacchetto di istruzioni specifiche per un compito.

• "Come debuggare una pipeline CI/CD" è una skill.
• "Implementa la feature descritta in questa issue" è un lavoro da agente.

 

Le Skills seguono il principio della progressive disclosure: l'agente legge solo la descrizione all'avvio e carica le istruzioni complete solo quando servono. Questo risparmia token e mantiene pulito il contesto.

Agents.md

Il file AGENTS.md (o CLAUDE.md per Anthropic) è il nuovo standard di fatto per dare contesto agli agenti. Inserito nella root del repository o la directory del progetto, definisce comandi, architettura, convenzioni e workflow. È un README scritto per le macchine.

La qualità dell'output è direttamente proporzionale alla qualità del contesto fornito.

# AGENTS.md

## Build & Test
- Build: `dotnet build --configuration Release`
- Test: `dotnet test --no-build --configuration Release`
- Singolo test: `dotnet test --filter "FullyQualifiedName~MyTest"`
- Lint: `dotnet format --verify-no-changes`

## Architettura
src/Domain — entità, value object (nessuna dipendenza)
src/Application — use case, interfacce, handler MediatR
src/Infrastructure — EF Core, servizi esterni, repository
src/Api — controller, middleware, registrazione DI
tests/ — struttura speculare a src/ con suffisso .Tests

## Convenzioni
- ALWAYS: nullable reference types abilitati
- ALWAYS: async ovunque, mai usare .Result o .Wait()
- ALWAYS: primary constructors per DI in .NET 8+
- ALWAYS: record types per DTO e value object
- NEVER: loggare PII o connection string
- NEVER: commit diretti su main

## Git Workflow
- Branch: `feature/<work-item-id>-<descrizione>`
- Commit: Conventional Commits (`feat(orders): add bulk endpoint`)

Copilot supporta i custom agents che definiscono agenti con ruoli specifici.

In sintesi, la gerarchia di Copilot è:

1. AGENTS.md (contesto generale) →
2. custom agents (ruoli specializzati) →
3. skills (procedure riutilizzabili).

Tre livelli di personalizzazione che si completano.

La lunghezza non è solo una questione di leggibilità ma è un limite tecnico. Tutto quello che mettiamo finisce nel contesto del modello, e il contesto è limitato. Ogni riga in più compete con codice e istruzioni, quindi a un certo punto perde peso o viene ignorata.

Per questo non mi convince molto l’idea di file .md troppo completi.

Il divario è incolmabile

Gli agenti sono strumenti, non sostituti del tuo cervello. Ma dobbiamo essere onesti: chi rifiuta questo approccio per "preservare la purezza del codice" sta solo perdendo tempo.

Usa l'estensione o l'IDE che preferisci. Usa la CLI per l'autonomia operativa. Impara a distinguere tra un piano e un'esecuzione.

Il codice non è più un prodotto di scrittura manuale. È il risultato di un'orchestrazione intelligente. E chi non orchestra, è destinato a restare indietro.