AI कोडिंग

टेक्स्ट बनाए बिना Jev ब्राउज़र कैसे चलाता और इंटरफ़ेस कैसे बनाता है? Browser Use और json-render का विश्लेषण

Browser Use और json-render के दो ओपन-सोर्स उदाहरणों के माध्यम से यह लेख समझाता है कि Jev सीमित action और component space में संरचित निर्णय कैसे लेता है, और DOM पढ़ना, टेक्स्ट बनाना, JSON जोड़ना, validation, rendering तथा अंतिम execution अब भी आसपास के कोड की ज़िम्मेदारी क्यों हैं।

BetterToken

संपादकीय टीम

22 सित॰ 202619 मिनट पढ़ने में

विषय-सूची

टेक्स्ट बनाए बिना Jev ब्राउज़र कैसे चलाता और इंटरफ़ेस कैसे बनाता है? Browser Use और json-render का विश्लेषण

जब किसी AI से ब्राउज़र चलवाना हो, तो सबसे सहज तरीका आम तौर पर यह होता है: पेज का स्क्रीनशॉट या DOM किसी सामान्य बड़े मॉडल को दें, उससे पेज का विश्लेषण और अगला कदम तय करवाएँ, फिर क्लिक की जगह, selector या tool call बनवाएँ।

इंटरफ़ेस बनाते समय भी अक्सर यही तरीका अपनाया जाता है। उपयोगकर्ता अपनी आवश्यकता बताता है, मॉडल सीधे JSON, JSX या front-end code बनाता है, और सिस्टम उस परिणाम को parse, validate और render करने की कोशिश करता है।

Browser Use का Jev Ultrafast और json-render का Jev प्रयोग अलग रास्ता लेते हैं:

कोड पहले मॉडल के लिए उपलब्ध कामों को एक सीमित set में बाँध देता है, और Jev केवल उसी set में से चुनाव करता है।

Browser Use में यह set मौजूदा वेब पेज पर उपलब्ध actions और interact करने योग्य elements का होता है। json-render में यह application द्वारा पहले से तैयार components, property configurations, data bindings और layout positions का होता है।

Jev को पूरा operation plan लिखने या पूरी UI JSON tree बनाने की आवश्यकता नहीं होती। वह केवल ऐसे प्रश्नों के उत्तर देता है:

अगला कदम क्लिक, टेक्स्ट इनपुट, स्क्रॉल या प्रतीक्षा में से क्या होना चाहिए?
वर्तमान पेज पर किस element के साथ काम करना चाहिए?
इंटरफ़ेस में कौन-से components होने चाहिए?
किसी component को किस parent container, किस slot और किस क्रम में रखा जाना चाहिए?

ये दोनों उदाहरण यह नहीं दिखाते कि “टेक्स्ट न बनाने वाला मॉडल भी सब कुछ कर सकता है।” वे एक अलग software architecture दिखाते हैं: खुले जनरेशन कार्य को सीमित और जाँचे जा सकने वाले निर्णयों की श्रृंखला में बदलना।

यहाँ Jev वास्तव में क्या करता है

Jev, TypeSafe AI द्वारा जारी किया गया System One model है। यह एक state और developer द्वारा परिभाषित typed questions लेता है, और इंसान के पढ़ने के लिए लंबा टेक्स्ट देने के बजाय Choice, Score या Noul जैसे structured results लौटाता है।

इसे probability output वाले decision function की तरह समझा जा सकता है:

वर्तमान स्थिति
   ↓
Developer सीमित candidate set बनाता है
   ↓
Jev चुनता, score करता या मूल्यांकन करता है
   ↓
सामान्य code परिणाम को validate करता है
   ↓
Action execute होता है या interface render होता है

यहाँ:

Choice: दिए गए विकल्पों में से एक चुनता है;
Score: developer द्वारा दी गई क्रमबद्ध levels पर स्थिति तय करता है;
Noul: किसी विशेष कथन के सही होने की probability लौटाता है।

