Devin, Cursor o Copilot: come scegliere l’agente AI per programmare

Questa guida serve a sviluppatori, team tecnici, founder e responsabili prodotto che vogliono usare Devin Desktop, il successore di Windsurf, insieme a Devin Cloud per trasformare issue, bug, refactor e piccole feature in lavoro eseguibile da agenti AI. Il risultato concreto è un ambiente operativo: IDE installato, repository indicizzato, regole di progetto impostate, integrazione GitHub attiva, primo task eseguito e flusso di revisione pronto.

Il tempo realistico per arrivare al primo risultato è di 45-90 minuti se hai già un repository Git e un account GitHub. Per un team, aggiungi 2-4 ore per permessi, policy, integrazioni e controllo dei costi. Non serve essere esperti di machine learning: serve però saper leggere una pull request, eseguire test e capire la struttura minima del progetto su cui vuoi far lavorare l’agente.

Il punto da chiarire subito è il nome. La scheda Product Hunt di Windsurf descriveva il prodotto come un IDE agentico nato dal team Codeium, pensato per combinare assistente di completamento e agenti software. La linea prodotto è poi confluita in Devin: la pagina ufficiale di Devin presenta oggi un agente software capace di lavorare su PR, documentazione, refactor, bug, test, automazioni e attività multi-repository.

1. Cosa serve prima di iniziare

Prima di installare strumenti e collegare repository, prepara un perimetro chiaro. Un agente di sviluppo è utile se gli dai codice, obiettivo, test e criteri di accettazione; diventa invece costoso e poco affidabile se gli chiedi “migliora tutto” senza vincoli. Parti da un repository reale, ma scegli una modifica piccola e verificabile.

• Account Devin: puoi partire da Devin Free, ma per lavoro regolare il riferimento self-service verificato il 13 settembre 2026 è Pro a 20 dollari/mese, Max a 200 dollari/mese e Teams con minimo 80 dollari/mese più 40 dollari/mese per full dev seat.
• Computer supportato: Devin Desktop è disponibile per macOS, Windows e Linux. I requisiti indicati da Cognition sono: macOS con aggiornamenti di sicurezza Apple supportati, Windows 10 a 64 bit, Linux con glibc >= 2.28 e glibcxx >= 3.4.25.
• Repository Git: locale o su GitHub, GitLab o Bitbucket. Per la prima prova usa un repository non critico o un branch separato.
• Ambiente di build e test: Node, Python, Java, .NET o altro devono essere già installati se vuoi che l’agente esegua test locali. L’agente può aiutarti a sistemare l’ambiente, ma la prima sessione riesce meglio se npm test, pytest, mvn test o il comando equivalente sono già noti.
• Permessi GitHub: per integrare Devin con un’organizzazione GitHub devi essere amministratore dell’organizzazione, perché la procedura ufficiale richiede di scegliere quali repository rendere accessibili all’app Devin.
• Policy sui segreti: prima di indicizzare il codice, controlla .gitignore, aggiungi un .codeiumignore se necessario e togli chiavi API, dump, credenziali, file .env non necessari e dati personali.

I costi cambiano spesso, quindi considera le cifre qui sotto come rilevate il 13 settembre 2026. Devin, Cursor, GitHub Copilot e Claude hanno modelli diversi: alcuni includono quota, altri crediti o consumo a token. Per confrontare l’ingresso individuale, il dato più leggibile è il prezzo mensile del primo piano professionale.

Prezzi mensili dei piani individuali principaliValori in USD/mese

• GitHub Copilot Pro10
• Devin Pro20
• Cursor Pro20
• Claude Pro20
• GitHub Copilot Max100
• Devin Max200
• Cursor Ultra200

Non collegare subito l’intera organizzazione GitHub. Per la prima configurazione scegli Select repositories, abilita un solo repository di prova e verifica che l’agente apra PR su branch separati. È il modo più semplice per limitare errori, costi e accessi non necessari.

2. I concetti indispensabili spiegati semplice

IDE agentico

Un IDE agentico è un editor in cui l’AI non si limita a completare una riga, ma può leggere più file, proporre un piano, modificare codice, eseguire comandi e aiutarti a verificare il risultato. Windsurf nasceva proprio con questa promessa: unire la logica del copilot con quella dell’agente software. In Devin Desktop questa idea si sposta dentro un’interfaccia più orientata alla gestione di più agenti e più attività.

Esempio concreto: invece di chiedere “scrivi una funzione di validazione email”, puoi chiedere “aggiungi la validazione email al form di registrazione, aggiorna i test unitari e mostrami i file modificati prima del commit”. La differenza è che il secondo prompt include obiettivo, punto del prodotto e verifica.

Devin Local e Devin Cloud

Devin Local è l’agente che lavora sulla tua macchina, usando file, strumenti e ambiente locali. La documentazione lo descrive come il nuovo harness condiviso con Devin CLI, integrato in Devin Desktop. Devin Cloud lavora invece in una sessione cloud, può continuare mentre chiudi il laptop e può arrivare fino alla creazione di pull request, test e debug su una propria macchina virtuale.

