Sviluppo software con Devin: consegnare una vertical slice (Parte 2)

Bentornato! Nel primo tutorial di questa serie, Devin ha rispolverato il mio vecchio repo fp-ts-exercises e ha aperto una PR pulita per l’aggiornamento delle dipendenze. In questa seconda parte, alziamo l’asticella e costruiamo funzionalità full-stack.

Puoi accedere a tutti i tutorial della serie su Devin qui:

1. Setup e prima Pull Request (Parte 1)
2. Consegnare una vertical slice con Devin (Parte 2) 
3. Integrazioni, test e CI/CD (Parte 3) 
4. Sicurezza, deployment, manutenzione (Parte 4)

Quando arriverai in fondo a questa seconda parte, avrai:

• Un playground Next.js 14, dove chi impara modifica il codice direttamente nel browser;
• Test Vitest live che diventano verdi (o rossi) in tempo reale; e
• Un backend NestJS con database SQL che salva i progressi usando nient’altro che un UUID anonimo in localStorage.

Lungo il percorso, lasceremo che Devin generi la sua lista di task, lo guarderemo destreggiarsi tra ticket front-end e back-end, e interverremo quando inciampa su gremlin di configurazione. Ti mostrerò dove ho speso (e risparmiato) ACU, cosa ho corretto a mano e come mantenere le sessioni efficienti.

Requisiti e ripasso

In tutta la serie, lavoriamo sul mio (un tempo) abbandonato repo di esercizi fp-ts.

Il progetto è una raccolta di piccole sfide pensate per insegnare concetti di programmazione funzionale (come Option, Either, ecc.) in TypeScript. Al momento è un repo “clona e avvia”: chi impara lo clona, modifica i file in locale ed esegue i test nel proprio terminale.

L’obiettivo è trasformare quegli esercizi in un playground interattivo nel browser, dove si può leggere una spiegazione, modificare il codice in un editor in pagina e vedere i test passare (o fallire) all’istante. Inoltre, chi impara potrà anche effettuare l’accesso per salvare i propri progressi.

Cosa abbiamo fatto nella prima parte

Ricorda che nel primo tutorial abbiamo:

• Modernizzato il vecchio repo fp-ts: dipendenze aggiornate, linting, type-check.
• Collegato Devin a GitHub e provato che può aprire una pull request pulita.

Strumenti locali necessari per la seconda parte

Per questo secondo tutorial, ci serviranno:

• Node 20+ e npm 10 (con supporto nativo ai workspaces).
• Docker con un container PostgreSQL (o un’istanza PostgreSQL locale).

Impostazioni consigliate per Devin

Ti consiglio le seguenti impostazioni per Devin:

• Imposta un limite morbido di 5 ACU per sessione in Settings > Usage & limits; avvieremo una sessione nuova per ogni fase.
• Tieni visibile la scheda timelapse per mettere in pausa o dare un colpetto a Devin se si blocca.

Lascia che Devin scriva il piano di gioco

Ho pensato che sarebbe stato interessante iniziare testando la capacità di pianificazione di Devin. Ho creato un prompt e ho chiesto a Devin, usando la funzione “Ask” (attualmente gratuita in Beta), di aiutarmi a pianificare il lavoro che faremo oggi.

Prompt:

Voglio trasformare il mio repo Node + TypeScript fp-ts-exercises esistente (attualmente esercizi CLI “clona e avvia”) in una piattaforma di apprendimento basata sul browser che tenga traccia dei progressi. 

Esperienza target: 

- Chi impara apre un’app web Next.js, sceglie un esercizio, modifica il codice nel browser e vede i test Vitest passare o fallire all’istante. 

- I progressi (gli slug completati) sono salvati lato server e ricaricati alle visite successive, ma per ora non aggiungiamo account utente (usa un UUID anonimo salvato nel browser). 

Scelte tecniche verso cui propendo: 

- Frontend: Next.js 14 (React 18, App Router) 

- Editor e runner del codice: Sandpack + @vitest/browser 

- API: NestJS 13 con @nestjs/graphql (Apollo Driver) 

