Wie steuert Jev Browser und baut Oberflächen, ohne Text zu erzeugen? Browser Use und json-render im Detail

Wenn ein KI-System einen Browser bedienen soll, liegt ein Ansatz besonders nahe: Man übergibt einem allgemeinen großen Modell einen Screenshot oder den DOM, lässt es die Seite analysieren und den nächsten Schritt planen und anschließend eine Klickposition, einen Selektor oder einen Tool-Aufruf erzeugen.

Beim Aufbau einer Benutzeroberfläche ist das Muster oft ähnlich. Der Nutzer beschreibt die gewünschte Oberfläche, das Modell erzeugt direkt JSON, JSX oder Frontend-Code, und das System versucht anschließend, das Ergebnis zu parsen, zu validieren und zu rendern.

Browser Use mit Jev Ultrafast und das Jev-Experiment von json-render wählen einen anderen Weg:

Der Code begrenzt zuerst, was das Modell tun darf, auf eine endliche Menge; Jev wählt nur innerhalb dieser Menge aus.

Bei Browser Use besteht diese Menge aus den ausführbaren Aktionen und bedienbaren Elementen der aktuellen Webseite. Bei json-render besteht sie aus Komponenten, Eigenschaftskonfigurationen, Datenbindungen und Layoutpositionen, die die Anwendung im Voraus vorbereitet hat.

Jev muss weder einen vollständigen Ablaufplan schreiben noch einen kompletten UI-JSON-Baum erzeugen. Es beantwortet lediglich Fragen wie:

• Soll der nächste Schritt ein Klick, eine Texteingabe, Scrollen oder Warten sein?
• Welches Element auf der aktuellen Seite soll bedient werden?
• Welche Komponenten sollen in der Oberfläche erscheinen?
• In welchem übergeordneten Container, Slot und an welcher Position soll eine Komponente platziert werden?

Die beiden Beispiele zeigen nicht, dass „ein Modell ohne Texterzeugung trotzdem alles kann“. Sie zeigen eine andere Softwarearchitektur: Eine offene Generierungsaufgabe wird in eine Folge begrenzter, überprüfbarer Entscheidungen umgewandelt.

Was Jev hier tatsächlich tut

Jev ist ein von TypeSafe AI veröffentlichtes System-One-Modell. Es erhält einen state sowie eine vom Entwickler definierte Menge typisierter Fragen und liefert strukturierte Ergebnisse wie Choice, Score oder Noul zurück – statt eines langen Textes für menschliche Leser.

Man kann es als Entscheidungsfunktion mit probabilistischen Ausgaben verstehen:

Aktueller Zustand
   ↓
Der Entwickler erstellt eine endliche Kandidatenmenge
   ↓
Jev wählt, bewertet oder prüft
   ↓
Gewöhnlicher Code validiert das Ergebnis
   ↓
Eine Aktion wird ausgeführt oder die Oberfläche gerendert

Dabei gilt:

• Choice: wählt eine Option aus einer vorgegebenen Menge;
• Score: ordnet das Ergebnis auf den vom Entwickler festgelegten geordneten Stufen ein;
• Noul: gibt die Wahrscheinlichkeit zurück, dass eine bestimmte Aussage wahr ist.

Entscheidend ist nicht das Antwortformat, sondern die Aufgabenteilung. Jev erzeugt weder frei Seitentexte noch Browser-Selektoren, JavaScript oder vollständiges JSON. Zustand, Kontrollfluss, Berechtigungen und Ausführung bleiben in der Hand des Codes. TypeSafe beschreibt dieses Muster als „unstrukturierter Zustand hinein, typisierte probabilistische Entscheidungen hinaus“. (typesafe.ai)

Im Folgenden sehen wir uns an, wie Browser Use und json-render dieses Muster in realen Systemen umsetzen.

---

Browser Use: Die Webseite zuerst in einen endlichen Aktionsraum verwandeln