Esempio concreto: usa Devin Local per capire una funzione, fare una modifica circoscritta o preparare un piano. Usa Devin Cloud per un ticket Jira completo, un refactor su più file o un bug che richiede browser, test, log e PR.

Ask, Plan e Agent

In Devin esistono modalità con responsabilità diverse. Ask serve per capire il codice e pianificare senza modificare i file; Agent è la modalità autonoma che può scrivere codice, eseguire comandi, navigare e completare task end-to-end; nel terminale Devin CLI espone anche comandi come /ask e /plan. La guida ufficiale consiglia di partire da Ask quando il task non è già perfettamente definito.

Esempio concreto: se devi “capire perché il checkout fallisce”, inizia con Ask. Se sai già che “il problema è nel calcolo IVA in src/pricing/tax.ts e i test attesi sono questi”, puoi passare direttamente ad Agent.

Contesto, regole e memoria

Il contesto è ciò che l’agente conosce: file aperti, repository indicizzato, prompt, documentazione, issue, conversazioni e regole. Le vecchie funzionalità Windsurf distinguevano Memories, generate automaticamente, e Rules, definite dall’utente. Nelle pratiche operative conviene privilegiare regole versionate e documenti nel repository, perché sono più stabili e condivisibili con il team.

Esempio concreto: una regola “usa pnpm, non npm” è meglio in un file di regole del repository rispetto a una memoria lasciata all’agente, perché resta visibile, revisionabile e applicabile da tutti.

Quota, crediti e token

I prodotti di coding AI non vendono solo “messaggi”. In Devin Desktop il sistema self-service usa quote giornaliere e settimanali basate sul consumo di token; oltre la quota, i piani a pagamento possono acquistare uso extra a prezzi API. La documentazione sulle quote indica anche che richieste corte, pochi file in contesto e modelli più economici riducono il consumo.

Esempio concreto: chiedere “modifica un test in questo file” consuma molto meno di “leggi tutto il monorepo, capisci l’architettura e proponi una migrazione”. Il primo task è adatto a Devin Local; il secondo va spezzato in fasi o delegato a cloud con budget controllato.

3. Scegli il percorso operativo giusto

La prima decisione non è quale modello usare, ma quale superficie di lavoro adottare. Devin Desktop è indicato quando vuoi rimanere nell’IDE, vedere file, diff, terminale e agenti insieme. Devin Cloud è indicato quando vuoi delegare attività più lunghe. Devin CLI è utile quando lavori da terminale o vuoi inserire l’agente in script e automazioni leggere.

Percorso A: singolo sviluppatore

1. Installa Devin Desktop.
2. Apri un repository locale.
3. Configura esclusioni e regole.
4. Usa Ask per far spiegare il progetto.
5. Passa a Devin Local per una modifica piccola.
6. Esegui test e commit manuale.

Risultato atteso: lavori con un agente nel tuo ambiente, senza concedere subito accessi ampi a sistemi esterni. È il percorso più sicuro per imparare.

Percorso B: team con backlog su GitHub, Linear o Jira

1. Attiva un piano Teams o Enterprise.
2. Configura repository e integrazioni.
3. Definisci playbook, criteri di completamento e branch protection.
4. Assegna a Devin ticket piccoli, verificabili e con test.
5. Fai revisionare le PR da un umano prima del merge.

Risultato atteso: Devin diventa un contributor controllato, non un sostituto del processo di revisione. La pagina ufficiale di Devin cita proprio ticket Linear/Jira, bug report, test, migrazioni e documentazione come casi d’uso adatti.

Percorso C: automazioni avanzate

1. Collega Slack, GitHub, Jira o webhook.
2. Definisci trigger, condizioni e azioni.
3. Imposta limiti di uso e permessi.
4. Monitora le sessioni da Agent Command Center.
5. Integra MCP o ACP solo dopo aver stabilizzato il flusso base.

Risultato atteso: eventi ricorrenti, come CI fallita o issue etichettata, avviano sessioni Devin senza intervento manuale. È potente, ma va introdotto dopo aver misurato costi e qualità su task manuali.

4. Installa e configura Devin Desktop

La migrazione da Windsurf a Devin Desktop è il passaggio centrale. Cognition ha annunciato che Windsurf è diventato Devin Desktop il 2 giugno 2026; la FAQ ufficiale chiarisce che l’editor, le estensioni, i keybinding e l’esperienza IDE restano disponibili, con Agent Command Center in primo piano.

Scarica la versione corretta

1. Apri la pagina Download di Devin.
2. Su macOS scegli Download for Apple Silicon se hai chip Apple, oppure Download for Intel se hai un Mac Intel.
3. Su Windows scegli Download for x64 o Download for arm64 in base all’architettura del computer.
4. Su Linux usa il pacchetto disponibile per la tua distribuzione, oppure l’installazione tramite apt o rpm se indicata dalla pagina.
5. Se usi un ambiente JetBrains, valuta il plugin Windsurf JetBrains, ancora indicato nella pagina download come opzione per IntelliJ IDEA, PyCharm, WebStorm e altri IDE JetBrains.