- Database: Prisma 5 con PostgreSQL 

- Workspace: semplici npm workspaces (apps/web, apps/api, packages/exercises) 

Proponi un piano di implementazione passo-passo (lista di task) che dia vita a questa vertical slice. Stima il costo relativo in ACU per ciascun task ed evidenzia eventuali passaggi lunghi (es. grandi migrazioni o installazioni pesanti di dipendenze).

Devin ha restituito utilmente una lista di task in sei fasi con stime ACU per ciascuna, ed ha segnalato i passaggi di “installazione dipendenze pesanti”.

Risposta di Devin:

Fase 1: Setup del workspace (2–3 ACU)

• Inizializza la struttura degli npm workspaces (1 ACU)
• Crea le directory apps/web, apps/api e packages/exercises
• Configura il package.json alla radice con le definizioni dei workspace
• Sposta i file degli esercizi esistenti in packages/exercises/src/
• Setup frontend Next.js 14 (1–2 ACU — Lungo: installazione dipendenze)Inizializza Next.js con App Router in apps/webConfigura TypeScript e Tailwind CSSImposta una struttura di routing di base

Fase 2: Migrazione del pacchetto esercizi (3–4 ACU)

• Estrai i contenuti degli esercizi in un pacchetto condiviso (2 ACU)
• Crea packages/exercises con estrazione dei metadata degli esercizi
• Analizza i file esistenti per estrarre:
• Istruzioni
• Codice iniziale
• Soluzioni
• Definisci interfacce TypeScript per la struttura degli esercizi
• Implementa un sistema di discovery degli esercizi (1–2 ACU)
• Costruisci uno scanner del file system (simile alla logica fs.readdirSync in exercise.js:17–28)
• Esporta i metadata degli esercizi: title, description, difficulty, tests

Fase 3: Backend API (4–5 ACU)

• Setup API NestJS con GraphQL (2 ACU — Lungo: installazione dipendenze)
• Inizializza il progetto NestJS in apps/api
• Configura il server Apollo GraphQL
• Imposta endpoint di health check di base
• Implementa Prisma + PostgreSQL (2 ACU — Lungo: setup database)
• Progetta lo schema per:
• Sessioni utente
• Esercizi completati
• Configura Prisma client e migrazioni
• Crea i resolver per il tracciamento dei progressi
• Gestione sessioni utente anonime (1 ACU)
• Genera un UUID e salvalo nel localStorage del browser
• Abilita la persistenza dei progressi basata su sessione senza autenticazione

Fase 4: Funzionalità core del frontend (5–6 ACU)

• Interfaccia di navigazione degli esercizi (2 ACU)
• Elenca gli esercizi per categoria (option, either, task, ecc.)
• Mostra indicatori di progresso e stato di completamento
• Abilita selezione e navigazione degli esercizi
• Integrazione dell’editor Sandpack (2–3 ACU — Lungo: setup Sandpack)
• Configura Sandpack con supporto TypeScript
• Carica codice iniziale e dipendenze fp-ts
• Imposta il file system per file di esercizi + test
• Integrazione del runner Vitest nel browser (1 ACU)
• Sostituisci le chiamate Vitest con execSync (exercise.js:45–47) con @vitest/browser
• Abilita esecuzione test in tempo reale e visualizzazione dei risultati

Fase 5: Tracciamento dei progressi (2–3 ACU)

• Gestione dei progressi lato client (1 ACU)
• Configura Apollo Client per GraphQL
• Sincronizza i progressi con il backend
• Rilevamento del completamento dell’esercizio (1–2 ACU)
• Adatta la logica di rilevamento del successo esistente (exercise.js:48–49)
• Attiva gli aggiornamenti di progresso sul backend al passaggio dei test

Fase 6: Finiture & Deployment (2–3 ACU)

• Miglioramenti UI/UX (1–2 ACU)
• Assicura un design responsive
• Aggiungi stati di caricamento e gestione degli errori
• Migliora la visualizzazione delle istruzioni degli esercizi
• Setup del deployment in produzione (1 ACU)
• Configura Docker per entrambe le app
• Gestisci le variabili d’ambiente
• Imposta il deployment del database