Das Projekt jev-ultrafast von Browser Use demonstriert einen Browser-Agenten: Der Nutzer formuliert ein Ziel in natürlicher Sprache, das Programm liest die aktuelle Seite, Jev wählt die nächste Aktion und Browser-Code führt sie aus.

In der öffentlichen Demonstration soll auf Google Flights ein einfacher Flug von Zürich nach London gesucht werden. Laut Projektaufzeichnung dauert die Aufgabe ungefähr 7,1 Sekunden, einschließlich Modellaufrufen, Texterzeugung, Browserausführung, Seitenladen und Wiederholungen aufgrund veralteter Entscheidungen. Das ist dennoch nur eine Aufgabe in einer bestimmten Browserkonfiguration und kein allgemeiner Zuverlässigkeitsbenchmark für beliebige Webseiten. (github.com)

Schritt 1: Der Code liest die Seite; Jev „betrachtet“ nicht einfach einen Screenshot

In jedem Entscheidungszyklus liest der Browser-Code zunächst die aktuell sichtbaren Steuerelemente und Texte und erstellt daraus eine nummerierte Elementtabelle.

Vereinfacht könnte sie so aussehen:

[1] button     Ticketart ändern · Hin- und Rückflug
[2] combobox   Von wo?          · San Francisco
[3] combobox   Wohin?           · leer
[4] textbox    Abflug           · leer
[5] button     Suchen

Die Tabelle enthält Elementtyp, Bezeichnung, aktuellen Wert und Index. Das Programm behält außerdem den echten DOM-Knoten zu jedem Index, damit das Ziel vor der Ausführung erneut aufgelöst werden kann.

Jev betrachtet in diesem Beispiel also nicht direkt einen Screenshot und rät, dass sich eine Schaltfläche an den Koordinaten (482, 316) befindet. Screenshots dienen vor allem der Demonstration und menschlichen Kontrolle. Die tatsächliche Entscheidung wird aus dem strukturierten, aus dem DOM extrahierten Zustand abgeleitet. Das Projekt erklärt außerdem, dass die Beschriftungen auf der Seite erst beim Rendern des Screenshots hinzugefügt werden und den Browser nicht steuern. (github.com)

Dieser Unterschied ist wichtig.

Wenn ein Modell Koordinaten oder einen CSS Selector frei erzeugt, kann es Folgendes zurückgeben:

• einen Selektor, der auf der Seite gar nicht existiert;
• eine bereits veraltete Elementposition;
• ein verdecktes oder nicht anklickbares Steuerelement;
• JavaScript, das beliebiges Verhalten ausführen könnte.

Jev Ultrafast beschränkt das Modell stattdessen auf die Indizes von Elementen, die das Programm gerade beobachtet hat.

Schritt 2: Jev wählt Aktion und Zielelement

Das Projekt stellt folgende Aktionen bereit:

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

Abhängig vom aktuellen Seitenzustand bietet das Programm nur Aktionen und kompatible Ziele an, die in diesem Moment tatsächlich verfügbar sind.

Zum Beispiel:

• Gibt es auf der Seite kein Dropdown, wird kein Ziel für SELECT angeboten.
• Gibt es drei Textfelder, sind Texteingabeziele auf diese drei Elemente beschränkt.
• Gibt es zehn anklickbare Elemente, sind Klickziele auf diese zehn Elemente beschränkt.

Eine Entscheidung lässt sich so vereinfachen:

Frage 1: Was soll die nächste Aktion sein?
Kandidaten: CLICK / TYPE_TEXT / SELECT / WAIT / DONE

Frage 2: Wenn die Aktion CLICK ist, welches Element soll angeklickt werden?
Kandidaten: [1] / [5] / [8] / [11]

Frage 3: Wenn die Aktion TYPE_TEXT ist, welches Element soll den Text erhalten?
Kandidaten: [2] / [3] / [4]

Diese Fragen können innerhalb einer Anfrage parallel ausgewertet werden. Ausgeführt wird nur das Ziel, das mit der ausgewählten Aktion kompatibel ist. Wählt Jev CLICK, liest das Programm nur click_target; ein für TYPE_TEXT im Voraus berechnetes Ziel wird nicht ausgeführt.

