Gli agenti di coding sempre attivi di Cursor sono arrivati. I tuoi team sono pronti?

La notizia

Giovedì Cursor ha rilasciato una funzionalità chiamata Automations. In breve: invece di dover sollecitare manualmente un agente AI ogni volta che serve qualcosa, Automations permette di definire dei trigger — un nuovo commit, un messaggio su Slack, un alert di PagerDuty, un timer — che avviano gli agenti in autonomia. Gli agenti lavorano e coinvolgono un essere umano solo quando incontrano qualcosa che richiede una valutazione.

Jonas Nelle, engineering lead di Cursor, l'ha spiegato senza giri di parole: gli ingegneri «non sono sempre loro a dare il via. Vengono chiamati nei momenti giusti di questo nastro trasportatore». L'azienda afferma di eseguire già centinaia di queste automazioni all'ora sul proprio codebase, gestendo di tutto: dal rilevamento di bug alla risposta agli incidenti, fino ai riepiloghi settimanali del changelog pubblicati su Slack.

I numeri che stanno dietro a tutto questo sono difficili da ignorare. Bloomberg ha riportato questa settimana che il fatturato annualizzato di Cursor ha superato i 2 miliardi di dollari, raddoppiando in circa tre mesi. L'azienda detiene circa il 25% della quota di mercato tra gli abbonati a strumenti di AI generativa.

Perché conta più di quanto sembri

In apparenza, sembra una comodità operativa. Imposti un trigger, lasci che un agente se ne occupi. Carino. Ma se si fa un passo indietro, ciò che Cursor sta effettivamente facendo è trasformare l'assistente AI per il coding in infrastruttura. Non uno strumento che apri e usi, ma un sistema sempre in esecuzione.

È un cambiamento significativo. Siamo passati dall'«autocompletamento nell'editor» a «processi in background che fanno commit, revisionano le PR, analizzano i problemi di sicurezza e rispondono agli incidenti in produzione mentre dormi». In circa due anni.

Continuo a tornare sul problema dell'attenzione. Uno sviluppatore che gestisce decine di agenti contemporaneamente non sta davvero revisionando nulla con cura — sta solo mettendo timbri. Automations cerca di risolvere questo problema essendo selettivo su quando richiedere l'intervento umano. È un buon istinto progettuale, ma significa anche che la qualità del giudizio dell'automazione diventa un elemento portante. Se l'agente decide che qualcosa non ha bisogno di revisione umana e si sbaglia, nessuno se ne accorge.

Cosa vediamo nella pratica

Nel nostro lavoro di sviluppo web e API, abbiamo assistito all'evoluzione della conversazione sugli strumenti AI nell'ultimo anno. All'inizio, i clienti volevano sapere se l'AI poteva accelerare lo sviluppo di nuove funzionalità. Ora le domande sono diverse: come governiamo ciò che gli agenti AI fanno nei nostri repository? Chi è responsabile quando una PR automatizzata introduce una regressione? Come la tracciamo?

Non sono domande ipotetiche. Nel nostro lavoro con clienti enterprise — soprattutto quelli soggetti ai requisiti di conformità svizzeri — «lo ha fatto un agente AI» non è una risposta accettabile quando qualcosa va storto. Serve tracciabilità. Bisogna sapere quale agente ha operato, cosa ha modificato, perché e chi ha approvato.

Il framework Automations di Cursor sembra capirlo, almeno in parte. L'integrazione con PagerDuty, ad esempio, interroga i log tramite connessioni MCP e assembla una timeline prima di proporre una soluzione. È una sorta di audit trail. Ma «una sorta di» non è sufficiente per gli ambienti regolamentati.

L'aspetto della sicurezza di cui nessuno parla

Ecco cosa mi preoccupa davvero. Nei nostri penetration test con studi di gaming e piattaforme enterprise, uno dei vettori di attacco più comuni che troviamo è rappresentato da processi automatizzati con permessi eccessivi: pipeline CI/CD che possono fare deploy in produzione, service account con accesso admin che nessuno rivede da due anni.