Risultato atteso: l’applicazione si avvia e ti chiede accesso o login. Se usavi già Windsurf, la migrazione dovrebbe arrivare come aggiornamento ordinario; se vuoi controllare una build stabile specifica, la pagina Releases elenca gli installer pubblicati per macOS, Windows e Linux.

Verifica la versione e abilita Devin Local

1. Apri Devin Desktop.
2. Apri la Command Palette con Cmd+Shift+P su macOS o Ctrl+Shift+P su Windows/Linux.
3. Cerca e apri Devin User Settings.
4. Entra nella scheda Agents.
5. Attiva il toggle Devin Local se non è già attivo.
6. Riavvia Devin Desktop.

Risultato atteso: nel selettore agente in basso a destra puoi scegliere Devin Local. Secondo la documentazione di Devin Local, le nuove conversazioni usano Devin Local quando non hai impostato un agente preferito e l’agente è disponibile.

Se arrivi da Windsurf e usavi Cascade

1. Apri la Command Palette.
2. Esegui il comando Devin: Open Cascade Migration Wizard.
3. Segui il flusso guidato per portare workflow e memorie verso il nuovo agente.
4. Controlla eventuali script, documentazione interna o istruzioni che citano ancora Cascade.

Risultato atteso: le vecchie conversazioni vengono migrabili o continuabili nel nuovo ambiente. Le release note indicano che dalla versione v3.9.19 dell’8 settembre 2026 Cascade è stato rimosso da Devin Desktop e Devin Local è l’unico agente disponibile nell’app.

Se nel tuo team ci sono procedure scritte con il nome “Cascade”, aggiornale. Il rischio non è solo lessicale: automazioni, materiali di onboarding e policy interne possono puntare a comandi o superfici non più presenti nelle versioni recenti.

5. Prepara repository, contesto e file da escludere

La qualità del primo risultato dipende soprattutto da come prepari il repository. Un agente non dovrebbe indicizzare tutto senza criterio: file generati, dipendenze, build, log, dump e segreti aumentano costo, rumore e rischio. Le vecchie documentazioni Windsurf restano utili perché spiegano come l’IDE gestisce indicizzazione, regole e file ignorati.

Crea o aggiorna .codeiumignore

1. Apri la root del repository.
2. Controlla che .gitignore escluda già dipendenze, build e file locali.
3. Crea un file .codeiumignore nella root se vuoi escludere file dall’indicizzazione dell’IDE.
4. Usa una sintassi simile a .gitignore.
5. Aggiungi percorsi come .env, *.pem, dist/, coverage/, tmp/, *.sqlite se presenti e non necessari al task.

Risultato atteso: i file esclusi non vengono indicizzati e non concorrono al limite di grandezza del workspace. La documentazione Windsurf Ignore indica che l’indicizzazione ignora già i percorsi in .gitignore, node_modules e i path nascosti; aggiungere .codeiumignore serve a raffinare ulteriormente il perimetro.

Considera tempo e memoria dell’indicizzazione

Alla prima apertura del workspace, l’indicizzazione può usare CPU per qualche minuto. La documentazione ufficiale indica un ordine di grandezza di 5-10 minuti alla prima indicizzazione e circa 300 MB di RAM per un workspace da 5.000 file; per macchine con circa 10 GB di RAM viene raccomandato di non superare 10.000 file nella dimensione massima di workspace indicizzato.

1. Apri solo la cartella del progetto, non una directory che contiene molti repository.
2. Se il workspace è un monorepo, parti da una sottocartella o aumenta il limite solo dopo aver escluso file inutili.
3. Attendi la fine dell’indicizzazione prima di chiedere analisi architetturali.

Risultato atteso: l’agente risponde con riferimenti più pertinenti e meno consumo. Se chiede spesso file che dovrebbe conoscere, il workspace potrebbe non essere stato indicizzato o il limite file potrebbe essere troppo basso.

Scrivi regole di progetto versionate

1. Crea la cartella .windsurf/rules nella root del repository se usi regole compatibili con l’eredità Windsurf.
2. Aggiungi file Markdown brevi, uno per tema: style.md, testing.md, security.md.
3. Se preferisci una convenzione più neutra e leggibile da più agenti, aggiungi anche un file AGENTS.md nella root.
4. Inserisci vincoli specifici: package manager, comando test, stile commit, directory da non modificare, criterio di fine task.

Risultato atteso: l’agente riceve istruzioni stabili. Le regole storiche di Windsurf distinguono regole globali, di workspace, manuali o attivate da pattern; il principio pratico è semplice: le istruzioni permanenti vanno in file versionati, non in prompt lunghi copiati ogni volta.

6. Avvia il primo lavoro con Ask, Agent e Devin Local

