In questo articolo Indice dei contenuti 2 sezioni
Automatizzare il setup di un progetto Node.js con Codex CLI direttamente dal terminale è l’esperimento al centro di questa guida, che parte da una condizione volutamente estrema: una directory vuota, niente file di configurazione, niente impalcatura preesistente. Da lì l’agente si mette al lavoro e costruisce l’intera base di un’applicazione con Express, TypeScript, Prisma, autenticazione JWT e Docker Compose. Nessun template scaricato, nessuno starter kit pronto all’uso, solo istruzioni testuali e un ambiente da riempire.
L’idea di fondo è semplice, anche se le implicazioni non lo sono affatto. Il bootstrap di un progetto backend è una di quelle attività che ogni sviluppatore ha ripetuto decine di volte, sempre uguale nella sostanza e sempre leggermente diversa nei dettagli. Struttura delle cartelle, script di build, configurazione del compilatore, gestione delle variabili d’ambiente, definizione dello schema del database. Lavoro necessario, ma raramente entusiasmante. Verificare se un agente da riga di comando possa occuparsene al posto nostro significa capire fino a che punto arriva l’autonomia reale di questi strumenti.
Cosa costruisce l’agente partendo da zero
Il perimetro dell’esperimento è quello di un backend moderno e piuttosto convenzionale. Express come framework per le rotte, TypeScript per la tipizzazione statica, Prisma come ORM per la gestione del database, un sistema di autenticazione basato su token JWT e un ambiente containerizzato orchestrato tramite Docker Compose. Uno stack che copre buona parte dei progetti backend che si incontrano nel lavoro quotidiano, quindi un banco di prova credibile.
Codex CLI non si limita a generare qualche file sparso. Costruisce la struttura del progetto, scrive le configurazioni, definisce lo schema del database, mette in piedi i middleware necessari e prepara l’ambiente Docker perché tutto funzioni insieme. Il punto interessante non è tanto la quantità di codice prodotto, quanto il fatto che l’agente debba prendere decisioni: dove collocare i file, quali convenzioni seguire, come collegare i vari pezzi tra loro. Sono scelte che normalmente ricadono su chi sviluppa e che qui vengono delegate.
Il confine tra autonomia e supervisione
La guida si concentra proprio su questo aspetto, che è poi la domanda più concreta che ci si può porre davanti a un agente da terminale. Quali decisioni riesce a prendere senza intervento umano e dove invece serve ancora una mano. Perché generare codice funzionante è una cosa, generare codice coerente con un’architettura sensata è tutt’altra faccenda.
Lavorare nel terminale cambia anche il modo in cui si interagisce con lo strumento. Non c’è un’interfaccia grafica che suggerisce, non ci sono suggerimenti inline mentre si scrive. C’è un dialogo testuale e un filesystem che si popola. Questo rende il processo più trasparente da un lato, perché ogni modifica è visibile e verificabile, e più impegnativo dall’altro, perché la qualità del risultato dipende in larga misura da come vengono formulate le richieste.
L’esperimento serve quindi a misurare qualcosa di molto pratico. Un progetto Node.js completo di autenticazione, database e containerizzazione rappresenta un carico di lavoro reale, non un esercizio didattico. Vedere quanto di quel carico può essere assorbito da un agente automatico dice parecchio sullo stato attuale degli strumenti di sviluppo assistito, al netto dell’entusiasmo che li circonda.