Das Projekt bezeichnet dies als dynamischen, indexierten Aktionsraum. Dadurch sinkt die Zahl serieller Modellaufrufe pro Schritt, und das Modell muss keine Operationsparameter frei erzeugen. (github.com)

Schritt 3: Ein generatives Modell nur dann aufrufen, wenn Text geschrieben werden muss

Jev kann entscheiden, dass jetzt Text in das Abflugfeld eingegeben werden soll, erzeugt den einzugebenden Text aber nicht selbst.

Wenn die Aktion TYPE_TEXT lautet, ruft das System ein kleines Textgenerierungsmodell auf, das aus der aktuellen Aufgabe und dem Zielfeld den Eingabewert erzeugt. Zum Beispiel:

{
  "text": "Zürich"
}

Auch dieses Ergebnis muss erst als sehr kleines JSON-Objekt geparst werden, bevor der Browser es eingeben darf.

Der Browser-Agent kombiniert damit zwei unterschiedliche Fähigkeiten:

Aufgabe	Verantwortliche Komponente
Entscheiden, ob der nächste Schritt Klicken, Eingeben, Auswählen oder Warten ist	Jev
Auswählen, welches Element auf der Seite bedient wird	Jev
Den einzugebenden natürlichsprachlichen Text erzeugen	Kleines generatives Modell
DOM und Seitenzustand lesen	Browser-Code
Klicken, eingeben und auswählen	Browser-Code
Prüfen, ob das Ziel tatsächlich erreicht wurde	Unabhängiger Validierungscode

Deshalb bedeutet „Jev steuert den Browser“ nicht, dass Jev die gesamte Browseraufgabe selbstständig erledigt.

Präziser ist: Jev ist der Aktionsselektor innerhalb der Browser-Schleife.

Schritt 4: Der Code prüft die Seite vor der Ausführung erneut

Nach der Modellauswahl klickt das Programm nicht sofort blind auf das Element.

Vor der Ausführung prüft Jev Ultrafast außerdem:

• ob die aktuelle Seite noch dieselbe ist, die das Modell gesehen hat;
• ob der betreffende DOM-Knoten noch existiert;
• ob das Element von anderem Inhalt überdeckt wird;
• ob seine aktuelle Geometrie noch gültig ist;
• ob Formularwert und unmittelbarer Kontext noch mit dem Snapshot übereinstimmen;
• ob sich die Eingabe für die Textgenerierungsanfrage verändert hat.

Ändert sich die Seite, bevor die Modellantwort eintrifft, kann die vorherige Entscheidung bereits ungültig sein. Das Programm behandelt sie als veraltet, statt weiter mit einem alten Element zu interagieren.

Das Projekt beschränkt ausdrücklich, was aus der Modellausgabe werden darf: Sie wird nicht direkt in einen CSS Selector, Bildschirmkoordinaten, einen Shell-Befehl oder ausführbares JavaScript umgewandelt. Jedes ausgeführte Ziel muss erneut auf einen echten, zuvor beobachteten DOM-Knoten aufgelöst werden. (github.com)

Dieser Code ist nicht „intelligent“, entscheidet aber darüber, ob das System zuverlässig ist.

Das Sieben-Sekunden-Ergebnis lässt sich nicht Jev allein zuschreiben

Bei sechs abwechselnden Durchläufen schlossen beide Implementierungen die Aufgabe jeweils dreimal ab. Die mediane Aufgabenzeit sank laut Projekt von ungefähr 9,450 Sekunden auf 7,092 Sekunden, also um etwa 25 %; die Zahl der Browserprotokoll-Aufrufe ging von 1.092 auf 101 zurück. Der Autor betont zugleich, dass es sich lediglich um drei Durchläufe je Implementierung mit derselben Aufgabe und Browserkonfiguration handelte, nicht um einen allgemeinen Zuverlässigkeitstest. (github.com)

