Ein KI-Agent baut eine Löschfunktion in eine Tabelle ein, prüft sie im Browser und meldet Erfolg. Gesehen hat er nur das Konto, mit dem er auf dem Entwicklungsserver angemeldet war. Matt Rothenberg, der bei Cloudflare das Designsystem betreut, zeigt, wie ein Prinzip von 2015 solche Lücken sichtbar macht.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenVier Schritte, alle erfolgreich: Code geändert, Typprüfung bestanden, Seite mit der Rolle Inhaber geöffnet, Screenshot gemacht. Mit der Rolle Betrachter zeigt dieselbe Tabelle den Löschknopf ebenfalls, obwohl in der Kopfzeile „Nur Lesen“ steht.[1] Rothenberg nennt das Beispiel konstruiert, aber typisch.
Das Wichtigste in Kürze
- KI-Agenten prüfen Oberflächen oft nur in dem Konto, mit dem sie gerade angemeldet sind.
- Schon vier Parameter mit je zwei Werten ergeben 16 Varianten einer Seite.
- Rothenberg rendert alle Zustände einer Seite nebeneinander, nach dem Prinzip Pure UI.
- Ein ausgeblendeter Knopf ersetzt keine Rechteprüfung auf dem Server.
Warum übersieht der Agent den Fehler?

Der Agent prüft nur das Konto, mit dem er angemeldet ist, und der Zustand einer Seite ist in großen React-Anwendungen über viele Stellen verteilt. Die Rolle kommt aus einer Komponente fünf Ebenen höher, der Tarif aus einem Kontext auf oberster Ebene, der Zahlungsstatus aus einem Layout und die Beta-Funktion aus einem Feature-Flag. In Rothenbergs Beispiel kennt die Kopfzeile die Rolle, die Tabelle nicht, und der Prompt nannte nur die Tabelle.[1]
Ein Agent meldet genauso „fertig“, ob er einen Zustand geprüft hat oder sechzehn, während jede generierte Änderung weniger Prüfzeit bekommt.[1] Wie knapp diese Zeit geworden ist, beschreibt unser Beitrag über KI-Code, der die Prüfkapazität der Teams übersteigt.
Was bedeutet Pure UI für Teams mit KI-Agenten?
Pure UI macht jeden Zustand, der die Anzeige bestimmt, zum ausdrücklichen Parameter der Seite, sodass sich alle Varianten nebeneinander rendern lassen. Guillermo Rauch beschrieb 2015 die Oberfläche einer Anwendung als reine Funktion ihres Zustands. Seine Faustregel: Hat ein Team 20 Zustände festgelegt, sollten alle als HTML auf dem Bildschirm zu sehen sein.[2]
Bei Rothenberg erhält die Seite Rolle, Tarif, Zahlungsstatus und Beta-Schalter als Argumente, statt sie tief im Komponentenbaum abzufragen. Auf einer Testseite mit allen 16 Kombinationen fallen die acht Betrachter-Varianten mit Löschknopf sofort auf.[1]
Welche Kombinationen relevant sind, muss das Team selbst festlegen, räumt Rothenberg ein.[1] Mit den Grenzen von Designsystemen hatte er sich schon im August befasst: Viele Teams haben nur eine Komponentenbibliothek, kein Designsystem.
Das Beispiel von Matt Rothenberg
Alle 16 Varianten im Raster
Blau umrandet: der eine Zustand, den der Agent gesehen hat. Orange: acht Betrachter-Varianten, die trotz „Nur Lesen“ einen Löschknopf zeigen. Anordnung vereinfacht nach dem Beispiel des Autors.
Werkzeuge, die Zustände sichtbar machen
Ein Screenshot aus einem einzigen Konto ist kein Test. Lassen Sie sich vom Agenten zeigen, welche Rollen er gesehen hat.
Michael Dobler, Herausgeber Dr. Web
Welche Werkzeuge helfen, und was bleibt Pflicht?
Storybook, Playwright und Vitest machen Zustände sichtbar, die Rechteprüfung auf dem Server bleibt Pflicht. Storybook rendert ausgewählte Zustände einer Komponente, Playwright prüft, ob sie in der laufenden Anwendung erreichbar sind.[1] Das Vitest-Addon von Storybook führt die Beispielzustände aus Storybook als Tests im Browser aus,[3] in einem Modus, den Vitest seit Version 4 als stabil einstuft.[4]
Laut OWASP ist Zugriffskontrolle nur wirksam, wenn sie im Servercode läuft, den Angreifer nicht verändern können. In den OWASP Top 10:2025 steht fehlerhafte Zugriffskontrolle erneut auf Platz 1, in allen getesteten Anwendungen fand sie sich in irgendeiner Form.[5]
Rothenbergs Agent änderte auch die Datei api/functions.ts. Prüfen Sie bei jeder generierten Löschfunktion, ob auch die API die Rolle abfragt.
Artikel 32 der DSGVO verlangt ein Verfahren zur regelmäßigen Überprüfung der Maßnahmen, die die Integrität der Systeme sichern.[6] Ein Raster aller Rollen kann Teil dieser Prüfung sein. Einen anderen Weg geht TesterArmy, das Apps per KI-Agent nach Anweisungen in natürlicher Sprache prüft.
Quellen
6 Quellen anzeigenQuellen ausblenden
- Matt RothenbergPure UI in the Agentic Era
- Guillermo RauchPure UI
- StorybookVitest addon
- VitestVitest 4.0 is out!
- OWASPA01:2025 Broken Access Control
- DSGVOArt. 32 DSGVO, Sicherheit der Verarbeitung
Mehr Newshunger?
- Anthropics Designteam: Wenn Code nicht mehr der Engpass ist
- Spielen Web-Frameworks im Zeitalter der Coding-Agenten noch eine Rolle?
- „Der Plan-Modus ist tot“: Warum Nuanced mit langen KI-Spezifikationen scheiterte
- Open Design System Bench: Wie KI-tauglich ist Ihr Design-System?
- Ein Designsystem ist, was es tut: Ex-USWDS-Entwickler warnt vor shadcn/ui für Behörden
- State of Devs 2026: Die KI schreibt knapp zwei Drittel des Codes, die Motivation der Entwickler sinkt
