„It generated successfully“ und „it matches the design“ sind zwei verschiedene Dinge. So formuliert es Alex Harper in einem Beitrag für Webdesigner Depot, und der Satz trifft einen wunden Punkt der aktuellen KI-gestützten UI-Entwicklung. Werkzeuge, die aus einer Beschreibung eine funktionierende Oberfläche machen, sind inzwischen gut. Der unangenehme Teil kommt danach: Sieht das Gebaute so aus wie das freigegebene Design? Harper beschreibt eine Neuerung von Applitools, die diese Frage automatisiert beantworten soll.
Die passende Analogie stammt aus dem Bauwesen. Ein Bauplan legt fest, wo eine Wand steht, wie hoch die Decke ist und wo die Tür sitzt. Ob die Wand am Ende dort steht, verrät der Plan nicht — dafür muss jemand auf die Baustelle gehen und nachmessen. Diese Rolle hatte bisher der Mensch: Figma im einen Fenster, der Browser im anderen, dazwischen ein ermüdendes Spiel namens Unterschiede finden. Das skaliert nicht, wenn ein Coding-Agent an einem Nachmittag dreißig Bildschirme umbaut.
Schneller Code, der trotzdem falsch aussehen kann
Dass Werkzeuge wie Claude Code, Cursor, GitHub Copilot oder Codex Frontend-Code schnell erzeugen und verändern, ist keine Neuigkeit mehr. Die Geschwindigkeit sagt aber nichts darüber aus, ob das gerenderte Ergebnis dem entspricht, was Designer freigegeben haben. Code kann technisch einwandfrei funktionieren und trotzdem falsch aussehen. Ein Button löst aus, was er auslösen soll, sitzt aber an einer Stelle, die nie jemand vorgesehen hat. Eine Überschrift bricht anders um als geplant, eine Karte wird zu breit, ein responsives Layout zerfällt bei einem bestimmten Viewport.
Nichts davon heißt zwangsläufig, dass der Code defekt ist. Es heißt, dass die Implementierung vom Design abgedriftet ist — jene schleichende Verschiebung, für die sich der Begriff Design Drift eingebürgert hat. Sie entsteht selten durch einen großen Fehler, sondern durch viele kleine Abweichungen, die einzeln harmlos wirken und in Summe das Ergebnis verfremden. Wer regelmäßig KI-generierte Interfaces abnimmt, kennt das Muster: Die Seite sieht auf den ersten Blick richtig aus. Je länger man hinschaut, desto mehr Details stimmen nicht.
Figma Frames als visuelle Baseline: Was die Integration mechanisch tut
Applitools hat eine Integration veröffentlicht, die Figma-Frames direkt als visuelle Baseline verwendet. Entwickler geben eine Figma-Frame-URL an, dieses Design dient dann als Referenz für den automatischen Vergleich. Laut Hersteller passt das System den Test-Viewport an die Abmessungen des ursprünglichen Frames an und markiert visuelle Abweichungen zwischen Entwurf und implementierter Oberfläche. Interessant ist, was wegfällt: kein Figma-Plugin, kein manueller Screenshot-Export, kein Hochladen separater Vergleichsbilder.
In der Praxis war der Abgleich bisher ein diszipliniertes Hin und Her zwischen zwei Fenstern. Man öffnete den Frame, machte einen Screenshot, legte ihn neben die gebaute Seite und suchte nach Verschiebungen. Das funktioniert, solange ein Mensch mit Geduld und gutem Auge daran sitzt — und es versagt, sobald sich Bildschirme, Zustände und Breakpoints vervielfachen. Indem Figma selbst zur Vergleichsquelle wird, wandert die Referenz dorthin, wo sie ohnehin gepflegt wird. Der Entwurf ist kein Dokument mehr, das jemand interpretieren muss, sondern ein Messpunkt.
Der Eyes MCP Server: Wenn der Agent seine eigenen Tests auswertet
Interessanter als die Baseline-Integration ist der zweite Teil der Veröffentlichung. Applitools hat den Eyes MCP Server erweitert, die Schnittstelle, die das eigene System für visuelles Testing mit KI-Coding-Agents verbindet. MCP steht für Model Context Protocol, ein Protokoll, über das ein Agent auf externe Werkzeuge zugreift. Zuvor konnte ein Agent aus dem Chat heraus nur visuelle Tests anlegen. Jetzt kann er sie auch inspizieren, bewerten und auflösen.
Konkret: Der Agent erhält pixelgenaue Informationen über visuelle Unterschiede, zusammen mit Kontext aus dem DOM. Damit lässt sich nachvollziehen, welches Element sich verändert hat, ohne dass ein Entwickler in ein separates Test-Dashboard wechseln muss. Baselines kann der Agent direkt aus dem Chat heraus akzeptieren, verwerfen oder maskieren. In den Release Notes nennt Applitools Claude Code, Cursor, Copilot und Codex, in der Ankündigung vom 15. September wird zusätzlich Cline unter den unterstützten Arbeitsabläufen aufgeführt.
Aus einzelnen Prüfungen wird ein Regelkreis
Setzt man die Teile zusammen, entsteht eine Kette: Figma-Design, Implementierung, visueller Vergleich, erkannte Abweichung, KI-gestützte Untersuchung. Das unterscheidet sich von der naheliegenden Frage „Sieht dieser Screenshot richtig aus?“ Applitools positioniert sein Visual-AI-System als deterministische Validierungsschicht, die den Vergleich durchführt und dem Coding-Agent die visuellen Differenzen und den strukturellen Kontext liefert.
Deterministisch heißt hier: Derselbe Vergleich führt bei gleicher Eingabe zum gleichen Ergebnis. Ein Sprachmodell, das eine Bildschirmaufnahme bewertet, tut das nie mit dieser Verlässlichkeit. Deshalb ist die Aufteilung sinnvoll — der Agent schreibt Code und kann Vorschläge machen, die Prüfinstanz bleibt eine messende Komponente. Der Designer verschwindet dabei nicht aus dem Prozess. Wenn überhaupt, gewinnt das freigegebene Design an Gewicht, weil es das Ziel definiert, gegen das gemessen wird.
Warum ein einzelner Browser-Durchlauf nicht reicht
KI-generierte Websites sehen in Demos gut aus — weil Demos in dem Moment enden, in dem die Seite erscheint. Echte Produkte verhalten sich anders. Schnittstellen werden geändert, Komponenten wiederverwendet, Browser interpretieren CSS unterschiedlich, responsive Layouts kippen, und irgendwann fragt jemand, warum der Bestellbutton auf einem iPhone seltsam aussieht.
Applitools gibt an, visuelle Validierung über verschiedene Browser, Geräte und Betriebssysteme hinweg durchzuführen, während die neue Figma-Anbindung eine direkte Referenz darauf liefert, wie die Oberfläche ursprünglich aussehen sollte. Damit verschiebt sich die Frage. Es geht nicht mehr darum, ob der Agent funktionierenden Code erzeugt hat, sondern darum, ob das, was Nutzer sehen, noch dem ähnelt, was Designer abgenommen haben. Visuelle Regressionstests prüfen hier nicht nur, ob etwas kaputtgegangen ist, sondern ob es sich unbemerkt verschoben hat.
Das Design wird zur verbindlichen Spezifikation
Über die Frage, was KI-Coding-Werkzeuge langfristig für klassische Design-Workflows bedeuten, wird viel spekuliert. Diese Entwicklung deutet eine mögliche Antwort an: Die Figma-Datei wird zur visuellen Spezifikation, die KI-generierte Oberflächen an das ursprüngliche Design bindet. Der Agent baut, der Browser rendert, Applitools vergleicht, das Design liefert die Referenz. Wer so arbeitet, verbringt weniger Zeit damit, auf falsche Innenabstände hinzuweisen, und mehr Zeit damit, zu entscheiden, wie die Oberfläche aussehen soll.
Was heißt das für den Alltag? Wer KI-Coding-Tools einsetzt, sollte den Abnahmeschritt nicht weiter als manuelle Sichtprüfung behandeln, sondern als eigenen, automatisierten Teil der Pipeline. Das setzt voraus, dass Figma-Dateien gepflegt sind — eine veraltete Baseline erzeugt zuverlässig Fehlalarme und untergräbt schnell das Vertrauen in das Verfahren. Es setzt außerdem voraus, dass Teams klären, wer Baselines akzeptieren darf, wenn ein Agent das aus dem Chat heraus kann. Und es verschiebt die Verantwortung: Der Designer wird nicht überflüssig, sondern zur Instanz, die festlegt, was als korrekt gilt. In vielen Organisationen ist KI-gestützte UI-Entwicklung längst Normalität — das Design-Review besteht dort aber noch aus Fensterwechsel.
Quelle: webdesignerdepot.com