Der Leistungsgewinn stammt daher nicht nur aus der Modellgeschwindigkeit, sondern aus der Browserimplementierung insgesamt:

• sichtbare Steuerelemente werden in einem Durchgang gelesen;
• Browserprotokoll-Roundtrips werden reduziert;
• Fragen nach Aktion und Ziel werden in derselben Entscheidung zusammengefasst;
• das generative Modell wird nur bei notwendiger Texteingabe aufgerufen;
• nach der Ausführung wird nur auf erforderliche Seitenänderungen gewartet;
• irrelevanter Seitentext wird nicht in den Modellkontext aufgenommen.

Es wäre deshalb falsch zu behaupten, der bloße Austausch eines Modells gegen Jev lasse jeden Browser-Agenten in sieben Sekunden fertig werden.

Der aktuelle MVP unterstützt außerdem shadow DOM, iframe, canvas, Datei-Uploads, Popup-Tabs, verschachteltes Scrollen und beliebige Tastatur-Widgets noch nicht vollständig. Selbst wenn das Modell DONE auswählt, verlangt das System eine unabhängige Prüfung, ob die Aufgabe wirklich abgeschlossen wurde. (github.com)

---

json-render: Jev Komponenten wählen lassen, statt das gesamte Seiten-JSON zu erzeugen

json-render behandelt ein anderes Problem: Wie lässt sich aus einer natürlichsprachlichen Anforderung eine direkt renderbare Oberfläche zusammensetzen?

Traditionelle generative UI-Systeme lassen das Modell häufig direkt Folgendes ausgeben:

• React- oder Vue-Code;
• einen vollständigen UI-Baum als JSON;
• CSS- und Layout-Eigenschaften;
• Event-Handler-Logik;
• Datenbindungskonfigurationen.

Das ist flexibel, gibt dem Modell aber auch einen sehr großen Ausgaberaum. Es kann Komponentennamen falsch schreiben, nicht vorhandene Eigenschaften erzeugen, auf eine nicht registrierte Aktion verweisen oder nicht parsebares JSON ausgeben.

Das Jev-Experiment in json-render formuliert die Aufgabe neu:

Die Anwendung bereitet zunächst eine Sammlung gültiger Komponenteninstanzen vor, und Jev entscheidet nur, welche davon verwendet und wie sie kombiniert werden.

Diese Funktion ist weiterhin als experimentell gekennzeichnet. experimental_composeSpec und experimental_createEvaluator wurden noch nicht als stabile APIs veröffentlicht; Namen und Verhalten können sich zwischen Versionen ändern. Die Dokumentation empfiehlt, eine exakte Version festzuschreiben und das Changelog zu prüfen. (json-render.dev)

Die Anwendung stellt zuerst Komponentenkatalog und Kandidaten bereit

Angenommen, der Nutzer verlangt:

Erstelle ein Vertriebs-Dashboard mit einer Bestelltabelle oben, darunter einer Reihe von Kennzahlen für Umsatz, Bestellanzahl und Neukunden und abschließend einem Diagramm des wöchentlichen Umsatzes.

Die Anwendung gibt diesen Satz nicht direkt an Jev weiter und fordert es auf, frei UI-JSON zu schreiben.

Stattdessen stellt sie zunächst Kandidaten bereit:

Dashboard
OrdersTable
MetricRow
RevenueMetric
OrdersMetric
NewCustomersMetric
RevenueBarGraph

Jeder Kandidat ist nicht nur ein Name, sondern eine von der Anwendung konfigurierte Komponenteninstanz. Sie kann enthalten:

• Komponententyp;
• feste Eigenschaften;
• verfügbare Layoutkonfiguration;
• Zustandsbindungen;
• Datenbindungen;
• erlaubte Aktionen;
• eine für das Modell bestimmte Kandidatenbeschreibung.

Eine Schaltfläche kann zum Beispiel vorab so definiert werden:

Komponente: Button
Text: Speichern
Aktion: savePreferences
Argumente: aktuellen Zustand von /name lesen

Jev kann entscheiden, ob diese Schaltfläche verwendet wird, kann aber keine nicht registrierte Aktion wie deleteAllUsers erfinden.

Die json-render-Dokumentation betont, dass die Plattform die verfügbaren Fähigkeiten und das Designsystem kontrolliert. Jev kann nur aus den Komponenten, Konfigurationen und Aktionsbindungen wählen, die die Anwendung bereitstellt; fehlende Texte, Daten oder Komponenten werden nicht automatisch von Jev erzeugt. (json-render.dev)

Phase 1: Auswählen, welche Komponenten die Oberfläche benötigt

Beim Erstellen einer neuen Oberfläche behandelt der erste Entscheidungsblock:

• welcher Kandidat zum Wurzelknoten wird;
• welche Komponenten ausgewählt werden sollen;
• wie viele Instanzen einer wiederverwendbaren Komponente gebraucht werden;
• welche Variante gewählt wird, wenn eine Ressource in mehreren Varianten vorliegt.

Zum Beispiel:

Wurzelkomponente: Dashboard

Einbeziehen:
- OrdersTable
- MetricRow
- RevenueMetric
- OrdersMetric
- NewCustomersMetric
- RevenueBarGraph

Nach diesen Entscheidungen setzt gewöhnlicher Code sofort ein erstes Spec zusammen, prüft Komponenteneigenschaften und Aktionsargumente gegen das Katalogschema und streamt eine bereits renderbare Vorschau.

Zu diesem Zeitpunkt kann das Layout noch der Reihenfolge im Katalog folgen, aber der Nutzer sieht bereits ein strukturell gültiges Zwischenergebnis.

Das unterscheidet sich davon, ein Modell das vollständige JSON Token für Token ausgeben zu lassen: Jev schreibt kein serialisiertes JSON. Der Code setzt das JSON aus begrenzten Auswahlentscheidungen zusammen. (json-render.dev)

Phase 2: Eltern-Kind-Beziehungen und Reihenfolge festlegen

Nachdem die Komponenten ausgewählt wurden, behandelt ein zweiter Entscheidungsblock das Layout:

• zu welchem Elternknoten jede Komponente gehört;
• in welchen benannten Slot des Elternknotens sie kommt;
• in welcher Reihenfolge Geschwisterkomponenten angeordnet sind.

Die endgültige Struktur kann so aussehen:

Dashboard
├── OrdersTable
├── MetricRow
│   ├── RevenueMetric
│   ├── OrdersMetric
│   └── NewCustomersMetric
└── RevenueBarGraph

Danach prüft der Code:

• ob genau eine gültige Wurzel vorhanden ist;
• ob ein Eltern-Kind-Zyklus entstanden ist;
• ob die Tiefe den Grenzwert überschreitet;
• ob eine Komponente in einem gültigen Slot liegt;
• ob jeder Kandidat in der erlaubten Anzahl verwendet wird;
• ob alle Eigenschaften, Bindungen und Aktionsargumente die Schemavalidierung bestehen.

Ist das zusammengesetzte Layout widersprüchlich, behält das System die zuvor validierte Vorschau, statt einen beschädigten UI-Baum auszugeben.

Bei einfachen Strukturen mit nur einer Wurzel oder nur einem Kind in einem einzigen Slot kann die zweite Layoutauswertung sogar entfallen. (json-render.dev)

Auch das Bearbeiten einer Oberfläche ist Auswahl, nicht Neuschreiben

json-render kann ein bestehendes Spec ebenfalls bearbeiten, zum Beispiel:

• die Schaltfläche Speichern entfernen;
• die Bestelltabelle oberhalb des Diagramms platzieren;
• einen Diagrammtyp durch einen anderen bereitgestellten Kandidaten ersetzen;
• die Reihenfolge von Feldern ändern;
• eine Komponentenkonfiguration ersetzen.

