कोड अब एजेंट लिखते हैं। डेवलपर का काम अब यह बन चुका है।

यह सवाल हर उस खाने की मेज़ पर उठता है जहाँ परिवार में कोई डेवलपर है: अगर कोड मशीन लिखती है, तो बचा क्या?

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

जो हिस्सा ऑटोमेट हुआ, वह कभी पूरा काम था ही नहीं

प्रोडक्शन तक जो कुछ भी पहुँचता है, वह छह कड़ियों से होकर गुज़रता है:

1. किसी को कुछ चाहिए, और वह उसे ख़राब ढंग से कहता है।
2. कोई तय करता है कि वह करने लायक़ है, और कब।
3. कोई उसे इतने सटीक विवरण में बदलता है कि उस पर अमल हो सके।
4. कोई उसे बनाता है।
5. कोई जाँचता है कि इससे कुछ और टूटा तो नहीं।
6. कोई उसे शिप करता है और जिसने माँगा था उसे बताता है।

एजेंट ने चौथी कड़ी ले ली। उन्होंने उसे भरोसा दिलाने वाले ढंग से लिया, और वे उसमें बेहतर होते जाएँगे। जो बात लगभग कोई ज़ोर से नहीं कहता, वह यह है कि इसका बाक़ी पाँच पर क्या असर पड़ता है: वे हल्की नहीं होतीं, भारी हो जाती हैं।

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

एक कड़ी सिकुड़ गई। जो बोझ वह अब तक छिपाए रखती थी, वह अब बाक़ी पाँच उठाती हैं।

पूरी कहानी बस इतनी है, और इस लेख का बाक़ी हिस्सा यह बताता है कि उन पाँच में से हर एक रोज़ाना निभानी पड़े तो कैसी दिखती है।

कड़ी 1: क्या बनाना है यह सुनना, आधा गँवाए बिना

चीज़ें बिगड़ने का नया तरीक़ा एकदम साफ़ है और महँगा है: आप कुछ भी बना सकते हैं, इसलिए आप ग़लत चीज़ और तेज़ी से बना डालते हैं।

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

दो चीज़ें होनी चाहिए, और ये दो अलग चीज़ें हैं।

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

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

इस कड़ी से बैकलॉग नहीं निकलता। इससे एक ऐसा ज़ख़ीरा निकलता है जिसे पढ़ा जा सके।

कड़ी 2: तय करना, जो अब सबसे दुर्लभ संसाधन है

आइडिया का बोर्ड कोई प्लान नहीं होता। एक को दूसरा बनाना वह फ़ैसला है जो पहले पूरी तिमाही में पतला-पतला फैला रहता था और अब हर हफ़्ते लेना पड़ता है।

यहाँ दो चीज़ें मायने रखती हैं।

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

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

कड़ी 3: ब्रीफ़ लिखना, वह हुनर जिसने टाइपिंग की जगह ली

असली हुनर यहीं आ गया है।

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

जिन्हें अच्छे नतीजे मिलते हैं और जो दिन भर अपने एजेंट से लड़ते रहते हैं, उनके बीच का फ़र्क़ प्रॉम्प्ट की चतुराई नहीं है। फ़र्क़ दोबारा इस्तेमाल होने वाला संदर्भ है। चार तरह का, जितना लौटाता है उस क्रम में।

वह संदर्भ जो एजेंट खोजबीन से पहले पढ़ते हैं। वर्ज़न कंट्रोल में रखी कन्वेंशन फ़ाइलें (CLAUDE.md, AGENTS.md) और एक प्रोजेक्ट मेमोरी जिसमें आर्किटेक्चर के फ़ैसले, पहले के जाल और यह वजह दर्ज हो कि चीज़ें जैसी हैं वैसी क्यों हैं। एक बार लिखी जाती है, हर मशीन पर हर एजेंट उसे हमेशा पढ़ता है। आज एक डेवलपर जो कुछ भी लिखता है, उसमें सबसे ज़्यादा लौटाने वाली लिखाई यही है, और लगभग कोई इसके लिए वक़्त नहीं रखता।

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

बताने के बजाय दिखाना। टेढ़े लगे बटन का वर्णन करने वाला पैराग्राफ़ उसी टेढ़े बटन की तस्वीर से कमतर है। स्क्रीन का एक हिस्सा सीधे भेजिए, या उस पर लकीर खींचकर दिखाइए कि आप किस चीज़ की बात कर रहे हैं। किसी वेब पेज के लिए एजेंट को ज़िंदा DOM थमा देना उसका वर्णन करने से हर बार बेहतर है।

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

