2026 में AI एजेंट के लिए heredoc-स्टाइल एक्ज़ीक्यूशन, REPL से बेहतर फ़िट क्यों है

शुरुआती कोडिंग एजेंट ने एक हैरान करने वाली बात दिखाई: एजेंट को Bash तक एक्सेस दे दो, और यह लगभग कुछ भी कर सकता है — कोड लिखने और कॉन्टेक्स्ट जुटाने से लेकर पूरे Git वर्कफ़्लो मैनेज करने तक।

इस समझ ने CLI-फ़र्स्ट सॉफ़्टवेयर की एक बड़ी लहर को हवा दी। कमांड-लाइन इंटरफ़ेस, जटिल ऐप्लिकेशन को AI एजेंट के लिए सुलभ बनाने का स्टैंडर्ड तरीका लगने लगे, और यहीं से एक जाना-पहचाना नारा निकला:

CLI ही सब कुछ है।

लेकिन इसकी एक छुपी कीमत है। एजेंट अक्सर टर्मिनल का इस्तेमाल इंसान की तरह ही करते हैं: एक छोटा कमांड चलाओ, नतीजा देखो, फिर तय करो आगे क्या करना है। टास्क जितने जटिल होते जाते हैं, मॉडल और उसके टूल के बीच उतना ही ज़्यादा आगे-पीछे होता है — यानी ज़्यादा LLM कॉल, ज़्यादा बर्बाद कॉन्टेक्स्ट, और ज़्यादा इंतज़ार।

एजेंट से जटिल शेल स्क्रिप्ट जोड़ने के लिए कहने की बजाय, हम चाहते हैं कि वे उस प्रोग्रामिंग भाषा में टास्क कोऑर्डिनेट करें जो उन्हें पहले से आती है। इससे थोड़ा अलग आर्किटेक्चर बनता है:

CLI को यूनिवर्सल एंट्री पॉइंट रहने दें, लेकिन सॉफ़्टवेयर से असल इंटरैक्शन के लिए कोड इस्तेमाल करें।

एजेंट कोड का एक ब्लॉक सबमिट करता है जिसमें वे ऑपरेशन, फ़ैसले और डेटा प्रोसेसिंग होती है जो वरना कई राउंड इंटरैक्शन में बिखरी होती। इसके बाद लोकल रनटाइम पूरा वर्कफ़्लो चलाता है।

ego-browser was built around this idea. Its CLI launches a programmable environment, the browser exposes its capabilities through a small set of functions, and the agent uses its existing programming skills to compose those functions and उन्हें ऑर्केस्ट्रेट करता है.

इस लेख में, हम तुलना करते हैं heredoc और REPL, CLI के ज़रिए कोड चलाने के दो तरीके, और ego-browser से मिले एक्सपेरिमेंट के नतीजे शेयर करते हैं। heredoc के साथ, एजेंट ने वही टास्क 44% कम एक्ज़ीक्यूशन राउंड में, 35.5% कम टूल कॉल के साथ, और 21.6% कम लागत में पूरे किए।

"CLI is all you need" — फिर आगे क्या?

"CLI is all you need" यह दावा मानकर चलता है कि मॉडल को पहले से पता है उस CLI को कैसे इस्तेमाल करना है।

Git, Docker और FFmpeg जैसे जाने-पहचाने टूल के लिए यह आमतौर पर दिक्कत नहीं है। मॉडल ने ट्रेनिंग के दौरान अनगिनत कमांड, ट्यूटोरियल, स्क्रिप्ट और एरर मैसेज देखे हैं, और उन्हें पहले से पता है आर्गुमेंट कैसे लगते हैं और कमांड आपस में कैसे जुड़ते हैं।

लेकिन जब हम एजेंट के लिए एक बिल्कुल नई CLI बनाते हैं, तो तस्वीर बदल जाती है। हर CLI के अपने सबकमांड, आर्गुमेंट, आउटपुट फ़ॉर्मेट और एरर सिमैंटिक्स होते हैं। मॉडल के लिए, यह असल में एक नई मिनी-लैंग्वेज है। पूरी डॉक्यूमेंटेशन होने पर भी, मॉडल को पहले नियम सीखने पड़ते हैं, फिर बार-बार कॉल करके यह समझना पड़ता है कि कमांड आपस में कैसे फ़िट होते हैं।

