"AI coding assistant" oggi copre tre lavori diversi sotto lo stesso nome: un motore di completamento che finisce la riga, un agente nell'editor che tocca più file insieme, e una sessione headless che porta a termine un intero task senza supervisione. Quasi tutte le guide all'acquisto trattano queste tre cose come un'unica categoria e le mettono su un'unica scala, di solito velocità o qualità del codice. È una domanda legittima. Non è l'unica a cui una software house deve rispondere prima di adottare uno strumento in modo standard.
Cos'è un AI coding assistant
Nella sua forma più stretta, un AI coding assistant è un autocomplete con più contesto: prevede le righe successive da quello che è già aperto, addestrato su codice pubblico e adattato al file corrente. Nella sua forma più ampia, il termine oggi arriva a coprire agenti completi, Claude Code, la modalità agente di Cursor, che leggono un repository, pianificano una modifica, editano più file, eseguono i test e riportano il risultato. Entrambi vengono chiamati "AI coding assistant" nel marketing e nell'intento di ricerca, ed è per questo che i confronti che non si chiedono prima quale lavoro sta facendo lo strumento finiscono per confrontare cose non confrontabili.
Assistente, agente e strumento di review non sono lo stesso lavoro
Tre categorie coprono quasi tutto quello che c'è oggi sul mercato:
Gli strumenti di completamento prevedono dentro un singolo file, al ritmo della digitazione. GitHub Copilot nella sua forma originale è il punto di riferimento: veloce, poco attrito, contesto minimo oltre al buffer aperto.
Gli strumenti agentici prendono la descrizione di un task e lavorano sull'intero codebase: Claude Code da una sessione da terminale, la modalità agente di Cursor dentro l'editor. Leggono di più, pianificano di più, e producono un diff che attraversa più file invece di un completamento dentro uno solo.
Gli strumenti di review stanno a valle di entrambi: CodeRabbit, Greptile e prodotti simili non scrivono la modifica, leggono una pull request e segnalano quello che un revisore umano potrebbe non notare. Giudicare uno strumento di review su quanto scrive bene il codice è il test sbagliato; giudicare uno strumento di completamento su quanto rivede bene una pull request è lo stesso errore nella direzione opposta.
Un team che sceglie una categoria per risolvere un problema per cui le altre due sono più adatte finisce deluso da uno strumento che, in realtà, non era mai sbagliato per il suo compito.
I criteri che i team usano davvero oggi
L'adozione dà un'idea di dove già stanno i soldi e l'attenzione. Gli strumenti di coding sono la singola categoria più grande di spesa AI dipartimentale, vicino ai 4 miliardi di dollari nel 2025 e oltre la metà del totale, secondo il report 2025 di Menlo Ventures sullo stato della generative AI in enterprise, con un'adozione superiore al 65% tra i team di ingegneria del quartile più alto. Non è più una categoria di nicchia: è il punto di ingresso di default dell'AI nella maggior parte delle organizzazioni di ingegneria.
Quello che i team controllano davvero prima di estendere uno strumento a tutti, in ordine approssimativo:
- Contesto e consapevolezza del codebase. Se ragiona sull'intero repository o solo sul file aperto.
- Modello di interazione. Accettazione blocco per blocco, interattiva, contro un task delegato e revisionato a fine lavoro.
- Dove gira. Legato all'editor contro scriptabile in CI, che decide se può girare senza supervisione oppure no.
- Adattamento a review e merge. Se produce un diff che si inserisce nel flusso di pull request già esistente del team, o se ne serve uno nuovo da imparare.
- Sicurezza e trattamento dei dati. Cosa esce dalla rete, e a quali condizioni, specialmente lavorando su più codebase cliente.
Il report DORA 2025 aggiunge un dato che quasi nessun confronto tra vendor considera: l'adozione dell'AI oggi è correlata positivamente al throughput, gli epic completati per sviluppatore crescono in modo netto, ma resta associata a più instabilità nella delivery, non meno. La lettura del report stesso è diretta: l'AI amplifica quello che un team già è. Un flusso di lavoro solido diventa più veloce. Uno debole diventa più veloce a spedire gli stessi problemi. Scegliere l'assistente più bravo non risolve questo punto: fa solo girare il processo esistente a una velocità più alta.
Il criterio che manca: la prova a sessione chiusa
Nessuno dei cinque criteri sopra chiede cosa resta di uno strumento quando il task è finito. Non è una dimenticanza, è fuori da quello che ciascuna di queste categorie è costruita per produrre. Uno strumento di completamento non ha una sessione da registrare. Uno strumento agentico registra il proprio ragionamento nel proprio formato, in un posto che non viaggia se il team cambia strumento. Uno strumento di review commenta un diff ma non porta con sé perché quel diff era stato richiesto in primo luogo.
Per un singolo sviluppatore su un singolo repository, questo divario raramente pesa: chi ha lanciato la sessione se lo ricorda ancora. Per una software house che consegna su più codebase cliente, dove chi ha eseguito un task potrebbe non essere chi ne risponde tre mesi dopo, "bisogna chiedere a chi l'ha lanciata" non è una risposta su cui un cliente, un auditor o una nuova persona sull'account possano agire. I criteri sopra dicono quanto velocemente uno strumento fa scrivere codice. Non dicono cosa resta da mostrare, a posteriori, per provare che requisito, autorizzazione e rilascio combaciano davvero.
Una tabella di decisione per le software house
| Se il lavoro è... | Serve... | Cosa non ti da' |
|---|---|---|
| Finire righe dentro un file, in fretta | Uno strumento di completamento (stile Copilot) | Ragionamento multi-file, un log della sessione |
| Una modifica multi-file interattiva, seguita passo passo | Un agente nell'editor (Cursor) | Esecuzione headless, senza supervisione |
| Un task delegato ed eseguito senza supervisione, in CI o in una pipeline | Un agente headless (Claude Code) | Un registro portabile se cambia strumento |
| Notare quello che un revisore umano potrebbe perdere in una PR | Uno strumento di review (CodeRabbit, Greptile) | Qualunque racconto del perché la modifica era autorizzata |
| Mostrare, mesi dopo, perché una consegna è andata in un certo modo | Nessuno dei precedenti da solo | — |
Quest'ultima riga è quella che quasi tutte le guide all'acquisto saltano, perché nessuno di questi strumenti è costruito per riempirla. Scegliere un AI coding assistant vuol dire scegliere la categoria giusta per il lavoro che si ha davanti oggi. Non risolve la domanda separata su cosa un cliente, un revisore o una persona assunta in futuro possano verificare quando la sessione che ha prodotto quel codice è ormai chiusa da tempo. Quel livello sta sopra l'assistente, non dentro.