कई AI मॉडलों के बीच लंबी अवधि के प्रोजेक्ट करने के लिए बनाया गया सहयोगी ढांचा

AI सहयोग में मेमरी चैट में नहीं, रिपॉजिटरी में होनी चाहिए

पिछले कुछ महीनों में GPT-5 सीरीज़ मॉडल, Claude, Copilot, Gemini आदि कई AI मॉडलों को बारी-बारी से इस्तेमाल करते हुए डेवलपमेंट का काम करने के मौके काफी बढ़ गए हैं। पहले एक ही टूल काफी होता था, लेकिन अब काम के प्रकार के अनुसार अधिक उपयुक्त मॉडल चुनना एक स्वाभाविक प्रवाह बन गया है.

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

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

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

"AI सहयोग में मेमरी चैट में होनी चाहिए, या फिर प्रोजेक्ट के पास अपनी खुद की मेमरी होनी चाहिए?"

Prompt Engineering से हल न होने वाली समस्या

AI का बेहतर इस्तेमाल करने के तरीके के रूप में Prompt Engineering की बहुत चर्चा होती है। लेकिन लंबी अवधि के प्रोजेक्ट पर काम करने पर पता चलता है कि प्रॉम्प्ट से भी अधिक महत्वपूर्ण एक समस्या है। वह है कॉन्टेक्स्ट का बना न रहना।

प्रॉम्प्ट एक बार की रिक्वेस्ट को बेहतर बनाने का तरीका है, जबकि प्रोजेक्ट कई कामों के क्रम में आगे बढ़ने वाली प्रक्रिया है। किसी प्रोजेक्ट को स्थिर रूप से चलाने के लिए कम-से-कम यह जानकारी लगातार बनी रहनी चाहिए।

• वर्तमान आवश्यकताएँ
• अब तक लिए गए निर्णयों का रिकॉर्ड
• कार्य योजना
• पूर्ण किए गए कार्य
• बदलावों का इतिहास
• आगे किए जाने वाले काम

अगर यह जानकारी बनी नहीं रहती, तो मॉडल कितना भी अच्छा हो, वही गलतियाँ दोहराई जाती हैं। इसलिए मैंने प्रॉम्प्ट को और बेहतर बनाने की दिशा में जाने के बजाय, कॉन्टेक्स्ट को ही मैनेज करने का तरीका बनाना शुरू किया। इस तरह के दृष्टिकोण को आम तौर पर Context Engineering कहा जाता है, और मैंने भी इसी तरह की समस्या झेलते हुए इस अवधारणा को प्रोजेक्ट-स्तरीय सहयोग में लागू करना शुरू किया।

चैट नहीं, रिपॉजिटरी के पास मेमरी होनी चाहिए

सबसे पहले मैंने कॉन्टेक्स्ट को स्टोर करने की जगह बदली। पहले सारा संदर्भ चैट के भीतर था, लेकिन चैट सेशन खत्म होते ही गायब हो जाता है। इसलिए मैंने प्रोजेक्ट रूट के भीतर कॉन्टेक्स्ट स्टोर करने की एक संरचना बनाई।

मैंने .cowork/ नाम का एक फ़ोल्डर बनाया और उसमें प्रोजेक्ट की स्थिति रिकॉर्ड करनी शुरू की। उदाहरण के लिए requirements, architecture decision record, task सूची, test रिकॉर्ड, release रिकॉर्ड, session log जैसी चीज़ें।

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

Plan → Approve → Execute नियम

AI सहयोग करते समय सबसे आम समस्याओं में से एक यह थी कि मॉडल सीधे कोड बदल देता था। वह पहले के निर्णयों को नज़रअंदाज़ कर देता, स्ट्रक्चर तोड़ देता, या पहले से सहमत दिशा से अलग बदलाव कर देता—ऐसी बातें बार-बार हुईं।

