# narreddi-training-ai-paint-with-code-2026-03-01

## Veille

Case study di **Surya Narreddi** (con **Cameron Franz** e **Alex Wang**) sul suo sito personale, datato **marzo 2026** (giorno non specificato; ~1.500 parole), intitolato *Training AI to Paint with Code*. Gli autori addestrano un modello linguistico (**Qwen 3.5 35B**) tramite reinforcement learning (**GRPO**) a produrre acquerelli come codice JavaScript **p5.brush**, con il codice stesso che funge da artefatto modificabile. La domanda di fondo: come fare RL quando la reward — estetica — non è verificabile.

## Titre Article

Training AI to Paint with Code (RLing Qwen to paint with code)

## Date

2026-03-01

## URL

https://surya.website/rling-qwen-to-paint-with-code

## Keywords

reinforcement learning, GRPO, funzione di reward, giudice pairwise, reward soggettiva, compiti creativi, Qwen, p5.brush, acquerello, generazione di codice, HPSv3, GEPA, ottimizzazione del prompt, pool di riferimento, allucinazione API, plateau della reward, segnali correlati, RLHF, Puppeteer, progettazione della reward

## Authors

Surya Narreddi — designer et développeur, auteur du projet (site personnel) ; collaborateurs Cameron Franz (infrastructure d'entraînement) et Alex Wang.

## Ton

Narrazione di progetto in prima persona, a metà tra un memoir di design e note di ricerca. Il testo procede attraverso il fallimento e poi la diagnosi: il plateau, la lettura delle sub-reward "in isolamento", la correzione. Le scelte sono spiegate concretamente, senza gergo superfluo, e i limiti sono enunciati chiaramente (tutte le immagini nel pool sono generate dal modello, il passaggio RLHF "che non abbiamo raggiunto", il metodo più lento della generazione di immagini convenzionale). La conclusione difende l'intento: partecipare alla creazione al di là del prompt, agendo sul modello e sull'artefatto.

## Pense-betes

- **Il problema**: un'immagine generata da un modello può essere modificata solo rifacendo il prompt; generare **codice** rende l'artefatto modificabile in modo fine. L'RL richiede una reward, e l'estetica non è né giusta né sbagliata.
- **Diagnosi della prima griglia**: cinque segnali (riconoscibilità, estetica, tecnica, profondità, adesione al prompt) correlati a 0,85-0,95 "misuravano la stessa cosa cinque volte"; la lunghezza, circa un terzo della reward, ha smesso di fornire qualsiasi gradiente dopo lo step 30; l'unico segnale con varianza reale, **HPSv3**, aveva un peso di 0,10.
- **Due correzioni**: giudizio **pairwise** (il giudice confronta il render con due riferimenti; la reward è la proporzione di vittorie) al posto di un punteggio da 0 a 10 compresso vicino a zero; un **pool di riferimento** valutato manualmente.
- **Pool**: 581 riferimenti (117 "love", 266 "okay", 198 aggiunti per colmare colori poco coperti), tutti prodotti da modelli (AutoResearch con Opus 4.6, GPT-5.4 e Gemini, un batch su Gemini 3.1 Pro), in assenza di esempi umani per questo strumento di nicchia.
- **System prompt via GEPA**: un riferimento API di 400 righe induceva il modello a inventare metodi; la versione con otto metodi consentiti, senza documentazione né esempi, ha prodotto per la prima volta un output utilizzabile in tre generazioni su tre.
- ⚠️ **Limiti**: la proposta di addestrare un piccolo modello di reward sulle valutazioni (**RLHF** propriamente detto) non è stata realizzata; un passaggio finale di addestramento è annunciato, con un rapporto tecnico in giugno 2026.

## RésuméDe400mots

**Surya Narreddi**, con **Cameron Franz** e **Alex Wang**, descrive in **marzo 2026** un progetto per addestrare un modello linguistico a dipingere con il codice. Il punto di partenza è un'osservazione: con un modello di immagini, il solo modo di partecipare è attraverso il prompt, e l'immagine non può essere modificata direttamente. Qui, il modello scrive un programma **p5.brush** in JavaScript che rende un acquerello; il codice è l'artefatto, modificabile in modo più fine di un prompt. La domanda di fondo è fare reinforcement learning su compiti creativi: l'RL funziona quando la reward è verificabile, cosa che l'estetica non è.

Il loop viene ripetuto migliaia di volte. Il modello (**Qwen 3.5 35B**) riceve un prompt — ad esempio, un ibisco pesca ad acquerello — e scrive lo sketch completo; questo viene renderizzato come PNG in un ambiente Puppeteer isolato; un modello giudice confronta il render con due riferimenti tratti da un pool valutato manualmente; il giudizio diventa una reward; **GRPO** aggiorna il modello.

La prima griglia di reward aveva nove segnali: un gate di compilazione, l'uso di **p5.brush**, una rampa di lunghezza intorno a 3.000 token, **HPSv3** (un modello di preferenza umana), l'adesione al prompt giudicata da GPT-5.4 e Gemini, e quattro giudici di qualità. Il modello si è stabilizzato a 0,65, con tutti gli output che erano fiori piatti, in stile clip-art. L'esame delle sub-reward in isolamento ha mostrato che cinque giudici erano correlati tra 0,85 e 0,95, che la lunghezza (un terzo del totale) si era saturata entro lo step 30, e che **HPSv3**, l'unico segnale con varianza reale, aveva un peso di appena 0,10.

La correzione: giudizio **pairwise** (il giudice scegli l'acquerello migliore tra il render e due riferimenti; la reward è la frazione di confronti vinti), che distribuisce i punteggi in modo più ampio rispetto a un punteggio assoluto compresso, più un **pool di riferimento** di 581 immagini tratte da 1.664 generazioni valutate "love", "okay" o "nope" (117 "love"). La griglia viene ridotta a quattro componenti: gate di compilazione e uso del brush (0,05), lunghezza (0,05), **HPSv3** (0,30), giudice pairwise (0,60). Con lo stesso modello e gli stessi dati, il vecchio plateau viene raggiunto tre volte più velocemente, il progresso continua, e il codice si riduce da 13.500 a meno di 2.000 token. Tutte le immagini nel pool sono output del modello, in assenza di esempi umani.

Anche il system prompt è stato rielaborato con **GEPA**: un riferimento API di 400 righe induceva il modello a inventare metodi inesistenti; dopo 200 iterazioni contro un giudice a sette esempi, la versione migliore si è rivelata una lista chiusa di otto metodi, senza documentazione. L'autore conclude che riferimenti lunghi in un prompt favoriscono l'allucinazione e che una lista breve e nettamente delimitata vincola meglio il modello.

In conclusione, l'autore scrive che l'RL soggettivo richiede di costruire a mano la reward: troppo specifica, e il modello copia gli esempi; troppo vaga, e non apprende nulla. Non presenta il metodo come un modo migliore di produrre immagini, ma piuttosto come un modo di agire sul prompt, sul modello e sull'artefatto. Un passaggio finale di addestramento e un rapporto tecnico sono annunciati per giugno 2026.

## GrapheDeConnaissance

- Surya Narreddi —publie→ article Training AI to Paint with Code (DOCUMENT, 0.97)
- Surya Narreddi —collabore_avec→ Cameron Franz (PERSONNE, 0.95)
- projet Paint with Code —utilise→ Qwen 3.5 35B (TECHNOLOGIE, 0.93)
- projet Paint with Code —utilise→ GRPO (METHODOLOGIE, 0.97)
- projet Paint with Code —utilise→ p5.brush (TECHNOLOGIE, 0.97)
- jugement par paires —résout→ plateau de récompense (CONCEPT, 0.92)
- jugement par paires —améliore→ grille de récompense (CONCEPT, 0.9)
- jugement par paires —utilise→ pool de références (CONCEPT, 0.93)
- grille de récompense —mesure→ plateau à 0,65 avec neuf signaux, juges corrélés à 0,85-0,95 (MESURE, 0.95)
- grille de récompense —mesure→ code réduit de 13 500 à moins de 2 000 jetons (MESURE, 0.93)
- GEPA —réduit→ hallucination d'API (CONCEPT, 0.9)
- Surya Narreddi —affirme_que→ une documentation d'API longue dans le prompt système favorise l'hallucination (AFFIRMATION, 0.88)
- Surya Narreddi —affirme_que→ le RL sur tâches créatives est un problème de design de la récompense (AFFIRMATION, 0.92)
- projet Paint with Code —s_oppose_à→ RLVR (METHODOLOGIE, 0.75)
- HPSv3 —fait_partie_de→ grille de récompense (CONCEPT, 0.93)

---
Canonical: https://www.thekb.eu/it/fiches/narreddi-training-ai-paint-with-code-2026-03-01/