Solche Änderungen folgen meist einem sequenziellen Protokoll:

1. Das zu ändernde Element auswählen.
2. Das neue Komponentenrezept oder Ziel auswählen.
3. Die Änderung im Code anwenden.
4. Den gesamten Baum erneut validieren.

Unveränderte Komponenten-IDs, Zustandsbindungen, Daten und kompatible Kindknoten werden möglichst beibehalten. Das eingegebene Spec wird nicht direkt mutiert. (json-render.dev)

Eine ausgewählte Schaltfläche wird nicht automatisch ausgeführt

json-render trennt „Oberfläche zusammensetzen“ klar von „Geschäftsaktion ausführen“.

Jev kann eine an savePreferences gebundene Schaltfläche auswählen, doch der Composer ruft diese Aktion nicht selbst auf. Die Ausführung geschieht erst nach einem Klick des Nutzers und wird vom action handler der Host-Anwendung übernommen.

Die Anwendung muss weiterhin Folgendes bereitstellen:

• Prüfung der Nutzerberechtigungen;
• Validierung der Argumente;
• serverseitige Autorisierung;
• Prüfung der Datengültigkeit;
• Idempotenz und Audit-Protokollierung;
• zusätzliche Bestätigung gefährlicher Aktionen.

Die Dokumentation warnt ausdrücklich, dass die Registrierung einer Aktion im Katalog nicht bedeutet, dass sie beliebige Argumente sicher entgegennehmen kann. Der Composer kann auch keinen zukünftigen Laufzeitzustand prüfen und übernimmt keine Autorisierung für die Anwendung. (json-render.dev)

Strukturell gültig bedeutet nicht automatisch inhaltlich richtig

json-render kann sicherstellen, dass die Ausgabe der unterstützten Struktur und dem Schema entspricht, aber nicht garantieren, dass die von Jev ausgewählte Oberfläche vollständig, sinnvoll oder visuell gelungen ist.

Die Dokumentation nennt dieses Beispiel:

Erzeuge ein Dashboard mit der Tabelle oben

Diese Anforderung kann nur eine Tabelle auswählen, weil Kennzahlen und Diagramm nicht ausdrücklich verlangt werden.

Eine präzisere Anforderung:

Erstelle ein Vertriebs-Dashboard:
Platziere die Bestelltabelle oben;
platziere darunter eine Reihe von Kennzahlen für Umsatz, Bestellungen und Neukunden;
platziere zuletzt das Diagramm des wöchentlichen Umsatzes.

wird eher alle benötigten Kandidaten auswählen und in der erwarteten Reihenfolge anordnen.

Das macht eine wichtige Grenze sichtbar: Jev entscheidet nur innerhalb des Kandidatenraums; für dessen Vollständigkeit und eine klare Anforderung bleiben die Entwickler verantwortlich.

Die in der öffentlichen Dokumentation beschriebene wiederverwendbare API verwendet standardmäßig höchstens 32 Auswertungen, höchstens 32 in einem Batch erzeugte Elemente und eine maximale Tiefe von 8. Im öffentlichen Playground gelten strengere Grenzen: höchstens 14 Elemente pro Batch, 14 Auswertungen und Tiefe 4. Wird ein Grenzwert für Aufrufe, Elemente oder Tiefe erreicht, kann das System ein unvollständiges Spec zurückgeben; „der Prozess ist abgeschlossen“ bedeutet jedoch weiterhin nicht, dass das Ergebnis semantisch richtig ist. (json-render.dev)

---

Beide Beispiele verwenden im Kern dieselbe Architektur

Stellt man Browser Use und json-render nebeneinander, lösen sie zwar unterschiedliche Probleme, besitzen aber fast dieselbe Struktur.