La prima sessione non deve essere ambiziosa. La guida ufficiale alla prima sessione consiglia di impostare e indicizzare i repository prima di iniziare, poi usare Ask per comprendere e pianificare se il task non è già definito. Segui questo flusso anche se sei esperto: riduce correzioni e consumo.

Fase 1: chiedi una mappa del progetto

1. Apri il repository in Devin Desktop.
2. Seleziona la modalità Ask.
3. Seleziona il repository o la cartella di lavoro corretta.
4. Invia una richiesta di analisi, ad esempio: Spiegami in 10 punti la struttura di questo repository. Indica dove sono entry point, test, configurazione e logica principale. Non modificare file.
5. Leggi la risposta e verifica che citi directory realmente esistenti.

Risultato atteso: ottieni una mappa navigabile del codice. Se la risposta è generica, chiedi all’agente di restringere l’analisi a src/, app/ o alla directory pertinente.

Fase 2: trasforma la richiesta in piano

1. Resta in Ask.
2. Formula il task con criterio di completamento: Voglio aggiungere un endpoint /health che ritorni status ok, versione applicazione e timestamp. Prepara un piano con file da modificare, test da aggiungere e rischi. Non scrivere codice.
3. Chiedi eventuali alternative se il progetto ha più framework o router.
4. Accetta il piano solo se indica file, test e comando di verifica.

Risultato atteso: hai un piano abbastanza preciso da eseguire. Se il piano non cita test, rifiutalo e chiedi esplicitamente “aggiungi test unitari o di integrazione e comando per eseguirli”.

Fase 3: passa all’esecuzione

1. Passa a Agent o seleziona Devin Local dal selettore agente.
2. Incolla il piano approvato o usa il pulsante Send to Devin quando arrivi da una sessione Ask che lo propone.
3. Chiedi modifiche piccole: Implementa solo l’endpoint /health e i test. Non cambiare configurazione di deploy. Fermati prima del commit e mostrami il diff.
4. Quando l’agente chiede permessi per comandi o modifiche, approva solo quelli coerenti con il task.
5. Esegui manualmente il test indicato o chiedi all’agente di eseguirlo e mostrarti output e file modificati.

Risultato atteso: hai un diff locale verificabile, non una PR enorme. A questo punto puoi fare revisione, correggere istruzioni e decidere se committare.

Non usare la modalità più permissiva come impostazione predefinita. Un agente che può scrivere file ed eseguire comandi senza conferme è utile in sandbox, ma in un repository reale devi prima imparare che cosa tende a fare sul tuo stack.

7. Usa Devin CLI quando lavori da terminale

Devin CLI è utile se preferisci lavorare in shell, se vuoi interrogare il codice senza aprire l’IDE o se devi integrare piccole richieste in script. La pagina download indica l’installazione con un comando singolo, mentre la documentazione dei comandi essenziali descrive modalità, permessi e comandi di sessione.

Installa e avvia

1. Apri un terminale.
2. Esegui curl -fsSL https://cli.devin.ai/install.sh | bash.
3. Entra nella directory del repository con cd percorso/del/repository.
4. Avvia una sessione interattiva con devin.
5. Oppure esegui una richiesta singola con devin -p "Spiega cosa fa questo repository in 5 punti".

Risultato atteso: nel primo caso entri in una REPL, cioè un’interfaccia testuale interattiva; nel secondo ottieni una risposta e il processo termina, utile per script e controlli veloci.

Scegli la modalità permessi

• Normal: approva automaticamente strumenti in sola lettura nella directory corrente e chiede conferma per scrittura o esecuzione. È il default più prudente.
• Accept Edits: approva modifiche ai file nel workspace, ma chiede conferma per shell e altre azioni. È spesso la modalità più comoda per sviluppo assistito.
• Smart: approva modifiche nel workspace e usa un modello veloce per decidere se altre azioni sono sicure; le categorie ad alto rischio continuano a richiedere conferma.
• Bypass: approva tutte le chiamate agli strumenti, inclusi comandi shell. È indicata solo in ambienti sacrificabili o molto isolati.
• Autonomous: lavora in modo più autonomo con sandbox OS-level, secondo le impostazioni disponibili sull’account e sull’organizzazione.

1. Per pianificare usa /plan.
2. Per fare domande senza modifiche usa /ask.
3. Per tornare alla modalità prudente usa /normal o /mode normal.
4. Per accettare modifiche ma non comandi indiscriminati usa /accept-edits.
5. Per avviare direttamente una sessione in Smart, se disponibile, usa devin --permission-mode smart.

Risultato atteso: controlli il grado di autonomia invece di scoprirlo a posteriori. Le policy amministrative dell’organizzazione hanno comunque precedenza sui permessi locali, quindi un divieto centrale non viene superato da /bypass.

8. Collega GitHub e porta il lavoro in pull request

Il salto da assistente locale a collaboratore di team avviene quando Devin può creare pull request e rispondere ai commenti. La documentazione GitHub di Devin indica una procedura precisa e raccomanda branch protection sulla branch principale per evitare merge senza controlli.

Configura la connessione GitHub