मुख्य बात response format नहीं, बल्कि ज़िम्मेदारियों का बँटवारा है। Jev page copy, browser selectors, JavaScript या पूरा JSON स्वतंत्र रूप से नहीं बनाता। state, control flow, permissions और execution अब भी code के नियंत्रण में रहते हैं। TypeSafe इस pattern को “unstructured state in, typed probabilistic decisions out” के रूप में वर्णित करता है। (typesafe.ai)

अब देखते हैं कि Browser Use और json-render इस pattern को वास्तविक systems में कैसे लागू करते हैं।

Browser Use: पहले वेब पेज को सीमित action space में बदलना

Browser Use का jev-ultrafast project एक browser agent दिखाता है: उपयोगकर्ता natural language में लक्ष्य देता है, program वर्तमान page पढ़ता है, Jev अगला action चुनता है और browser code उसे execute करता है।

Public demo में Google Flights पर Zürich से London तक one-way flight खोजनी है। Project द्वारा दर्ज परिणाम लगभग 7.1 सेकंड का है, जिसमें model calls, text generation, browser execution, page loading और stale decisions के कारण retries शामिल हैं। फिर भी यह एक browser configuration में किया गया केवल एक task है; arbitrary websites पर सामान्य reliability benchmark नहीं है। (github.com)

चरण 1: पेज code पढ़ता है; Jev केवल “स्क्रीनशॉट नहीं देखता”

हर decision cycle में browser code पहले पेज पर दिख रहे controls और text को पढ़ता है और numbered element table बनाता है।

सरल रूप में यह ऐसा दिख सकता है:

[1] button     टिकट का प्रकार बदलें · आने-जाने का
[2] combobox   कहाँ से?             · San Francisco
[3] combobox   कहाँ तक?             · खाली
[4] textbox    प्रस्थान              · खाली
[5] button     खोजें

इस table में element type, नाम, वर्तमान value और index होते हैं। Program हर index से जुड़े वास्तविक DOM node को भी रखता है, ताकि execution से पहले target को फिर से resolve किया जा सके।

इस उदाहरण में Jev सीधे screenshot देखकर यह अनुमान नहीं लगाता कि कोई button coordinates (482, 316) पर है। Screenshots मुख्य रूप से demo और human inspection के लिए हैं। वास्तविक decisions DOM से निकाले गए structured state से चलते हैं। Project यह भी स्पष्ट करता है कि page labels screenshot render करते समय जोड़े जाते हैं और browser को drive नहीं करते। (github.com)

यह अंतर महत्वपूर्ण है।

अगर model स्वतंत्र रूप से coordinates या CSS Selector बनाए, तो वह लौटा सकता है:

ऐसा selector जो page पर है ही नहीं;
element की ऐसी position जो अब stale हो चुकी है;
ऐसा control जो ढका हुआ है या clickable नहीं है;
ऐसा JavaScript जो arbitrary behavior चला सकता है।

इसके विपरीत, Jev Ultrafast model को उन्हीं element indexes में से चुनने देता है जिन्हें program ने अभी-अभी observe किया है।

चरण 2: Jev action और target element चुनता है

Project निम्न action set देता है:

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

वर्तमान page state के आधार पर program केवल वही actions और compatible targets देता है जो उस समय वास्तव में उपलब्ध हैं।

उदाहरण के लिए:

अगर page पर dropdown नहीं है, तो SELECT के लिए कोई target नहीं दिया जाता;
अगर तीन text fields हैं, तो text-input targets केवल उन्हीं तीन elements तक सीमित रहते हैं;
अगर दस clickable elements हैं, तो click targets उन्हीं दस elements तक सीमित रहते हैं।

एक decision को इस तरह सरल किया जा सकता है:

प्रश्न 1: अगला action क्या होना चाहिए?
Candidates: CLICK / TYPE_TEXT / SELECT / WAIT / DONE

प्रश्न 2: अगर action CLICK है, तो किस element पर click करना चाहिए?
Candidates: [1] / [5] / [8] / [11]

