CRAP (Compiler Replacement for Assembling Programs) non è un nuovo compilatore. È un fine-tuning di Gemma 4 E2B che, dato un prompt come 'genera un binario Linux x86_64 che stampa boop', emette direttamente un file ELF funzionante in formato esadecimale. L'idea del suo autore, matthewhaynesonline, è aggirare l'intera catena di compilazione: niente assembler, niente tool call, solo un LLM che produce istruzioni macchina.

La versione 1.1 porta miglioramenti su più fronti. Sul set legacy il modello resta fermo a 20 successi su 23; sulle stringhe nuove passa da 8 a 26 su 40; sul multi-turn da 0 a 10 su 12; sulle stringhe con caratteri raddoppiati da 2 a 18 su 24; sui codici di uscita 'jank' mai visti in addestramento ottiene 23 su 25. L'autore segnala un dettaglio istruttivo: un training run ha raggiunto una loss di 0,038 ma falliva ancora 11 dei 12 exit code su cui era stato addestrato. In altre parole, la discesa del gradiente non coincide con il completamento del compito.

La demo gira nel browser tramite wllama su WebGPU. Carica il GGUF Q6_K da circa 3,6 GiB, genera l'hex, lo trasforma in ELF e lo consegna all'utente, che deve scaricarlo ed eseguirlo in locale. Su un Mac M4 Pro con Chrome, il Q6_K ottiene 109 successi su 144, contro 114 su 144 del modello f16; i cinque fallimenti aggiuntivi del Q6_K riguardano valori errati, non binari completamente rotti. Il Q4_K_M crolla a 3 su 144, motivo per cui la demo non lo usa.

Il crollo tra Q6_K e Q4_K_M è il segnale più interessante per chi osserva l'inference locale. Non si tratta di un degrado graduale: a un certo livello di quantization il modello smette di produrre artefatti validi, non solo meno precisi. Per un carico di lavoro che richiede output esatti, come la generazione di codice macchina, è un vincolo strutturale. In un chat assistant un token impreciso può essere corretto in un secondo giro; in un binario ELF un byte sbagliato in un punto critico rende l'eseguibile inutilizzabile.

La provocazione di CRAP non sta nel sostituire un compilatore. Sta nel mostrare che un LLM può apprendere una rappresentazione operativa di un formato binario ma non conviene usarlo per produrlo. Un compilatore lo fa in millisecondi, in modo deterministico e corretto; CRAP lo fa con diversi gigabyte di pesi, più lentamente e occasionalmente in modo errato. La differenza non è di scala ma di garanzie. Per chi gestisce pipeline locali o edge, il rischio non è il modello 'quasi giusto', ma il costo di verificare ogni output in un contesto in cui l'errore non è tollerato.

Le esclusioni del titolo sono la parte seria: il modello sa generare solo programmi che stampano una stringa ed escono. Il resto è ancora territorio del compilatore. Ma il fatto che un fine-tuning di Gemma 4 arrivi a 109/144 con un Q6_K in un browser, senza passare da un server cloud, è un dato che merita attenzione per chi segue l'evoluzione dell'inference locale e dei modelli in esecuzione locale.