पहले तीन की क़ीमत हर काम पर चुकानी पड़ती है। चौथे की एक बार, और फ़सल हमेशा मिलती रहती है।

कड़ी 4: काम चलाना, सही मशीन पर

एक एजेंट एक औज़ार है। कई एजेंट एक सिस्टम हैं, और सिस्टम को चलाने वाला चाहिए होता है।

व्यावहारिक सवालों में कोई चमक नहीं है, और वही अब असल काम हैं। क्या-क्या समानांतर चल सकता है बिना इसके कि दो एजेंट एक ही मॉड्यूल में लिखने लगें? कौन सा काम चलते हुए आपके ध्यान का हक़दार है और कौन सा नहीं? आपके सोते वक़्त क्या चलता रहना चाहिए?

आख़िरी सवाल ही तय करता है कि काम कहाँ चलेगा। जिस चीज़ को आपको बीच में रोकना, सुधारना या मोड़ना पड़ सकता है, वह आपके सामने वाली मशीन पर रहती है। लंबा, अच्छी तरह तय किया हुआ, बिना धुँधलेपन वाला काम कहीं और जाता है: आपका अपना कोई दूसरा कंप्यूटर या SSH पर कोई सर्वर, ताकि दो घंटे का काम आपके लैपटॉप को बंधक बनाकर न रखे। बार-बार लौटने वाला काम शेड्यूल पर जाता है। जो सवाल फ़ैसला करता है वह कभी कच्ची ताक़त का नहीं होता, वह यह होता है कि आपको दख़ल देने की कितनी संभावना है।

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

और चूँकि इसमें से किसी के लिए भी आपका वहाँ बैठा होना ज़रूरी नहीं, फ़ोन से चलाना नौटंकी नहीं रह जाता। ट्रेन में बैठे-बैठे एजेंट का सवाल पढ़कर बीस सेकंड में उसका जवाब दे देना ही उस काम में फ़र्क़ डालता है जो ख़त्म हो गया और उस काम में जो चार घंटे आपका इंतज़ार करता रहा।

कड़ी 5: समीक्षा, जहाँ जवाबदेही रहती है

यह वह कड़ी है जो सौंपी नहीं जा सकती, और वजह तकनीकी नहीं है।

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

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

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

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

यह ध्यान कहाँ ख़र्च करना है, इस पर हमने एक पूरा लेख लिखा है: क्या आपको अभी भी अपने AI एजेंट के कोड की समीक्षा करनी चाहिए।

कड़ी 6: शिप करना, और चक्र को बंद करना

शिप करना इस कड़ी का आसान आधा हिस्सा है। जो आधा छूट जाता है, वह है जिसने माँगा था उसे बताना।

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

उससे पहले आमतौर पर कोई न कोई ऐसा होता है जिसे चीज़ चलती हुई देखनी है और जिसके पास आपका डेवलपमेंट एनवायरनमेंट नहीं है: कोई क्लाइंट, कोई डिज़ाइनर, किसी दूसरे महाद्वीप पर बैठा कोई सहकर्मी। आपकी लोकल मशीन की ओर इशारा करता एक पब्लिक HTTPS URL इसे डिप्लॉयमेंट से एक लिंक में बदल देता है, और जो फ़ीडबैक वापस आता है वह सीधे कड़ी एक में चला जाता है।

शृंखला बंद हो जाती है। यही इसे कतार के बजाय एक काम बनाता है।

असल में क्या सिकुड़ा, और असल में क्या बढ़ा

इस टेबल को ईमानदारी से पढ़िए और घबराहट की शक्ल बदल जाती है। जो हिस्से सिकुड़े हैं, वही हिस्से थे जिनके लिए भर्ती करना सबसे आसान था। जो हिस्से बढ़े हैं, उनके लिए ऐसा आदमी चाहिए जो सिस्टम, यूज़र और उनके नतीजों को समझता हो। यह ज़्यादा मुश्किल काम है, छोटा काम नहीं, और उस पुराने रूप से कहीं कम अकेला है जिसमें आप दिन भर टाइप करते थे।

इस सब में AgentsRoom कहाँ बैठता है

हम वह टूल बनाते हैं जो पूरी शृंखला को थामे रखता है, क्योंकि इसका विकल्प छह ऐसे टूल हैं जो एक-दूसरे को जानते ही नहीं।

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

अलग-अलग टुकड़े कहीं और भी मौजूद हैं। उनके बीच की जोड़ें ही थीं जिन्हें कोई शिप नहीं कर रहा था, और काम रिसता उन्हीं जोड़ों से है।

लोग असल में जो सवाल पूछते हैं

क्या AI सॉफ़्टवेयर डेवलपर की जगह ले लेगा?