Costo stimato totale: 18–24 ACU

Il piano era complessivamente buono. Ho cambiato alcune cose, in particolare nella sesta fase, dato che affronteremo il deployment nel quarto tutorial.

Fase 1: Workspace & impalcatura del front-end

Obiettivo: Avviare npm workspaces, spostare i file legacy e bootstrap di un guscio Next.js 14 vuoto. ACU consumati: 3,66 (previsti 1–2). Esito: Il repo ora ha /apps/web, il pacchetto condiviso packages/exercises e un’app Next.js pronta per Tailwind in esecuzione su localhost:3000.

Il prompt

Ho chiesto a Devin di costruire il piano che aveva proposto per la prima fase. Devin in modalità agent non ha contesto di quanto potresti aver chiesto prima nella funzione “Ask Devin”, quindi devi creare un prompt separato e fornire il contesto. 

Non incollerò tutti i prompt in questo articolo, ma ecco il primo:

Prompt:

Task: Inizializzare la struttura degli npm workspaces e il frontend Next.js per la piattaforma browser di fp-ts-exercisesContesto:

Sto convertendo il mio sistema di apprendimento basato su CLI fp-ts-exercises esistente in una piattaforma basata sul browser. L’attuale sistema ha esercizi organizzati in 10-from-either.exercise.ts:1-3 con configurazione TypeScript in tsconfig.json:88 e setup di Vitest in vitest.config.ts:7.

Requisiti:

• Crea la struttura degli npm workspaces:
• package.json alla radice con configurazione dei workspace per apps/web, apps/api, packages/exercises
• Sposta i file degli esercizi esistenti dall’attuale src/ a packages/exercises/src/
• Mantieni la convenzione di naming attuale (.exercise.ts e .solution.ts)
• Inizializza il frontend Next.js 14 in apps/web:
• Usa l’App Router (non il Pages Router)
• Configura TypeScript con impostazioni strict simili a tsconfig.json:88
• Aggiungi Tailwind CSS per lo styling
• Crea una struttura di routing di base per la navigazione degli esercizi
• Mantieni la compatibilità:
• Assicurati che la struttura degli esercizi esistente e gli import funzionino ancora
• Mantieni accessibili le dipendenze fp-ts attraverso il workspace
• Preserva i pattern di configurazione attuali di Vitest

Deliverable:

• package.json alla radice configurato per i workspace
• App Next.js in apps/web/ con TypeScript e Tailwind
• Esercizi migrati in packages/exercises/
• Struttura di routing di base (/exercises, /exercises/[category], /exercises/[category]/[slug])

Stack tecnico:

• Next.js 14 con App Router
• TypeScript (strict mode)
• Tailwind CSS
• npm workspaces (non yarn/pnpm)

Consegna:

• Assicurati che gli script di lint e typecheck passino
• Crea una PR con le tue modifiche

Tutti i prompt che ho scritto in seguito hanno seguito lo stesso schema: evidenziazione del task, contesto, requisiti, deliverable, stack tecnico e dettagli di consegna.

Cosa ha fatto davvero Devin

Ci ha messo abbastanza a decidere il da farsi (circa quattro minuti), ma ha:

1. Creato lo scheletro del workspace
2. Migrato tutte le cartelle degli esercizi in packages/exercises/src.
3. Bootstrap di Next.js 14 con App Router, TypeScript e Tailwind.
4. Aggiunto gli script di lint & type-check all’app frontend (dopo un mio sollecito).

Perché il costo in ACU è salito

Il costo in ACU è salito perché:

• Devin ha passato un minuto intero a ripetere i tentativi di npm install dopo un timeout dello specchio.
• Ha provato a fermare il dev server e i processi con q in Vim, poi con Ctrl-C, e entrambi sono falliti. Gli ho dato un po’ di tempo per provare a sistemare da solo, ma alla fine sono intervenuto manualmente e ho chiuso i processi entrambe le volte. Ogni minuto extra significava ACU extra, e non avrei colto il problema rapidamente se non avessi seguito da vicino le azioni di Devin.

