Quando il golden standard fallisce: antirez testa Kimi, Opus e GPT su una vera code review

Antirez non gira attorno alle cose. Guarda ai modelli cinesi con interesse crescente, e non è idealismo. È pragmatismo.

Su una vera code review sulla sua codebase, Kimi K2.6 ha trovato un bug reale che GPT-5.4 ha completamente ignorato al primo passaggio. Claude Opus 4.7 ha fatto l’analisi più completa, ma il takeaway va oltre la classifica: l’optionality ha valore, e va costruita prima di averne bisogno.

Dove andiamo

Se usi LLM per programmare, questo confronto ti tocca. Antirez ha preso una vera pull request da Richard Hipp, l’ha data in pasto a tre modelli di punta, e ha visto il “golden standard” fallire su un bug reale. Qui vediamo cosa è successo, perché GPT-5.4 ha fallito, e perché tutto questo va oltre il singolo test.

Il contesto: una PR che merita attenzione

La pull request arriva da Richard Hipp. Se hai mai digitato sqlite3 in un terminale, hai usato il suo software. Il creatore di SQLite, uno dei pezzi di codice più deployati nella storia dell’informatica, ha sottoposto una patch a linenoise, la libreria minimalista di line editing di antirez che funge da prompt handler di default dentro SQLite stesso.

Le parole di Hipp: “linenoise si adatta perfettamente alla filosofia low-dependency, self-contained, it just works di SQLite.” Due ingegneri che la pensano allo stesso modo, che si scambiano codice. È il tipo di review dove vuoi arrivarci preparato.

Il bug: prompt colorati, cursori rotti

Il problema è ingannevolmente semplice. Quando colori un prompt di terminale con sequenze di escape ANSI (diciamo rosso dentro una transazione SQL e verde fuori), linenoise calcola male la larghezza visiva del prompt. Conta i byte di escape come caratteri stampabili, e il cursore finisce nel posto sbagliato. Chiunque abbia mai visto un prompt sovrascriversi da solo ha sbattuto contro questa classe di bug.

La fix di Hipp è elegante: una funzione linenoiseEscapeSeqLen() che riceve un puntatore, verifica se si trova all’inizio di una sequenza di escape, e ritorna la lunghezza in byte di quella sequenza (oppure zero se non è una sequenza). Il codice chiamante può saltare quei byte quando calcola la larghezza visiva. Patch piccola, autocontenuta, proprio il tipo di cosa che approveresti in cinque minuti, tranne quando non lo fai.

Kimi K2.6: inciampa, poi centra il bersaglio

Antirez ha dato a Kimi Code (il coding agent di Moonshot) la directory di linenoise e il link alla PR. Primo tentativo: Kimi ha capito il bug correttamente ma non è riuscito ad accedere al file della patch. I suoi tool, ancora meno rifiniti di Claude Code o Codex, non ce l’hanno fatta. Dopo che antirez ha copiato la patch in /tmp/patch.txt, Kimi si è messo al lavoro e ha prodotto due risultati significativi:

• La detection CSI è sufficiente per il caso d’uso. La patch gestisce le sequenze CSI (Control Sequence Introducer), che coprono i prompt colorati che Hipp vuole. Esistono anche OSC e altri tipi di sequenze, ma non compaiono nei prompt di comando. Kimi ha riconosciuto questa distinzione senza che gli venisse suggerita.
• Un bug reale di out-of-bounds nella patch stessa. Il codice accede a s[1] per verificare il carattere dopo un escape, ma senza prima controllare che la sequenza di escape sia abbastanza lunga da avere un byte alla posizione 1. Se gli passi una sequenza malformata o troncata, leggi oltre il buffer. Kimi l’ha individuato, l’ha spiegato chiaramente, e ha proposto il fix corretto.

Un dettaglio che merita attenzione: l’intero chain of thought di Kimi è visibile. Puoi tracciare esattamente come il modello ragiona sul codice. Questo non è più possibile con i modelli a pagamento di OpenAI e Anthropic, che hanno nascosto il ragionamento. Per la code review, dove capire come un modello è arrivato alla conclusione conta quanto la conclusione stessa, questa trasparenza ha un valore pratico reale.

Claude Opus 4.7: veloce, approfondito, un passo avanti

Passando la stessa review a Claude Opus 4.7 in modalità “high effort”, antirez ha ottenuto un’analisi più rapida e completa. Opus ha confermato l’out-of-bounds read, ha notato la portata limitata alle sole sequenze CSI, e poi ha fatto una cosa che né Kimi né GPT sono riusciti a fare: ha sollevato il caso edge dello ZWJ (Zero Width Joiner).