इसकी बजाय अगर वही क्षमताएं JavaScript API के रूप में, या किसी और भाषा की API के रूप में उजागर की जाएं, तो मॉडल को फिर भी नए डोमेन कॉन्सेप्ट सीखने पड़ते हैं, लेकिन कंट्रोल फ़्लो, डेटा स्ट्रक्चर या कंपोज़िशन दोबारा सीखने की ज़रूरत नहीं रहती। लूप, कंडीशन, एक्सेप्शन हैंडलिंग और डेटा प्रोसेसिंग — सब उसी प्रोग्रामिंग भाषा में रहते हैं जो उसे पहले से आती है।

एक आसान टास्क लें: एक वेबपेज खोलें और उसका मुख्य हेडिंग पढ़ें। अगर ego-browser एक पारंपरिक कमांड-स्टाइल इंटरफ़ेस देता, तो एजेंट को इसे पूरा करने के लिए कई स्टेप लगते:

# First call: open the page
ego-browser open https://example.com

# Tool response: the page is open

# Second call: locate the main heading
ego-browser find --role heading

# Tool response: a heading was found

# Third call: read the heading
ego-browser read --role heading

हर स्टेप के बाद, एजेंट टूल का इंतज़ार करता है, नतीजा पढ़ता है, और तय करता है आगे क्या करना है।

ego-browser जो असल में कोड इंटरफ़ेस इस्तेमाल करता है, वह पूरे वर्कफ़्लो को एक साथ व्यक्त करने देता है:

await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);

दोनों तरीके एक ही काम पूरा करते हैं। कमांड-स्टाइल इंटरफ़ेस पूरी प्रोसेस को मॉडल-टूल इंटरैक्शन के कई राउंड में बांट देता है; कोड इंटरफ़ेस एजेंट को पूरी प्रोसेस एक बार में लिखकर लोकल रनटाइम को सौंपने देता है।

यह ठीक वही डिज़ाइन आइडिया है जो पहले बताया गया: CLI को यूनिवर्सल एंट्री पॉइंट रहने दें, लेकिन सॉफ़्टवेयर से असल इंटरफ़ेस के लिए कोड इस्तेमाल करें। इससे CLI का वह फ़ायदा बना रहता है कि इसे कॉल और इंटीग्रेट करना आसान है, जबकि मॉडल को कंपोज़िशन और ऑर्केस्ट्रेशन के लिए अपनी पहले से मौजूद प्रोग्रामिंग skills इस्तेमाल करने देता है।

जब CLI कोड का गेटवे बन जाए

जब एक बार CLI कोड स्वीकार करने लगे, अगला सवाल यह है कि एजेंट उस कोड को एक्ज़ीक्यूशन एनवायरनमेंट तक कैसे पहुँचाए?

सख़्ती से कहें तो, heredoc एक शेल इनपुट सिंटैक्स है और REPL एक इंटरप्रेटर का एक्ज़ीक्यूशन मोड; दोनों एक जैसे एब्स्ट्रैक्शन लेयर पर नहीं हैं। यह लेख असल में जो तुलना करता है वह है ego-browser में heredoc से डाला गया वन-शॉट कोड एक्ज़ीक्यूशन, बनाम REPL पर बना एक लगातार चलने वाला इंटरैक्टिव सेशन। संक्षिप्तता के लिए, हम आगे इन्हें बस heredoc और REPL ही कहेंगे।

एक विकल्प है heredoc। ego-browser में, एजेंट पूरा JavaScript ब्लॉक एक ही बार में सबमिट करता है:

ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOF

शेल कोड को ego-browser तक पहुंचाता है, इसके पूरा होने का इंतज़ार करता है, नतीजा पाता है, और बाहर निकल जाता है। एजेंट के लिए, यह एक पारंपरिक टूल कॉल जैसा ही व्यवहार करता है:

