il futuro dello sviluppo software? La nostra prova

Codex sembra la versione Web costruita attorno a Codex CLI e orientata all’integrazione con GitHub da cui l’agente va a recuperare i codici sorgenti e propone modifiche mediante il meccanismo delle pull request.

Come funziona Codex, l’agente di Openai

Vista la complessità delle funzioni richieste questo agente ha una sua interfaccia Web separata da ChatGPT in cui è collegata (per ora in anteprima ai livelli di sottoscrizione Pro, Team e Enterprise) mediante un link nella barra di sinistra dell’interfaccia.

Una volta aperta la nuova scheda (che punta a https://chatgpt.com/codex) si viene guidati da un wizard che spiega di cosa si occupa il nuovo agente e cosa può fare:

Alla prima esecuzione viene anche richiesto il collegamento a una o più organizzazioni GitHub (incluso lo spazio personale) così da poter accedere ai repository di codice e proporre modifiche.

Codex ragiona per ambienti, ovverosia spazi in cui un repository viene clonato all’interno di macchine virtuali nel cloud in cui l’AI potrà eseguire confinata i comandi di shell necessari all’analisi e alla manipolazione del codice.

Dopo aver creato il collegamento tra Codex e GitHub è necessario selezionare un repository per terminare la creazione di un ambiente e poter cominciare ad operare. In questo caso ho scelto il repository di Oraculum.

Per ciascun ambiente è possibile anche specificare se consentire l’addestramento o meno per migliorare i modelli:

Essendo Codex un agente l’interfaccia è concepita per essere asincrona e mostra la text box per effettuare richieste e le attività in corso o concluse su specifici repository di codice e rami di versione. Le attività in corso e quelle non ancora archiviate sono quindi visibili e corrispondono ad un’interazione con l’agente, una sorta di Chat ma decisamente più articolata dal punto di vista della visualizzazione:

Durante la creazione dell’ambiente vengono proposti tre esempi di attività che si possono eseguire per cominciare. Codex consente sia di analizzare che di proporre modifiche al codice. Viene anche ricordato che il codice generato può contenere errori e va sempre rivisto:

L’agente non si limita a lanciare comandi per analizzare e modificare il codice, può anche eseguire i comandi necessari per effettuare i test di unità e verificare che, nel caso di linguaggi compilati, il processo di build si concluda con successo. Essendo Oraculum una codebase scritta in .NET e in Python nella sezione avanzata della creazione dell’ambiente ho inserito lo script di configurazione che ha eseguito i comandi per installare la versione di .NET necessaria ai test che non è disponibile per default:

Come usare OpenAI Codex: la prova

Ho chiesto come primo compito quello di analizzare i vari progetti disponibili nel repository al fine di spiegarne la struttura per qualcuno che volesse contribuire al progetto Open Source. L’analisi è sicuramente sorprendente, non solo per la corretta individuazione delle funzionalità ma anche per i suggerimenti che vengono generati per spiegare come iniziare lo sviluppo:

La libreria PowerShell di Oraculum ha un bug su cui non ho avuto ancora tempo di lavorare: i cmdlet che leggono configurazioni usano come directory corrente quella in cui è stata avviata la shell e non quella corrente, ho provato quindi a richiedere di risolvere il problema. Si tratta di un compito non troppo complicato e allo stesso tempo che richiede la verifica di numerosi file, mi sembrava un buon punto di partenza per testare Codex:

Ho monitorato l’attività mentre l’agente ha lavorato sul mio prompt, ed è affascinante vedere tutti i passaggi che l’AI svolge per elaborare così tanti file riuscendo a costruire una visione articolata. Al completamento dell’attività ho analizzato le modifiche proposte aprendo l’attività e visualizzando i cambiamenti mediante un’interfaccia a cui gli sviluppatori sono ormai abituati che mostra i cambiamenti proposti. Nel nostro caso le modifiche sono puntuali ed effettuate sui file in cui effettivamente il bug era presente.

Ho quindi usato il menu Push in alto a destra per creare una pull request che ho prontamente ritrovato su GitHub:

Codex, la differenza con Microsoft

Codex sembra un’interfaccia convincente per uno sviluppo (o quantomeno la manipolazione) di programmi nell’era dell’AI.

È un approccio AI centered in opposizione alla strada seguita da Microsoft (e recentemente ribadita alla conferenza Build) che spinge sull’integrazione delle funzioni di AI all’interno degli strumenti di sviluppo come fa con Copilot per GitHub.

Come prima anteprima ho trovato l’intero approccio decisamente maturo ed efficace ma apre un problema che sarà sempre più rilevante: chi è in grado di supervisionare il lavoro di una AI?

La sfida della supervisione dell’AI

Un programmatore che sviluppa codice lo fa usando le proprie conoscenze e quindi per definizione è in grado sperabilmente di anticipare il comportamento del sistema che sta sviluppando, ma come si fa se deve rivedere codice generato da una AI che ha una conoscenza enorme su linguaggi di programmazione e può quindi utilizzare caratteristiche ignote al revisore? È un tema di enorme rilevanza poiché l’AI potrebbe inserire comportamenti non interamente compresi e gli sviluppatori potrebbero non accorgersene portando a potenziali malfunzionamenti che, nel caso di sistemi di attuazione potrebbero addirittura produrre danni.

Lo sviluppo basato su AI è già una realtà, e personalmente penso che sarà un mix di scrittura di codice in editor come VSCode integrati con l’AI e strumenti come Codex che consentono analisi e manipolazioni di alto livello di intere codebase. Ma questo inevitabilmente alzerà l’asticella delle competenze di un programmatore che dovrà essere in grado di rivedere codice generato e che potrebbe includere problemi che vanno individuati.

Il futuro: un nuovo ruolo per programmatori

Sembra quindi che la professione del programmatore sia destinata a cambiare rapidamente, richiedendo sempre più competenze che consentano l’analisi di codici scritti da AI e potenzialmente più complessi di quelli che possono sviluppare programmatori iunior. Questo fatto inevitabilmente costringerà a rivedere l’approccio che abbiamo seguito nel corso degli ultimi cinquant’anni che prevedeva la formazione di programmatori con differenti livelli di competenze per sviluppare un numero sempre crescente di sistemi. Si pensava anche che saper programmare fosse anche un modo per avvicinare gli uomini alle macchine, oltre che una competenza utile per la vita professionale. Ora alle macchine parliamo in linguaggio naturale per scrivere sistemi, e avremo bisogno sempre più di esperti capaci di analizzare i codici generati.

Allo stesso tempo prepariamoci ad un’altra accelerazione nello sviluppo dei sistemi software: chi riesce ad integrare in modo controllato e con le opportune supervisioni queste tecnologie potrà sviluppare codice ad una velocità semplicemente impossibile in precedenza.

Non resta che ammirare la lungimiranza di Alan Turing che all’inizio degli anni cinquanta aveva previsto tutto ciò: dopo una prima fase in cui matematici scrivono tabelle per programmare le macchine sarebbe seguita una fase in cui le macchine autonomamente avrebbero svolto questo compito. Sembra che la prima fase si avvicini al termine e che stiamo assistendo alla nuova fase.