Gli agenti di coding sempre attivi rientrano nella stessa categoria di rischio, con ancora più autonomia. Un agente che può leggere il tuo codebase, interrogare i log di produzione via Datadog, aprire PR e avviare deployment è un bersaglio straordinariamente appetibile. Se un attaccante compromette il meccanismo di trigger — diciamo, un messaggio Slack appositamente costruito — ottiene potenzialmente un accesso a livello di agente sull'intero flusso di sviluppo.

Automations di Cursor si attiva attualmente da messaggi Slack, modifiche al codice e alert di PagerDuty. Ognuno di questi è una superficie d'attacco. Quando configuriamo strumenti come Cloudflare o Akamai per la protezione DDoS, mappiamo sempre l'intera catena dei sistemi automatizzati che possono modificare lo stato di produzione. Gli agenti AI per il coding appartengono ora a quella mappa.

Cosa dovresti fare subito

Se il tuo team sta usando o valutando strumenti AI per il coding con funzionalità di automazione, ecco alcune azioni concrete da affrontare questa settimana:

1. Fai un inventario dei permessi degli agenti. Cosa può leggere, scrivere ed eseguire ciascun agente? Trattalo come faresti con un audit di service account. Se un agente può aprire PR e interrogare i log di produzione, necessita dello stesso scrutinio di sicurezza di qualsiasi strumento di deployment automatizzato.

2. Definisci la tua policy di supervisione umana prima di averne bisogno. Non lasciare che sia lo strumento a decidere cosa è abbastanza importante da mostrare a un essere umano. Il tuo team dovrebbe definire quella soglia in base al rischio: qualsiasi cosa riguardi autenticazione, pagamenti, configurazione dell'infrastruttura o dati utente deve essere revisionata da un umano. Senza eccezioni.

3. Registra tutto. Se stai eseguendo agenti che apportano modifiche in autonomia, hai bisogno di log immutabili di ciò che è stato attivato, cosa è cambiato e cosa è stato approvato (e da chi). Nel nostro lavoro di sviluppo di applicazioni cloud-native per clienti enterprise, questo lo integriamo nella pipeline CI/CD fin dal primo giorno. Aggiungerlo in seguito significa perdere delle lacune.

4. Tratta le integrazioni degli agenti come parte del tuo threat model. Se stai svolgendo qualsiasi tipo di security review o pen test, includi le configurazioni dei tuoi agenti AI. Nei nostri progetti nativi iOS e Android, abbiamo visto team blindare la sicurezza della loro app mobile lasciando però la toolchain di sviluppo completamente aperta. Lo stesso principio vale qui.

Il quadro generale

Lo spazio del coding agentivo si muove velocemente. Entrambi i principali laboratori AI hanno rilasciato funzionalità concorrenti nell'ultimo mese, e la direzione è chiara: gli strumenti di coding vogliono essere sempre attivi, autonomi e profondamente integrati nel tuo stack.

È probabilmente la direzione verso cui si va. Non sto suggerendo ai team di evitare questi strumenti. Anche noi usiamo lo sviluppo assistito da AI, e i guadagni di produttività su boilerplate, scaffolding dei test e refactoring di routine sono reali.

Ma c'è una differenza tra usare gli strumenti AI e lasciar gestire il processo di sviluppo agli strumenti AI senza supervisione. Il confine tra le due cose è appena diventato più sfumato. I team che trattano i loro agenti AI con lo stesso rigore che applicano a qualsiasi altro sistema automatizzato con accesso alla produzione staranno bene. Quelli che non lo fanno impareranno la lezione nel modo più difficile.

Abbiamo già visto questo schema. Quando le pipeline CI/CD si sono diffuse per la prima volta, i team che le hanno trattate come infrastruttura critica per la sicurezza fin dal primo giorno hanno evitato le violazioni che hanno colpito tutti gli altri qualche anno dopo. Gli agenti AI per il coding si trovano proprio in quel punto di svolta adesso.

Se capire come governare gli strumenti AI nel tuo team di sviluppo è il tuo mal di testa attuale, parliamone.