Qwen3.7-Plus è davvero affidabile per programmare? Il mio test sul login sicuro in PHP

Perché ho scelto proprio un login sicuro

Se avete mai scritto un sistema di autenticazione saprete certamente che il problema non è far confrontare una password con un hash, quello lo si fa in poche righe, il problema vero arriva quando nello stesso pezzo di codice bisogna tenere insieme il lockout, la concorrenza, le transazioni, il timing attack, il rinnovo dell'hash, la session fixation ed il timeout della sessione senza lasciare un buco nascosto in mezzo. È proprio per questo che ho scelto SecureLogin come banco di prova per Qwen3.7-Plus, non volevo un esercizio enorme nel quale un errore potesse essere giustificato dalla quantità di codice, volevo una classe relativamente breve nella quale però quasi ogni riga fosse collegata ad una invariante di sicurezza, ovvero un problema che a prima vista sembra normale PHP ma che diventa rapidamente cattivo appena si prova ad implementarlo davvero.

Il prompt di partenza era questo:

text

PHP 8.3 vanilla: implementa SecureLogin (max 100 righe di codice, solo PDO/stdlib). API: __construct(PDO $db), login(string $email,string $password,string $ip): bool, logout(): void, userId(): ?int.

DB: users(id,email,password_hash,failed_count,locked_until,last_failed_at), email UNIQUE. Usa prepared statement, password_verify, password_needs_rehash(PASSWORD_DEFAULT) e aggiorna hash dopo login valido.

Utente inesistente/password errata/blocco devono essere indistinguibili; mitiga timing enumeration anche se l’email non esiste. Dopo 5 errori entro 15 min blocca 15 min; successo azzera contatori. Verifica credenziali+contatori atomica in transazione e sicura contro login concorrenti.

Al successo: session_regenerate_id(true), salva solo user_id e last_activity. userId() scade dopo 30 min inattivi e rinnova last_activity. logout() distrugge sessione e cookie. Vietati SQL dinamico, sleep, framework/librerie esterne. Output solo codice.

Ho scelto questo prompt perché costringe il modello ad arrivare contemporaneamente a scegliere correttamente password_verify, usare prepared statement, serializzare i login concorrenti con una transazione e SELECT ... FOR UPDATE, gestire una finestra di errori ed un blocco temporaneo, evitare che un account inesistente sia riconoscibile semplicemente dal tempo di risposta, fare il rehash senza uscire dalla logica atomica ed infine passare dalla sicurezza del database a quella della sessione. In pratica non stavo misurando quanto PHP conoscesse Qwen, stavo cercando di capire se fosse capace di mantenere coerenti parecchie condizioni che interagiscono tra loro, perché è proprio qui che un modello può produrre codice dall'aspetto impeccabile ed avere invece una riga sbagliata che manda all'aria tutto.

Le prime prove e la sorpresa della lingua

All'inizio ho ripetuto lo stesso test in italiano, cinese ed inglese, ed il primo risultato sembrava quasi raccontare una storia semplice, 58 su 100 in italiano, 72 in cinese ed 82 in inglese. Sarebbe stato facile concludere che il modello rendesse meglio in inglese, ma sarebbe stata una conclusione troppo comoda, infatti ripetendo il prompt italiano ho ottenuto 80, 74, 78 ed 86, cioè la stessa lingua che aveva prodotto un 58 è arrivata anche ad 86, mentre le prove successive in cinese hanno oscillato ancora di più arrivando da 41 ad 84 e, cosa che mi ha colpito parecchio, in un singolo giro il modello mi ha proposto due soluzioni alternative delle quali una valeva circa 84 ed una circa 43. Il punto è che la variabilità tra due generazioni dello STESSO MODELLO era più grande della differenza che avevo inizialmente attribuito alla lingua, quindi il primo dato che mi sono portato a casa è stato semplice: una sola risposta non basta per giudicare una AI di programmazione. I punteggi che riporto non sono un benchmark ufficiale del produttore e non pretendono di esserlo, sono voti che ho assegnato dopo una code review della singola risposta cercando errori funzionali, violazioni del prompt e falle di sicurezza, quindi servono soprattutto a confrontare la STABILITÀ delle diverse generazioni dello stesso test.

Gli errori non erano cosmetici, a volte compariva un lockout che poteva essere prolungato continuamente da chi continuava a tentare il login, altre volte il modello eseguiva un UPDATE e subito dopo un ROLLBACK, annullando proprio il contatore che avrebbe dovuto proteggere l'account, in altri casi dimenticava di avviare la sessione prima di rigenerarne l'ID oppure confondeva timestamp Unix e DATETIME SQL. Il caso più interessante era però quello dei placeholder PDO, perché in due risposte una query con un solo ? riceveva quattro parametri in execute(), errore banalissimo che avrebbe impedito qualsiasi login valido pur dentro ad un codice che per il resto sembrava scritto da qualcuno che sapeva perfettamente cosa stava facendo.

Ho provato anche a dirgli di ragionare da senior

A quel punto ho aggiunto una regola molto generale che gli chiedeva di comportarsi da Senior SWE, descrivere prima la logica, dichiarare invarianti e casi limite, validare i tipi e gestire le eccezioni. Mi aspettavo che la pianificazione esplicita riducesse gli errori, ma nei tre giri italiani i punteggi sono stati 62, 34 e 52, quindi non solo non avevo ottenuto la stabilità che cercavo ma avevo visto una cosa ancora più curiosa, il modello poteva scrivere nei commenti che una certa invariante era garantita e poi violarla poche righe sotto. Per così dire la spiegazione era diventata più professionale del programma, e questo per me è un segnale da non sottovalutare perché una AI che sa spiegare perfettamente ciò che dovrebbe fare può dare una falsa sensazione di sicurezza se poi non verifica davvero che il codice faccia la stessa cosa.