1. Accedi a Devin.
2. Vai in Settings → Connections → GitHub.
3. Clicca Add Connection.
4. Autenticati su GitHub se richiesto.
5. Seleziona l’organizzazione GitHub da collegare.
6. Scegli Select repositories per iniziare con pochi repository, oppure All repositories solo se hai già una policy approvata.
7. Completa l’autorizzazione e torna alle impostazioni Devin per verificare che la connessione sia attiva.

Risultato atteso: puoi menzionare repository nei prompt e Devin può lavorare come contributor sui repository autorizzati. In ambiente Enterprise, la delega dei repository può essere gestita da Enterprise Settings > Repository Permissions.

Imposta una richiesta adatta a PR

1. Apri una nuova sessione Agent o avvia Devin Cloud dal contesto del repository.
2. Scrivi un prompt con obiettivo, limiti, test e formato della PR: Implementa il ticket DEV-123. Modifica solo backend e test. Non cambiare schema database. Apri una PR con descrizione, file toccati, test eseguiti e rischi residui.
3. Chiedi a Devin di fermarsi se incontra una decisione di prodotto non specificata.
4. Quando la PR è pronta, rivedi diff, test e commenti.
5. Usa i commenti di review per chiedere correzioni; Devin può rispondere ai commenti PR finché la sessione non è archiviata.

Risultato atteso: ottieni una PR revisionabile, con commit prodotti dall’agente e correzioni iterative. Non cambiare la regola base: nessuna PR agentica dovrebbe essere mergiata senza review umana e CI verde.

9. Integra Slack, Jira e automazioni

Quando il flusso manuale funziona, puoi portare Devin nei luoghi in cui il team riceve lavoro: chat, issue tracker, CI e webhook. La pagina principale di Devin cita integrazioni con strumenti come GitHub, Datadog, Linear, Slack, Sentry, AWS, Notion e altri; le integrazioni operative più immediate sono Slack e Jira.

Usa Devin da Slack

1. Vai in Settings > Connections > Slack.
2. Clicca Connect.
3. Installa l’app Devin nel workspace Slack.
4. Assicurati che ogni utente colleghi il proprio account; la documentazione segnala che l’email Slack deve corrispondere a quella usata in Devin se ci sono problemi di collegamento.
5. In un canale, menziona @Devin con istruzioni specifiche.

Risultato atteso: Devin risponde nel thread Slack, fa domande e aggiorna il team sullo stato della sessione. La documentazione Slack indica anche la possibilità di sincronizzare sessioni con thread e usare canali dedicati.

Usa Devin da Jira

1. Vai in Settings > Connections > Jira.
2. Clicca Connect.
3. Autorizza i permessi in Jira.
4. Configura eventuali playbook label.
5. Avvia Devin assegnando il ticket all’account di servizio Devin, aggiungendo una label come devin, usando una label playbook come !plan o !implement, oppure menzionando @Devin in un commento.

Risultato atteso: un ticket può trasformarsi in sessione Devin. La documentazione Jira chiarisce che la label devin funziona con matching case-insensitive quando “devin” è parola autonoma, per esempio devin, Devin o devin-task.

Crea automazioni solo dopo una fase manuale

1. Apri la sezione automazioni in Devin.
2. Scegli un trigger: messaggio Slack, webhook GitHub, update Linear, evento Jira, schedule o webhook custom.
3. Aggiungi condizioni: repository, label, priorità, canale o stato.
4. Scegli l’azione: Start session, Message session, Triage Devin o notifica email.
5. Testa l’automazione su un canale o progetto non critico.

Risultato atteso: l’agente si avvia quando arriva un evento preciso. La documentazione Automations descrive trigger da Slack, GitHub, GitLab, Linear, Jira, Pylon, schedule e webhook; proprio per questo devi usare condizioni strette, altrimenti rischi molte sessioni inutili.

10. Esempi reali e casi d’uso

Scenario semplice: endpoint di salute in una piccola API

Repository: API Node/Express da 4.000 file, esclusi node_modules, dist e coverage. Obiettivo: aggiungere GET /health, restituire { "status": "ok" }, aggiungere test e non toccare database o deploy.

1. Apri il progetto in Devin Desktop.
2. Chiedi in Ask: Dove sono definiti router e test dell’API? Non modificare file.
3. Chiedi un piano di 5 righe.
4. Passa a Devin Local e fai implementare solo endpoint e test.
5. Esegui npm test o il comando indicato dal repository.

Output atteso: 1-3 file modificati, test verde, nessuna PR automatica. È il caso ideale per imparare perché ha uno scope piccolo e un criterio di verifica netto.

Scenario professionale: bug da ticket Jira a pull request

Repository: applicazione SaaS con backend e frontend. Ticket: “Il totale ordine mostra IVA errata quando lo sconto percentuale è applicato prima delle spese di spedizione”. Dati concreti: ordine da 100 euro, sconto 10%, spedizione 5 euro, IVA 22%. Il risultato atteso va scritto nel ticket con formula e test.

