Åtte tillatte metoder slo 400 linjer API-dokumentasjon i systemprompten

Den første versjonen av systemprompten inneholdt en 400 linjers API-referanse for tegnebiblioteket p5.brush. Modellen svarte med selvsikker, velformatert JavaScript som kalte metoder som ikke eksisterte. Erstatningen ble en streng allowlist på åtte penselmetoder, uten API-dokumentasjon og uten eksempler. Det var den versjonen som først klarte å produsere synlige hibiskusformer i tre av tre genereringer.

Funnet kommer fra Surya Narreddi, designer og creative technologist i Brooklyn, som sammen med Cameron Franz og Alex Wang har trent Qwen 3.5 35B til å lage bilder ved å skrive kode. Gjennomgangen ble delt på Hacker News 23. august og passerte 180 poeng. Premisset er at prompten er det eneste inngrepspunktet du har mot en vanlig bildemodell: vil du endre noe, må du tilbake og prompte på nytt. Når modellen i stedet skriver en p5.brush-skisse, er koden artefaktet, og koden kan redigeres linje for linje.

Treningsløkka har fire steg og kjøres tusenvis av ganger. Modellen får en prompt, for eksempel å tegne en ferskenfarget hibiskus i akvarell, og skriver en komplett skisse. Skissen rendres i et sandkasset Puppeteer-miljø som gir en PNG. Bildet holdes opp mot to tilfeldig trukne referansemalerier fra en håndsortert pool, og en egen dommermodell velger den beste akvarellen. Dommen gjøres om til et belønningssignal, GRPO oppdaterer modellen, og løkka går igjen.

Referansepoolen består av 581 malerier, håndsortert fra 1664 genereringer: 117 i toppkategorien, 266 godkjente og 198 supplementer fra en separat kjøring, lagt til for å dekke farger der de håndsorterte eksemplene var tynne. Alt i poolen er modell-output, siden p5.brush er et nisjeverktøy og teamet ikke fant nok menneskeskapte eksempler. Selve prompt-fiksen ble gjort med GEPA, et bibliotek som utvikler en prompt mot en scoringsfunksjon, i 200 iterasjoner mot en smaksforankret dommer med sju eksempler.

«Lang referansedokumentasjon i en systemprompt fikk modellene til å hallusinere APIer. En kort, meningsbærende allowlist styrer output bedre enn den opprinnelige spesifikasjonen» — Surya Narreddi

Overføringsverdien ligger i belønningsfunksjonen. Forsterkende læring virker når belønningen kan verifiseres: et matteproblem er riktig eller galt, et spill er vunnet eller tapt. Estetisk kvalitet er ingen av delene, så designproblemet blir selve belønningen og kriteriene dommeren får. For strengt, og modellen konvergerer mot kopier av eksemplene du rangerte. For løst, og den lærer ingenting bestemt. Narreddi understreker selv at dette ikke er en bedre måte å lage bilder på, bare en langsommere måte som gir deg noe å redigere.

På Hacker News var det nettopp den delen som traff.

«Jeg likte virkelig videopresentasjonen, særlig delen om at bildegeneratorer umiddelbart låser oss inn i en bestemt kontekst og reduserer oss fra skapende til tilskuere» — mskogly, kommentar på Hacker News

Hva bør du gjøre?

1. Mål API-referansen i din egen systemprompt. Har du limt inn hele dokumentasjonen for et bibliotek, bytt den mot en liste over funksjonene modellen faktisk skal bruke, og sammenlign treffraten før og etter.
2. Skill det som kan verifiseres fra det som ikke kan. Kode som kjører eller ikke kjører gir deg et gratis belønningssignal, mens smak og tone må forankres i eksempler du selv har rangert.
3. Be om kode når artefaktet skal kunne endres. En skisse kan redigeres på linjenivå, mens en PNG fra en bildemodell bare kan promptes på nytt.