आपका Repo कभी पूरी कहानी नहीं था

किसी feature के ship होने के छह महीने बाद repository खोलें, तो आप बहुत कुछ फिर से समझ सकते हैं। आप architecture का पता लगा सकते हैं, schema की जाँच कर सकते हैं, tests पढ़ सकते हैं, और ठीक-ठीक देख सकते हैं कि कौन-सी lines बदली थीं।

लेकिन आम तौर पर आप उस बातचीत को फिर से नहीं बना सकते, जिसने उन lines को ज़रूरी बनाया था।

कोड आपको यह नहीं बताएगा कि कोई validation rule इसलिए मौजूद है क्योंकि एक customer malformed exports भेजता है। यह नहीं समझाएगा कि कोई अजीब-सी retry policy downstream system में duplicate transactions को रोकती है। यह नहीं दिखाएगा कि accessibility test के बाद cleaner interface को ठुकरा दिया गया था, या यह कि कोई service boundary engineering preference के बजाय contractual restriction को दर्शाती है।

Git code history को सुरक्षित रखने में बेहतरीन है। लेकिन intent तभी सुरक्षित रहता है जब कोई team उसे जानबूझकर लिखकर रखे और implementation से जुड़ा हुआ बनाए रखे।

यह gap हमेशा से software engineering का हिस्सा रहा है। AI coding tools इसे और ज़्यादा स्पष्ट बना देते हैं। कोई system repository की हर file पढ़ सकता है, हर symbol को follow कर सकता है, और तकनीकी रूप से भरोसेमंद patch बना सकता है, फिर भी गलत समस्या हल कर सकता है।

समस्या यह नहीं है कि कोड भ्रामक है। कोड बस एक अधिक संकरे सवाल का जवाब दे रहा है।

इंजीनियरिंग की सच्चाई की पाँच परतें

ज़्यादातर सार्थक software changes पाँच अलग-अलग परतों के evidence पर निर्भर करते हैं।

1. Intent — user, customer, या business किस outcome की माँग कर रहा है? यह किसी specification, ticket, support conversation, या meeting note में हो सकता है.
2. Constraints — क्या नहीं टूटना चाहिए? Compatibility promises, security boundaries, regulations, contracts, budgets, और deadlines अक्सर repository के बाहर होते हैं.
3. Implementation — system आज कैसे काम करता है? Code, tests, schemas, dependencies, और deployment configuration यह परत देते हैं.
4. Runtime evidence — असली system में क्या हो रहा है? Logs, traces, metrics, production data, और incident reports उन assumptions का खंडन कर सकते हैं जो code में उचित लगती हैं.
5. Decision history — मौजूदा approach क्यों चुना गया था? Pull requests, design discussions, rejected alternatives, और previous incidents इसका जवाब रखते हैं।

तीसरी परत में repository सबसे मज़बूत होती है। इसमें बाकी परतों के कुछ हिस्से होते हैं, लेकिन शायद ही कभी इतने कि वे उन्हें पूरी तरह दर्शा सकें।

यह इसलिए मायने रखता है क्योंकि software failures अक्सर परतों के बीच की सीमाओं पर दिखाई देते हैं। Implementation किसी outdated specification से मेल खाती है। Fix ticket को संतुष्ट करता है लेकिन किसी operational constraint का उल्लंघन करता है। Tests pass हो जाते हैं क्योंकि वे कल की assumptions को encode करते हैं। Code भीतर से consistent होता है, जबकि production data ऐसे pattern का पालन करता है जिसे किसी ने document नहीं किया।

स्थानीय स्तर पर सही patch भी फिर गलत बदलाव हो सकता है।

रिपॉज़िटरी अपने आप क्या जवाब नहीं दे सकती

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

सर्च कोड यह समझा सकता है कि परिणाम कैसे लौटाए जाते हैं। लेकिन वह यह नहीं बता सकता कि असली समस्या सिंक्रोनाइज़ेशन में देरी, पुराना एक्सट्रैक्शन, कैश इनवैलिडेशन, अनुमति प्रसार, या ऐसी अपेक्षा है जिसे प्रोडक्ट ने कभी परिभाषित ही नहीं किया।

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

जटिलता को हटाना मूल्यवान है। लेकिन जटिलता के रूप में छिपे इतिहास को हटाना महँगा पड़ता है।

अधिक संदर्भ होने पर भी गलत उत्तर मिल सकता है

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

इससे पहुँच मिलती है, समझ नहीं।

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

इसलिए एक गंभीर कॉन्टेक्स्ट सिस्टम को केवल रिट्रीवल से अधिक की आवश्यकता होती है। उसे इन बातों पर विचार करने का तरीका चाहिए:

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

कॉन्टेक्स्ट टोकनों का ढेर नहीं है। यह समय, प्रामाणिकता, और सीमाओं वाला एक ग्राफ है।

अधिक कॉन्टेक्स्ट से अधिक साक्ष्य मिलने चाहिए, साक्ष्य के बिना अधिक आत्मविश्वास नहीं।

काम की वास्तविक इकाई परिवर्तन है

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

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

वास्तविक सॉफ़्टवेयर पर काम करने वाली AI प्रणाली को उसी जीवनचक्र का पालन करना चाहिए।

