In quasi trent'anni di sviluppo ho visto framework e tecnologie succedersi con la promessa di rendere il lavoro più produttivo, quasi sempre senza riuscirci davvero. Con i coding agent, gli strumenti di intelligenza artificiale che scrivono e modificano il codice su indicazione dello sviluppatore, qualcosa cambia, pur con molti punti deboli. Li uso, Claude Code e Codex in particolare, non come una chat a cui fare domande ma con un metodo che parte da specifiche scritte (spec-driven) e su una base di conoscenza costruita progetto per progetto.
Per chi mi affida un progetto il rapporto non cambia: specifiche, verifiche e responsabilità restano le stesse. Cambia, dove il contesto lo permette, la velocità con cui si passa dalla specifica al codice.
Requisiti, vincoli e criteri di accettazione, scritti prima del codice a partire dalla documentazione o dalla descrizione del cliente.
Come realizzarla: parti coinvolte, sequenza, rischi. Specifica e piano passano da una revisione prima di scrivere codice.
Alterno Claude Code e Codex nelle diverse fasi, seguendo il piano approvato.
Prima automatici, poi interattivi. Quando serve, il problema o la feature diventa un test ripetibile.
Verifico che il codice corrisponda alla specifica e aggiorno la documentazione: lavoro svolto, roadmap, decisioni, insidie.
In questo ciclo l'agente fa tre lavori diversi: esegue i compiti che gli assegno, discute con me specifica e piano come in un lavoro in coppia (pair programming), e cerca informazioni durante lo sviluppo. Gli ultimi due sono i più utili e i più delicati: li descrivo nei limiti.
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 insidie 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.
Una harness efficace deve anche rendere visibili gli errori: limiti alle azioni e verifiche indipendenti aiutano a fermare una modifica sbagliata prima che entri nel prodotto.
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.
Mantenere la harness allineata mentre il progetto cresce.
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.
Nei sistemi in cui ogni prova richiede l’applicativo completo, un database condiviso o configurazioni manuali, preparo prima un ambiente e controlli ripetibili. Il lavoro necessario per rendere verificabili le modifiche fa parte dell’adozione dell’agente.
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.
Analizzo il codice e i pattern in uso: è utile soprattutto quando il rispetto di quei criteri viene verificato in revisione. 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.
Tenere sempre un occhio critico: quello che l'agente propone va confrontato con ciò che si sa del progetto.
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.
Rendere espliciti i flussi tra sistemi, che nessun singolo repository mostra per intero.
Con accesso diretto ai dati, l'agente permette analisi approfondite in modo interattivo 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.
Lavorare su ambienti di test o su dati anonimizzati, non su dati di produzione.
Per la mia esperienza, accettare quello che l'agente propone non porta lontano. Bisogna entrare nei temi e nel dominio del problema.
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.
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. Su argomenti lontani dalla nostra esperienza ragiona da esperto, e porta gradualmente a valutazioni tecniche che richiedono di studiare l'argomento.
L'agente dà ai termini tecnici il significato che ricava dai testi su cui è stato addestrato, e non sempre coincide con quello del cliente, delle regole aziendali o della mia esperienza. Chiedergli di essere più preciso non sempre basta. Quando posso chiarisco i termini nella harness e controllo se poi siamo allineati; più spesso è un lavoro misto: lo allineo in parte e intanto imparo l'argomento, anche perché di ciò che viene fatto rispondo io.
Quando lo uso per cercare informazioni, gli chiedo di non fermarsi a ciò che sa il modello: deve verificare su fonti esterne e indicarmi i link, così posso controllare il contenuto e la sua origine.
Una harness che tutti possono modificare si degrada e perde precisione. In un team andrebbe gestita come il codice, nel repository, con un responsabile e un processo di revisione e rilascio: è un passo molto più complesso, che non ho ancora affrontato in un progetto. Per ora la tengo come mio strumento di lavoro, fuori dal repository del progetto, con la stessa riservatezza del codice del cliente.
Posso formare i singoli sviluppatori a usare i coding agent con metodo, ciascuno sul proprio lavoro, e seguirli durante il progetto.
Nella maggior parte dei progetti, a fine lavoro riconsegno i sorgenti. Con i coding agent conviene chiarire prima in che stato saranno.
Un aumento di produttività è gradito a chi commissiona il lavoro. Ma un codice perfettamente funzionante e conforme alle specifiche può risultare difficile da leggere per una persona, pur restando facile da gestire per un agente.
Per questo non do nulla per scontato sullo stato finale dei sorgenti: rispettano ciò che è stato chiesto e verificato, mentre ciò che non è stato chiesto resta alle scelte del modello.
Se il prodotto dovrà essere ripreso da qualcuno anche nel modo tradizionale, a mano, i criteri di valutazione e di validazione vanno chiariti all'inizio, in ogni loro forma: leggibilità, convenzioni del vostro team, documentazione, test. Come le specifiche, li concordo con voi. Altrimenti si rischia un prodotto che funziona e rispetta le specifiche, ma che è molto complesso da prendere in mano.
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.
L'IA dentro le applicazioni è un tema diverso: Intelligenza artificiale per le PMI
Gli studi misurano compiti e contesti diversi: non dimostrano un guadagno di produttività valido per tutti i progetti.