Submit command → wait for process → receive result

REPL अलग तरीके से काम करता है। इंटरप्रेटर चालू रहता है, जिससे एजेंट बार-बार कोड डाल सकता है जबकि वेरिएबल और सेशन स्टेट बनी रहती है:

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}

> await page.getByRole("heading").textContent()
< "Example Domain"

अभिव्यक्ति की क्षमता के मामले में, दोनों असल में बराबर हैं। REPL एक ही बार में लूप, कंडीशन और एक्सेप्शन हैंडलिंग वाला पूरा प्रोग्राम चला सकता है, और heredoc सिर्फ़ एक लाइन भी सबमिट कर सकता है।

साफ़ फ़र्क़ है प्रोसेस लाइफ़साइकल का। heredoc में, कोड चलते ही प्रोसेस बाहर निकल जाती है; REPL इंटरप्रेटर प्रोसेस को चालू रखता है, अगले इनपुट का इंतज़ार करते हुए। इसका मतलब यह भी है कि दोनों एजेंट टूल से अलग-अलग मांग करते हैं। heredoc सीधे जाने-पहचाने रिक्वेस्ट-रिस्पॉन्स मॉडल पर चलता है:

submit the command → wait for the process to exit → get the result

REPL टूल से ज़्यादा मांगता है: लगातार चलने वाली प्रोसेस, सेशन मैनेजमेंट, कंटीन्युअस इनपुट, इंटरप्शन और रिकवरी। ज़्यादातर एजेंट के बिल्ट-इन Bash टूल में ये क्षमताएं नहीं हैं। आज के मुख्यधारा प्रोडक्ट में, सिर्फ़ Codex इन्हें ठीक-ठाक सपोर्ट करता है।

हर एनवायरनमेंट में मॉडल कोड कैसे लिखते हैं

सिद्धांत रूप में, मॉडल की प्रोग्रामिंग क्षमता दोनों एनवायरनमेंट में एक जैसी होती है। व्यवहार में, हमने एक लगातार दिखने वाला व्यवहारगत फ़र्क़ देखा:

• REPL में, मॉडल का रुझान कोड को धीरे-धीरे, टुकड़ों में डालने का होता है।
• heredoc में, इसकी संभावना ज़्यादा है कि यह एक ही बार में पूरा प्रोग्राम बना दे।

इंसानों के लिए बना सॉफ़्टवेयर एर्गोनॉमिक्स का ख़याल रखता है। एजेंट के लिए बने सॉफ़्टवेयर को भी वैसा ही अनुशासन चाहिए: इसे कहें मॉडल-एक्सपीरियंस इंजीनियरिंग. एक इंटरफ़ेस को मॉडल के ट्रेनिंग के दौरान बने व्यवहारगत पैटर्न के साथ काम करना चाहिए।

REPL और heredoc के बीच का फ़र्क़ उनके ट्रेनिंग डेटा के डिस्ट्रीब्यूशन को दिखाता है।

REPL के उदाहरण आमतौर पर ट्यूटोरियल, डीबगिंग सेशन और सवाल-जवाब से आते हैं। इनका सामान्य पैटर्न एक्सप्लोरेटरी होता है:

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

Heredoc कोड ब्लॉक स्क्रिप्ट या सोर्स फ़ाइल जैसे ज़्यादा दिखते हैं। इनकी साफ़ शुरुआत और अंत की सीमाएं होती हैं, जो मॉडल को एक लगातार चलने वाला वर्कफ़्लो बनाने के लिए प्रेरित करती हैं:

const page = await openPage();
const element = await findElement(page);
const text = await readText(element);

console.log(text);

इसका मतलब यह नहीं कि REPL पूरे प्रोग्राम नहीं चला सकता। मॉडल वही कोड ब्लॉक REPL को एक ही स्टेप में सबमिट कर सकता है।

फ़र्क़ कॉन्टेक्स्ट का है। REPL इसे बढ़ावा देता है एक्ज़ीक्यूट करो, देखो, आगे बढ़ो पैटर्न। heredoc इसे बढ़ावा देता है पहले व्यवस्थित करो, फिर एक्ज़ीक्यूट करो पैटर्न।