Phase	Browser Use	json-render
Nutzerziel	Einen Flug suchen, ein Formular ausfüllen, eine Seite öffnen	Eine Oberfläche erstellen oder ändern
Vom Code gelesener Zustand	Sichtbarer DOM, Steuerelemente, Texte und Werte	Aktuelles Spec, Komponentenkandidaten, Katalog und Baumstruktur
Endlicher Kandidatenraum	Klicken, Eingeben, Auswählen, Scrollen und bedienbare Elemente	Komponenteninstanzen, Eltern, Slots und Reihenfolge
Aufgabe von Jev	Aktion und Ziel auswählen	Komponenten, Eltern-Kind-Beziehungen und Reihenfolge auswählen
Aufgabe des generativen Modells	Text nur dann erzeugen, wenn Eingabe nötig ist	Im Jev-Pfad keine freie UI-Erzeugung; neue Texte und Daten müssen vorher bereitgestellt oder separat erzeugt werden
Aufgabe des gewöhnlichen Codes	DOM-Snapshots, Aktualitätsprüfung, Ausführung, Warten und Ergebnisvalidierung	Spec-Zusammenbau, Schemavalidierung, Baumvalidierung, Rendering und Aktionsautorisierung
Wichtigste Fehlermodi	Veralteter Seitenzustand, fehlendes Ziel, nicht unterstütztes Steuerelement	Fehlende Kandidaten, mehrdeutige Anforderung, unvollständiges Layout, schlechte Auswahl
Abschließende Prüfung	Prüfen, ob das Aufgabenziel wirklich erreicht wurde	Prüfen, ob das Spec vollständig, nutzbar und mit den Produktanforderungen vereinbar ist

Beide folgen derselben Formel:

Die Umgebung in strukturierten Zustand umwandeln
        ↓
Verfügbare Aktionen in eine endliche Kandidatenmenge umwandeln
        ↓
Jev auswählen lassen
        ↓
Code validieren und ausführen lassen
        ↓
Das Ergebnis erneut beobachten

Gegenüber der freien Erzeugung des nächsten Schritts gibt dieser Ansatz etwas Flexibilität auf und gewinnt klarere Kontrollgrenzen.

---

Warum ein Modell ohne Texterzeugung trotzdem „intelligent“ wirken kann

Intelligenz muss sich nicht als Artikel, Programm oder Gespräch ausdrücken.

In vielen Softwareabläufen braucht das System lediglich eine Entscheidung:

• Welche Schaltfläche soll jetzt angeklickt werden?
• In welchem Bereich soll dieses Element platziert werden?
• Soll die Ausführung fortgesetzt werden?
• Welche Komponentenkonfiguration passt am besten zur Nutzeranforderung?
• Hat das aktuelle Ergebnis das Ziel erreicht?

Ein allgemeines LLM kann zunächst eine Erklärung erzeugen und seine Antwort dann in JSON verpacken. Benötigt der Code letztlich jedoch nur eine Option, kann ein großer Teil dieser Zwischentexterzeugung ohne Nutzen sein.

Die Experimente von Browser Use und json-render verlagern mehr vom „Denkprozess“ in das Systemdesign:

• Entwickler definieren den Zustand;
• Entwickler definieren den Kandidatenraum;
• Entwickler definieren die Ausführungsregeln;
• das Modell schließt nur semantische Entscheidungslücken, die sich mit klassischen Regeln schwer abdecken lassen.

Diese Architektur beseitigt Fehler nicht, sondern verändert ihre Form.

Jev gibt keine Komponente und keine Aktion außerhalb der Kandidatenmenge zurück, kann aber dennoch:

• die falsche Schaltfläche wählen;
• die falsche Komponente wählen;
• eine Aufgabe zu früh für abgeschlossen erklären;
• unter mehreren sinnvollen Layouts ein schwächeres auswählen;
• wegen einer mehrdeutigen Anforderung notwendige Inhalte auslassen.

Typsicherheit garantiert die Schnittstelle, nicht die Wahrheit. Auch der bereitgestellte Forschungsbericht betont, dass eine begrenzte Struktur keine korrekte Geschäftsentscheidung garantiert; Fragendesign, Zustandsmodellierung, Schwellenwerte und unabhängige Validierung bleiben für Produktionssysteme zentral.

