Problemet med skjermbilder

La meg male et bilde for deg. Klokken er 02:00. Du har fiklet med den samme CSS-layouten i en time. Endelig tar du et skjermbilde, limer det inn i terminalen og skriver: «fiks denne skjevstilte knappen».

AI-assistenten din gransker pikslene, gjør sitt beste forsøk på å tolke dem, og – forhåpentligvis – gir deg noe nyttig. Men her er hva som egentlig skjedde i den svarte boksen: modellen brukte tokens bare på å se skjermen din, deretter flere tokens på å tolke hva den så, og deretter gjette på hvilket av de 47 UI-elementene på din 1440p-skjerm du egentlig mente.

Det er mye gjetting for en 02:00-feilsøkingsøkt.

Token-regnskapet ingen snakker om

Her er noe AI-kodingassistenter-leverandørene ikke starter med: hvert skjermbilde du limer inn koster ekte penger og spiser opp kontekstvinduet ditt. Et typisk retina-skjermbilde på Claude bruker rundt 1 500+ tokens bare for bildebehandling. På GPT-4o snakker vi om rundt 1 100 tokens. Gemini 2.5? Omtrent 1 550.

Nå multipliser det med en iterativ økt. Du viser agenten skjermtilstanden din hvert par prompts – noe som, hvis du er som meg som fikler med komplekse UI-problemer, kan være 15-20 ganger per økt.

Plutselig har du brukt 22 000 til 31 000 tokens bare på bilder før agenten har gjort noe som helst nyttig. På et 200k-kontekstvindu er det plass du ikke får tilbake. Og hvis du kjører Opus 4.7 eller 4.8? Forbered deg på rundt 96 000 visjonstokens i løpet av samme økt.

Alternativet? Strukturert JSON som beskriver UI-elementene dine: posisjoner, farger, tekstinnhold og semantiske roller. Samme skjermtilstand i JSON? Rundt 700 tokens. Over en 20-prompt-økt: omtrent 14 000 tokens totalt.

Det er ikke en marginal forbedring. Det er forskjellen mellom å fullføre refaktoreringen din og å bli kastet ut av konteksten midt i arbeidet.

Struktur slår piksler: Den virkelige gevinsten

Men her er hva som egentlig betyr noe utover token-regnskapet – og dette er delen jeg stadig kommer tilbake til.

Når du limer inn et skjermbilde, må agenten tolke alt på nytt hver eneste gang. Rå piksler er ikke vedvarende resonnementstilstand. Spør et oppfølgingsspørsmål seks prompts senere, og modellen går tilbake til å granske piksler, tolke på nytt, gjette på nytt.

Strrukturert JSON endrer hele dynamikken. I stedet for «her er hva pikslene kanskje representerer», gir du agenten fakta den kan referere til og bygge videre på: «Element e4 er en knapp på posisjon [0.34, 0.60, 0.32, 0.07], farget #3B82F6, merket 'Registrer deg'.»

Agenten trenger ikke gjette hvilken input du peker på. Skjemaet vet det allerede. Resonnementet er forankret i de samme primitivene som neste runde vil bruke. Du viser ikke; du forteller.

Hvorfor dette betyr noe for Vibe Coding

Her er hvor dette kobles til det større skiftet som skjer i AI-assistert utvikling – det noen kaller «vibe coding.»

Hele poenget med vibe coding er at du skal kunne beskrive hva du vil, iterere raskt, og stole på at AI-en håndterer implementasjonsdetaljene. Men vibe coding fungerer bare når AI-en har nøyaktig informasjon om hva den jobber med.

Et skjermbilde er tapsfullt. En annotasjon i en PNG er bare røde piksler på et rektangel. Men en annotasjon i strukturert JSON har intensjon: hvilket element den retter seg mot, hva den prøver å fremheve, hva du ber agenten gjøre med det.

Når du fjerner gjettingen, fjerner du friksjonen. Og å fjerne friksjon er det vibe coding egentlig handler om.

Det praktiske rådet

Altså, jeg sier ikke at du aldri skal lime inn et skjermbilde. Noen ganger trenger du bare å vise noe fort. Men hvis du driver seriøs iterativt arbeid med en AI-kodingsassistent – refaktorering, feilsøking, bygging av funksjoner med komplekst UI – er strukturert data veien å gå.

Verktøyene som forstår dette blir smartere. De som ikke gjør det, er i ferd med å sakke akterut. For til syvende og sist: AI-assistenten din ser egentlig ikke når du limer inn et bilde. Den tolker. Og tolkning er dyrt, tapsfullt og inkonsistent.

Gi den heller noe den faktisk kan lese.