हर दो घंटे में, Codex मेरे समीक्षा के लिए ईमेल रिप्लाई तैयार करता है।
ज़्यादातर ड्राफ़्ट अच्छे होते हैं। फिर भी मैं उनमें बदलाव करता हूँ।
हो सकता है कि मैं किसी पुरानी चर्चा या आमने-सामने की बातचीत से कोई निर्णय जोड़ दूँ, टोन को हल्का कर दूँ क्योंकि मैं भेजने वाले को जानता हूँ, या कोई ऐसी प्रतिबद्धता हटा दूँ जिसे निभाने के लिए मैं तैयार नहीं हूँ। ड्राफ़्ट अच्छी तरह लिखा जा सकता है और फिर भी जेनेरिक लग सकता है। उस जेनेरिक फीलिंग को अक्सर "AI slop" कहा जाता है, लेकिन ऐसे मामलों में, समस्या बुद्धिमत्ता की नहीं है। यह गायब कॉन्टेक्स्ट है।
किसी ने कोई गलती नहीं की। Codex ने अपने पास उपलब्ध जानकारी से काम किया, जबकि मेरे संपादनों ने वह कॉन्टेक्स्ट प्रदान किया जो उसके पास नहीं था। दिलचस्प बात यह है कि उन संपादनों में भी कॉन्टेक्स्ट होता है। वे बताते हैं कि इस स्थिति में क्या मायने रखता था: मैंने क्या रखा, क्या बदला, क्या अस्वीकार किया, और क्या भेजने में सहज महसूस नहीं किया।
ज़्यादातर ऑटोमेशन उस कॉन्टेक्स्ट को संरक्षित नहीं करते। अगली बार में वही अधूरी तस्वीर से शुरुआत होती है।
मैं कॉन्टेक्स्ट को दो श्रेणियों में सोचना उपयोगी पाता हूँ।
पहला, वह कॉन्टेक्स्ट जो काम शुरू करने से पहले आवश्यक है: इतिहास, तथ्य, बाधाएँ, रिश्ते, और पिछले निर्णय।
दूसरा, वह कॉन्टेक्स्ट जो काम के बाद प्रकट होता है: समीक्षा के दौरान कोई व्यक्ति क्या रखता है, बदलता है, अस्वीकार करता है, भेजता है, या लंबित रखता है।
इससे हमें दो लूप मिलते हैं। इनर लूप सही कॉन्टेक्स्ट को काम पर लाता है और एक ड्राफ़्ट तैयार करता है। आउटर लूप समीक्षा से सीखता है और उस कॉन्टेक्स्ट को अगली बार काम चलने पर उपलब्ध कराता है।
इनर लूप कॉन्टेक्स्ट को काम पर लाता है
ईमेल के लिए, इनर लूप तय करता है कि किसी संदेश को जवाब की ज़रूरत है या नहीं, प्रासंगिक कॉन्टेक्स्ट ढूँढता है, जवाब का ड्राफ़्ट तैयार करता है, उसके दावों की जाँच करता है, और समीक्षा के लिए ड्राफ़्ट बनाता है।
वर्कफ़्लो को कोड में लिखे गए वर्कफ़्लो या वर्कफ़्लो बिल्डर से बनाया जा सकता है: संदेश लाएँ, शोर फ़िल्टर करें, वर्गीकृत करें, ड्राफ़्ट करें, और परिणाम जाँचें। या फिर Codex एक सरल प्रॉम्प्ट जैसे "हर सुबह 9 बजे उन ईमेलों के लिए ड्राफ़्ट बनाएँ जिनका मुझे जवाब देना है" से तय कर सकता है कि क्या कदम उठाने हैं, और यह नई थ्रेड्स का निरीक्षण करेगा, प्रासंगिक इतिहास पुनर्प्राप्त करेगा, जो कमी है उस पर शोध करेगा, जवाब तैयार करेगा, और जो कुछ अस्पष्ट है उसे सामने लाएगा।
कोई भी तरीका काम कर सकता है। महत्वपूर्ण बात यह है कि रिट्रीवल लिखने का हिस्सा है।
एक जवाब किसी समान ईमेल, छह महीने पुराने निर्णय, प्रोजेक्ट ट्रैकर में वर्तमान स्थिति, या किसी अनुमोदित स्रोत के तथ्य पर निर्भर हो सकता है। Codex उस कॉन्टेक्स्ट को इकट्ठा कर सकता है या किसी विशिष्ट प्रश्न पर शोध करने के लिए सब-एजेंट को कह सकता है। लक्ष्य सब कुछ पुनर्प्राप्त करना नहीं है, बल्कि जानकारी का सबसे छोटा सेट ढूँढना है जो जवाब को सटीक और विशिष्ट बनाता है।
मैं कार्रवाई को प्रतिवर्ती रखता हूँ: ड्राफ़्ट बनाएँ, कभी न भेजें। संपादन से पहले, इनर लूप प्रस्तावित जवाब, उसके स्रोतों, और उसके प्रॉम्प्ट और लेखन दिशानिर्देशों के संस्करणों को सहेजता है। उस रिकॉर्ड के बिना, समीक्षा एक किस्सा मात्र है। उसके साथ, समीक्षा सबूत बन जाती है।
आउटर लूप समीक्षा से कॉन्टेक्स्ट पुनर्प्राप्त करता है
आउटर लूप तब शुरू होता है जब मैं ड्राफ़्ट की समीक्षा करता हूँ। क्या इसे बिना बदले भेजा गया, संपादित करके भेजा गया, हटा दिया गया, या लंबित रखा गया?
उन परिणामों के अलग-अलग मायने हैं। बिना बदले भेजने से पता चलता है कि ड्राफ़्ट ने काम किया। संपादित करके भेजने से पहले और बाद की जोड़ी मिलती है। हटाए गए ड्राफ़्ट को समझना मुश्किल है: शायद वह गलत था, या शायद कोई जवाब ज़रूरी नहीं था। लंबित ड्राफ़्ट हमें कुछ नहीं बताता।
यहाँ तक कि भेजा गया ईमेल भी केवल यह दर्ज करता है कि मैंने क्या स्वीकार किया, यह नहीं कि जवाब ने काम किया या नहीं। असली परिणाम बाद में आने वाले जवाब या काम में दिख सकता है। फिर भी, समीक्षा उस सबूत को जोड़ती है जो ड्राफ़्ट लिखे जाने के समय उपलब्ध नहीं था।
ड्राफ़्ट और भेजे गए संस्करण के बीच का अंतर सबूत है। यह अपने आप में कोई सबक नहीं है, और इसे अपने आप प्रॉम्प्ट में बदलाव नहीं बनना चाहिए।
एक छोटी शुरुआत लेखन प्राथमिकता दिखा सकती है। एक जोड़ा गया तथ्य बता सकता है कि इनर लूप ने गलत जगह खोज की। एक हटाई गई प्रतिबद्धता किसी ऐसी जाँच की ओर इशारा कर सकती है जिसकी वर्कफ़्लो को ज़रूरत है। एक फिर से लिखा गया पैराग्राफ़ उस निर्णय को दर्शा सकता है जो मानव के पास ही रहना चाहिए।
एक डिफ़ दिखा सकता है कि क्या बदला। यह समझना कि इसका क्या मतलब है, आउटर लूप का असली काम है।
आउटर लूप इनर लूप को बेहतर बनाता है
आउटर लूप इसलिए है ताकि अगली इनर लूप रन बेहतर हो सके।
यह देखता है कि Codex के ड्राफ़्ट और मेरे द्वारा भेजे गए संस्करण के बीच क्या बदला, फिर पूछता है: क्या चीज़ Codex को पहली बार करीब लाने में मदद करती?
जवाब बेहतर लेखन दिशानिर्देश, कोई दूसरा स्रोत, एक नया खोज चरण, असमर्थित प्रतिबद्धताओं की जाँच, या मेरे लिए जल्दी हैंडऑफ़ हो सकता है। हर संपादन नियम नहीं बनता। आउटर लूप पैटर्न देखता है, सबसे छोटा उपयोगी बदलाव प्रस्तावित करता है, और मैं तय करता हूँ कि क्या रखना है।
व्यवहार में, मैं इन स्वीकृत सबक को एक सरल मार्कडाउन फ़ाइल में रखूँगा। आउटर लूप उस फ़ाइल में अपडेट प्रस्तावित करता है; इनर ऑटोमेशन अगला ईमेल ड्राफ़्ट करने से पहले उसे पढ़ता है।
इस तरह समीक्षा इनर लूप को बेहतर बनाती है: आज मैं जो सुधार करता हूँ, वह कल के रन के लिए उपयोगी कॉन्टेक्स्ट बन जाता है।
दो लूप, दो घड़ियाँ
लूप अलग-अलग गति से चलते हैं। इनर लूप जल्दी मदद करता है, शायद हर दो घंटे में। आउटर लूप पर्याप्त उदाहरणों की प्रतीक्षा करता है, दिन के अंत में, दस समीक्षित ड्राफ़्ट के बाद, या साप्ताहिक जब उदाहरण कम हों।
आउटर लूप को बहुत बार चलाने से वह किसी असामान्य मामले से सीख सकता है। इसे कभी न चलाने से उपयोगी सुधार अगले ड्राफ़्ट के साथ गायब हो जाते हैं।
यही पैटर्न डेक, रिपोर्ट, ब्रीफ़, और इश्यू ट्राएज पर भी लागू होता है। हर मामले में, काम तब बेहतर होता है जब वर्कफ़्लो दोनों प्रकार के कॉन्टेक्स्ट का उपयोग कर सके: वह जो पहले ड्राफ़्ट से पहले ज्ञात था, और वह जो समीक्षा के बाद प्रकट हुआ।
मॉडल पहले से ही सक्षम हैं। अवसर यह है कि ऐसे वर्कफ़्लो बनाएँ जो उन्हें हर रन पर वही कॉन्टेक्स्ट दोबारा खोजने के लिए मजबूर न करें।
इनर लूप सही कॉन्टेक्स्ट को काम पर लाता है। आउटर लूप काम से प्रकट हुए कॉन्टेक्स्ट को संरक्षित करता है।