प्रश्न 3: अगर action TYPE_TEXT है, तो किस element को text मिलना चाहिए?
Candidates: [2] / [3] / [4]

इन questions को एक ही request में parallel evaluate किया जा सकता है। केवल वही target execute होता है जो चुने गए action के compatible हो। अगर Jev CLICK चुनता है, तो program केवल click_target पढ़ता है; वह TYPE_TEXT के लिए पहले से calculate किए गए target को execute नहीं करता।

Project इसे dynamic, indexed action space कहता है। इससे हर step पर आवश्यक serial model calls घटते हैं और model को operation parameters स्वतंत्र रूप से बनाने की आवश्यकता नहीं रहती। (github.com)

चरण 3: केवल तभी generative model बुलाएँ जब text लिखना हो

Jev यह तय कर सकता है कि अब origin field में कुछ लिखना चाहिए, लेकिन वह लिखे जाने वाला text स्वयं नहीं बनाता।

जब action TYPE_TEXT होता है, तब system वर्तमान task और target field के आधार पर input value बनाने के लिए एक छोटा text-generation model बुलाता है। उदाहरण:

{
  "text": "Zürich"
}

Browser में डालने से पहले इस result को भी एक छोटे JSON object के रूप में parse करना पड़ता है।

इसलिए यह browser agent दो अलग क्षमताओं को जोड़ता है:

कार्य	ज़िम्मेदार component
तय करना कि अगला step click, typing, selection या wait है	Jev
चुनना कि page पर किस element पर action हो	Jev
input के लिए natural-language text बनाना	छोटा generative model
DOM और page state पढ़ना	Browser code
click, type और select करना	Browser code
जाँचना कि लक्ष्य वास्तव में पूरा हुआ	स्वतंत्र validation code

इसीलिए “Jev browser चलाता है” का अर्थ यह नहीं कि Jev पूरा browser task अकेले पूरा करता है।

अधिक सही वर्णन है: Jev browser loop के अंदर action selector है।

चरण 4: execution से पहले code page को फिर जाँचता है

Model के चुनाव के बाद program तुरंत आँख बंद करके click नहीं करता।

Execution से पहले Jev Ultrafast जाँचता है:

क्या वर्तमान page वही है जिसे model ने देखा था;
क्या संबंधित DOM node अब भी मौजूद है;
क्या element किसी दूसरे content से ढका है;
क्या उसका वर्तमान geometry अब भी valid है;
क्या form value और पास का context snapshot से मेल खाते हैं;
क्या text-generation request का input बदल गया है।

अगर model response आने से पहले page बदल जाता है, तो पिछला decision invalid हो सकता है। Program उसे stale decision मानता है और पुराने element पर काम जारी नहीं रखता।

Project स्पष्ट रूप से सीमित करता है कि model output किसमें बदल सकता है: उसे सीधे CSS Selector, screen coordinate, Shell command या executable JavaScript में नहीं बदला जाता। Execute होने वाला हर target पहले observe किए गए वास्तविक DOM node पर दोबारा resolve होना चाहिए। (github.com)

यह code “intelligent” नहीं है, लेकिन system की reliability इसी से तय होती है।

सात सेकंड का परिणाम केवल Jev को नहीं दिया जा सकता

छह alternating runs में project ने बताया कि दोनों implementations ने task तीन-तीन बार पूरा किया। Median task time लगभग 9.450 सेकंड से घटकर 7.092 सेकंड हुआ, यानी लगभग 25% की कमी; browser protocol calls 1,092 से घटकर 101 हुए। लेखक साथ ही यह स्पष्ट करता है कि यह एक ही task और browser configuration पर हर implementation के केवल तीन runs थे, सामान्य reliability test नहीं। (github.com)

इसलिए performance gain केवल model speed से नहीं, पूरे browser implementation से आता है:

visible controls को एक pass में पढ़ना;
browser protocol round trips कम करना;
action और target questions को एक ही decision request में रखना;
केवल text input की ज़रूरत पर generative model बुलाना;
execution के बाद केवल आवश्यक page changes का इंतज़ार करना;
unrelated page text को model context में न भेजना।

