Proč je lepší mluvit s AI asistentem v strukturovaných datech než posílat obrázky

Proč jsou screenshoty problém

Představ si to. Je druhá hodina ráno. Hodinu se snažíš vyřešit stejný CSS layout problém. Nakonec uděláš screenshot, vložíš ho do terminálu a napíšeš: "oprav ten posunutej button."

Tvůj AI asistent se na ty pixely podívá, udělá nejlepší interpretaci a — doufejme — ti dá něco užitečného. Ale co se vlastně stalo v tom černém boxu: model spotřeboval tokeny jen na to, aby viděl tvou obrazovku, pak další tokeny na interpretaci, a pak hádal, který z 47 UI prvků na tvém 1440p displeji jsi vlastně myslel.

Hodně hádání na druhou hodinu ráno.

Tokenová matematika, o které se nemluví

Tady je něco, s čím tě dodavatelé AI coding asistentů neuvítají: každý screenshot stojí reálné peníze a ukrajuje z tvého context window. Typický retina screenshot u Claude žere asi 1500+ tokenů jen za vision processing. U GPT-4o jsme zhruba na 1100 tokenech. Gemini 2.5? Přibližně 1550.

A teď to vynásob iterativní sessionou. Ukazuješ agentovi stav obrazovky každých pár promptů — což, když debuguješ komplexní UI problémy jako já, může být 15-20krát za session.

Najednou jsi utratil 22 000 až 31 000 tokenů jen za vision — a agent ještě neudělal nic užitečného. Na 200k context window je to místo, které se ti nevrátí. A pokud běžíš na Opus 4.7 nebo 4.8? Připrav se na zhruba 96 000 vision tokenů za stejnou sessionu.

Alternativa? Strukturovaný JSON popisující tvé UI elementy: jejich pozice, barvy, textový obsah, sémantické role. Ten samý stav obrazovky v JSON? Zhruba 700 tokenů. Přes 20 kol? Zhruba 14 000 tokenů celkem.

To není marginální zlepšení. To je rozdíl mezi tím, jestli dokončíš refactor, nebo tě agent vyhodí uprostřed práce kvůli context window limitu.

Struktura válcuje pixely: Skutečná výhra

Ale tady je to, co je opravdu důležité — a tohle je ta věc, ke které se pořád vracím.

Když vložíš screenshot, agent musí znovu interpretovat všechno každé kolo. Surové pixely nejsou perzistentní reasoning stav. Zeptej se follow-up otázky o šest promptů později a model zase hledí na pixely, znovu interpretuje, znovu hádá.

Strukturovaný JSON mění celou dynamiku. Místo "tady je to, co ty pixely možná reprezentují" dáváš agentovi fakta, na která se může odkazovat a stavět: "Element e4 je button na pozici [0.34, 0.60, 0.32, 0.07], barva #3B82F6, popisek 'Sign up.'"

Agent nemusí hádat, na který input ukazuješ. Schema to už ví. Reasoning je ukotvený ve stejných primitivech, které použije další kolo. Neukazuješ; říkáš.

Proč tohle souvisí s vibe codingem

Tady se to napojuje na širší posun v AI-assisted vývoji — tomu, co někteří nazývají "vibe coding."

Celý point vibe codingu je, že bys měl být schopný popsat, co chceš, rychle iterovat a věřit AI, že zvládne implementační detaily. Ale vibe coding funguje jen když má AI přesné informace o tom, s čím pracuje.

Screenshot je ztrátový formát. Annotace v PNG je jen červený pixely na obdélníku. Ale annotace ve strukturovaném JSON má intent: který element cílí, co se snaží zvýraznit, co po agentovi chceš.

Když eliminuješ hádání, eliminuješ friction. A eliminování friction je vlastně to, o co vibe codingu jde.

Praktický závěr

Nechci říct, že bys nikdy neměl vložit screenshot. Někdy prostě potřebuješ něco rychle ukázat. Ale pokud děláš seriózní iterativní práci s AI coding asistentem — refactoring, debugging, stavění features s komplexním UI — strukturovaná data jsou správná cesta.

Nástroje, které to chápou, se zlepšují. Ty, které ne, brzy zůstanou pozadu. Protože tvůj AI asistent ve skutečnosti při vkládání obrázku nic "nevidí". Interpretuje. A interpretace je drahá, ztrátová a nekonzistentní.

Dej mu radši něco, co může opravdu přečíst.

Co si o tom myslíš? Zaznamenal jsi tlak na context window při dlouhých AI coding sessionách? Napiš komentář — stavíme to v reálném čase a tvůj názor nás zajímá.