इम्प्लीमेंटेशन से पहले, उसे अनुरोध, प्रासंगिक बाधाओं, और किसी भी परस्पर-विरोधी स्रोत की पहचान करनी चाहिए। उसे पता होना चाहिए कि वह किसी दोष को ठीक कर रही है, अपेक्षित व्यवहार बदल रही है, या कोई नया अनुबंध पेश कर रही है।

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

इम्प्लीमेंटेशन के बाद, उसे सत्यापन के परिणाम, समीक्षा के निर्णय, और नई खोजी गई सीमाओं को उस बदलाव के साथ संलग्न करना चाहिए। नहीं तो अगला व्यक्ति—या अगला AI सत्र—उन्हें फिर से खोजने में समय लगाएगा।

यही अंतर है उस टूल में जो किसी repository को संपादित कर सकता है और उस सिस्टम में जो इंजीनियरिंग कार्य में भाग ले सकता है।

AI को पुनर्निर्माण कम करना चाहिए, निर्णय नहीं हटाना चाहिए

बेहतर context को कभी-कभी स्वायत्त सॉफ़्टवेयर विकास के रास्ते के रूप में पेश किया जाता है। इसका तात्कालिक मूल्य कम नाटकीय, लेकिन अधिक उपयोगी है: किसी बदलाव से पहले वास्तविकता को फिर से समझने की लागत को कम करना।

AI मूल requirement को संबंधित code के साथ ला सकता है। वह उस incident को सामने ला सकता है जो किसी असामान्य safeguard की वजह समझाता है। वह किसी failing metric को उस release से जोड़ सकता है जिसने उसे बदला था। वह यह भी दिखा सकता है कि इम्प्लीमेंटेशन शुरू होने से पहले ही दो authoritative sources आपस में असहमत हैं।

ये क्षमताएँ इंजीनियरिंग निर्णय को समाप्त नहीं करतीं। वे उसे बेहतर जानकारी पर आधारित बनाती हैं।

किसी व्यक्ति को अब भी यह तय करना होता है कि कौन-सा tradeoff स्वीकार्य है, कोई requirement पूरी है या नहीं, और कोई release कितना जोखिम उठा सकता है। सिस्टम को साक्ष्य को सामने लाना चाहिए और तर्क को जाँचने योग्य बनाना चाहिए। उसे एक polished patch के पीछे अनिश्चितता नहीं छिपानी चाहिए।

मानक यह नहीं है: “क्या यह code generate कर सकता है?”

मानक यह है: “क्या यह समझा सकता है कि अभी यही सही बदलाव क्यों है?”

repository-aware से work-aware तक

कोडिंग assistants सबसे पहले तब उपयोगी बने जब वे डेवलपर के सामने मौजूद file को समझने लगे। Repository awareness अगला बड़ा कदम था: संबंधित code ढूँढ़ना, symbols को follow करना, और पूरे project में बदलाव लागू करना।

अगला कदम repository के आसपास होने वाले काम के प्रति जागरूकता है।

इसका मतलब है code को उस specification से जोड़ना जिसने इसकी मांग की, उस बातचीत से जिसने इसे स्पष्ट किया, उस production evidence से जिसने इसे चुनौती दी, और उस निर्णय से जिसे बाद में याद रखा जाना चाहिए। इसका यह भी मतलब है कि उस context को बाहर रखा जाए जो अप्रासंगिक, पुराना, या उपयोगकर्ता की permissions के बाहर है।

Dvina बनाते समय, यह उन विचारों में से एक है जिन पर हम बार-बार लौटते हैं। काम किसी एक file, application, या conversation के भीतर नहीं होता। अर्थ उनके बीच के संबंधों में रहता है और इस बात में कि समय के साथ वे संबंध कैसे बदलते हैं।

Repository अब भी अनिवार्य है। यह सिस्टम के व्यवहार के लिए executable source of truth है। बस इतना है कि यह product intent, operational reality, या organizational memory के लिए truth का पूरा स्रोत नहीं है।

पूरी कहानी यह बदल देती है कि क्या बनाया जाता है

जब केवल code हो, तो स्वाभाविक प्रश्न होता है:

इस सिस्टम के लिए कौन-सा बदलाव उपयुक्त है?

विस्तृत context के साथ, प्रश्न बन जाता है:

कौन-सा बदलाव इस सिस्टम, इस requirement, इस history, और इस moment के अनुरूप है?

वह दूसरा सवाल सीमाओं को regression बनने से पहले ही पकड़ लेता है। यह reviewers को implementation के पीछे की reasoning देता है। यह टीम के नए सदस्यों को समझने में मदद करता है कि सिस्टम वैसा क्यों दिखता है जैसा वह दिखता है। यह AI को एक ठोस भूमिका देता है: editor के भीतर किसी oracle की नहीं, बल्कि ऐसे participant की जो पूरे काम में फैले साक्ष्यों को एक साथ जोड़ सके।

आपका repo कभी भी पूरी कहानी नहीं था।

मौका ऐसे systems बनाने का है जो उसकी बाकी कहानी भी पढ़ सकें—और अपना काम दिखा सकें।