इसलिए यह निष्कर्ष गलत होगा कि किसी भी browser agent में model बदलकर Jev लगा देने से हर task सात सेकंड में पूरा हो जाएगा।

वर्तमान MVP shadow DOM, iframe, canvas, file upload, pop-up tabs, nested scrolling और arbitrary keyboard widgets का पूर्ण support भी नहीं देता। Model DONE चुने तब भी system स्वतंत्र रूप से जाँचता है कि task सच में पूरा हुआ या नहीं। (github.com)

json-render: पूरा page JSON बनवाने के बजाय Jev से components चुनवाना

json-render एक अलग समस्या हल करता है: natural-language request से ऐसी interface कैसे बने जिसे सीधे render किया जा सके।

Traditional generative UI अक्सर model से सीधे यह सब output करवाता है:

React या Vue code;
पूरी JSON UI tree;
CSS और layout properties;
event-handling logic;
data-binding configuration।

यह तरीका flexible है, लेकिन model का output space भी बहुत बड़ा हो जाता है। Model component का नाम गलत लिख सकता है, ऐसी property बना सकता है जो मौजूद नहीं, unregistered action refer कर सकता है, या ऐसा JSON दे सकता है जिसे parse नहीं किया जा सके।

json-render का Jev experiment समस्या को इस तरह बदलता है:

Application पहले valid component instances का collection तैयार करती है, और Jev केवल यह तय करता है कि किन्हें इस्तेमाल करना है और कैसे जोड़ना है।

यह capability अभी भी experimental के रूप में चिह्नित है। experimental_composeSpec और experimental_createEvaluator stable APIs के रूप में जारी नहीं हुए हैं; versions बदलने पर इनके names और behavior बदल सकते हैं। Documentation exact version pin करने और changelog जाँचने की सलाह देती है। (json-render.dev)

Application पहले component catalog और candidates देती है

मान लीजिए उपयोगकर्ता कहता है:

एक sales dashboard बनाएँ: ऊपर orders table रखें, उसके नीचे revenue, order count और new customers की metrics की एक row रखें, और अंत में weekly revenue chart रखें।

Application इस वाक्य को सीधे Jev को देकर UI JSON स्वतंत्र रूप से लिखने को नहीं कहती।

इसके बजाय वह पहले candidates देती है:

Dashboard
OrdersTable
MetricRow
RevenueMetric
OrdersMetric
NewCustomersMetric
RevenueBarGraph

हर candidate केवल नाम नहीं, बल्कि application द्वारा configured component instance है। इसमें शामिल हो सकता है:

component type;
fixed properties;
उपलब्ध layout configuration;
state bindings;
data bindings;
allowed actions;
model के लिए candidate description।

उदाहरण के लिए button candidate पहले से इस तरह defined हो सकता है:

Component: Button
Text: सहेजें
Action: savePreferences
Arguments: वर्तमान /name state पढ़ें

Jev यह चुन सकता है कि इस button को शामिल करना है या नहीं, लेकिन वह unregistered deleteAllUsers action नहीं बना सकता।

json-render documentation इस बात पर ज़ोर देती है कि available capabilities और design system platform के नियंत्रण में रहते हैं। Jev केवल application द्वारा दिए गए components, configurations और action bindings में से चुन सकता है; missing copy, data या components Jev अपने-आप नहीं बनाता। (json-render.dev)

चरण 1: interface के लिए आवश्यक components चुनना

नई interface बनाते समय पहला decision batch यह तय करता है:

कौन-सा candidate root node बनेगा;
कौन-से components चुने जाएँगे;
reusable component की कितनी instances चाहिए;
अगर एक ही resource के कई variants हों तो कौन-सा चुना जाए।

उदाहरण:

Root component: Dashboard

शामिल करें:
- OrdersTable
- MetricRow
- RevenueMetric
- OrdersMetric
- NewCustomersMetric
- RevenueBarGraph