---

Welche Aufgaben zu diesem Muster passen

Browser Use und json-render liefern einen praktischen Test:

Lässt sich eine Aufgabe in „aus einer endlichen Kandidatenmenge auswählen“ zerlegen, kann es sinnvoll sein, diesen Entscheidungsknoten Jev zuzuweisen.

Relativ gut geeignet sind:

• Aktionsauswahl in Browsern und Desktop-Anwendungen;
• Routing von Agentenwerkzeugen und -fähigkeiten;
• Zusammensetzen einer Oberfläche aus einem kontrollierten Komponentenkatalog;
• Auswahl zwischen Layoutkandidaten;
• Klassifikation von E-Mails, Support-Tickets und Dokumenten;
• Auswahl relevanter Inhalte aus Kandidatenbelegen;
• Entscheidung, ob ein Ergebnis wiederholt oder an einen Menschen eskaliert werden soll.

Nicht direkt an Jev übergeben werden sollten:

• lange Artikel oder Kundendienstantworten schreiben;
• neue Texte erzeugen, die nicht im Kandidatenraum vorhanden sind;
• ein vollständig neues visuelles System frei entwerfen;
• komplexe Programme schreiben;
• mehrstufige Arithmetik oder Datumsberechnungen durchführen;
• eine Lösung erfinden, wenn keine passende Kandidatenaktion existiert;
• Aufgaben mit langen Schlussfolgerungsketten und offener Planung.

Reale Produkte benötigen meist eine Kombination verschiedener Modelle:

Allgemeines Modell: Ziele, Text, Code oder Kandidatenpläne erzeugen
Jev: Kandidaten beurteilen, filtern und routen
Gewöhnlicher Code: validieren, ausführen, zurückfallen und protokollieren

Das kleine Textmodell in Browser Use ist ein direktes Beispiel dieser Arbeitsteilung: Jev entscheidet, dass Text eingegeben werden soll; das generative Modell entscheidet, welcher Text.

---

Die eigentliche Lehre ist die Trennung der Verantwortlichkeiten, nicht die beiden Demos

Die am besten übertragbare Erkenntnis aus Browser Use und json-render lautet nicht „Jev kann im Web browsen“ oder „Jev kann UIs erzeugen“.

Präziser ist:

• Browser Use verwandelt freie Browseroperationen in Aktionsauswahl über echte DOM-Elemente;
• json-render verwandelt freies Schreiben von UI-JSON in Auswahl und Anordnung innerhalb des anwendungseigenen Komponentenkatalogs;
• Jev liefert semantische Entscheidungen;
• Code begrenzt Berechtigungen, verwaltet Zustand, validiert Struktur und führt Ergebnisse aus;
• wenn offener Text benötigt wird, übernimmt weiterhin ein generatives Modell.

Damit wird KI vom alleinigen Fahrer des Systems zu einem Entscheidungsknoten innerhalb eines codegesteuerten Ablaufs.

Für Teams, die KI tatsächlich in Produktionssoftware einbauen wollen, kann dies wichtiger sein als die Frage, ob ein Modell in einem Durchlauf eine vollständige Antwort erzeugt. Die Zuverlässigkeit eines Systems hängt am Ende nicht nur davon ab, was das Modell auswählt, sondern auch davon:

• welchen Zustand das Modell gesehen hat;
• welche Kandidaten der Entwickler bereitgestellt hat;
• welche Aktionen das System erlaubt;
• ob fehlerhafte Ergebnisse abgefangen werden können;
• ob nach Änderungen an Seite oder Oberfläche neu entschieden werden kann;
• ob der Abschluss unabhängig überprüft wird.

Keinen Text zu erzeugen bedeutet nicht, dass Jev nichts kann.

Es bedeutet, dass sich die Intelligenz des Modells nicht in erster Linie als Zeichenkette ausdrückt, sondern als Menge von Entscheidungen, die Software direkt verarbeiten kann – und dennoch sorgfältig validieren muss.