Strumenti Dev della Settimana

SWE-2 di Cognition: come valutare un nuovo modello AI per programmare (senza farsi abbagliare dai benchmark)

Cognition, l'azienda dietro l'agente di coding Devin, ha presentato SWE-2: un modello che dichiara di avvicinarsi alle prestazioni dei modelli di punta su benchmark di programmazione, a una frazione del costo. È l'ennesimo annuncio di "il nostro modello è quasi come quello grande ma costa molto meno" nel giro di poche settimane. La domanda utile non è se il numero sul benchmark sia vero, ma come si fa a capire se conviene davvero per il tuo lavoro quotidiano.

Cosa dichiara SWE-2, in breve

Secondo il post di lancio, SWE-2 nasce da un modello base con quasi tre volte i parametri del suo predecessore, allenato poi con reinforcement learning specifico per il coding agentico. Il punto che Cognition sottolinea di più non è il punteggio assoluto sui benchmark, ma l'efficienza: a parità (o quasi) di qualità del codice prodotto, il modello userebbe meno passaggi per arrivare alla soluzione — nei loro test, un numero di "turni" ridotto di oltre la metà rispetto alla generazione precedente, e un costo per task inferiore dell'80% circa. In pratica, l'azienda dice che il modello precedente tendeva a esplorare troppo il codice prima di agire, mentre la nuova versione capisce più in fretta quali parti del progetto contano davvero per il compito richiesto.

Perché il benchmark non basta per decidere

Ogni pochi mesi esce un modello che "quasi eguaglia" quello più costoso spendendo una frazione del prezzo. È un pattern ricorrente, non un'eccezione, e i benchmark citati (spesso proprietari dell'azienda stessa, o poco noti fuori dal settore) misurano compiti sintetici che possono assomigliare poco al tuo repository reale, con le sue convenzioni, la sua storia, le sue dipendenze datate. Prima di cambiare strumento — o di sceglierne uno per la prima volta — conviene avere un piccolo protocollo di verifica personale, invece di fidarsi del grafico nel post di lancio.

Un protocollo semplice e concreto potrebbe essere questo:

  • Scegli 3-5 task reali già risolti in passato nel tuo progetto (un bug specifico, una piccola feature, un refactoring), di cui conosci già la soluzione corretta.
  • Fai risolvere lo stesso task al modello nuovo e a quello che usi già, con lo stesso prompt e lo stesso contesto di partenza.
  • Misura tre cose, non una sola: se il codice prodotto è corretto, quanti "giri" di correzione ti sono serviti per arrivarci, e quanto ti è costato in token o in abbonamento.
  • Valuta anche i test che genera, non solo il codice applicativo: un modello che scrive test superficiali ti farà risparmiare tempo oggi e perdere fiducia domani, quando un test verde non intercetta una regressione reale.

Il vero criterio: cosa ti serve, non chi vince la classifica

Se lavori da solo o in un piccolo team, il costo per task e la velocità con cui il modello capisce quale parte del codice toccare contano più del punteggio assoluto su un benchmark che nessuno dei tuoi clienti vedrà mai. Se invece gestisci un progetto complesso con molte dipendenze legacy, la capacità di "non over-esplorare" può essere un rischio quanto un vantaggio: un modello troppo sicuro di sé che salta l'esplorazione del codice esistente può introdurre bug sottili proprio nei punti più delicati, quelli che richiederebbero più cautela, non meno.

In ogni caso, la scelta dello strumento AI che usi per scrivere codice oggi non è una decisione da prendere una volta per tutte: vale la pena rivalutarla ogni pochi mesi con lo stesso metro, man mano che escono nuovi modelli, invece di restare fedeli per abitudine a quello con cui hai iniziato.

Fonte: Introducing SWE-2: Pushing the Pareto Frontier, su cognition.com