1. In Jira collega Devin da Settings > Connections > Jira.
2. Aggiungi al ticket criteri numerici: imponibile = 100 - 10 + 5 = 95; IVA = 20,90; totale = 115,90.
3. Assegna il ticket a Devin o aggiungi la label devin.
4. Chiedi sessione in modalità scoping se il codice non è chiaro.
5. Fai aprire una PR con test sul caso numerico.

Output atteso: PR con test che fallisce prima e passa dopo. Questo scenario è adatto a un team perché ticket, numeri e revisione riducono ambiguità.

Scenario avanzato: refactor multi-repository controllato

Repository: tre servizi interni, ciascuno con wrapper HTTP diverso. Obiettivo: uniformare header X-Request-Id, logging e gestione errori, senza cambiare API pubbliche. Invece di chiedere una modifica unica, dividi il lavoro in tre sessioni parallele o in una sessione cloud con piano esplicito.

1. Usa Ask per generare una mappa dei punti in cui viene creato o letto X-Request-Id.
2. Chiedi un piano per repository, con file e test.
3. Apri una sessione Devin Cloud per ogni repository oppure una sessione principale con sotto-attività.
4. Imponi criterio di completamento: test verdi, nessuna modifica agli endpoint pubblici, changelog interno aggiornato.
5. Rivedi le PR in ordine: libreria condivisa, servizio 1, servizio 2, servizio 3.

Output atteso: più PR piccole e collegate, non un mega-diff. Devin è adatto a questo tipo di attività perché la pagina prodotto evidenzia proprio migrazioni, refactor, progetti multi-repo, QA e attività ripetitive come casi d’uso.

11. Confronto delle alternative

Non esiste un solo strumento migliore per tutti. Devi scegliere in base a dove vivi durante il lavoro: IDE, terminale, GitHub, chat aziendale o cloud. Usa questo confronto come criterio pratico, non come classifica astratta.

• Devin Desktop: conviene se vuoi un IDE completo, eredità Windsurf, agenti locali, Agent Command Center, integrazione con Devin Cloud e possibilità di governare più sessioni. È particolarmente interessante se hai bisogno di passare da editing locale a delega cloud.
• Devin Cloud: conviene se vuoi assegnare ticket, bug, test, refactor e attività lunghe a un agente che lavora in autonomia e può produrre PR. La documentazione di introduzione indica come riferimento pratico task che un umano completerebbe in circa 3 ore.
• GitHub Copilot: conviene se il tuo processo è già dentro GitHub e vuoi completamento, agent mode, code review e cloud agent con integrazione nativa. La pagina prezzi ufficiale indica, al 13 settembre 2026, Free con 2.000 completions/mese, Pro a 10 dollari/mese, Pro+ a 39 dollari/mese e Max a 100 dollari/mese.
• Cursor: conviene se vuoi un editor AI-native vicino all’esperienza VS Code, con Agent, MCP, cloud agents e piani individuali graduati. La pagina ufficiale Cursor indica Hobby gratis, Pro a 20 dollari/mese, Pro+ a 60 dollari/mese, Ultra a 200 dollari/mese, più piani Teams; la documentazione Teams indica Standard a 40 dollari/utente/mese e Premium a 120 dollari/utente/mese.
• Claude Code: conviene se lavori molto da terminale e vuoi il modello Claude dentro il flusso shell. La pagina prezzi Claude indica che Claude Code è incluso nei piani a pagamento, con Pro e Max; Max parte da 100 dollari/mese.

Il criterio economico non deve fermarsi al canone. Conta quanto contesto mandi, quali modelli selezioni, quante sessioni lasci aperte e quante correzioni richiedi. In Devin Desktop, la pagina AI Models mostra prezzi per milione di token molto diversi tra modelli: Adaptive è più economico, mentre modelli come Claude Fable 5.1 o GPT-6 Astra hanno costi di output molto più alti. Dati verificati il 13 settembre 2026.

Costo modelli in Devin DesktopValori in USD per 1M token

InputOutput

• Adaptive0,502
• Gemini 3.7 Flash intro0,753,75
• Claude Sonnet 5210
• Claude Opus 5525
• Claude Fable 5.11050

12. Errori frequenti e come risolverli

L’agente propone modifiche troppo ampie

Sintomo: il diff tocca molti file non collegati al task. Causa: prompt troppo generico o contesto eccessivo. Soluzione: annulla o rifiuta il diff, torna ad Ask e riscrivi il task con limite esplicito: file ammessi, file vietati, test richiesti e frase “fermati prima del commit”.

Il repository non sembra indicizzato

Sintomo: l’agente non trova file esistenti o dà risposte vaghe. Causa: workspace troppo grande, indicizzazione non completata o cartella sbagliata aperta. Soluzione: apri solo la root corretta, aspetta 5-10 minuti alla prima indicizzazione, controlla esclusioni e aumenta il parametro di dimensione massima solo se serve.

Devin Local non compare nel selettore agente

