Luca Morelli
Analista programmatore
Team lead

Coding agent nei progetti dei clienti: metodo, conoscenza del progetto e limiti.

Dal 2000 ho visto framework e tecnologie succedersi con la promessa di rendere lo sviluppo più produttivo, quasi sempre senza riuscirci davvero. Con i coding agent qualcosa cambia, pur con molti punti deboli. Li uso, Claude e Codex in particolare, non come una chat a cui fare domande ma su un metodo spec-driven e su una base di conoscenza costruita progetto per progetto.

In tutti i progetti con i clientiDal 2025, su sviluppo, migrazione e manutenzione.
La responsabilità resta miaL'agente accelera l'esecuzione; analisi, architettura e revisione restano mie.

Il metodo: specifiche prima del codice

  1. Specifica

    Requisiti, vincoli e criteri di accettazione, scritti prima del codice a partire dalla documentazione o dalla descrizione del cliente.

  2. Piano

    Come realizzarla: parti coinvolte, sequenza, rischi. Specifica e piano passano da una revisione prima di scrivere codice.

  3. Sviluppo

    Alterno Claude e Codex nelle diverse fasi, seguendo il piano approvato.

  4. Test

    Prima automatici, poi interattivi. Quando serve, il problema o la feature diventa un test ripetibile.

  5. Revisione

    Verifico che il codice corrisponda alla specifica e aggiorno la documentazione: lavoro svolto, roadmap, decisioni, pitfalls.

La harness di progetto

Chiamo harness l'insieme di istruzioni, conoscenza di dominio e procedure che l'agente consulta a ogni richiesta. Per ogni progetto la costruisco un po' alla volta, in documenti chiamati constitution: regole del dominio, procedure di gestione, informazioni vitali per la qualità.

È un'inversione di tendenza rispetto a quello che ho visto negli ultimi anni, con progetti che spesso non avevano una riga di documentazione. Con un agente, tracciare decisioni, richieste degli utenti e pitfalls diventa indispensabile: serve a ricostruire il perché di ogni scelta.

Ha un costo. Le informazioni crescono, e l'agente deve continuare a trovare quelle giuste: la harness va mantenuta e ottimizzata come il codice. E va costruita su misura, perché oltre a una struttura di base ogni progetto ha esigenze proprie.

Rende al massimo nei progetti complessi, dove un processo attraversa web app, web API e servizi esterni come un CRM, spesso su più repository. Senza una conoscenza di dominio esplicita, l'agente nell'IDE vede un pezzo alla volta e prova a ricostruire l'intero flusso a ogni domanda; con la harness può seguirlo attraverso tutti gli ambienti.

Scenari

01

Nuovo sviluppo

Definisco lo stack tecnologico e le linee guida, imposto la harness e sviluppo le feature con il ciclo spec-driven, a partire dalla documentazione o dalla descrizione del cliente. Quando serve, organizzo il lavoro su più filoni paralleli.

Il punto critico

Mantenere la harness allineata mentre il progetto cresce.

02

Migrazione

Parto dal materiale esistente, spesso il codice stesso, e stabilisco una roadmap di migrazione passo per passo, scegliendo la sequenza migliore. Alterno i test eseguiti dall'agente con prove dirette sul semilavorato.

Il punto critico

Avere il prima possibile qualcosa di eseguibile e testabile, anche minimo. Il rischio è lavorare settimane a testa bassa e, al primo avvio, non capire perché non funziona: meglio partire con poco, verificare che giri e integrare le funzioni un po' alla volta.

03

Manutenzione

Analizzo il codice e i pattern in uso, cosa utile soprattutto quando l'aderenza a quei criteri viene verificata. Trasferisco nella harness la conoscenza di dominio raccolta con gli stakeholder e gli esperti del prodotto. Mi aiuta molto a entrare nel progetto e a diventare autonomo in fretta.

Il punto critico

