पैरलल agents को prompts डिक्टेट करना, lane दर lane

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

वजह agents नहीं हैं। वजह उस input का आकार है जो उन्हें चाहिए। एक coding agent चलता है सादे वाक्यों पर: "handler को तोड़ो, public signature वैसी ही रखो, timeout वाले रास्ते के लिए एक test जोड़ो।" वाक्य सोचने में सस्ते हैं और पहुँचाने में महँगे, क्योंकि पहुँचाने का मतलब है सही पल पर अपने हाथ और ध्यान सही window में रखना। एक agent के साथ वह पल आपकी अपनी लय से मेल खाता है। तीन के साथ पल तब आते हैं जब आते हैं, और हर एक उस चीज़ को काटता है जिसके बीच में आप थे।

यह पोस्ट पहुँचाने की समस्या पर है, सोचने की नहीं। यह Mac पर पैरलल agent lanes में prompts डिक्टेट करने का एक व्यावहारिक workflow है, ईमानदार सीमाओं के साथ। अगर आपने अपनी आवाज़ से Claude Code चलाना नहीं पढ़ा, वह पोस्ट एक lane वाली बुनियाद देती है; यह वाली मानकर चलती है कि आप पहले से एक से ज़्यादा चला रहे हैं।

पैरलल lanes ख़ासकर टाइपिंग को ही सज़ा क्यों देती हैं

एक prompt के तीन ख़र्च होते हैं: उसे बनाना, उसे पहुँचाना, और उसके बाद वापस लौटना। बनाना अटल है और ज़्यादातर आपके सिर में होता है। पहुँचाना, जब आप टाइप करते हैं, मतलब agent के terminal पर focus बदलना, input लाइन ढूँढ़ना, चालीस से अस्सी शब्द टाइप करना, और return दबाना। लौटना मतलब उस चीज़ पर वापस पहुँचना जो agent के पूछने से पहले आप कर रहे थे।

एक ही lane हो तो पहुँचाने का ख़र्च कम है, क्योंकि आप शायद पहले से उसी terminal को देख रहे थे। पैरलल lanes में आप लगभग कभी नहीं देख रहे होते। lane एक सवाल पूछती है जब आप lane दो का diff पढ़ रहे होते हैं। सवाल आसान है; जवाब एक वाक्य का। पर जवाब देने का मतलब है diff छोड़ना, और लौटने पर आप आख़िरी तीस लाइनें दोबारा पढ़ते हैं यह ढूँढ़ने के लिए कि आप कहाँ थे।

इसे हर redirect से गुणा कीजिए, हर "हाँ, चलते रहो" से, हर "नहीं, दूसरी फ़ाइल" से, और यह overhead जुड़ता चला जाता है। पैरलल lanes इसलिए नहीं टूटतीं कि agents धीमे हैं। वे इसलिए टूटती हैं कि आप ख़ुद message bus बन जाते हैं, और जिस bus को windows के बीच शारीरिक रूप से चलना पड़े उसकी latency भयानक होती है।

आवाज़ पहुँचाने का ज़्यादातर ख़र्च हटा देती है। नज़र diff पर रहती है, एक key दबाए रखिए, वाक्य बोलिए, छोड़ दीजिए। शब्द agent के input field में गिर जाते हैं। आप कहीं गए ही नहीं।

जो setup काम करता है

यह रहा setup, जान-बूझकर उबाऊ रखा हुआ।

Hotkey, window नहीं। Keebye menu bar में रहता है और एक hold-या-tap hotkey सुनता है (डिफ़ॉल्ट में दायाँ Command; Fn और दायाँ Option बाक़ी विकल्प हैं, और Escape चल रही dictation रद्द कर देता है)। खोलने के लिए कोई app window नहीं और घुसने के लिए कोई mode नहीं। दबाइए, बोलिए, छोड़िए। यह सुनने से ज़्यादा मायने रखता है: जिस dictation टूल को अपना window चाहिए, वह बस एक और lane है।