इसलिए मैंने एक कार्य नियम बनाया। हमेशा Plan → Approve → Execute क्रम का पालन करना है। पहले योजना बनाई जाए, फिर इंसान उसकी पुष्टि करे, और उसके बाद ही उसे लागू किया जाए। सिर्फ इस एक नियम से भी लंबी अवधि के प्रोजेक्ट में होने वाली गलतियाँ काफी कम हो गईं।

Artifact is Memory

इस फ़्रेमवर्क में जिस सिद्धांत को मैं सबसे महत्वपूर्ण मानता हूँ, उसे 'Artifact is Memory' इस वाक्य में समेटा जा सकता है। मेमरी चैट में नहीं, बल्कि प्रोजेक्ट के artifacts में होनी चाहिए।

तभी मॉडल बदलने पर, सेशन बदलने पर, टूल बदलने पर, या IDE बदलने पर भी प्रोजेक्ट की स्थिति बनाए रखी जा सकती है। खासकर ऐसे माहौल में जहाँ कई मॉडल एक साथ इस्तेमाल हो रहे हों, यह सिद्धांत उम्मीद से कहीं ज्यादा महत्वपूर्ण हो जाता है।

यहाँ artifacts से मतलब सिर्फ उन चीज़ों से नहीं है जो शुरू से दस्तावेज़ के रूप में लिखी गई हों। AI के साथ होने वाली बातचीत के दौरान भी requirements का refinement, डिज़ाइन निर्णय, कार्य योजना, review परिणाम जैसी बहुत-सी ऐसी जानकारी लगातार बनती रहती है जो वास्तव में प्रोजेक्ट में बची रहनी चाहिए। समस्या यह है कि जब तक ये बातें चैट के भीतर रहती हैं, तब तक वे एक-बार इस्तेमाल होने वाले संदर्भ की तरह खत्म हो जाती हैं।

इसलिए मैं AI के साथ हुई बातचीत में से अर्थपूर्ण सामग्री को अपने-आप वर्गीकृत करके रिकॉर्ड करने, और फिर उसे दोबारा प्रोजेक्ट artifacts के रूप में इस्तेमाल करने के तरीके को महत्वपूर्ण मानता हूँ। यह सिर्फ बातचीत के logs जमा करना नहीं है, बल्कि बातचीत से निकली मुख्य बातों को decision record, requirements दस्तावेज़, कार्य योजना, session log जैसी रूपरेखाओं में व्यवस्थित करके दोबारा इस्तेमाल योग्य स्थिति में छोड़ना है।

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

कई मॉडलों के बीच काम करते समय होने वाली समस्या

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

ऐसे में अगर कॉन्टेक्स्ट सिर्फ चैट के भीतर हो, तो हर बार मॉडल बदलने पर प्रोजेक्ट फिर से समझाना पड़ता है। इसलिए मैंने ऐसी संरचना बनाई जिसमें कॉन्टेक्स्ट चैट में नहीं, बल्कि रिपॉजिटरी के भीतर रहता है।

जो बनाया: cowork-context-framework

मैंने इस पूरी प्रक्रिया को व्यवस्थित करके एक फ़्रेमवर्क के रूप में तैयार किया। यह ऐसी संरचना है जो प्रोजेक्ट के भीतर कॉन्टेक्स्ट स्टोर करती है, सेशन restore करती है, निर्णय रिकॉर्ड करती है, कार्य को track करती है, और मॉडल बदलने पर भी काम को वहीं से आगे बढ़ाने देती है।

• GitHub: https://github.com/lim8603/cowork-context-framework

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

जानना चाहता हूँ कि क्या किसी ने ऐसा ही कुछ आज़माया है

• जिन लोगों ने कई AI मॉडल साथ में इस्तेमाल किए हैं
• जिनका सेशन टूटने पर एक ही बात बार-बार समझाने का अनुभव रहा है
• जिन्होंने agent / workflow / harness जैसी कोई संरचना बनाई है
• जिन्होंने प्रोजेक्ट कॉन्टेक्स्ट को अलग से मैनेज किया है

अगर आपका अनुभव इससे मिलता-जुलता है, तो आपकी राय सुनना चाहूँगा।