यही रुझान यह भी तय करता है कि कंट्रोल फ़्लो कहाँ रहता है। REPL में, मॉडल का रुझान टास्क को कई चरणों में बांटने और हर नतीजे के बाद फ़ैसला लेने का होता है। heredoc में, इसका रुझान लूप, कंडीशन, फ़िल्टरिंग और डेटा प्रोसेसिंग को सीधे प्रोग्राम में डालने और लोकल रनटाइम को संभालने देने का होता है।

एक्सपेरिमेंट में क्या निकला

हम भरोसे से जिन मुख्यधारा एजेंट टूल को इंटीग्रेट कर सके, उनमें Codex ने वे एक्ज़ीक्यूशन क्षमताएं दीं जो एक लगातार चलने वाले REPL को चाहिए होती हैं। तो हमने Codex SDK पर एक ऑटोमेटेड बेंचमार्क बनाया: वही एजेंट REPL और heredoc, दोनों के ज़रिए चार तरह के असली ब्राउज़र टास्क पूरे करता है, और हमने तुलना के लिए बार-बार चलाए गए रन के नतीजे इकट्ठा किए।

टास्क ये थे:

• X trending-post analysis (a typical social media scraping workload): पिछले सात दिनों की OpenAI की मूल पोस्ट इकट्ठा करो, पिन की गई पोस्ट, रीपोस्ट और रिप्लाई छोड़कर, व्यूज़ के हिसाब से टॉप पांच को रैंक करो, और उनकी एंगेजमेंट रेट व कुल औसत निकालो।
• OpenAI जॉब एप्लिकेशन: San Francisco में सही Cloud Infrastructure पोज़िशन ढूंढो, रिज़्यूमे अपलोड करो, एप्लिकेशन फ़ॉर्म पूरा भरो, और आख़िरी सबमिशन से पहले रुक जाओ।
• Redfin मॉर्गेज कैलकुलेशन: Austin में घर के टाइप और कीमत से प्रॉपर्टी फ़िल्टर करो, सॉर्ट करने के बाद पहला नतीजा खोलो, डाउन पेमेंट 20% करो, और अपडेटेड अनुमानित मंथली पेमेंट निकालो।
• Expedia फ़्लाइट सर्च: JFK से MIA तक एक-तरफ़ा, नॉनस्टॉप फ़्लाइट ढूंढो, बताई गई एयरलाइन का सबसे सस्ता ऑप्शन चुनो, पैसेंजर की जानकारी भरो, और पेमेंट से पहले रुक जाओ।

These tasks covered more than opening pages and reading text. They included structured extraction, conditional filtering, navigation across pages, file uploads, form completion, page-state changes, and calculations, covering most of the common operations performed by browser agents.

दोनों तरीकों ने ज़्यादातर टास्क पूरे किए। Heredoc ने 77.5% सफलता दर हासिल की, REPL के 75.0% के मुक़ाबले। भरोसेमंदी में फ़र्क़ मामूली था।

बड़ा फ़र्क़ था दक्षता में:

• औसत पूरा होने का समय इतना कम हुआ 35.0%.
• मीडियन पूरा होने का समय इतना कम हुआ 30.7%.
• टूल कॉल इतने कम हुए 35.5%.
• टोकन खर्च इतना कम हुआ 29.8%.
• औसत लागत इतनी कम हुई 21.6%.

हालांकि REPL रनटाइम स्टेट दोबारा इस्तेमाल कर सकता है, इस फ़ायदे से कम इंटरैक्शन नहीं हुए। व्यवहार में, heredoc एजेंट ने कम टूल कॉल किए।

नतीजे हमारी पहले की टिप्पणियों से मेल खाते थे। REPL के अंदर, एजेंट अक्सर कोड का एक छोटा हिस्सा चलाता, नतीजा जांचता, और फिर तय करता आगे क्या करना है। ऐसे लूप, फ़िल्टर और फ़ैसले जो एक ही प्रोग्राम में हो सकते थे, इसकी बजाय कई मॉडल-टूल आदान-प्रदान में बंट गए।