Lo scenario: un’emoji seguita da un code point ZWJ, seguito da una sequenza di escape per il colore. In teoria, questo potrebbe interagire male con il calcolo della lunghezza della patch. In pratica, come lo stesso antirez ha osservato, nessuno compone prompt concatenando emoji, codici di giunzione e sequenze di colore. È una preoccupazione teorica, non pratica. Ma il fatto che Opus l’abbia individuata rivela un livello di analisi esaustiva genuinamente impressionante. È il tipo di cosa che un revisore umano meticoloso segnalerebbe come “probabilmente ok, ma vale la pena annotarlo.”

GPT-5.4: quello che non l’ha visto

E qui arriva la sorpresa. GPT-5.4, il modello che antirez definisce “il golden standard della programmazione”, quello che usa tutti i giorni con Codex, non ha trovato nulla di problematico al primo passaggio. La sua risposta: “Findings: no blocking findings.” Ha persino classificato la PR come “issue” anziché pull request. L’accesso out-of-bounds su s[1]? Completamente invisibile.

Solo quando antirez ha chiesto esplicitamente “La patch contiene qualche bug?” GPT-5.4 ha trovato lo stesso problema su s[1] che Kimi aveva già segnalato, e ha proposto essenzialmente lo stesso fix. Il modello ci è arrivato, ma solo con un umano che gli teneva la mano.

La sintesi di antirez è diretta: “Questo è un esempio in cui GPT-5.4, di solito il più forte, ha funzionato peggio di tutti, e Kimi ha funzionato meglio in questo contesto specifico.” Un test non ridefinisce la classifica. Ma è un promemoria utile: “miglior modello” è sempre dipendente dal contesto, e il divario tra i modelli di punta su un compito specifico è spesso più piccolo di quanto il marketing farebbe credere.

Il vero takeaway: affinità e optionality

Il confronto sulla code review è interessante, ma antirez punta a qualcosa di più grande. Non sta dicendo che Kimi è meglio di GPT in generale. Sta dicendo: ho bisogno di sviluppare affinità con le alternative, perché il mio accesso ai modelli dominanti non è garantito.

Affinità significa più di “l’ho testato una volta.” Significa capire le stranezze di un modello, imparare i suoi punti ciechi, costruire la memoria muscolare di come promptarlo efficacemente. Antirez usa GPT-5.4 con Codex tutti i giorni. Sa come pensa. Quell’intuizione accumulata è essa stessa una forma di dipendenza, e lui lo sa. Usare Kimi di più, sviluppare la stessa sensibilità per i suoi punti di forza e le sue lacune, è una copertura.

Sui piccoli modelli locali (Gemma 4, Qwen 3.5/3.6), il suo verdetto è diretto come al solito: “Funzionicchiano, ma questo è un altro livello di capacità.” Il divario tra un MoE da 32B attivi nel cloud con 262K di contesto e un modello 8B quantizzato sul tuo portatile non è sottile. È la differenza tra uno strumento che individua un buffer overread reale e uno che ti dice “mi sembra tutto ok.”

La lezione non è “usa i modelli cinesi invece.” È che l’optionality ha valore, e l’optionality richiede investimento prima di averne bisogno.

Per chi vuole approfondire

Da qui in poi si entra nel tecnico. Se ti interessa l’idea più dell’implementazione, puoi saltare direttamente alla conclusione.

La patch di Richard Hipp: dettagli

La funzione linenoiseEscapeSeqLen() gestisce tre tipi di sequenze di escape:

La patch originale di Hipp copriva solo le CSI, che sono sufficienti per i prompt colorati. Il bug di out-of-bounds riguardava l’accesso a s[1] senza verificare che la stringa fosse abbastanza lunga da contenere almeno 2 byte dopo l’escape.

Benchmark comparativi dei tre modelli

Il punto

Punti chiave:

• Su una code review reale, Kimi K2.6 ha trovato un bug che GPT-5.4 ha completamente ignorato al primo passaggio
• Claude Opus 4.7 ha fatto l’analisi più esaustiva, individuando anche un edge case teorico (ZWJ) che gli altri hanno saltato
• Il chain of thought visibile di Kimi è un vantaggio pratico per la code review, dove capire come si è arrivati a una conclusione conta quanto la conclusione stessa
• Sviluppare affinità con modelli alternativi non è ideologia, è pragmatismo: l’accesso ai modelli dominanti non è garantito

Un singolo test non ridefinisce le classifiche, ma ricorda qualcosa che il marketing fa finta di dimenticare: il modello migliore dipende sempre dal contesto.

Risorse

• Video originale
• Kimi K2.6 su Hugging Face
• Dettaglio benchmark Kimi K2.6 - What LLM
• Kimi K2.6 vs Opus 4.6 vs GPT-5.4 - Verdent Guides
• Pull request di Richard Hipp su linenoise (repository)