Deine KI-generierte UI braucht einen Playtester, keinen Screenshot-Review

KI kann heute kleine Games, Demos, Rechner, Dashboards, Landing Pages, Onboarding-Flows und interne Tools in Minuten erzeugen.

Das ist nützlich.

Es erzeugt aber ein neues Testproblem: Das Artefakt sieht oft fertig aus, bevor es sich korrekt verhält.

Ein Screenshot kann lügen. Ein sauberer Component Tree kann lügen. Ein erfolgreicher Build kann lügen. Auch eine selbstbewusste Agenten-Zusammenfassung kann lügen.

Die eigentliche Frage ist nicht:

Sieht die UI okay aus?

Die bessere Frage ist:

Kann ein naiver User den erwarteten Interaktionspfad wirklich abschließen?

Dafür ist eine GUI-Playtester-Loop nützlich.

Statt denselben Coding-Agenten seine eigene UI bewerten zu lassen, schickst du einen separaten Browser-Agenten als Playtester in die App. Er klickt, tippt, wartet, beobachtet sichtbare States, speichert Screenshots, loggt jede Aktion und reportet Fehler mit Reproduction Steps.

Die stärkste Version dieser Loop nutzt einen Webwright-artigen Ansatz: Der Agent klickt nicht nur herum und gibt eine Meinung ab. Er schreibt ein rerunnable Playwright Script, speichert Screenshots und Logs und macht aus Fehlern Regression Tests.

Die GUI-Playtester-Loop

vom generierten Interface zu reproduzierbarer Interaktions-Evidence

1. 01
   KI baut UI
2. 02
   Expected Behaviors definieren
3. 03
   Webwright playtestet im Browser
4. 04
   Screenshots + Logs
5. 05
   Evidence-backed Bug Report
6. 06
   Nur beobachtete Fehler fixen
7. 07
   Als Regression rerunnen

Der praktische Shift:

Frag KI nicht, ob das Interface funktioniert. Lass KI Browser-Evidence erzeugen, die zeigt, was passiert ist.

Warum Screenshot-Review zu schwach ist

Der normale KI-UI-Workflow ist gefährlich flach:

App generieren → Preview öffnen → Screenshot anschauen → shippen oder tweaken

Das findet visuellen Unsinn. Es findet keine Interaktionsfehler.

Ein Memory-Spiel kann Karten rendern, aber falsche Paare nie zurückdrehen. Ein Rechner kann Buttons zeigen, aber Zahlen falsch verketten. Ein Formular kann vollständig aussehen, aber Daten nach Validation verlieren. Ein Dashboard kann Charts zeigen, aber Filter nicht aktualisieren. Ein Onboarding-Flow kann polished aussehen, aber User in Schritt drei festhalten.

Diese Fehler sieht man nicht in einem statischen Screenshot.

Sie leben in Sequenzen:

Start klicken → Karte A klicken → Karte B klicken → warten → Score ändert sich → State resetet

Das nützliche Testartefakt ist deshalb nicht ein Screenshot. Es ist ein Interaction Trace.

Screenshot Review vs. Playtester Evidence

Screenshot Review

• Prüft, ob die UI gerendert aussieht.
• Meist einmalig und subjektiv.
• Findet Layout-Probleme und offensichtliche visuelle Fehler.
• Endet oft mit “looks good”.

GUI-Playtester-Loop

• Prüft, ob erwartete Nutzerverhalten wirklich funktionieren.
• Erzeugt rerunnable Playwright Scripts, Logs und Screenshots.
• Findet kaputte Flows, fehlende State Transitions, tote Buttons und Regressionen.
• Endet mit Pass/Fail-Evidence und Reproduction Steps.

Was Webwright hinzufügt

Microsoft Webwright ist hier spannend, weil es Browser-Arbeit als Code-as-Action behandelt.

Statt das Modell in einzelne Browser-Aktionen einzusperren, gibt Webwright dem Coding-Modell Terminal und Browser. Der Agent schreibt Scripts, führt sie aus, inspiziert Screenshots wenn nötig und hält das dauerhafte Artefakt im Workspace: Code, Screenshots und Logs.

Für Tests von generierten UIs ist das genau die richtige Form.

Ein normaler Browser-Agent macht vielleicht:

App öffnen → herumklicken → sagen, dass es funktioniert

Ein Webwright-artiger Playtester macht:

Playwright Script schreiben
→ Interaktionspfad ausführen
→ Screenshot pro kritischem Schritt speichern
→ Action Log speichern
→ Pass/Fail pro Expected Behavior reporten
→ dasselbe Script nach dem Fix erneut ausführen

Damit wird Playtesting von einer Meinung zu einem wiederverwendbaren Artefakt.

5-8

