Non uso ChatGPT e Codex per farmi scrivere qualche frammento di codice. Li utilizzo all’interno di un processo strutturato, nel quale definisco il contesto, delimito i task, verifico le modifiche e mantengo il controllo finale su ogni decisione.
Questa distinzione, apparentemente semplice, cambia radicalmente il modo di utilizzare l’intelligenza artificiale nello sviluppo software.
Chiedere a un modello di generare una classe, una query SQL o un componente grafico può essere utile. Tuttavia, lo sviluppo di un’applicazione reale non consiste nella produzione di singoli blocchi di codice. Comprende analisi, progettazione, scelte architetturali, gestione dello stato del progetto, test, documentazione, versionamento, distribuzione e controllo delle regressioni.
Per questo motivo preferisco parlare di sviluppo agentico, non soltanto di programmazione assistita.
Nel mio metodo ChatGPT svolge prevalentemente il ruolo di orchestratore: mi aiuta a ragionare sul progetto, a ricostruire il contesto, a formalizzare i requisiti e a trasformare un’idea in un’attività operativa ben delimitata.
Codex interviene invece direttamente sul repository. Analizza il codice esistente, individua i file coinvolti, implementa le modifiche, esegue build e test, verifica le differenze introdotte e prepara il lavoro per il commit e il deploy.
Io mantengo la responsabilità dell’intero processo.
Non considero un’attività conclusa perché un agente dichiara di averla completata. La considero conclusa quando il codice, i test, il repository e l’ambiente pubblicato forniscono evidenze coerenti.
Uno degli errori più comuni nell’uso dell’intelligenza artificiale applicata allo sviluppo è affidare allo stesso strumento un compito troppo ampio e poco definito.
Una richiesta come:
Realizza una piattaforma per gestire corsi, materiali e utenti.
contiene troppe decisioni implicite.
Quali utenti? Con quale sistema di autenticazione? Quali dati devono essere memorizzati? Quali funzionalità devono essere pubbliche? Quali riservate? Quali tecnologie sono già presenti? Quali vincoli impone l’hosting? Esiste già un database? È necessario intervenire sullo schema? Devono essere creati test? Quali caratteristiche sono esplicitamente escluse dalla prima versione?
In assenza di queste informazioni, l’agente deve colmare autonomamente i vuoti. Può quindi generare una soluzione tecnicamente plausibile, ma non necessariamente coerente con il progetto reale.
Il mio approccio separa nettamente tre responsabilità.
La prima è la responsabilità progettuale. Riguarda la finalità del prodotto, le priorità, i vincoli e le decisioni che hanno conseguenze sul medio e lungo periodo.
La seconda è l’orchestrazione. Consiste nel trasformare decisioni e requisiti in un contesto comprensibile, verificabile e utilizzabile da un agente operativo.
La terza è l’esecuzione tecnica. È il lavoro svolto sul repository: lettura del codice, modifica dei file, compilazione, test, controllo delle regressioni e preparazione della distribuzione.
Questi ruoli possono essere rappresentati in modo molto semplice:
io mantengo il controllo sul prodotto, sull’architettura e sulle decisioni finali;
ChatGPT organizza il ragionamento e trasforma gli obiettivi in task eseguibili;
Codex interviene come agente di sviluppo sul progetto reale.
Non è una delega completa. È una forma di collaborazione strutturata.
La qualità del risultato dipende in larga misura dalla qualità del contesto.
Quando si lavora con un collega umano, molte informazioni vengono acquisite progressivamente. Lo sviluppatore conosce il prodotto, ricorda le decisioni prese nelle riunioni precedenti, sa quali parti del sistema sono delicate e quali convenzioni vengono utilizzate nel codice.
Un agente AI non possiede automaticamente questa conoscenza.
Può leggere il repository, ma il repository non contiene necessariamente tutte le motivazioni delle decisioni. Può trovare una classe o un servizio, ma non sempre può sapere se quella struttura rappresenta una soluzione definitiva, un compromesso temporaneo o una parte destinata a essere sostituita.
Per questo motivo considero il contesto un vero artefatto di progetto.
Non è un’introduzione generica da anteporre a ogni richiesta. È un insieme di informazioni operative che deve essere mantenuto, aggiornato e verificato.
Nel mio lavoro distinguo idealmente quattro livelli di contesto.
Il primo è il contesto stabile del progetto. Comprende tecnologie, architettura generale, convenzioni, vincoli infrastrutturali, regole di sicurezza e criteri di qualità.
Il secondo è lo stato corrente. Indica quali funzionalità sono già presenti, quali attività sono state completate, quali decisioni sono state confermate e quali problemi rimangono aperti.
Il terzo è il contesto specifico del task. Descrive ciò che deve essere realizzato, ciò che non deve essere modificato, i file o i moduli probabilmente coinvolti e i criteri di accettazione.
Il quarto è il risultato verificato del task precedente. Comprende commit, test eseguiti, eventuale deploy e stato finale del repository.
Questa stratificazione evita due problemi frequenti: ricominciare ogni volta da zero e accumulare istruzioni contraddittorie.
Un’idea non è ancora un task di sviluppo.
Prendiamo un esempio concreto legato a deghetto.it.
L’idea iniziale poteva essere espressa così:
Vorrei creare una sezione pubblica dedicata alla formazione e alla futura Academy.
La richiesta descrive una direzione, ma non è sufficientemente precisa per intervenire sul codice.
Prima di affidarla a Codex, è necessario trasformarla in qualcosa di più strutturato.
Occorre stabilire, per esempio, se la nuova pagina debba essere integrata nella navigazione esistente, quali contenuti debba mostrare, se debba introdurre nuove entità nel database, se debba avere una propria area amministrativa, quali collegamenti possa utilizzare e quali funzionalità debbano essere rimandate.
Nel caso concreto, il lavoro è stato suddiviso in passi distinti.
Un primo task ha riorganizzato la pagina pubblica dedicata alla formazione. Sono stati introdotti il marchio “Garage40 Academy by deghetto.it”, alcuni contenuti descrittivi e i collegamenti verso le aree già esistenti. Non è stata ancora creata una piattaforma completa e non sono state introdotte modifiche al database.
Un task successivo ha aggiunto una pagina pubblica autonoma per l’Academy, mantenendo comunque il perimetro strettamente informativo.
Questa progressione è importante.
La tentazione di chiedere immediatamente un sistema completo è forte, soprattutto quando l’agente è in grado di produrre rapidamente molto codice. Ma la quantità di codice generato non coincide con il valore prodotto.
Un piccolo incremento coerente, testato e pubblicato è spesso più utile di una grande funzionalità costruita su requisiti ancora instabili.
Un buon task non descrive soltanto il risultato atteso.
Deve anche indicare chiaramente ciò che è fuori perimetro.
Nel lavoro tradizionale questa informazione viene spesso lasciata implicita. Con un agente AI, invece, è particolarmente importante.
Se chiedo di realizzare una pagina pubblica per una nuova iniziativa formativa, l’agente potrebbe ritenere utile creare anche tabelle, servizi applicativi, modelli, procedure amministrative e sistemi di registrazione.
Dal punto di vista tecnico potrebbe sembrare un comportamento proattivo. Dal punto di vista progettuale potrebbe essere un errore.
Quelle strutture potrebbero essere premature, basate su requisiti non ancora definiti o incompatibili con decisioni future.
Per questo motivo nei task specifico frequentemente vincoli come:
nessuna modifica al database;
nessuna nuova migrazione;
nessuna nuova dipendenza;
nessuna modifica all’autenticazione;
nessun collegamento verso route non ancora esistenti;
nessuna modifica a componenti non coinvolti;
nessun dato sensibile nella documentazione o nei log.
Le esclusioni non limitano l’intelligenza dell’agente. Proteggono la coerenza del progetto.
Sia deghetto.it sia Studio Ergo Sum sono stati sviluppati attraverso una successione di attività circoscritte.
Ogni task deve lasciare il progetto in uno stato coerente e possibilmente distribuibile.
Questo significa che l’obiettivo non è soltanto “scrivere il codice”, ma completare un ciclo tecnico.
In genere il ciclo comprende:
analisi del contesto;
definizione del perimetro;
identificazione dei criteri di accettazione;
intervento sul repository;
esecuzione della build;
esecuzione dei test;
controllo delle differenze Git;
aggiornamento della documentazione;
creazione del commit;
eventuale publish e deploy;
verifica delle principali URL o funzionalità;
registrazione dello stato finale.
Non tutte le attività richiedono necessariamente ogni passaggio, ma il principio resta lo stesso: il risultato deve essere verificabile.
Nel progetto Studio Ergo Sum, per esempio, numerosi interventi hanno riguardato aspetti apparentemente secondari, ma essenziali in una demo pubblica: avvisi chiari sulla natura dimostrativa del prodotto, protezione delle informazioni tecniche, pagina di stato non sensibile, gestione prudente del modulo di contatto, comportamento della PWA e verifica delle pagine pubblicate.
Affrontare questi elementi in task separati ha consentito di controllare meglio ogni modifica e di evitare che un intervento interferisse con funzionalità già consolidate.
Quando si parla di AI e programmazione, l’attenzione si concentra quasi sempre sulla generazione del codice.
Nella pratica, però, il codice è soltanto una parte del risultato.
Un agente può produrre un’implementazione formalmente corretta e, nello stesso tempo, introdurre una regressione, modificare un comportamento non richiesto, rompere un collegamento o dimenticare di aggiornare un test.
Per questo motivo considero build e test parte integrante del task, non una verifica opzionale da svolgere in seguito.
Quando possibile, il task deve specificare quali test aggiungere o aggiornare e quali condizioni devono essere dimostrate.
Anche il controllo del repository è essenziale.
Prima di considerare terminato il lavoro è necessario verificare quali file siano stati modificati, se siano comparsi file temporanei, se siano state introdotte configurazioni locali o informazioni che non devono essere versionate.
Il commit rappresenta poi un’unità logica del progetto. Deve descrivere un cambiamento coerente, non una somma casuale di interventi accumulati nel tempo.
Infine, quando il task comprende il deploy, la verifica non termina con il caricamento dei file.
Occorre controllare che l’applicazione sia effettivamente disponibile, che le pagine principali rispondano correttamente, che le aree protette continuino a esserlo e che eventuali file temporanei utilizzati durante la pubblicazione siano stati rimossi.
La differenza è sostanziale.
Un’attività non è completata quando il codice “sembra corretto”. È completata quando l’intero percorso dal requisito all’ambiente finale è stato controllato.
L’espressione “human in the loop” viene utilizzata spesso, talvolta in modo generico.
Nel mio metodo il controllo umano non consiste semplicemente nell’approvare l’ultima risposta prodotta dall’agente.
Significa mantenere la responsabilità delle decisioni.
Sono io a stabilire se una funzionalità è necessaria, se il suo perimetro è adeguato, se una struttura architetturale è coerente e se il rischio di introdurla è accettabile.
ChatGPT può aiutarmi a individuare alternative, conseguenze e punti deboli.
Codex può analizzare il repository e proporre un’implementazione.
Ma la decisione finale non viene delegata.
Questo è particolarmente importante quando il progetto comprende autenticazione, dati personali, configurazioni, invio di email, pubblicazione su Internet o dipendenze esterne.
L’agente può verificare molti aspetti tecnici, ma non può assumersi la responsabilità professionale del risultato.
Il controllo umano comprende anche la capacità di fermare un’attività.
Se durante l’implementazione emerge che il requisito è più ampio del previsto, non è sempre opportuno lasciare che l’agente completi comunque una soluzione.
Può essere preferibile ridurre il perimetro, creare un task intermedio o rimandare una decisione fino a quando il contesto non sarà sufficientemente stabile.
Lo sviluppo agentico può sembrare lento in alcuni momenti.
La definizione del contesto richiede tempo. La scomposizione del lavoro richiede attenzione. Build, test e verifiche possono rallentare il completamento apparente di una funzionalità.
Tuttavia, confrontare soltanto il tempo impiegato a scrivere il codice sarebbe fuorviante.
La produttività reale comprende anche il tempo non speso a correggere regressioni, ricostruire decisioni dimenticate, modificare funzionalità premature o individuare file alterati accidentalmente.
Nel mio caso il processo basato su ChatGPT e Codex mi consente di procedere con continuità anche su progetti articolati, mantenendo traccia delle decisioni e riducendo il carico operativo delle attività ripetitive.
Non significa che l’agente non commetta errori.
Significa che il processo è progettato per intercettarli.
La vera accelerazione non deriva soltanto dalla capacità dell’AI di scrivere codice più rapidamente. Deriva dalla possibilità di mantenere un flusso costante tra analisi, implementazione, verifica e documentazione.
L’esperienza maturata su questi progetti mi ha mostrato anche alcuni errori ricorrenti.
Il primo è affidare all’agente task troppo grandi. Più il perimetro è esteso, più aumenta la probabilità di decisioni arbitrarie, modifiche non richieste e difficoltà nella revisione.
Il secondo è utilizzare un contesto obsoleto. Un’istruzione corretta alcune settimane prima potrebbe non esserlo più dopo una modifica architetturale.
Il terzo è confondere il riepilogo prodotto dall’agente con una verifica. Una frase come “tutti i test sono stati superati” deve corrispondere a un’esecuzione reale e controllabile.
Il quarto è trascurare la documentazione. Se una decisione importante rimane soltanto nella conversazione, rischia di non essere disponibile nel momento in cui servirà a un altro task o a un altro agente.
Il quinto è permettere che l’AI introduca strutture premature “per completezza”. Nello sviluppo software la completezza anticipata è spesso una forma elegante di spreco.
Uno degli aspetti più interessanti dello sviluppo agentico è che costringe a rendere esplicite molte informazioni che, nei progetti tradizionali, rimangono disperse.
Decisioni, vincoli, esclusioni e criteri di completamento devono essere descritti in modo sufficientemente chiaro da poter essere utilizzati da un agente.
Questo migliora non soltanto il lavoro dell’AI, ma anche la qualità complessiva del progetto.
Un contesto ben costruito diventa una memoria operativa.
Consente di riprendere il lavoro dopo una pausa, trasferire un’attività, verificare se una nuova proposta è coerente con le decisioni precedenti e comprendere perché una determinata soluzione è stata adottata.
L’intelligenza artificiale, da questo punto di vista, non elimina la necessità della documentazione. La rende ancora più evidente.
Se il contesto è confuso, l’agente produrrà facilmente risultati confusi.
Se il contesto è aggiornato, delimitato e verificabile, l’agente può diventare un collaboratore estremamente produttivo.
Non credo che il valore principale dello sviluppo agentico consista nel sostituire lo sviluppatore.
Il vero vantaggio consiste nell’amplificare un metodo di lavoro.
Un processo disordinato, affidato a un agente molto veloce, rimane disordinato. Produce soltanto più modifiche in meno tempo.
Un processo strutturato, invece, può beneficiare enormemente della capacità dell’agente di leggere codice, eseguire attività ripetitive, verificare condizioni e mantenere il ritmo operativo.
Il risultato dipende quindi dall’interazione tra competenza umana, qualità del contesto e capacità tecnica degli strumenti.
Nel mio caso ChatGPT e Codex non rappresentano due assistenti intercambiabili.
Sono componenti di un flusso.
ChatGPT mi aiuta a passare dall’idea alla specifica operativa.
Codex trasforma quella specifica in modifiche concrete sul repository.
Test, Git e ambiente pubblicato forniscono le evidenze.
Io mantengo il controllo sul significato e sulla direzione del lavoro.
Lo sviluppo agentico non consiste nel formulare un prompt particolarmente brillante e attendere che l’intelligenza artificiale costruisca un’applicazione.
Consiste nel progettare un processo nel quale ogni partecipante abbia un ruolo definito.
L’agente deve ricevere contesto sufficiente, task circoscritti, vincoli espliciti e criteri di accettazione verificabili.
Il repository deve rimanere la fonte concreta dello stato tecnico.
I test devono dimostrare che le modifiche non abbiano compromesso il sistema.
Il commit deve rappresentare un incremento coerente.
Il deploy deve essere verificato nell’ambiente reale.
E il controllo umano deve rimanere presente dall’inizio alla fine.
È questo il metodo che sto applicando nello sviluppo di deghetto.it e Studio Ergo Sum.
Non un’automazione cieca, non una semplice generazione di codice e nemmeno la ricerca dello strumento capace di produrre la risposta più spettacolare.
Piuttosto, una collaborazione organizzata tra ragionamento umano, orchestrazione e agenti operativi.
Il codice rimane importante.
Ma, nello sviluppo agentico, il vero vantaggio competitivo potrebbe essere la capacità di costruire e governare il processo che lo produce.
NOTA: ho il piacere di informarvi che è stato pubblicato il mio libro “FLUSSI INFORMATIVI SANITARI E SOCIOSANITARI” (576 pagine). Lo trovate su Amazon per Kindle e in cartaceo (https://www.amazon.it/Flussi-informativi-sanitari-sociosanitari-Ghetto/dp/B0H6YCR6VC). Nel libro non troverete tracciati record, bensì le logiche che stanno dietro agli innumerevoli flussi ospedalieri e territoriali, gli aspetti più prettamente amministrativi ed economici (anagrafica, mobilità sanitaria, flussi di bilancio ecc.) e le interconnessioni che permettono la governance del Sistema Sanitario Nazionale, dal livello locale gestionale e operativo fino al livello centrale.
Nessun post
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.