Choices तय होने के बाद सामान्य code तुरंत शुरुआती Spec बनाता है, component properties और action arguments को catalog schema के विरुद्ध जाँचता है, और ऐसा preview stream करता है जिसे पहले ही render किया जा सकता है।

इस stage पर layout अब भी catalog order में हो सकता है, लेकिन user को structurally valid intermediate result दिखने लगता है।

यह उस तरीके से अलग है जिसमें model पूरा JSON token by token output करता है: Jev serialized JSON नहीं लिखता। सीमित choices के आधार पर code JSON बनाता है। (json-render.dev)

चरण 2: parent-child संबंध और क्रम तय करना

Components चुनने के बाद दूसरा decision batch layout तय करता है:

हर component किस parent node से जुड़ा है;
parent के किस named slot में रखा जाना चाहिए;
sibling components किस क्रम में होने चाहिए।

अंतिम structure ऐसा हो सकता है:

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

इसके बाद code जाँचता है:

क्या केवल एक valid root है;
क्या parent-child cycle बन गया है;
क्या depth limit से अधिक है;
क्या component valid slot में रखा गया है;
क्या हर candidate अनुमत संख्या में इस्तेमाल हुआ है;
क्या सभी properties, bindings और action arguments schema validation पास करते हैं।

अगर composed layout असंगत है, तो system टूटी UI tree output करने के बजाय पहले से validated preview रखता है।

अगर structure बहुत सरल है—जैसे केवल एक root या single slot में एक ही child—तो दूसरी layout evaluation की आवश्यकता भी नहीं पड़ सकती। (json-render.dev)

Interface edit करना भी selection है, rewrite नहीं

json-render मौजूदा Spec को edit भी कर सकता है, जैसे:

Save button हटाना;
orders table को chart से ऊपर ले जाना;
किसी chart type को दूसरे उपलब्ध candidate से बदलना;
fields का क्रम बदलना;
component configuration बदलना।

ऐसे edits आम तौर पर sequential protocol अपनाते हैं:

वह element चुनें जिसे बदलना है।
नया component recipe या destination चुनें।
Code change लागू करे।
पूरी tree को फिर validate करें।

Unchanged component IDs, state bindings, data और compatible children को जहाँ संभव हो बनाए रखा जाता है। Input Spec को सीधे mutate नहीं किया जाता। (json-render.dev)

Button चुन लेने से उसका action अपने-आप execute नहीं होता

json-render “interface compose करना” और “business action execute करना” अलग रखता है।

Jev savePreferences से bound button चुन सकता है, लेकिन composer स्वयं वह action invoke नहीं करता। वास्तविक execution user के click करने के बाद होता है और host application का action handler उसे संभालता है।

Application को अब भी यह सब करना होता है:

user permission checks;
argument validation;
server-side authorization;
data validity checks;
idempotency और audit logging;
dangerous operations के लिए secondary confirmation।

Documentation विशेष रूप से चेतावनी देती है कि catalog में action register करने से वह arbitrary arguments स्वीकार करने के लिए safe नहीं हो जाता। Composer future runtime state validate नहीं कर सकता और application की ओर से authorization भी नहीं करता। (json-render.dev)

Structure valid हो तो भी interface सही होना ज़रूरी नहीं

json-render यह सुनिश्चित कर सकता है कि output supported structure और schema के अनुरूप हो, लेकिन यह guarantee नहीं कर सकता कि Jev द्वारा चुना interface complete, sensible या visually good है।

Documentation यह उदाहरण देती है:

ऊपर table वाला dashboard बनाएँ

यह request केवल table चुन सकती है, क्योंकि इसमें metrics और chart स्पष्ट रूप से नहीं माँगे गए हैं।

अधिक स्पष्ट request:

एक sales dashboard बनाएँ:
ऊपर orders table रखें;
उसके नीचे revenue, orders और new customers की metrics की row रखें;
अंत में weekly revenue chart रखें।

