Il confronto non arriva da un benchmark ufficiale, ma è più interessante per questo. Un appassionato che da mesi ricostruisce le demo grafiche in BASIC di fine anni Ottanta ha messo insieme un harness agentico e un transpiler da BASIC a JavaScript dentro una pagina web. L'agente scrive programmi BASIC, li esegue, guarda l'immagine renderizzata e itera. È in questo ciclo che la differenza tra Qwen3.6-27B e Qwen3.8-27B diventa visibile: non nel classico test a singolo passaggio, ma nella capacità di correggersi dopo aver visto il risultato.

Entrambi i modelli girano con quantization unsloth UD-Q8_K_XL. Il prompt chiedeva un ray tracer ricorsivo per tre sfere metalliche (rame, argento, oro) su un piano a scacchiera lucido e sotto un cielo blu intenso, usando il modello Cook-Torrance per le sfere. Qwen3.6 riusciva ad arrivare a un ray tracer con qualche intervento dell'utente, ma spesso sbagliava qualcosa che non riusciva a vedere o notare: senza ulteriori prompt, non lo correggeva. Qwen3.8, invece, in genere chiude il giro da solo e itera fino a un buon risultato.

Il punto strutturale è la chiusura del ciclo di feedback visivo. Scrivere codice per un ray tracer è già un compito non banale; accorgersi che i riflessi, le ombre o i materiali non tornano guardando l'output e intervenire sul codice è un problema diverso. Qwen3.6 mostra il limite classico degli LLM usati come generatori one-shot: se l'errore non emerge nel testo del codice, ma solo nell'immagine renderizzata, il modello resta cieco. Qwen3.8 sembra aver ridotto proprio quella cecità, almeno in questo scenario. Non è un salto di benchmark astratto, è un cambiamento nella capacità di operare come agente.

Per chi valuta deployment on-premise o self-hosted, la differenza cambia il calcolo. Un agente che richiede meno interventi umani riduce i costi di supervisione e rende più sostenibili pipeline locali di creative coding, prototipazione grafica o automazione visuale. Inoltre, il fatto che entrambi girino con quantization spinta (unsloth UD-Q8_K_XL) suggerisce che il confronto avviene su un profilo di risorse compatibile con hardware locale, anche se la fonte non riporta specifiche di GPU o VRAM. Il vincolo non è solo la latenza di una singola inference, ma il throughput iterativo: più cicli autonomi riesce a fare il modello, più il costo umano scende.

C'è però un rovescio. I benchmark tradizionali non catturano quasi nulla di tutto questo: valutare una demo visiva richiede un ambiente con rendering, esecuzione e confronto con l'immagine attesa. Chi costruisce tooling per LLM locali dovrà esporre in modo nativo l'output visuale e il risultato dell'esecuzione, non solo la generazione del testo. E chi mantiene modelli aperti avrà un incentivo a pubblicare valutazioni multi-turno che misurino il tasso di correzione autonoma, non solo il pass@1. Il caso Qwen3.6 vs Qwen3.8, pur essendo un esperimento amatoriale, segnala che la frontiera si sta spostando dal singolo token al ciclo completo.

Per chi valuta deployment on-premise, esistono trade-off tra footprint di VRAM, velocità iterativa e autonomia dell'agente; AI-RADAR offre framework analitici su /llm-onpremise per esplorarli senza ridurre tutto a una classifica di modelli. La chiusura del loop, più della dimensione del parametro, è ciò che rende un modello utile quando deve lavorare da solo.