Come affrontare lo sviluppo con agenti IA
Il controllo sul risultato, la persona come architetto e tester, e uno skill che costringe l’agente a spiegare il progetto prima di scrivere codice.
Penso che circolino parecchie opinioni su come usare correttamente gli agenti nello sviluppo. In questo articolo condivido il mio approccio. Probabilmente differirà da quello di altri, ma le idee di fondo saranno di certo molto simili.
1. Come mantenere il controllo su ciò che produce l’agente
Credo che la base di un buon uso degli agenti nello sviluppo sia il controllo sul risultato. Non dobbiamo conoscere ogni riga di codice. Dovremmo però conoscere ogni decisione architetturale e capirla.
La differenza fra le due cose è sostanziale. Una riga di codice si riscrive in un minuto e quasi mai ne dipende qualcosa. Una decisione architetturale ti torna indietro dopo sei mesi, quando nessuno ricorda più perché sia così — e riscriverla non costa un minuto, ma settimane.
2. Che ruolo ha la persona nello sviluppo con agenti IA
A mio avviso, nello sviluppo con gli agenti la persona deve essere prima di tutto architetto, designer UX e tester. Naturalmente l’IA può aiutare anche in questi ruoli — ma la persona deve farsi carico di una parte considerevole della verifica.
È la parte che non si può delegare. L’agente ti scriverà del codice che funziona. Se sia il codice giusto al posto giusto, e se quello che hai chiesto fosse perlomeno una buona idea — questo resta a te.
3. Come scrivere uno skill per Claude Code che imponga il progetto
Per esperienza diretta consiglio di crearsi uno skill in cui dici all’agente che prima di qualunque implementazione deve spiegarti i passi architetturali che ha scelto — in una struttura predefinita dentro un file Markdown.
Di’ all’agente di usare in abbondanza diagrammi mermaid, esempi e grafici. Un diagramma scopre l’assurdità che in un testo discorsivo si nasconde bene: quando l’agente disegna il flusso dei dati e due componenti si parlano in entrambe le direzioni, si vede al primo sguardo.
Uno skill del genere può avere questo aspetto:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Elabora un’analisi IT
---
# Analista IT
Sei un analista IT senior. Sei specializzato in analisi IT di sistemi informatici e della loro architettura.
## Workflow
1. **Capisci che cosa devi risolvere** — Capisci la richiesta e ragionaci. Come risolverla? quali sono le varianti di soluzione? Edge case?
2. **Elabora l’analisi secondo il modello template.md**
3. **Se ci sono risposte a domande esistenti** - Rielabora l’analisi sulla base delle risposte alle domande aperte. Non cancellare né le domande aperte né le risposte, lascia quelle originali. Puoi aggiungere altre domande. Alla fine dell’analisi metti un riepilogo delle modifiche (changelog).
## Rules
- L’output deve seguire il modello `template.md`.claude/skills/it-analysis/template.md
# Modello per la stesura delle analisi
## Indice
1. [Architettura](#1-architettura)
2. [Database](#2-database)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Rischi di implementazione](#5-rischi-di-implementazione)
6. [Domande aperte da decidere](#6-domande-aperte-da-decidere)
## 1) Architettura
In questa parte viene analizzata l’architettura proposta della funzione implementata. Viene inoltre analizzato in che modo cambierà l’architettura esistente e come ci si collega ad essa. Sono auspicabili diagrammi UML adeguati in mermaid.
## 2) Database
In questa parte viene analizzato il modello dati proposto tramite un diagramma ER. Vengono inoltre analizzate le modifiche al modello dati esistente e il collegamento ad esso. Sono auspicabili i diagrammi ER.
## 3) Backend
Qui vengono analizzati sotto forma di elenco puntato gli effetti sul backend — cioè che cosa bisognerà aggiungere / eliminare / modificare.
## 4) Frontend
Qui vengono analizzati sotto forma di elenco puntato gli effetti sul frontend — cioè che cosa bisognerà aggiungere / eliminare / modificare.
## 6) Domande aperte da decidere
Un elenco numerato di domande da decidere. Ogni voce dell’elenco avrà questo aspetto:
- **Nome descrittivo della domanda**: Il testo dettagliato della domanda, dal quale devo poter capire che cosa stai chiedendo.
`Risposta`: Il testo della risposta, oppure `-` se non c’è ancora alcuna risposta.4. Perché conviene far progettare prima la soluzione all’agente
Sulla base di questo skill ti fai sempre proporre prima una soluzione, che approvi sempre prima di ogni altra cosa. Naturalmente l’output di questo skill va riletto per bene, ma ne vale sicuramente la pena.
Inoltre, a mio avviso è importante capire queste questioni di fondo anche se il codice lo scrive l’agente. È l’unica parte in cui si decide se fra un anno il progetto varrà ancora qualcosa.
La sezione con le domande aperte nel modello è lì proprio per questo. Un agente tende a sciogliere le ambiguità da solo e in silenzio — e tu lo scopri quando il codice è già finito. Se lo costringi a elencare le domande, le ricevi prima che ci si costruisca sopra qualcosa.
5. Come discutere un progetto che non capisci
Se su alcune parti del documento non sei sicuro, non avere paura di discuterne con l’agente in modo iterativo. Parlandone con lui capirai meglio la soluzione proposta e ti aiuterà a consegnare un prodotto di qualità.
Vale la pena notare che questa discussione ha anche un secondo effetto. Quando chiedi qualcosa e la risposta non ha senso, di solito non è perché non hai capito — ma perché il progetto è difettoso. La propria incertezza è un discreto rilevatore di problemi.
6. Perché trattare un agente IA come un junior
A mio avviso dovremmo trattare un agente IA sempre come un junior in un determinato ruolo — quello che gli stiamo facendo ricoprire in quel momento.
A un junior affidi un lavoro, ti fai spiegare come intende farlo e poi rileggi il risultato. Non gli lasci decisioni difficili da annullare e non lo lasci lavorare una settimana senza guardare. Allo stesso tempo non gli stai dietro le spalle a ogni riga, perché allora tanto varrebbe farlo da solo.
È esattamente così che lavorare con un agente ha funzionato per me.
7. Riepilogo: tre regole per sviluppare con gli agenti
Questo modo di lavorare è finora quello che mi ha dato i risultati migliori. Lo riassumerei in tre frasi: conosci ogni decisione architetturale, fattela spiegare prima che esista del codice, e chiedi di tutto ciò che non capisci.
La vedi diversamente? Scrivi a support@coden-app.com.