Codex CLI: assegnazione del progetto di sviluppo e fasi iniziali

Il setup di un nuovo progetto Node.js è una di quelle attività che ogni sviluppatore ha eseguito decine di volte e che ogni volta richiede le stesse micro-decisioni: quale versione di TypeScript scegliere, come configurare tsconfig.json, dove mettere i file compilati, come strutturare i middleware Express, come inizializzare Prisma, come scrivere il docker-compose.yml in modo che lo sviluppo locale e il CI girino sullo stesso ambiente. Sono fasi ripetitive, non particolarmente creative e abbastanza standardizzate da essere un candidato naturale per l'automazione agentica.

Perché scegliere Codex CLI

Il nostro esperimento partiva da una directory completamente vuota con nessun package.json, nessun file di configurazione, nessuna struttura di cartelle e da un singolo task assegnato a Codex CLI tramite terminale:

codex "Crea la struttura completa di un progetto Express con TypeScript,
Prisma come ORM, autenticazione JWT con refresh token, e Docker Compose
con un servizio PostgreSQL e uno Redis. Il progetto deve essere pronto
per lo sviluppo locale con hot reload e per il deploy in produzione con
build ottimizzata. Usa ESM modules, non CommonJS."

Il vincolo di non toccare la tastiera era metodologico. Volevo osservare le decisioni autonome dell'agente senza interferire, e intervenire solo quando il processo si bloccava completamente. L'obiettivo non era quello di ottenere in output un progetto finito e pronto per la produzione, ma capire dove Codex CLI riesce ad arrivare da solo e dove si aspetta che lo sviluppatore prenda il controllo.

Cosa costruisce l'agente AI in fase iniziale

La prima osservazione interessante riguarda l'ordine delle operazioni. Codex CLI non ha iniziato dal package.json, cosa che sarebbe la scelta intuitiva per un developer umano, ma dalla struttura delle cartelle. Prima ancora di installare una singola dipendenza, ha creato questa gerarchia:

src/
  config/
  controllers/
  middleware/
  models/
  routes/
  services/
  types/
  utils/
prisma/
docker/
tests/
  unit/
  integration/

È una scelta che rivela come l'agente ragiona sul task. Esso costruisce prima lo scheletro architetturale, poi lo popola. Ogni cartella era accompagnata da un file index.ts vuoto che esportava un oggetto vuoto, in pratica un placeholder per mantenere la struttura nel controllo di versione senza dover gestire cartelle vuote con .gitkeep. Non era stato chiesto esplicitamente, ma è una pratica ragionevole che dimostra familiarità con i pattern più comuni dei progetti basati su Node.js.

Subito dopo la struttura, l'agente ha generato il package.json. Ed è qui che cominciano le prime decisioni autonome che meritano la nostra attenzione.

Le versioni dei package selezionati da Codex CLI

Il package.json generato da Codex CLI fissava le versioni di tutte le dipendenze in modo molto preciso, senza specificare dei range:

{
  "name": "api-service",
  "version": "0.1.0",
  "type": "module",
  "engines": {
    "node": ">=20.0.0"
  },
  "scripts": {
    "dev": "tsx watch src/index.ts",
    "build": "tsc --project tsconfig.build.json",
    "start": "node dist/index.js",
    "test": "vitest",
    "lint": "eslint src --ext .ts",
    "db:migrate": "prisma migrate dev",
    "db:generate": "prisma generate",
    "db:studio": "prisma studio"
  },
  "dependencies": {
    "express": "4.18.2",
    "@prisma/client": "5.7.1",
    "jsonwebtoken": "9.0.2",
    "bcryptjs": "2.4.3",
    "zod": "3.22.4",
    "helmet": "7.1.0",
    "cors": "2.8.5",
    "compression": "1.7.4",
    "ioredis": "5.3.2",
    "winston": "3.11.0",
    "dotenv": "16.3.1"
  },
  "devDependencies": {
    "typescript": "5.3.3",
    "tsx": "4.6.2",
    "vitest": "1.1.0",
    "prisma": "5.7.1",
    "eslint": "8.56.0",
    "@typescript-eslint/parser": "6.18.1",
    "@typescript-eslint/eslint-plugin": "6.18.1",
    "@types/express": "4.17.21",
    "@types/jsonwebtoken": "9.0.5",
    "@types/bcryptjs": "2.4.6",
    "@types/cors": "2.8.17",
    "@types/compression": "1.7.5"
  }
}

Ci sono due elementi degni di nota in questo file. Il primo è positivo in quanto l'agente ha scelto tsx per il development con hot reload invece di ts-node o nodemon, e vitest invece di Jest. Sono scelte difendibili in quanto tsx è molto più veloce di ts-node per progetti ESM, e vitest ha una compatibilità nativa con ESM che Jest fatica ancora a gestire senza configurazione aggiuntiva.

L'agente ha ragionato sulla coerenza tra la scelta di ESM modules nel task iniziale e i tool di sviluppo conseguenti.

Un problema con la scelta delle release

La seconda osservazione è più critica. Le versioni indicate corrispondevano a release di diversi mesi prima rispetto al momento dell'esperimento. Non erano versioni errate ma stabili e ben testate, erano però già superate da patch release che includevano fix di sicurezza.

Codex CLI le ha scelte perché erano le versioni più presenti nel suo training data, non perché fossero le più recenti. Su un progetto in fase di produzione, usare un package.json generato da un agente senza verificare che le versioni siano aggiornate rappresenta un rischio, specialmente per pacchetti come jsonwebtoken o bcryptjs che gestiscono passaggi delicati come quello relativo all'autenticazione.