जिस field पर focus है, उसी में insertion। transcript वहीं डलता है जहाँ आपका cursor है। डिफ़ॉल्ट में यह paste होता है, terminal-समझदार chunking के साथ, ताकि लंबा prompt shell को बहा न ले जाए। अगर आप agents tmux के भीतर या SSH पर चलाते हैं, जहाँ paste ठीक से नहीं चलता, तो एक opt-in typing mode है जो text को Unicode keystrokes की तरह डालता है; टर्मिनल में टिकने वाली dictation बताती है कि इसे कब पलटें।

Batch, streaming नहीं। Keebye key छोड़ने पर transcribe करता है, एक ही utterance के रूप में। बोलते हुए शब्द उभरते नहीं दिखेंगे। prompting के लिए यही सही सौदा है: आप चाहते हैं कि पूरा वाक्य एक साथ, साफ़ होकर गिरे, बजाय इसके कि वह शब्द-दर-शब्द बनता दिखे जबकि agent के input में पहले ही आधा ख़याल पड़ा हो।

सब कुछ on-device। transcription स्थानीय चलती है (अंग्रेज़ी के लिए tuned डिफ़ॉल्ट model, या 25 भाषाओं वाला model अगर आप चुनें)। model डाउनलोड होने के बाद यह Wi-Fi बंद करके भी चलता है। agent prompting के लिए यह privacy का दिखावा कम और latency की बात ज़्यादा है: server तक आना-जाना है ही नहीं, तो छोटा prompt key छोड़ते ही लगभग तैयार होता है।

lane बदलने की एक लय

जो workflow आख़िर में टिका, उसमें तीन आदतें हैं।

नज़र उसी lane पर टिकी रहती है जिसे फ़ैसला चाहिए। किसी भी पल एक lane वह होती है जहाँ आपका ध्यान होना चाहिए, आमतौर पर कोई diff या test का output। वही lane आप पढ़ते हैं। बाक़ियों को बस छोटे मौखिक निर्देश मिलते हैं। जब lane दो को फ़ैसला चाहिए, आप नज़र डालते हैं, उसके input में click करते हैं, key दबाए रखते हैं, फ़ैसला बोलते हैं, छोड़ते हैं और वापस click कर लेते हैं। click ही एकमात्र मशीनी ख़र्च है; वाक्य ख़ुद मुफ़्त है।

prompts पूरे वाक्यों में बोले जाते हैं। agents पूरे वाक्यों को तार-भाषा वाले टुकड़ों से बेहतर सँभालते हैं, और dictation पूरे वाक्य क़ुदरती तौर पर बनाती है क्योंकि लोग ऐसे ही बोलते हैं। "schema वाला बदलाव revert कर दो पर API का rename रहने दो, फिर migration दोबारा चलाकर मुझे output दिखाओ" एक बढ़िया बोला हुआ prompt है। टाइप करने में यही थकाऊ है।

भरती के शब्द हटते हैं, अर्थ नहीं। Keebye की सफ़ाई डिफ़ॉल्ट में नियम-आधारित है: यह "उम", "आ", दोहराया गया शब्द हटाती है और आपकी शब्दावली को छेड़ती नहीं। साफ़-सुथरे वाक्यों के लिए एक वैकल्पिक on-device local-LLM polish भी है, जिसके पीछे एक fidelity guard है जो polished संस्करण में गंभीर token loss, फैलाव या दोहराव दिखने पर शब्दशः transcript पर लौट आता है। वह guard एक heuristic है, semantic जाँच नहीं: यह पुष्टि नहीं करता कि polished text ने आपका अर्थ या कोई निषेध बचाया। agent को prompt करने के लिए ज़्यादातर लोग polish बंद ही रखते हैं; शब्दशः transcript ठीक वही है जो आपने कहा, और agent को वही चलाना चाहिए।

आवाज़ किस काम की है, lane दर lane