Interventi umani e lezioni apprese

Ecco un riepilogo delle correzioni che ho dovuto fare:

Spostare grandi alberi di file è più veloce a mano, e molto meno costoso dato che Devin addebita per tempo/task. Ho trascinato le cartelle, fatto commit e lasciato che l’agente rilevasse la nuova struttura. È riuscito a prendere le mie modifiche e a fare un merge da solo!

Detto ciò, ho dovuto sollecitarlo a eseguire gli script di lint e typecheck, anche se l’avevo specificato nel prompt iniziale. Alla fine li ha eseguiti entrambi, ma sono falliti. Devin ha comunque considerato il tutto un successo ed è andato avanti con la PR.

Ho corretto entrambi i problemi in locale, eseguito io stesso gli script, avviato il nuovo server di sviluppo web per assicurarmi che partisse come previsto e pushato il commit.

Fase 2: Impacchettare gli esercizi

Obiettivo:  Estrarre tutti i file delle challenge in un pacchetto riutilizzabile packages/exercises e generare metadata per ogni esercizio. ACU consumati:  0,6 (previsti 2+). Esito: Il pacchetto condiviso esporta metadata tipizzati che l’app web e la futura API possono importare con import { exercises } from '@exercises/registry'.

Cosa ha fatto davvero Devin

Devin ha creato:

• Interfacce TypeScript strutturate per esercizi, metadata, categorie e l’intero catalogo.
• Parser degli esercizi che:
• Estrae metadata da commenti del codice e firme di funzione
• Analizza codice iniziale, soluzioni e test case Vitest
• Auto-genera tag dall’uso di fp-ts
• Converte i nomi camelCase in titoli leggibili
• Sistema di discovery degli esercizi che:
• Scansiona il file system per coppie .exercise.ts e .solution.ts
• Costruisce un catalogo basato su slug (per esempio, option-01)
• Organizza gli esercizi per categoria con caching per le performance
• Export comodi per interrogare esercizi e categorie:
• getExercises(), getExerciseBySlug(), getExercisesByCategory(), getCategories(), getCategoryBySlug()

Perché Devin è rimasto sotto budget

Devin è riuscito a tenere basso il costo in ACU — ecco come:

• Nessuna installazione pesante o chiamate di rete
• Gli spostamenti di file sono stati lineari; Devin ha usato git mv (economico) invece di copia-incolla più diff
• La generazione dei metadata era puro TypeScript, veloce da pianificare ed eseguire

Interventi umani

Questa volta nessuno!

Facendo tesoro della volta precedente, ho fatto checkout del branch di Devin ed eseguito gli script in locale. Tutto ha compilato e il registry esporta definizioni di tipo pulite, perfette come input per la UI e l’API che costruiremo dopo.

Fase 3: API NestJS + GraphQL

Obiettivo: Alzare un servizio NestJS 13 che espone i progressi degli esercizi via GraphQL e persiste i dati in PostgreSQL con Prisma. ACU consumati: 4,2 (previsti 4). Esito: apps/api si avvia su localhost:4000/graphql. Puoi interrogare e mutare i record di progresso indicizzati da un ID di sessione anonimo.

Cosa ha fatto davvero Devin

Per la terza fase, Devin ha:

1. Creato un’API NestJS completa in apps/api con TypeScript e Apollo GraphQL
2. Integrato PostgreSQL con Prisma ORM e impostato lo schema con modelli Session e CompletedExercise
3. Implementato la gestione di sessioni anonime tramite UUID (senza auth)
4. Costruito resolver GraphQL per creazione/validazione sessione, query su esercizi e tracciamento dei progressi
5. Collegato il backend al pacchetto condiviso degli esercizi (packages/exercises) per la discovery dei dati
6. Configurato CORS per supportare la comunicazione con il frontend Next.js
7. Garantita la compatibilità di tipo tra schema GraphQL e interfacce TypeScript esistenti
8. Impostato script di sviluppo, flusso delle migrazioni del database e integrazione con Prisma Studio