Expected Behaviors reichen für einen ersten Playtest-Pass

1

rerunnable Script wird zum dauerhaften Regression-Artefakt

0

Code-Vorschläge vom Playtester, bevor Interaktions-Evidence vollständig ist

Der Workflow

Nutze das für KI-generierte interaktive Artefakte:

• Mini-Games
• Educational Demos
• generierte Web-Tools
• Formular-Flows
• Onboarding-Flows
• Dashboards
• Rechner
• interne Admin-Screens
• Prototypen aus Vibe-Coding-Sessions

Die Loop hat drei Rollen.

1. Builder

Der Builder erzeugt das Artefakt.

Das kann ein Mensch sein, ein Coding Agent, Claude Code, Codex, Cursor, OpenClaw, v0, Lovable, Replit oder jedes System, das eine interaktive Webseite produziert.

Der Job des Builders ist Implementierung. Nicht Bewertung.

Builder Prompt:

Build the interactive artifact described below.
Keep the implementation simple.
Do not write tests yet.
At the end, provide:
- local URL or run command
- known assumptions
- expected user behaviors

Der wichtige Output ist nicht nur die App. Es ist die Liste erwarteter Verhalten.

Für ein Memory-Spiel:

Expected behaviors:
1. Start button begins the game.
2. Cards are hidden before the game starts.
3. Cards flip when clicked.
4. Matching pair stays visible.
5. Non-matching pair flips back after a short delay.
6. Score increments on match.
7. Game-over state appears after all pairs are matched.
8. Restart resets the board and score.

2. Playtester

Der Playtester ist vom Builder getrennt.

Sein Job ist nicht, Code zu verbessern. Sein Job ist, die UI wie ein User zu beobachten und Evidence zu erzeugen.

Playtester Prompt:

You are the GUI playtester, not the builder.

Open this app:
http://localhost:3000

Create a rerunnable Playwright script that tests these expected behaviors:
[PASTE EXPECTED BEHAVIORS]

For each behavior, record:
- action taken
- visible result
- pass/fail
- screenshot path
- reproduction steps
- smallest user-facing bug statement

Rules:
- Do not suggest code fixes.
- Do not redesign the app.
- Do not mark a behavior as passed without visible evidence.
- Save screenshots for every critical state.
- Save an action log with one line per meaningful interaction.

Eine Webwright-artige Umsetzung sollte ungefähr so einen Workspace erzeugen:

playtest-runs/memory-game/
├── plan.md
├── final_script.py
└── final_runs/
    └── run_1/
        ├── final_script.py
        ├── final_script_log.txt
        └── screenshots/
            ├── final_execution_01_start_screen.png
            ├── final_execution_02_cards_visible.png
            ├── final_execution_03_match_pair.png
            ├── final_execution_04_wrong_pair.png
            └── final_execution_05_game_over.png

Die exakten Ordner sind egal. Der Contract zählt.

Du willst:

Der Playtester Evidence Contract

• Einen Plan mit Expected Behaviors und kritischen States.
• Ein rerunnable Playwright Script, nicht nur ein Chat Transcript.
• Screenshots für States, die Pass/Fail beweisen.
• Ein Action Log mit der exakten Interaktionssequenz.
• Einen Bug Report in user-facing Sprache.
• Einen sauberen Rerun nach dem Fix, der zeigt, dass der Fehler weg ist.

3. Repair Agent

Erst wenn der Playtester Evidence hat, sollte Builder oder Repair Agent Code ändern.

Repair Prompt:

Fix only the failures reported by the GUI playtester.

Use these artifacts as evidence:
- final_script_log.txt
- screenshots/
- pass/fail report

Rules:
- Do not redesign unrelated behavior.
- Do not change passing behaviors unless necessary for the failing case.
- Preserve the playtester script.
- After the fix, rerun the same playtest script.
- Report which failures are now passing and cite the new evidence.

Das verhindert den typischen Agentenfehler, bei dem aus einem Repair plötzlich ein Redesign wird.

Der Bug war: falsche Paare drehen sich nicht zurück.

Der Fix sollte nicht werden: Kartensystem neu bauen, Scoring ändern, Animationen hinzufügen, UI-Library wechseln und dabei Restart kaputtmachen.

Evidence begrenzt Repair.

Beispiel für einen guten Bug Report

Ein guter Playtester Report ist langweilig und konkret.

FAIL: Non-matching cards flip back

Expected:
When the user clicks two non-matching cards, both cards should flip back after a short delay.

Observed:
The two non-matching cards stayed visible indefinitely.

Actions:
1. Opened http://localhost:3000
2. Clicked Start
3. Clicked card 1
4. Clicked card 4
5. Waited 1500ms

Evidence:
- final_runs/run_1/screenshots/final_execution_04_wrong_pair.png
- final_script_log.txt, steps 2-5