Sintomo: nel selettore in basso a destra non vedi Devin Local. Causa: agente non abilitato o app non riavviata. Soluzione: apri Cmd+Shift+P o Ctrl+Shift+P, cerca Devin User Settings, entra in Agents, attiva Devin Local e riavvia.

Slack non avvia sessioni correttamente

Sintomo: menzioni @Devin, ma non parte nulla o il collegamento utente fallisce. Causa: app Slack non installata, utente non collegato o email Slack diversa dall’email Devin. Soluzione: torna in Settings > Connections > Slack, reinstalla o riconnetti e verifica la corrispondenza email come suggerito dalla documentazione.

La label Jira non attiva Devin

Sintomo: aggiungi una label, ma il ticket resta fermo. Causa: label non configurata o nome non riconosciuto. Soluzione: usa devin come parola autonoma, oppure una playbook label configurata come !plan o !implement. Evita forme come devin_workshop, che la documentazione segnala come non corrispondenti al pattern.

La spesa cresce senza un output proporzionato

Sintomo: consumi quota o crediti rapidamente, ma ricevi piani lunghi e poco codice utile. Causa: sessioni troppo estese, prompt vaghi, modelli costosi, molto contesto e troppi giri di feedback. Soluzione: usa Ask per pianificare, dividi task grandi, seleziona modelli più economici per lavoro ordinario e controlla l’uso residuo dal meter in Devin Desktop o dalla pagina piano.

13. Buone pratiche per sicurezza, privacy e costi

Un agente AI di sviluppo va trattato come un collaboratore tecnico con accessi limitati. Può leggere codice, proporre modifiche, aprire PR, eseguire comandi e interagire con strumenti aziendali: sono capacità utili, ma vanno governate.

• Branch protection sempre attiva: la documentazione GitHub di Devin raccomanda regole di protezione sulla branch principale. Richiedi CI verde e review umana.
• Repository minimi: assegna solo i repository necessari. Parti da Select repositories, non da tutta l’organizzazione.
• File ignorati: mantieni .gitignore e .codeiumignore. In Enterprise puoi usare anche un .codeiumignore globale in ~/.codeium/.
• Segreti fuori dai prompt: non incollare token, password o chiavi. Usa secret manager e variabili di ambiente con permessi controllati.
• Sessioni brevi: un task per sessione. La documentazione sull’uso indica che complessità, dimensione del contesto, runtime, file toccati e conversazioni lunghe aumentano il consumo.
• Idle sotto controllo: Devin va in sleep automaticamente dopo 30 minuti di inattività di default; durante lo sleep non consuma uso. Gli account Enterprise possono chiedere timeout tra 5 e 120 minuti.
• Windows solo quando serve: la documentazione di billing indica che sessioni Windows consumano circa 9% in più rispetto a sessioni Linux Ubuntu equivalenti.
• Verifica proprietà e training: la documentazione Enterprise Security indica che Cognition è SOC 2 Type II da settembre 2024, che per impostazione predefinita non addestra modelli su dati o codice cliente e che l’output generato è proprietà intellettuale del cliente, con i vincoli contrattuali indicati.

La sicurezza non si risolve con una singola impostazione. Devi combinare repository selezionati, branch protection, esclusione dei segreti, revisione umana, limiti di consumo e log delle sessioni. Se manca uno di questi pezzi, l’agente diventa più difficile da controllare.

14. Livello avanzato: automazioni, MCP, ACP e agenti multipli

Dopo il primo mese di uso controllato puoi passare da “assistente nel codice” a “sistema operativo per attività software”. Qui entrano in gioco MCP, ACP, automazioni, agenti multipli e sandbox.

Usa MCP per collegare strumenti esterni

Il Model Context Protocol permette ad applicazioni AI compatibili di collegarsi a strumenti e sorgenti dati in modo standardizzato. La documentazione Devin MCP descrive un server ufficiale che espone gestione sessioni, playbook, knowledge, schedule e documentazione repository. Il server richiede autenticazione con API key Devin.

1. Crea una API key dalle impostazioni Devin.
2. Configura il client MCP con serverUrl impostato a https://mcp.devin.ai/mcp.
3. Aggiungi header Authorization: Bearer <API_KEY>.
4. Per account Enterprise con chiavi non org-scoped, aggiungi X-Org-Id: <YOUR_ORG_ID>.
5. Non usare vecchie chiavi con prefisso apk_ o apk_user_, perché la documentazione indica che non sono supportate dal server MCP.

Risultato atteso: strumenti compatibili possono gestire risorse Devin in modo programmatico. Parti con permessi minimi e un ambiente di test: MCP amplia molto il raggio d’azione dell’agente.

Capisci ACP prima di aggiungere agenti terzi

ACP, Agent Client Protocol, è un protocollo aperto per standardizzare la comunicazione tra editor e coding agent. La documentazione ufficiale ACP lo presenta come un livello di interoperabilità per scenari locali e remoti; la documentazione Devin Desktop spiega che serve a eseguire agenti terzi dentro Agent Command Center.

