Sviluppare con l’IA e dare un metodo agli agenti

Il 16 settembre ho partecipato al WordPress Meetup Pisa dedicato allo sviluppo assistito dall’IA. Il talk di Luca Baroncini mi ha aiutato a mettere in relazione termini che incontravo già nel lavoro quotidiano: skill, MCP, harness e coding agent. Il titolo dell’incontro, “Oltre il tool del mese: la cassetta degli attrezzi per sviluppare con l’AI”, anticipava bene l’impostazione.

L’ho trovato interessante perché ha offerto una chiave per orientarsi tra strumenti che operano su livelli diversi. Quando si lavora con un agente sul codice, infatti, scegliere un modello è soltanto una delle decisioni. Contano anche le informazioni accessibili, il modo di descrivere il progetto e le verifiche con cui si decide se una modifica è accettabile.

Dare un posto ai diversi strumenti

Una distinzione utile è quella tra il modello e l’ambiente in cui viene utilizzato. Il modello elabora il contesto e propone azioni. Un coding agent combina queste capacità con un ciclo di lavoro sul progetto: legge file, modifica codice, esegue comandi e osserva i risultati, secondo gli strumenti e i permessi disponibili.

Con harness si indica comunemente l’infrastruttura software che sostiene questo ciclo. Comprende aspetti come la gestione del contesto, le chiamate agli strumenti e le condizioni di esecuzione. I confini dei termini possono cambiare tra prodotti: avere presente la funzione è più utile che cercare una tassonomia rigida.

Le skill raccolgono istruzioni e procedure riutilizzabili per attività specifiche. Possono aiutare a rendere più costante un processo, dalla definizione dei requisiti alla revisione. Restano istruzioni da comprendere e valutare, non una garanzia che il modello le rispetti sempre.

MCP, il Model Context Protocol, riguarda invece il collegamento delle applicazioni IA a strumenti e fonti esterne. Una connessione può rendere disponibile documentazione o funzionalità operative; ciò che l’agente può fare dipende dal server, dal client e dalle autorizzazioni. La presenza di MCP non sostituisce una politica di accesso.

Un progetto comprensibile anche al prossimo agente

Uno dei temi dichiarati del meetup era la preparazione del progetto: contesto esplicito, istruzioni versionate, ambienti riproducibili e criteri verificabili. È l’aspetto che mi interessa maggiormente portare nel mio lavoro.

Se le scelte importanti rimangono in una conversazione personale, il collaboratore successivo dovrà ricostruirle. Lo stesso succede quando si cambia agente. Descrivere come si avvia l’applicazione, quali componenti usare e quali verifiche eseguire rende più semplice riprendere il progetto e discutere le modifiche.

La portabilità richiede comunque attenzione. Un insieme di istruzioni può essere riutilizzabile, mentre comandi, permessi o formati di configurazione possono dipendere dal prodotto. Conviene separare le regole del progetto dalle impostazioni dello strumento e verificare ciò che cambia quando si passa da un ambiente all’altro.

Le risorse segnalate durante il meetup

I materiali dell’incontro offrono diversi punti di ingresso. Riporto i collegamenti verificati e la funzione che può aiutare a collocarli nel lavoro. È una selezione di risorse da approfondire, non una comparativa basata su prove personali di tutti i prodotti. Le descrizioni si riferiscono alla documentazione consultata oggi e possono differire dalle versioni mostrate durante il meetup.

Queste risorse risolvono problemi diversi e in parte si sovrappongono. Una raccolta di skill non equivale a un terminale; un framework di specifiche non sostituisce i test. Installarle tutte insieme renderebbe anche più difficile capire da quale istruzione dipenda un comportamento inatteso.

Partire da un problema del proprio flusso di lavoro

Per orientarmi partirei da una domanda concreta. L’agente fraintende i requisiti? Mancano istruzioni sull’architettura? Le modifiche crescono troppo? Non è chiaro se i test siano stati eseguiti? Ogni risposta porta a un intervento differente.

Su un progetto WordPress, per esempio, una richiesta apparentemente semplice può coinvolgere template, dati, accessibilità e comportamento sui dispositivi mobili. Una specifica utile dovrebbe descrivere il risultato atteso e il modo di verificarlo. L’agente deve poi poter trovare i componenti esistenti e ricevere un riscontro dai controlli.

È un esempio che collego alla mia esperienza di sviluppo: la leggibilità di una patch e la possibilità di ripetere una verifica contano quanto la velocità con cui viene generata. Cambiare uno strumento alla volta, su un’attività circoscritta, aiuta a capire se il nuovo elemento migliori davvero il lavoro.

Perché vale la pena recuperare l’incontro

Il meetup mi ha chiarito soprattutto come leggere questa cassetta degli attrezzi: ogni elemento dovrebbe avere un ruolo riconoscibile nel processo. Per chi sviluppa o coordina servizi digitali, anche nella PA e nell’università, è un criterio utile per valutare nuove soluzioni senza perdere di vista la manutenzione.

La registrazione dell’incontro è disponibile su YouTube. La consiglio a chi sta già sperimentando con gli agenti e vuole ragionare su contesto, strumenti e verifiche come parti dello stesso ambiente di sviluppo.

Fonti e materiali

• Scheda del meetup del 16 settembre 2026.
• Presentazione dell’evento sul sito WP Pisa.
• Documentazione ufficiale MCP.

I collegamenti della tabella rimandano ai siti e ai repository dei progetti segnalati nei materiali dell’incontro.

• Cassetta degli attrezzi condivisa tra i materiali della live.