Tenere sempre un occhio critico: quello che l'agente propone va confrontato con ciò che si sa del progetto.

04

Sistemi distribuiti

Nei progetti su più repository o su più prodotti analizzo le procedure che passano da un sistema all'altro. Serve nel debug di anomalie distribuite e, nelle nuove feature, per valutare le conseguenze delle modifiche. Di solito si affianca alla manutenzione: in progetti così si entra quando il sistema è già operativo e consolidato.

Il punto critico

Rendere espliciti i flussi tra sistemi, che nessun singolo repository mostra per intero.

05

Analisi dati

Con accesso diretto ai dati, l'agente permette analisi approfondite in tempo reale e può proporre strumenti e algoritmi. La harness registra analisi e risultati precedenti, decisioni e motivazioni, per ricostruire il flusso dei dati e il perché delle scelte.

Il punto critico

Lavorare su ambienti di test o su dati anonimizzati, non su dati di produzione.

Limiti e condizioni

Approvare non basta

Per la mia esperienza, accettare quello che l'agente propone non porta lontano. Bisogna entrare nei temi e nel dominio del problema.

Dipende dalla tecnologia

L'agente ragiona sulla conoscenza media raccolta durante l'addestramento: è molto efficace su stack diffusi e metodi attuali, meno affidabile su contesti legacy o fuori standard. Un motivo in più per preferire, quando possibile, le soluzioni attuali.

Siamo noi ad adattarci

All'inizio sembra aprire nuovi fronti velocemente. Andando avanti, però, bisogna imparare il suo vocabolario, entrare nel suo mondo e apprenderne i metodi: ci adattiamo più noi a lui che il contrario.

Non scala da sola in team

Una harness che tutti possono modificare si degrada e perde precisione. In un team andrebbe gestita come il codice, con un responsabile e un processo di revisione e rilascio. Per questo oggi è un mio strumento di lavoro, fuori dal repository del progetto, che tratto con la stessa riservatezza del codice del cliente.

Agenti e formazione

L'agente rende un junior un junior migliore e un senior un senior migliore: aumenta la produttività di tutti, ma non colma le differenze.

Cambia anche il modo di formare i profili junior. Il rischio è una persona che non cresce e si limita a interrogare l'IA finché non ottiene qualcosa che funziona. Per questo chiedo ai junior che seguo di costruirsi una visione diretta del prodotto, e discuto sempre con loro gli elementi assegnati. È lo stesso principio con cui lavoro da team lead.

Riservatezza

Uso i coding agent solo dove le regole del cliente lo consentono, e con account professionali. Se il cliente non ammette strumenti di IA, lavoro senza.

Nelle analisi sui dati lavoro su ambienti di test o su dati anonimizzati, non su dati di produzione.

IA nelle applicazioni

E l'IA dentro le applicazioni?

È un tema diverso dall'IA come strumento di sviluppo, e va trattato con la stessa concretezza.

Chi lavora come me su applicazioni enterprise, sul loro sviluppo e sulla loro manutenzione, incontra l'IA nelle applicazioni molto meno spesso di quanto il clamore attuale lasci pensare. A parte i servizi davvero innovativi, che richiedono probabilmente personale specializzato, la richiesta più comune resta "chatta con i tuoi dati". E anche lì va fatta una distinzione netta.

Un RAG che interroga un insieme di documenti e risponde restando aderente ai testi è relativamente semplice. Uno strumento che fa analisi precise e dà risposte corrette è un altro lavoro: bisogna far collaborare codice deterministico e un modello linguistico che per natura non lo è, e lo sforzo cresce molto più della precisione che si ottiene.

I coding agent conoscono molto bene questi temi, che sono il loro terreno. Ma anche qui, per arrivare lontano bisogna entrare nel dominio del problema.

Il progetto, l'architettura e i costi in dettaglio: Applicazioni con IA integrata

Vi interessa questo modo di lavorare sul vostro progetto?

Curriculum dettagliato e referenze su richiesta.