Usalo quando hai davvero più agenti specializzati: uno per refactor, uno per test, uno per documentazione, uno per analisi sicurezza. Se hai un solo sviluppatore e un solo repository, ACP è interessante ma non necessario per ottenere valore iniziale.

Sfrutta subagent e sandbox

Devin Local può creare subagent, cioè agenti indipendenti per sotto-attività, e supporta sandbox OS-level. La documentazione segnala anche un miglioramento di efficienza: molti task richiedono fino al 30% di token in meno rispetto a Cascade per lo stesso risultato. Per attivare i subagent, cerca nelle impostazioni Devin il toggle Subagents (Preview), se disponibile sul tuo account.

1. Definisci sotto-attività indipendenti: test, documentazione, refactor, verifica regressioni.
2. Attiva sandbox quando l’agente deve eseguire comandi non banali.
3. Configura allowlist e denylist di dominio se il task richiede rete.
4. Limita i path scrivibili con permission scopes.
5. Confronta output e diff prima di unire il lavoro.

Risultato atteso: puoi parallelizzare attività senza perdere controllo. Il vantaggio non è “fare tutto da solo”, ma avere più bozze verificabili da rivedere.

15. Riepilogo operativo finale

1. Definisci un task piccolo, verificabile e con test.
2. Installa Devin Desktop dalla pagina ufficiale e scegli il pacchetto corretto per il tuo sistema operativo.
3. Se arrivi da Windsurf, esegui Devin: Open Cascade Migration Wizard.
4. Abilita Devin Local da Devin User Settings > Agents se non compare nel selettore.
5. Apri solo il repository necessario.
6. Aggiungi o aggiorna .gitignore e .codeiumignore.
7. Scrivi regole di progetto in .windsurf/rules o AGENTS.md.
8. Usa Ask per capire il codice e produrre un piano.
9. Passa a Agent o Devin Local per implementare una modifica limitata.
10. Esegui test e rivedi il diff manualmente.
11. Collega GitHub da Settings → Connections → GitHub solo quando il flusso locale è stabile.
12. Attiva Slack, Jira e automazioni dopo aver definito permessi, branch protection e limiti di consumo.
13. Controlla quote, modelli e uso extra prima di aumentare autonomia e parallelismo.

Domande e risposte

Windsurf esiste ancora o devo installare Devin Desktop?

Dal 2 giugno 2026 Windsurf è diventato Devin Desktop. Cognition indica che editor, estensioni, keybinding e funzionalità principali restano disponibili, ma l’interfaccia mette davanti Agent Command Center, Spaces e Devin Local. Se scarichi il prodotto nuovo, installa Devin Desktop; “Windsurf” resta soprattutto come nome storico o in alcune pagine/documentazioni legacy.

Quanto costa Devin per un singolo sviluppatore?

Al 13 settembre 2026, il piano Devin Pro costa 20 dollari al mese e Max costa 200 dollari al mese. Esiste anche Free con uso limitato. Pro e Max sono piani individuali e non possono essere condivisi con più utenti; per un team serve Teams, con minimo 80 dollari al mese.

Devin può modificare direttamente il mio repository GitHub?

Sì, dopo l’integrazione GitHub. La procedura passa da Settings → Connections → GitHub → Add Connection, poi scegli organizzazione e repository. Devin può creare pull request e rispondere ai commenti PR. Per sicurezza, al 2026 la configurazione raccomandata è concedere accesso solo a repository selezionati e tenere branch protection attiva.

Come evito che Devin legga file segreti o inutili?

Usa prima .gitignore, poi aggiungi .codeiumignore nella root del repository per escludere file come .env, chiavi, dump, build e directory temporanee. Le vecchie regole Windsurf indicano anche un .codeiumignore globale in ~/.codeium/. Questa preparazione riduce rischio, rumore e consumo di token.

Quando conviene usare Devin Cloud invece di Devin Local?

Usa Devin Local per analisi, piccole modifiche, test rapidi e lavoro nel tuo ambiente. Usa Devin Cloud quando il task richiede più passaggi, browser, VM, test lunghi, PR o lavoro mentre non sei al computer. La documentazione Devin suggerisce come regola pratica task che un umano completerebbe in circa 3 ore.

Il mio consiglio è di non partire dall’automazione, ma dal metodo. Devin Desktop e l’eredità Windsurf diventano davvero utili quando costruisci un rituale: Ask per capire, piano breve, Devin Local per la modifica, test, diff, poi eventualmente Devin Cloud per produrre una PR. Salterei qualunque promessa di “sviluppo autonomo totale” e investirei invece tempo in regole di repository, criteri di completamento e branch protection.

Il passaggio che non eviterei mai è la preparazione del contesto: .codeiumignore, AGENTS.md, comandi di test scritti chiaramente e prompt con limiti espliciti. È meno spettacolare di vedere un agente scrivere codice, ma è ciò che separa una demo brillante da un processo affidabile. La vera opportunità è usare questi strumenti per ridurre backlog, manutenzione e lavori ripetitivi, mantenendo agli sviluppatori il controllo delle decisioni tecniche importanti.