Ho quindi tolto quella meta-regola ed ho riscritto il problema in maniera più precisa, specificando meglio la semantica dei tempi, del lockout, delle transazioni e della sessione. Con quella variante, ancora vincolata nella lunghezza, i cinque risultati sono stati 45, 84, 47, 89 e 91. Il massimo era salito parecchio, ma la distribuzione restava quasi spaccata in due, due soluzioni cattive e tre molto buone, quindi avevo ridotto le ambiguità del problema ma non la probabilità che durante la scrittura comparisse un errore elementare.

La variabile che ha cambiato davvero il risultato

La prova che mi ha fatto cambiare idea sul comportamento del modello è arrivata quando ho eliminato il limite artificiale sulle righe mantenendo il resto del prompt sostanzialmente identico. Ho eseguito cinque volte il test ed ho ottenuto 86, 92, 95, 88 ed 87 su 100, cioè una media di 89,6, una mediana di 88, un minimo di 86 ed un massimo di 95 con appena nove punti di escursione. Questa volta non era migliorato soltanto il picco, era soprattutto sparita la coda delle risposte da 40 o 50 punti, ed è proprio questo che considero il risultato più interessante dell'intera prova.

La mia interpretazione è che Qwen3.7-Plus sappia davvero affrontare il problema, ma quando gli impongo contemporaneamente correttezza, sicurezza ed una compressione aggressiva del codice aumenta la probabilità che perda una delle condizioni locali mentre cerca di stare dentro al formato. Senza quel limite ha avuto lo spazio per separare meglio i passaggi, usare helper quando servivano, evitare di schiacciare troppa logica dentro alla stessa riga ed arrivare ad una soluzione molto più stabile. Questo non significa che il limite delle righe sia sempre sbagliato, significa che se sto usando una AI per codice delicato preferisco lasciarla scrivere qualche riga in più e poi rifattorizzare, anziché costringerla a comprimere subito qualcosa che deve prima di tutto essere CORRETTO.

Il mio giudizio su Qwen3.7-Plus

Dopo queste prove il mio parere è positivo, Qwen3.7-Plus non mi è sembrato un modello che conosce soltanto la sintassi e mette insieme API plausibili, nei run migliori ha gestito correttamente concorrenza, transazioni, FOR UPDATE, password hashing, rehash, session fixation, lockout, cookie e timeout, ossia concetti che devono funzionare assieme e non separatamente. Ma non arriverei mai a prendere una sua classe di autenticazione e metterla in produzione senza test e code review, perché le prove peggiori hanno mostrato esattamente il tipo di errore che mi preoccupa di più, non codice palesemente rotto che si riconosce in dieci secondi, bensì codice dall'aspetto professionale con UNA SOLA DECISIONE SBAGLIATA capace di compromettere il requisito di sicurezza.

Per questo lo considero un ottimo coprogrammatore ed un candidato molto serio anche per attività tecniche complesse, ma non un sostituto della verifica umana quando il codice tocca autenticazione, autorizzazioni, pagamenti o dati sensibili. La cosa che mi ha convinto di più non è il 95 ottenuto nel run migliore, è il fatto che senza il vincolo di lunghezza cinque risposte consecutive siano rimaste tutte tra 86 e 95, perché una AI utile sul lavoro non deve soltanto essere capace di trovare la soluzione giusta una volta, deve riuscire ad avvicinarsi alla soluzione giusta con una certa regolarità.

Perché il test l'ho fatto online e cosa voglio provare in locale

C'è poi una precisazione importante, perché Qwen3.7-Plus è il modello che ho provato online su Qwen Studio durante tutta questa serie di test, mentre per il self-hosting il riferimento open-weight comparabile è Qwen3.5-397B-A17B. Quest'ultimo ha 397 miliardi di parametri totali, circa 17 miliardi attivi per token e la distribuzione ufficiale non quantizzata pubblicata su Hugging Face occupa circa 807 GB. Con i miei attuali 512 GB di RAM non potrei quindi caricare integralmente la versione non quantizzata, a maggior ragione considerando che oltre ai pesi servono memoria per runtime, buffer e KV cache, ed è per questo che questo primo confronto l'ho eseguito online anziché tentare un caricamento locale impossibile sulla configurazione attuale.

La cosa interessante è che lo stesso modello open-weight può essere quantizzato a 4 bit, scendendo grossomodo nell'ordine dei 200 e qualcosa GB a seconda del formato e della quantizzazione concreta, una dimensione che diventa invece compatibile con una macchina da 512 GB. Il prossimo articolo sarà quindi dedicato proprio al test della VERSIONE QUANTIZZATA A 4 BIT, usando per quanto possibile lo stesso tipo di prova sul login sicuro così da confrontare non soltanto il punteggio massimo ma soprattutto la stabilità fra più generazioni.

Nel frattempo mi sto operando per reperire altri 512 GB di memoria RAM per il mio Dell PowerEdge R930, portandolo dagli attuali 512 GB ad 1 TB di RAM, perché a quel punto voglio tentare anche il test locale della versione non quantizzata da circa 807 GB e capire cosa significhi davvero far girare una bestia di queste dimensioni completamente in casa, senza GPU e senza affidarsi ad un endpoint remoto. Sarà probabilmente un test molto diverso da quello online, soprattutto per velocità, memoria effettivamente disponibile e gestione del contesto, ma è proprio questo che voglio misurare e non soltanto immaginare sulla carta. Se avete consigli da proporre o esperienze da condividere, iscrivetevi e dite la vostra!