Corso
Introduzione agli AI Agents
1 ore 30 min
147.4K
Credo che abbiamo tutti sentito parlare di Devin, il “junior software engineer IA” che a quanto pare clona il tuo repo, aggiunge nuove funzionalità, esegue i test e apre una pull request prima che tu finisca il caffè del mattino.
Come per tutte le cose IA di questi tempi, è piuttosto difficile capire quanto sia valido senza provarlo in prima persona, quindi ho deciso di farlo. Ho fatto passare Devin attraverso ogni fase dell’intero ciclo di vita dello sviluppo software e ho scritto una serie di quattro tutorial nella speranza che aiutino altri sviluppatori a trarne il massimo.
Puoi accedere a tutti i tutorial della serie su Devin qui:
- Configurazione e prima pull request (Parte 1)
- Pubblicare una “vertical slice” con Devin (Parte 2)
- Integrazioni, test e CI/CD (Parte 3)
- Sicurezza, deployment, manutenzione (Parte 4)
Se il tuo profilo GitHub è un “cimitero” di repository dimenticati, sei in buona compagnia. Il mio è pieno di esperimenti lasciati a metà. Nei prossimi quattro tutorial metteremo Devin al lavoro sul mio repo abbandonato di esercizi fp-ts, trasformando gli esercizi da clonare ed eseguire dell’anno scorso in una moderna piattaforma di apprendimento nel browser.
Lasciami spiegare molto velocemente il mio piano per i quattro tutorial, poi passeremo alla parte pratica per il resto della serie.
Cosa tratteremo in questa serie di tutorial
Rianimeremo un side-project dal mio cimitero GitHub, perché Devin rende al meglio quando ha codice reale, test reali e un po’ di storia su cui ragionare, non un repo vuoto.
Il progetto è fp-ts-exercises, una raccolta di piccole sfide pensate per insegnare concetti di programmazione funzionale (come Option, Either, ecc.) in TypeScript. Al momento è un repo da clonare ed eseguire: chi impara lo scarica, modifica i file in locale ed esegue i test nel proprio terminale.
Il mio obiettivo è trasformare quegli esercizi in un playground interattivo nel browser, dove si può leggere una spiegazione, modificare il codice in un editor nella pagina e vedere subito i test passare (o fallire). Gli utenti potranno anche effettuare l’accesso per salvare i progressi.
Nota: ho aggiornato il repo con Devin mentre scrivevo questi tutorial. Il link sopra mostra lo stato del codice ad aprile 2023, prima di aver abbandonato il progetto. Il codice aggiornato si trova qui.
Ecco il piano per le quattro parti:
- Parte 1 - Configurazione e prima pull request
- Registrati a Devin, connetti GitHub.
- Lascia che Devin ripulisca il repo: aggiorna le dipendenze, crea nuove regole di lint e script e apra la sua prima PR.
- Parte 2 - Pubblicare funzionalità
- Usa Devin per pianificare la nuova UI nel browser e l’API.
- Crea pagine, configura un database e i secret e fai aprire a Devin le PR delle feature.
- Parte 3 - Integrazioni, test e CI/CD
- Introduci test Vitest/Playwright e lascia che Devin li mantenga verdi.
- Genera una pipeline GitHub Actions, collega i ticket a Jira e connetti Devin a Slack.
- Esplora la funzionalità Wiki.
- Parte 4 - Sicurezza, deployment e manutenzione
- Aggiungi l’autenticazione, effettua il deployment dell’app e collega Sentry per il monitoraggio degli errori.
Alla fine, il vecchio repo da CLI dovrebbe diventare una web app rifinita!
Prima di iniziare con la parte pratica, diamo una presentazione generale di Devin. Se sai già che cos’è Devin e come funziona, passa pure alla sezione di configurazione.
Che cos’è Devin?
Devin è un agente di coding completamente autonomo, ospitato nel cloud e sviluppato da Cognition. Se lo inserisci in un repo, apre una shell, un editor e un browser in sandbox, poi pianifica ed esegue i task end-to-end senza toccare la tua macchina locale.
È stato lanciato a marzo 2024, con il post sul blog di Cognition che affermava che Devin aveva chiuso il 13,86% di issue GitHub reali sul benchmark SWE-bench, superando di gran lunga il precedente SOTA dell’1,96%. In pratica significa che, su un sottoinsieme accuratamente selezionato (570 issue), ha risolto 79 bug da progetti popolari come Django e scikit-learn senza aiuto umano.
È notevole, ma è pur sempre codice da benchmark (bug circoscritti e ben definiti con test suite), quindi nel mondo reale i risultati variano. In ogni caso, c’è chi dice che renda quanto un developer junior.
Casi d’uso di Devin
Devin è un ottimo alleato se vuoi implementare:
- Upgrade incrementali del repo: può eseguire i test, aggiornare le dipendenze e correggere iterativamente le rotture, il che è perfetto per task del tipo “porta questo progetto Node 14 a Node 20”.
- Ticket di feature ben delimitati: dato un’issue su GitHub o un ticket Jira con criteri di accettazione chiari, il ciclo piano-modifica-testa di Devin funziona piuttosto bene.
- Task non di coding: rigenerare la documentazione, cablare template di CI o formattare in massa i file può essere noioso per gli umani, ma è perfetto per un agente.
Tuttavia, Devin non è particolarmente adatto a:
- Architetture greenfield: fatica se gli dici semplicemente “costruiscimi una piattaforma SaaS da zero”. Ha bisogno di impalcature e rende meglio quando ha più contesto.
- Decisioni di prodotto ambigue: se gli chiedi di scegliere tra Stripe e Paddle per i pagamenti, potrebbe semplicemente scegliere a caso.
- Monorepo massivi: i limiti di contesto lo costringono a caricare e scaricare file, e le prestazioni crollano su workspace da 100k linee.
Come funziona Devin?
Tutti gli agenti di coding moderni, Devin incluso, eseguono un loop che rispecchia un ciclo di control:
|
Fase |
Cosa “vede” Devin |
Tecnologia chiave |
|
Perceive |
Legge file di codice, log dei test, output del terminale, DOM del browser |
Indicizzatore di codice, parser di log |
|
Cognize / Plan |
Scompone il prompt dell’utente in una lista di task, ragiona su ordine e strumenti |
Planner basato su LLM con memoria potenziata da retrieval |
|
Act |
Esegue comandi shell, modifica file, clicca su UI web |
Sandbox sicura (Docker/VM) con strumenti Shell / Editor / Browser |
|
Reflect / Learn |
Ri-esegue i test, ispeziona i diff, aggiorna il piano (o chiede a te) |
Prompt di autocritica + memoria su vector store |
|
Persist |
Salva timeline e artefatti per replay o hand-off |
Cloud object store + interfaccia timeline |
Devin è costruito come uno stack a livelli di moduli cooperanti:
- Tutto parte dall’interfaccia chat o dal bot Slack/ticket Jira, dove esprimi l’obiettivo sotto forma di prompt.
- Il prompt viene passato a un LLM planner che espande l’obiettivo in un piano passo-passo e autocritica ogni step prima dell’esecuzione.
- Un esecutore leggero seleziona poi lo strumento giusto per ogni step (shell, editor di codice o browser headless), il tutto in un workspace strettamente sandboxato.
- Quella sandbox è di fatto un laptop nel cloud e isola le credenziali, dà a Devin un prompt Bash, un editor in stile VS Code e un’istanza di Chrome che può cliccare.
- Sotto il workspace c’è uno strato di memoria che conserva snapshot vettorializzati della codebase più una timeline completa di replay di ogni comando, diff di file e tab del browser toccati da Devin.
Perché questa architettura è così valida? Primo, il ciclo di feedback stretto: non appena i test falliscono o i linter si lamentano, Devin può iterare in autonomia finché la build torna verde.
Secondo, il design in sandbox rende banale parallelizzare i lavoretti, perché più sandbox possono girare affiancate senza pestarsi i piedi.
Terzo, la memoria persistente permette a Devin di affrontare migrazioni di lunga durata: l’agente può mantenere una to-do list di sotto-task e smaltirli nell’arco di ore o giorni, completando refactor massivi diverse volte più velocemente di un umano a mano.
Primi passi con Devin
Prima di tutto, creiamo un account.
Registrati e scegli un piano
Andiamo su devin.ai e clicchiamo “Get Started”.
I primi passaggi della procedura guidata sono abbastanza semplici da seguire. Mi sono state poste alcune domande su di me, sull’azienda e sul nome del mio team. Se sei uno sviluppatore solista come me, nessun problema: la procedura copre anche quel caso.
Poi è il momento di scegliere un piano. Ci sono due opzioni:
- Core (a consumo): per la maggior parte degli sviluppatori solisti, il piano Core è il più economico: paghi 20 $ in anticipo, che acquistano 9 Agent Compute Unit (ACU).
- Teams: il piano Teams ti dà 250 ACU/mese. Questa pagina di documentazione ufficiale fornisce informazioni dettagliate su ACU e sul modello di fatturazione di Devin.
Il piano Core è un modo piuttosto economico per provare Devin, quindi ho deciso di pagare 20 $ e vedere fin dove sarei arrivata.
Ho inserito i dati di pagamento e ho avuto l’opzione di impostare una soglia di ricarica automatica così che Devin possa ricaricare gli ACU automaticamente invece di fermarsi a metà di un task. Non ho abilitato questa funzione e probabilmente non la consiglierei a questo punto. L’opzione è disponibile più tardi nelle impostazioni, quindi puoi prima provare un task e vedere come va il consumo. Puoi anche impostare limiti di ACU per sessione, utile per non sforare il budget.
Due conti al volo: 20 $ / 9 ACU ≈ 2,25 $ per ACU. L’abbonamento Teams (500 $/mese) lo porta a 2,00 $ e pre-carica 250 ACU, ma risparmierai solo se prevedi che Devin giri per oltre 30 ore al mese.
Connessione a Github (e opzionalmente a Jira e Slack)
Il passo successivo è connettere un account GitHub e dare a Devin accesso ai repository.
Ho scelto di dare a Devin accesso solo al nostro repository fp-ts-exercises, dato che è l’unico di cui ha bisogno, e probabilmente dovresti fare lo stesso per evitare modifiche indesiderate al codice.
Fatto ciò, ho avuto la possibilità di connettere un sistema di project management. Devin sembra supportare l’integrazione con Jira, GitHub Issues e Linear.
Cliccando sull’opzione Jira si apre questa modale, e le righe in giallo specificano che è meglio che Devin usi un account di servizio specifico e abbia accesso a un solo workspace, anche se ciò significa creare un account Jira dedicato.
Nota che è possibile aggiungere l’integrazione con Jira più tardi dalle impostazioni, quindi non è necessario farlo ora.
C’è anche l’opzione di integrarsi con Slack, ma per ora l’ho saltata.
Primo task: aggiornare un repository obsoleto
Ok, ora che è tutto configurato, passiamo alla parte divertente. È il momento di vedere quanto è bravo Devin!
Prompting
Una volta completata la configurazione iniziale, atterriamo su questa pagina:
Com’era prevedibile, tutto parte da un prompt. Ho passato il mouse su tutte le piccole icone per capire le funzionalità disponibili, poi ho scritto il mio prompt.
Prompt: Qualche anno fa ho avviato un repo chiamato fp-ts-exercises, pensato per aiutare gli sviluppatori a imparare la programmazione funzionale in TypeScript usando la libreria fp-ts. Contiene una serie di esercizi locali che coprono concetti come Option, Either, ecc. Gli utenti clonano il repo, risolvono gli esercizi ed eseguono i test per verificare le soluzioni.
Vorrei modernizzare e rilanciare questo progetto con i seguenti obiettivi:
Aggiornare e refactorizzare la codebase esistente
- Aggiorna tutte le dipendenze e garantisci la compatibilità con l’ultima versione di fp-ts
- Migliora struttura, leggibilità e developer experience
- Sostituisci strumenti o pattern obsoleti (ad es. migra da Mocha a Vitest, o simili se opportuno)
Quel prompt non era granché, ma era voluto. L’output di un agente IA può essere solo tanto buono quanto l’input che riceve, e un obiettivo vago può essere interpretato in vari modi. Nel caso di Devin, il costo di un’incomprensione è significativo. Se i confini dell’esecuzione e l’output atteso non sono ben definiti, e lo metti su un task semi-complesso, sprecherai un sacco di ACU.
Quello che volevo provare qui era la piccola icona “penna magica” accanto al pulsante “Send”. È una funzione “Analyze prompt” comoda per aiutarti a affinare il prompt prima di inviarlo e quindi sfruttare al meglio le capacità di Devin.
Quando l’ho cliccata, ha riformulato parti del mio prompt, ma mi ha anche segnalato opportunità di miglioramento.
Ottimo feedback, quindi ho modificato leggermente il mio prompt per fornire requisiti extra. Non avevo impostato linting o unit test a quel punto, quindi ho specificato che dovesse eseguire i test dei learner sulla soluzione del primo problema per assicurarsi che l’app si comportasse come previsto.
Prompt: Voglio modernizzare e rilanciare il mio repository fp-ts-exercises, che aiuta gli sviluppatori a imparare la programmazione funzionale in TypeScript usando la libreria fp-ts. Il repository contiene esercizi locali che coprono concetti come Option ed Either. Gli utenti clonano il repo, risolvono gli esercizi ed eseguono i test per verificarli. L’obiettivo è aggiornare il progetto e migliorare la developer experience. Per favore, fai quanto segue:
- Aggiorna tutte le dipendenze alle ultime versioni e garantisci la compatibilità con l’ultima versione di fp-ts.
- Refactorizza la codebase esistente per migliorare struttura, leggibilità e la developer experience complessiva.
- Sostituisci strumenti o pattern obsoleti. Ad esempio, migra da Mocha a Vitest o suggerisci altri aggiornamenti opportuni agli strumenti. Fornisci una motivazione per ogni modifica agli strumenti che proponi.
- Assicurati che tutti gli esercizi e i test esistenti continuino a funzionare correttamente dopo gli aggiornamenti e il refactoring.
Puoi eseguire npm run solution -- option 01 per assicurarti che i test passino e che tutto funzioni come previsto.
Specifica quali step eseguirai per effettuare aggiornamenti e refactoring. Prima di apportare modifiche significative, proponi il tuo approccio e chiedi un feedback.
Puoi inviare le modifiche in revisione con una Pull Request.
Come previsto, analizzando il mio prompt stavolta è comparso un toast “Prompt looks good!”.
L’interfaccia
Ho inviato il prompt e Devin ha iniziato subito a pensare.
La UI è un po’ impegnativa a prima vista, ma è abbastanza facile da navigare una volta capito cosa fa ogni elemento. Vediamola per parti.
Il pannello con le sessioni attive a sinistra è comprimibile, se preferisci concentrarti su una sessione alla volta.
C’è un’interfaccia in stile chat, dove puoi seguire il ragionamento di Devin e interagire con lui.
La parte destra dello schermo è occupata da un pannello con varie schede: Progress, Shell, Browser ed Editor. Queste schede mostrano l’esatto ragionamento e i passaggi che Devin esegue nei diversi ambienti.
Cliccando su ciascuna puoi vedere i passaggi effettuati nella shell (ad esempio il clone del repo), nel browser (la navigazione alla pagina del repo su GitHub) e nell’Editor, che è un editor in stile VSCode con tutti i file del repo (dove poi modificherà il nostro codice). La scheda Progress evidenzia gli step mentre vengono eseguiti.
In alto a destra c’è un altro set di schede: Timelapse, IDE e Browser. Sono le viste che tu puoi navigare e usare. La scheda Timelapse selezionata mostra i progressi e le azioni di Devin, come spiegato sopra. La funzione di timelapse interattivo (puoi vedere “Live” e la barra di avanzamento in basso) ti permette di riprodurre una sessione. La scheda IDE apre un IDE online in stile VSCode dove puoi modificare il codice e persino fare commit su GitHub.
Pianificazione e ragionamento di Devin
Devin ha pensato per qualche minuto, ha analizzato l’intero repo e ha spiegato le sue azioni a ogni passo. Nota il messaggio evidenziato “Devin ha clonato il repo, valuta di configurare un workspace di Devin”. Ci torneremo tra poco.
Ha poi proposto un piano, mi ha detto che la sua confidenza era alta e mi ha chiesto di confermare:
Ero abbastanza soddisfatta del piano, quindi ho cliccato Confirm. Devin si è messo subito al lavoro.
Vedi il piccolo menu a discesa “Agent” in basso nell’interfaccia della chat? L’altra opzione è “Ask”. Questa funzionalità non interrompe il lavoro di Devin ma ti permette di interagirci. Ho deciso di provarla chiedendogli di aggiungere script di linting e di controllo della compilazione TypeScript.
Il lavoro era già iniziato, ma mi ha detto che si sarebbe assicurato di aggiungere questi script (e l’ha fatto!).
La pull request
Non ho cronometrato esattamente, ma dopo pochi minuti aveva pronta una pull request, e la descrizione era approfondita e accurata.
È stata una piacevole sorpresa che di sua iniziativa abbia fatto più del necessario per assicurarsi che i test della prima soluzione passassero. Ha testato la terza soluzione, ma anche il primo esercizio, e ha verificato che i test fallissero (come previsto, dato che nessun learner aveva completato l’esercizio).
Ho revisionato la PR e ho avuto il sospetto che i miei script di linting e compilazione TypeScript sarebbero falliti. Mancava, per esempio, un "type":"module" nel mio package.json.
Non so perché Devin non abbia eseguito quegli script dopo averli scritti per assicurarsi che funzionassero. Perché non gliel’ho chiesto esplicitamente? O perché ho aggiunto questi requisiti dopo che aveva iniziato il lavoro?
Ho deciso di usare l’editor di codice online per correggere la svista di Devin, cosa che mi ha preso circa 5 minuti. Ho eseguito ogni comando nel terminale e tutto sembrava comportarsi come previsto dopo la mia correzione.
Avrei potuto delegare la correzione a Devin, ma era più rapido farla da me. In circa cinque minuti ho eseguito gli script, confermato i fallimenti di lint e compilazione e individuato la causa. Due minuti dopo, la patch era in posto e tutti i check sono passati. Scrivere un prompt dettagliato, aspettare che Devin lo eseguisse e poi rivedere l’output avrebbe richiesto più tempo.
Trovare il punto di equilibrio tra lavoro umano e IA è un’arte sottile: quando una modifica è chiaramente a portata di mano, preferisco farla piuttosto che digitare “per favore, correggi questo” e aspettare. Ognuno ha le proprie preferenze, e la tua soglia personale varierà con la tua esperienza, il task e—diciamolo—l’umore del giorno.
Chiusura della sessione
A quel punto avevo finito la modernizzazione del repo e tutto funzionava come previsto. Ma e adesso? Come si chiude una sessione, e sto ancora pagando per questo tempo di inattività?
L’interfaccia qui si è fatta un po’ confusa. All’estrema destra, nel menu della sessione, avevo due opzioni: mettere Devin in sleep o terminare la sessione.
Ho consultato la documentazione, e questo è ciò che ho trovato: Devin non usa ACU mentre è in sleep, e andrà in sleep automaticamente dopo ~0,1 ACU di inattività.
Ho anche chiesto al bot AI della documentazione qual è la differenza tra sleep e terminazione:
La risposta è stata piuttosto chiara. Il nostro lavoro qui era finito, quindi ho terminato la sessione.
Configurare il nostro repo nel workspace di Devin
Ricordi il messaggio evidenziato apparso in chat mentre Devin pianificava il lavoro? Ci chiedeva di configurare il repo sulla macchina di Devin, così da non doverlo clonare ogni volta che vogliamo lavorarci. Ma perché dovremmo volerlo fare?Ogni nuova sessione parte con una macchina virtuale pulita, quindi senza configurazione Devin deve:
- Capire la nostra codebase da zero
- Installare tutte le dipendenze e gli strumenti
- Imparare la struttura e le convenzioni del progetto
- Sprecare tempo prezioso per la configurazione dell’ambiente invece che sul lavoro reale
Quindi configurare il nostro repo è un approccio più efficiente in termini di costi e tempo. È anche più coerente, perché ogni sessione parte con la stessa configurazione e Devin sa esattamente come eseguire, testare e lintare il nostro codice.
Questa funzione si trova nel pannello di navigazione del tuo team, e i passaggi sono, ancora una volta, abbastanza semplici da seguire.
Iniziamo specificando i comandi per recuperare l’ultima versione del repo:
Puoi inserire comandi personalizzati e cliccando sul pulsante “Verify Command” verranno eseguiti automaticamente nel terminale davanti a te. Puoi vedere in pochi secondi se hanno successo o falliscono.
Ho saltato il passaggio di configurazione dei secret, dato che per ora non ne abbiamo. Installare e mantenere le dipendenze funziona allo stesso modo e, una volta che il comando ha avuto successo, il passaggio viene contrassegnato come completato.
Il resto dei passaggi funziona in modo simile e, una volta completati tutti i passaggi (o saltati, se non applicabili), la configurazione viene salvata.
Uso della sessione e review
Finora, abbiamo completato un task semplice con Devin, creato una pull request, l’abbiamo unita e abbiamo configurato il nostro repo per le sessioni future. Diamo un’occhiata ad alcuni dati della nostra sessione. Cliccando sulla piccola icona in alto nella sessione si apre una modale con insight sulla sessione:
La dimensione della nostra sessione è XS che, secondo la guida alle dimensioni di Devin, è piuttosto buona.
Se clicchi sul pulsante “Generate Insights” e aspetti qualche secondo, potrai vedere alcune informazioni generali sulla tua sessione, i passaggi specifici che ha compiuto Devin e dove ha avuto difficoltà.
Volevo anche vedere quante ACU avevamo usato. Una cosa strana che ho notato è che la pagina dei piani mostrava che mi restavano 8,73 ACU, nonostante avessi già usato 1,7 ACU su un totale di 9 (vedi l’evidenziazione blu nella sezione Core).
La pagina Usage & Limits, invece, mostrava correttamente che avevamo usato 1,7 ACU e che ne restavano 7,3.
Sono tornata dopo 18 ore e la pagina Plans mostrava 7,3 ACU rimanenti, quindi c’è un leggero ritardo nell’aggiornamento di queste informazioni. Usa la pagina Usage & Limits come fonte di verità per evitare sorprese!
Ne è valsa la pena?
Facciamo due conti.
Quindi, 1,7 ACU a 2,25 $/ACU = 3,83 $ per questa sessione.
Io ho speso forse 20 minuti tra prompting e review. Fare tutto a mano avrebbe richiesto ben più tempo, e avrei rimandato ogni passo perché è il tipo di attività che trovo particolarmente noiosa. Al prezzo di un cappuccino, Devin si è preso il lavoro. Lo rifarei ogni giorno.
E adesso?
Ok, quindi abbiamo:
- Creato il nostro account
- Connesso il nostro repository GitHub
- Configurato il repo per le sessioni future sulla macchina di Devin
- Eseguito il nostro primo task di upgrade delle dipendenze
- Rivisto le metriche e l’uso della sessione
Un ottimo inizio! Nel prossimo tutorial andremo più a fondo e metteremo alla prova le capacità di Devin chiedendogli di pianificare e implementare feature complete, con integrazioni API e database.
Se sei pronta/o a proseguire, clicca sul secondo elemento della lista qui sotto per andare al secondo tutorial:
- Configurazione e prima pull request
- Pubblicare una “vertical slice” con Devin (Parte 2)
- Integrazioni, test e CI/CD (Parte 3)
- Sicurezza, deployment, manutenzione (Parte 4)
Author
Marie Fayard
Argomenti