आवश्यक सभी candidates चुनने और उन्हें अपेक्षित क्रम में लगाने की अधिक संभावना रखती है।

यह एक महत्वपूर्ण सीमा दिखाता है: Jev केवल candidate space के भीतर निर्णय कर सकता है; उस space को complete बनाना और requirement को स्पष्ट लिखना developer की ज़िम्मेदारी है।

Public documentation में reusable API के default limits हैं: अधिकतम 32 evaluations, एक batch में अधिकतम 32 elements, और maximum depth 8। Public Playground इससे भी सख्त है: प्रति batch अधिकतम 14 elements, 14 evaluations और depth 4। Call, element या depth limit पहुँचने पर system partial Spec लौटा सकता है, लेकिन “process पूरा हुआ” का अर्थ यह नहीं कि result semantically सही है। (json-render.dev)

दोनों उदाहरण वास्तव में एक ही architecture का उपयोग करते हैं

Browser Use और json-render को साथ रखने पर दिखता है कि समस्याएँ अलग हैं, लेकिन structure लगभग एक जैसा है।

चरण	Browser Use	json-render
User goal	Flight खोजना, form भरना, page खोलना	Interface बनाना या बदलना
Code द्वारा पढ़ा state	Visible DOM, controls, text और values	वर्तमान `Spec`, component candidates, catalog और tree structure
सीमित candidate space	Click, type, select, scroll और interactable elements	Component instances, parents, slots और ordering
Jev की ज़िम्मेदारी	Action और target चुनना	Components, parent-child संबंध और order चुनना
Generative model की ज़िम्मेदारी	Input की ज़रूरत पर ही text generate करना	Jev path में UI स्वतंत्र रूप से generate नहीं होता; नया copy और data पहले से देना या अलग से बनाना होता है
सामान्य code की ज़िम्मेदारी	DOM snapshots, freshness checks, execution, waiting और result validation	`Spec` assembly, schema validation, tree validation, rendering और action authorization
मुख्य failure modes	Stale page state, target गायब, unsupported controls	Missing candidates, ambiguous request, incomplete layout, poor selection
Final verification	जाँचना कि task goal वास्तव में पूरा हुआ	जाँचना कि `Spec` complete, usable और product requirements के अनुरूप है

दोनों एक ही formula अपनाते हैं:

Environment को structured state में बदलें
        ↓
Available actions को सीमित candidate set में बदलें
        ↓
Jev से चुनाव करवाएँ
        ↓
Code से validate और execute करवाएँ
        ↓
Result को फिर observe करें

Model को अगला step स्वतंत्र रूप से generate करने देने की तुलना में, यह approach कुछ flexibility छोड़कर अधिक स्पष्ट control boundaries देता है।

टेक्स्ट न बनाने वाला model फिर भी “intelligent” क्यों लगता है

Intelligence को article, program या conversation के रूप में ही व्यक्त होना आवश्यक नहीं है।

बहुत से software workflows में system को वास्तव में केवल एक decision चाहिए:

अभी कौन-सा button क्लिक होना चाहिए?
यह element किस region में रखा जाए?
क्या execution जारी रहना चाहिए?
कौन-सी component configuration user की request से सबसे अधिक मेल खाती है?
क्या वर्तमान result ने goal पूरा कर लिया है?

General-purpose LLM पहले explanation बना सकता है और फिर answer को JSON में wrap कर सकता है। लेकिन अगर code को अंत में केवल एक option चाहिए, तो बीच का बहुत-सा text generation उपयोगी नहीं हो सकता।

Browser Use और json-render के प्रयोग “thinking process” का अधिक हिस्सा system design में ले जाते हैं:

developer state परिभाषित करता है;
developer candidate space परिभाषित करता है;
developer execution rules परिभाषित करता है;
model केवल उन semantic decision gaps को भरता है जिन्हें सामान्य rules आसानी से handle नहीं कर पाते।

यह architecture errors हटाता नहीं, उनका रूप बदलता है।