Dove Devin ha inciampato

Questi sono i problemi incontrati durante la terza fase e le correzioni che ho dovuto fare:

Lezioni apprese

Questi sono i miei takeaway:

• Config vs. codice: Devin eccelle una volta che il boilerplate del framework è a posto, ma diagnosticare problemi di dipendenze richiede ancora un occhio umano.
• Esegui sempre in locale: avevo già creato un database PostgreSQL locale sulla mia macchina, e le istruzioni nella PR per eseguire la migrazione Prisma e avviare l’ambiente di sviluppo erano chiare e facili da seguire (vedi immagine sotto). Il commento di Devin diceva che era riuscito ad avviare l’API in locale, eppure npm run dev andava in crash finché non è stato aggiunto reflect-metadata.

• Devin gestisce bene i commenti in PR. Ho commentato la PR spiegando a Devin che avevo provato a eseguire l’API in locale e avevo riscontrato un errore. Ha subito messo un’emoji a forma di occhio, e la sessione è ripresa da sola per correggere l’errore; una fix è stata pushata pochi minuti dopo.

• Controlla sempre i file segreti: Devin aveva committato un file .env con una variabile DATABASE_URL, che conteneva username e password fittizi. Una volta pullato in locale, ho cambiato username e password con quelli del mio database locale e mi sono assicurato di rimuovere il file dal tracciamento git e aggiungerlo a .gitignore. Vedremo nei prossimi tutorial come gestire in sicurezza i segreti.

Fase 4: Playground Sandpack & test live

Obiettivo: Fornire a chi impara un editor nel browser che esegue soluzioni fp-ts e controlli Vitest in tempo reale. ACU consumati: 7,2 (previsti 3-4). Esito: Visitando /exercises/option-01 si apre una vista divisa: editor Sandpack a sinistra, “tunnel” dei test a destra, e compare un messaggio di successo nel momento in cui tutti gli spec passano.

Cosa ha fatto davvero Devin

Ecco cosa ha fatto Devin per la quarta fase:

• Costruito pagine di elenco esercizi e navigazione con supporto dinamico per categoria e slug
• Integrato l’editor Sandpack con TypeScript, fp-ts e supporto al file system in tempo reale
• Sostituito il test runner da CLI con Vitest nel browser e feedback live
• Collegato il frontend al backend tramite Apollo Client per il tracciamento dei progressi basato su sessione
• Implementata una UI responsive con stati di caricamento e gestione degli errori

Dove Devin ha bruciato ACU extra

Devin ha consumato più ACU del previsto per questa fase — ecco perché:

Lezioni apprese

I miei takeaway stavolta sono:

• Guardare in silenzio = bruciare soldi. Tieni aperta la scheda Timelapse e, se Devin entra in loop, dagli un colpetto o mettilo in pausa.
• Elimina presto il codice morto. Devin non elimina davvero il codice obsoleto da solo, a meno che tu non glielo dica. Ho commesso l’errore in precedenza di chiedergli di spostare i file senza dirgli esplicitamente di eliminarli, e ci siamo ritrovati con punti di ingresso multipli che hanno molto confuso il povero Devin in questa fase.

Qui Devin ha impiegato un po’ di tempo. Ha fatto loop su loop, tentando di risolvere gli stessi problemi, non collegando correttamente backend e frontend, facendo modifiche, riavviando i server, controllando nel browser se funzionava, ecc. Insomma, proprio come il normale lavoro di sviluppo, suppongo…

Ora abbiamo un’app funzionale. Sono riuscito ad avviare sia l’API sia il server web, navigare su localhost, modificare la funzione stub, premere Salva e guardare il pannello dei test passare da rosso a verde. Poi mi sono accorto che il lavoro era solo a metà: aveva hardcodato i test e la soluzione del primo esercizio su ogni pagina esercizio. L’ho fatto notare e, dopo altri loop, è riuscito a correggerlo e pushare le fix.