दोनों एनवायरनमेंट लगभग एक जैसी अभिव्यक्ति क्षमता देते हैं। इनकी दक्षता का फ़र्क़ मुख्य रूप से इस बात से आता है कि इनके इंटरैक्शन पैटर्न एजेंट के व्यवहार को कैसे आकार देते हैं। कम से कम इन चार ब्राउज़र-एजेंट टास्क के लिए, heredoc ने मॉडल को ज़्यादा लगातार तरीके से पूरा प्रोग्राम व्यवस्थित करने, लूप, फ़िल्टरिंग और फ़ैसलों को कोड में डालने, और स्टेप-बाय-स्टेप फ़ैसले के एक्स्ट्रा राउंड ट्रिप से बचने के लिए प्रेरित किया।

हमने यह भी जांचा कि क्या यही पैटर्न बड़े पैमाने पर भी बना रहता है, ego-browser की तुलना Odysseys डेटासेट पर एक जैसे REPL-आधारित ब्राउज़र ऑटोमेशन प्रोडक्ट से करके। ऊपर के नियंत्रित एक्सपेरिमेंट के उलट, इस तुलना में दो पूरे प्रोडक्ट शामिल थे, न कि दो इंटरफ़ेस से चल रहा एक ही मॉडल। इसलिए यह एक कुल दक्षता तुलना के तौर पर उपयोगी है, लेकिन इसके फ़र्क़ पूरी तरह heredoc बनाम REPL को नहीं दिए जा सकते।

यह heredoc की कोई स्थायी जीत नहीं है

हम यह नहीं मानते कि heredoc मूल रूप से REPL से बेहतर है।

हमारा निष्कर्ष मॉडल की क्षमताओं, उनके ट्रेनिंग डेटा के डिस्ट्रीब्यूशन, और 2026 में मौजूद एजेंट टूल के डिज़ाइन पर निर्भर करता है।

आज के एजेंट आमतौर पर एक ही बार में पूरा कोड ब्लॉक बनाने में बेहतर होते हैं। इनके शेल टूल भी एक आसान लाइफ़साइकल के आसपास बने हैं: कमांड सबमिट करो, इसके बाहर निकलने का इंतज़ार करो, और नतीजा लौटाओ। इन शर्तों में, heredoc इंटरैक्शन राउंड कम करना और कंट्रोल फ़्लो को लोकली एक्ज़ीक्यूट होने वाले कोड में ले जाना आसान बना देता है।

ये शर्तें जल्दी बदल सकती हैं।

भविष्य के एजेंट टूल भरोसेमंद, लगातार चलने वाले सेशन, स्ट्रक्चर्ड आउटपुट, और मज़बूत स्टेट रिकवरी दे सकते हैं। हो सकता है एजेंट को खुद REPL प्रॉम्प्ट, प्रोसेस स्टेट और अटके सेशन संभालने की ज़रूरत ही न रहे। टारगेटेड ट्रेनिंग मॉडल को यह भी सिखा सकती है कि REPL के अंदर बेवजह स्टेप-बाय-स्टेप इंटरैक्शन में फंसने की बजाय, पहले से ही पूरे प्रोग्राम सबमिट करें।

अगर ऐसा होता है, तो REPL बिना ज़्यादा मॉडल कॉल के, स्टेट दोबारा इस्तेमाल करने और तुरंत फ़ीडबैक मिलने के फ़ायदे बरकरार रख सकते हैं। ऐसे टास्क के लिए तो ये बेहतर विकल्प भी बन सकते हैं जिनमें इनिशियलाइज़ेशन महंगी हो, स्टेट लंबे समय तक चले, या वर्कफ़्लो सच में एक्सप्लोरेटरी हो।

यही वजह है कि टाइटल में साफ़ बताया गया है 2026. हम यह दावा नहीं कर रहे कि हमने कोई स्थायी नियम खोज लिया है। यह आज उपलब्ध मॉडल और एजेंट टूलिंग के आधार पर लिया गया एक समय-विशेष इंजीनियरिंग फ़ैसला है।