Jev candidate set से बाहर का component या action नहीं लौटाएगा, लेकिन फिर भी वह:

गलत button चुन सकता है;
गलत component चुन सकता है;
task को बहुत जल्दी complete मान सकता है;
कई reasonable layouts में से कम अच्छा layout चुन सकता है;
ambiguous request के कारण आवश्यक content छोड़ सकता है।

Type safety interface की guarantee है, truth की नहीं। दिए गए research report में भी ज़ोर दिया गया है कि constrained structure सही business judgment की guarantee नहीं देता; question design, state modeling, thresholds और independent validation production systems में अब भी मुख्य हैं।

कौन-से tasks इस pattern के लिए उपयुक्त हैं

Browser Use और json-render एक व्यावहारिक test देते हैं:

अगर task को “सीमित candidates में से चुनना” के रूप में तोड़ा जा सकता है, तो उस decision node को Jev को देना उपयोगी हो सकता है।

तुलनात्मक रूप से उपयुक्त tasks में शामिल हैं:

browser और desktop applications में action selection;
agent tool और skill routing;
controlled component catalog से interface compose करना;
candidate layouts में से चयन;
email, support tickets और documents का classification;
candidate evidence में से relevant content चुनना;
result retry करना है या human को escalate करना है, यह तय करना।

इन tasks को सीधे Jev को नहीं देना चाहिए:

लंबे articles या customer-service replies लिखना;
candidate set में न मौजूद नया copy बनाना;
बिल्कुल नया visual system स्वतंत्र रूप से design करना;
complex programs लिखना;
multi-step arithmetic या date calculations करना;
जब candidate action मौजूद न हो तब solution invent करना;
long-chain reasoning और open-ended planning वाले tasks।

वास्तविक products में अक्सर अलग-अलग models का combination चाहिए:

General-purpose model: goals, text, code या candidate plans generate करना
Jev: candidates को judge, filter और route करना
सामान्य code: validate, execute, fallback और log करना

Browser Use का छोटा text model इस division का सीधा उदाहरण है: Jev तय करता है कि text input चाहिए, generative model तय करता है कि क्या text डालना है।

असली सीख दो demos नहीं, responsibility separation है

Browser Use और json-render से सबसे अधिक पुनः उपयोग योग्य सीख यह नहीं कि “Jev web browse कर सकता है” या “Jev UI generate कर सकता है।”

अधिक सही निष्कर्ष है:

Browser Use browser operation को free-form generation से वास्तविक DOM elements पर action selection में बदलता है;
json-render UI JSON के free-form लेखन को application के अपने component catalog पर selection और ordering में बदलता है;
Jev semantic decisions देता है;
code permissions सीमित करता है, state बनाए रखता है, structure validate करता है और result execute करता है;
open-ended text की ज़रूरत पर generative model अब भी उसे संभालता है।

इस architecture में AI system का एकमात्र driver नहीं रहता, बल्कि code-controlled workflow के अंदर एक decision node बनता है।

जो teams वास्तव में AI को production software में रखना चाहती हैं, उनके लिए यह इस बात से अधिक महत्वपूर्ण हो सकता है कि model एक ही बार में पूरा answer बना सकता है या नहीं। System reliability केवल इस पर निर्भर नहीं करती कि model ने क्या चुना, बल्कि इस पर भी निर्भर करती है:

model को कौन-सा state दिखाया गया;
developer ने कौन-से candidates दिए;
system ने कौन-से actions की अनुमति दी;
गलत results रोके जा सकते हैं या नहीं;
page या interface बदलने के बाद फिर से decision लिया जा सकता है या नहीं;
completion को independently verify किया गया या नहीं।

टेक्स्ट न बनाना यह नहीं दर्शाता कि Jev कुछ नहीं कर सकता।

इसका अर्थ है कि model की intelligence मुख्य रूप से string के रूप में नहीं, बल्कि ऐसे choices के set के रूप में व्यक्त होती है जिन्हें software सीधे consume कर सकता है—और फिर भी सावधानी से validate करना आवश्यक है।