उसने टाइपिंग की जगह ली है, काम की नहीं। कोड लिखना उस शृंखला की एक कड़ी है जिसमें यह सब भी शामिल है: यूज़र को क्या चाहिए यह सुनना, क्या बनाना लायक़ है यह तय करना, उसे सटीक ढंग से कागज़ पर उतारना, काम चलाना, जाँचना और शिप करना। एजेंट ने एक कड़ी की क़ीमत गिरा दी, जिससे बाक़ी पाँच अड़चन बन गईं। पंक्तियाँ पैदा करने के पैसे कम लोगों को मिलेंगे। कौन सी पंक्तियाँ होनी चाहिए यह तय करने और लाइव होने के बाद उनका जवाब देने के पैसे ज़्यादा लोगों को मिल रहे हैं।

जब कोड एजेंट लिखते हैं तो डेवलपर असल में करता क्या है?

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

क्या अब भी कोड लिखना आना ज़रूरी है?

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

कोड एजेंट के हवाले करने पर सबसे पहले क्या टूटता है?

प्राथमिकता तय करना। जब बनाने में दो हफ़्ते के बजाय एक दोपहर लगती है, तो ग़लत चीज़ बनाने की क़ीमत नज़र से ओझल हो जाती है, इसलिए वह बन जाती है। टीमों के पास शिप हुए फ़ीचर ज़्यादा हो जाते हैं और सुलझी हुई समस्याएँ एक भी ज़्यादा नहीं। दूसरी चीज़ जो टूटती है वह फ़ीडबैक का चक्र है: यूज़र की माँगें उतनी तेज़ी से आती हैं जितनी तेज़ी से कोई उन्हें छाँट नहीं सकता, इसलिए वे चैट के धागों में जमा होकर खो जाती हैं, और वही माँग दो बार बना दी जाती है क्योंकि किसी ने ध्यान ही नहीं दिया कि वह वही थी।

इस नए तरीक़े में सबसे मुश्किल हुनर कौन सा है?

ऐसा ब्रीफ़ लिखना जिसे एजेंट ग़लत न पढ़ सके। एजेंट किसी दोहरे मतलब वाले निर्देश पर वैसे सवाल नहीं उठाता जैसे कोई सहकर्मी उठाता है, इसलिए वह ख़ाली जगहों को एक मुमकिन-सी अटकल से भर देता है और ऐसी चीज़ थमा देता है जो तालमेल में तो है पर ग़लत है। जिन्हें अच्छे नतीजे मिलते हैं वे चतुर प्रॉम्प्ट वाले लोग नहीं होते, वे वे लोग होते हैं जो दोबारा इस्तेमाल होने वाला संदर्भ अपनी जगह पर बनाए रखते हैं: वर्ज़न कंट्रोल में रखी कन्वेंशन फ़ाइलें, हर बार-बार लौटने वाले काम के लिए एक सहेजी हुई प्रक्रिया, एक प्रोजेक्ट मेमोरी जिसे एजेंट खोजबीन से पहले पढ़ते हैं, और स्क्रीन का वर्णन करने वाले पैराग्राफ़ के बजाय स्क्रीनशॉट या खींची हुई लकीरें।

कोडिंग एजेंट आपकी अपनी मशीन पर चलने चाहिए या किसी दूर की मशीन पर?

दोनों, हर काम के हिसाब से चुनकर। जिस चीज़ को आप बीच में देखना, रोकना या सुधारना चाहेंगे, वह आपके सामने वाली मशीन पर रहती है। लंबा, अच्छी तरह तय किया हुआ, बिना धुँधलेपन वाला काम आपके अपने किसी दूसरे कंप्यूटर पर या SSH के ज़रिए किसी सर्वर पर जाता है, ताकि दो घंटे का काम आपके लैपटॉप को बंधक बनाकर न रखे। जो सवाल फ़ैसला करता है वह ताक़त का नहीं है, वह यह है कि आपको दख़ल देने की कितनी संभावना है।

संक्षेप में

काम ग़ायब नहीं हुआ। वह एडिटर से निकलकर उसके चारों तरफ़ की शृंखला में जा बैठा है।

अगर इस महीने आप सिर्फ़ एक चीज़ बदलना चाहते हैं, तो कड़ी एक उठाइए। उसके नीचे की हर चीज़ बेकार मेहनत है जब वह ग़लत समस्या पर तनी हो, और यही अकेली कड़ी है जहाँ आपके ध्यान का एक घंटा आज भी एजेंट के एक घंटे को ऐसे अनुपात से हराता है जिसे कोई माप नहीं सकता।