Reproduction:
Start → click card 1 → click card 4 → wait 1500ms

Smallest user-facing bug statement:
Wrong memory-game pairs do not flip back, so the game becomes too easy and the board state is wrong.

Das ist viel besser als:

The game mostly works but there might be an issue with cards.

Es geht nicht nur darum, den Bug zu finden. Es geht darum, ihn reproduzierbar zu machen.

Mach aus dem Playtest einen Regression Test

Das Beste an der Webwright-artigen Loop: Das finale Script kann die aktuelle Session überleben.

Nach dem Repair führst du dasselbe Script erneut aus.

python final_script.py

Wenn der Bug gefixt ist, behalte das Script als leichten Regression Test für dieses Artefakt.

Für Prototypen reicht das oft. Für Produktionsapps kannst du die stabilen Teile in deine normale Playwright-Test-Suite übernehmen.

Eine nützliche Trennung:

Exploratory playtester script:
- schnell generiert
- evidence-heavy
- überall Screenshots
- gut zum Finden kaputter Flows

Production Playwright test:
- aufgeräumt
- deterministische Selektoren
- läuft in CI
- assertet stabiles Verhalten

Verwechsle die beiden nicht.

Das Playtester Script darf etwas messy sein, weil es Verhalten entdeckt. Der Production Test sollte stabil sein, weil er Verhalten erzwingt.

Wo das scheitert

GUI-Playtester-Loops sind nützlich, aber nicht magisch.

Ein Browser-Agent kann subjektive Qualität verpassen. Er kann komisch klicken. Er kann zu stark auf Textlabels overfitten. Er kann einen Flow bestehen, der sich für Menschen schlecht anfühlt. Er kann scheitern, weil Selektoren instabil sind — nicht weil das Produkt kaputt ist.

Nutze die Loop also für das, worin sie stark ist: sichtbare Behavior Evidence.

Nutze GUI-Playtester für den richtigen Job

Gut für

• ✓ Prüfen, ob erwartete Click/Type/Play-Pfade funktionieren.
• ✓ Dead Buttons, fehlende States, kaputte Formular-Flows und offensichtliche Regressionen finden.
• ✓ Reproduzierbare Bug Reports aus KI-generierten Prototypen erzeugen.
• ✓ Einen ersten Draft für Playwright Regression Coverage generieren.

Nicht nutzen als

• × Ersatz für menschlichen Product Taste.
• × vollständiges Accessibility Audit.
• × Beweis, dass ein Game Spaß macht oder ein Workflow angenehm ist.
• × Freifahrtschein zum Shippen ohne Human Review bei riskanten Flows.

Die kleine Version für Solo Builder

Wenn du heute mit KI baust, starte klein.

Schreibe nach jeder generierten UI fünf Expected Behaviors:

1. What should happen first?
2. What should change after the main click?
3. What should happen on invalid input?
4. What should happen after success?
5. What should reset or persist?

Dann bitte einen browserfähigen Coding Agent um ein rerunnable Script und Evidence.

Minimal Prompt:

You are a GUI playtester.
Open http://localhost:3000.
Test these five expected behaviors.
Write a rerunnable Playwright script.
For every behavior, save a screenshot, log the action, and report pass/fail.
Do not suggest code fixes until the evidence is complete.

Das allein findet überraschend viele “sah fertig aus”-Bugs.

Warum dieses Muster wichtig ist

KI macht interaktive Artefakte billig.

Dadurch wandert der Engpass von Creation zu Verification.

Der gewinnende Workflow ist nicht:

mehr UI schneller generieren

Sondern:

UI generieren
→ wie ein User playtesten
→ Evidence speichern
→ nur bewiesene Fehler reparieren
→ denselben Pfad rerunnen

Das ist dieselbe größere Lektion, die gerade überall in AI Engineering auftaucht: Bewerte nicht nur das Modell. Bewerte die Schleife um das Modell.

Für UI-Arbeit braucht diese Schleife einen Playtester.

Keinen Screenshot Review.

Keinen Self-Check vom Builder.

Einen separaten Browser-Agenten, der Script, Screenshots, Logs und reproduzierbare Bugs hinterlässt.

So werden KI-generierte Interfaces weniger Demo und mehr Software.

Quellen

• Webwright by Microsoft — ein Code-as-Action Browser-Agent-Ansatz mit rerunnable Scripts, Screenshots und Logs.
• Webwright: A Terminal Is All You Need For Web Agents — Microsoft Research Artikel zur Webwright-Architektur.
• GUI Agents for Continual Game Generation — verwandtes Research-Signal: Generation als Loop, in der GUI Agents generierte Spiele interaktiv testen und Beobachtungen zurück in Verbesserung geben.