हर prompt बोलने लायक़ नहीं होता। कुछ महीनों बाद बँटवारा मोटे तौर पर ऐसा है।

Redirects और continuations: हमेशा आवाज़। "चलते रहो।" "नहीं, दूसरा config।" "ख़ाली case के लिए test जोड़ो और दोबारा चलाओ।" पैरलल session में यही सबसे ज़्यादा बार आने वाले prompts हैं और सब एक साँस भर के हैं।

Review की टिप्पणियाँ: ज़्यादातर आवाज़। diff पढ़ते हुए यह बोलना कि इसमें क्या ग़लत है, स्वाभाविक है। "retry loop error निगल जाता है, sleep से पहले उसे log करो, और कोशिशें पाँच पर सीमित कर दो।" dictation इसे बोलने की रफ़्तार पर पकड़ लेती है जबकि नज़र code पर बनी रहती है।

शुरुआती task briefs: मिला-जुला। फ़ाइल paths और शर्तों वाला लंबा, संरचित brief अब भी टाइप करने से, या मोटा-मोटी बोलकर फिर एडिट करने से बेहतर बनता है। गद्य के लिए आवाज़ ठीक है; सटीक identifiers टाइप करना आसान है। यहाँ custom dictionary मदद करती है: अपने project के module नाम और बार-बार आने वाली शब्दावली एक बार जोड़ दीजिए, फिर वे नज़दीकी अंग्रेज़ी शब्द की तरह transcribe होना बंद कर देते हैं।

जिसमें code हो: टाइप कीजिए। regex डिक्टेट करना बुरा अनुभव है। निर्देश डिक्टेट कीजिए ("एक regex लिखो जो version header से match करे"), चीज़ ख़ुद नहीं।

ईमानदार सीमाएँ

इनमें कुछ Keebye की हैं; कुछ पूरी श्रेणी की।

पहली dictation की latency। माइक session की पहली dictation के बाद गर्म होता है और उसके बाद 500 ms का pre-roll रखता है। दिन का सबसे पहला hold stream शुरू होने की क़ीमत चुका सकता है, और buffer चालू होने से पहले बोला गया शब्द कट सकता है। dictation ऐप्स आपका पहला शब्द क्यों खा जाते हैं इसकी मशीनरी समझाती है।

identifiers पर सटीकता। snake case वाले variable नाम और अंदरूनी संक्षेप वहीं हैं जहाँ हर speech model लड़खड़ाता है। dictionary इसे घटाती है, ख़त्म नहीं करती। कुछ भी विनाशकारी चलाने से पहले prompt पढ़ लीजिए।

सुरक्षित fields। Keebye password और secure input fields में डालने से मना कर देता है। यह जान-बूझकर है और कभी-कभार असुविधाजनक, जब terminal passphrase माँग रहा हो।

कोई वॉइस कमांड नहीं। "नई लाइन" या "सब चुनो" जैसी कोई शब्दावली नहीं है। Keebye एक dictation टूल है, वॉइस कंट्रोल की परत नहीं। lanes के बीच आना-जाना अब भी एक click या keyboard shortcut है।

सिर्फ़ macOS। Windows build जारी नहीं हुआ है।

आगे कहाँ जाएँ

अगर आपके agents ज़्यादातर किसी एक editor में रहते हैं, तो Cursor और Claude Code गाइड में हर टूल की बारीकियाँ हैं। अगर आप इस workflow के लिए dictation ऐप्स में से चुन रहे हैं, तो Keebye vs Superwhisper एक ईमानदार तुलना है जिसमें यह भी है कि Superwhisper कहाँ बेहतर बैठता है।

ऊपर की हर बात का छोटा सार: पैरलल agents को यह नहीं चाहिए कि आप तेज़ टाइप करें। उन्हें यह चाहिए कि आप उनके बीच का सबसे धीमा पड़ाव बनना बंद करें। नज़र उस lane पर रखिए जिसे फ़ैसला चाहिए, और बाक़ियों से बोलकर काम लीजिए।