Das Problem mit Screenshots

Stell dir folgendes vor: Es ist 2 Uhr nachts. Du debuggst seit einer Stunde das gleiche CSS-Layout-Problem. Endlich machst du einen Screenshot, fügst ihn in dein Terminal ein und tippst: „Beheb dieses schief ausgerichtete Button-Problem."

Dein KI-Assistent squintet auf die Pixel, interpretiert nach bestem Wissen und – hoffentlich – liefert dir etwas Brauchbares. Aber was da wirklich passiert ist? Das Modell hat Token verbrannt, um deinen Bildschirm zu sehen. Dann hat es weitere Token verbrannt, um zu verstehen, was es da sieht. Und schließlich hat es geraten, welches der 47 UI-Elemente auf deinem 1440p-Display du eigentlich meinst.

Für eine 2-Uhr-nachts-Debugging-Session ist das verdammt viel Raten.

Die Token-Rechnung, die niemand thematisiert

Hier ist etwas, womit die KI-Coding-Assistent-Anbieter nicht werben: Jeder Screenshot, den du einfügst, kostet echtes Geld und belegt Platz in deinem Context Window. Ein typischer Retina-Screenshot verbraucht bei Claude ungefähr 1.500+ Token nur für die Bildverarbeitung. Bei GPT-4o sind es etwa 1.100 Token. Gemini 2.5? Rund 1.550.

Jetzt multipliziere das mit einer iterativen Session. Du zeigst dem Agenten alle paar Prompts den aktuellen Bildschirmzustand – was, wenn du wie ich komplexe UI-Probleme debuggst, vielleicht 15-20 Mal pro Session sein dürfte.

Plötzlich hast du 22.000 bis 31.000 Token nur für Vision verbraten, bevor der Agent überhaupt irgendetwas Nützliches getan hat. Bei einem 200k Context Window ist das Immobilien, die du nicht zurückbekommst. Und wenn du Opus 4.7 oder 4.8 nutzt? Mach dich gefasst auf ungefähr 96.000 Vision-Token über die gleiche Session.

Die Alternative? Strukturiertes JSON, das deine UI-Elemente beschreibt: Positionen, Farben, Textinhalte, semantische Rollen. Der gleiche Bildschirmzustand als JSON? Rund 700 Token. Über eine 20-Prompt-Session: etwa 14.000 Token insgesamt.

Das ist keine marginale Verbesserung. Das ist der Unterschied zwischen „Ich schaffe mein Refactoring" und „Der Context Window ist voll, ich fliege raus."

Struktur schlägt Pixel: Der eigentliche Vorteil

Aber hier ist das, was wirklich zählt – jenseits der Token-Mathematik. Und darüber denke ich immer wieder nach.

Wenn du einen Screenshot einfügst, muss der Agent alles bei jedem einzelnen Turn neu interpretieren. Rohe Pixel sind kein persistenter Reasoning-Zustand. Stellst du eine Follow-up-Frage sechs Prompts später, geht das Modell zurück zu seinem Pixel-Squinten, reinterpretiert, rät erneut.

Strukturiertes JSON verändert die gesamte Dynamik. Statt „hier ist, was die Pixel vielleicht darstellen könnten" gibst du dem Agenten Fakten, auf die er referenzieren und aufbauen kann: „Element e4 ist ein Button an Position [0.34, 0.60, 0.32, 0.07], farblich #3B82F6, beschriftet mit 'Registrieren.'"

Der Agent muss nicht raten, auf welches Input-Feld du zeigst. Das Schema weiß es bereits. Das Reasoning basiert auf den gleichen Grundelementen, die auch im nächsten Turn verwendet werden. Du zeigst nicht; du erzählst.

Warum das für Vibe Coding relevant ist

Hier schließt sich der Kreis zu dem größeren Wandel, der gerade in der KI-gestützten Entwicklung passiert – dem, was manche „Vibe Coding" nennen.

Der ganze Sinn von Vibe Coding ist, dass du beschreiben können solltest, was du willst, schnell iterieren und der KI vertrauen kannst, sich um Implementierungsdetails zu kümmern. Aber Vibe Coding funktioniert nur, wenn die KI genaue Informationen darüber hat, womit sie arbeitet.

Ein Screenshot ist verlustbehaftet. Eine Annotation in einem PNG ist nur ein rotes Rechteck. Aber eine Annotation in strukturiertem JSON enthält Intention: Welches Element sie anvisiert, was sie hervorheben soll, was du den Agenten damit tun lassen willst.

Wenn du das Raten eliminierst, eliminierst du die Reibung. Und Reibung eliminieren – das ist Vibe Coding tatsächlich.

Der praktische Rat

Schau, ich sage nicht, dass du niemals einen Screenshot einfügen solltest. Manchmal willst du einfach schnell etwas zeigen. Aber wenn du ernsthafte iterative Arbeit mit einem KI-Coding-Assistenten machst – Refactoring, Debugging, Features mit komplexer UI – dann ist strukturiertes Data der richtige Weg.

Die Tools, die das verstehen, werden intelligenter. Die, die es nicht tun, werden bald den Anschluss verlieren. Denn am Ende des Tages „sieht" dein KI-Assistent nicht wirklich, wenn du ein Bild einfügst. Er interpretiert. Und Interpretation ist teuer, verlustbehaftet und inkonsistent.

Gib ihm etwas, das er tatsächlich lesen kann.

Was denkst du? Hast du den Context-Window-Druck in langen KI-Coding-Sessions bemerkt? Schreib’s in die Kommentare – wir entwickeln das hier in Echtzeit, und deine Erfahrung zählt.