बेहतर कोड बनाने के लिए कोड को समझना

अपना ही प्रोजेक्ट समझ में न आने का एहसास मुझे अच्छा नहीं लगता।

ज़रूरतें मैंने बताई थीं। फ़ीचर भी वही थे जो मैं चाहता था। AI के कोड बनाने के बाद मैंने यह भी जाँचा था कि वह काम कर रहा है। लेकिन कोई पूछे कि यह फ़ीचर किन मॉड्यूल से होकर गुज़रता है, इसे ऐसे क्यों बनाया गया, या किसी और जगह बदलाव करने से क्या प्रभावित होगा, तो शायद मैं साफ़ जवाब न दे पाऊँ।

FiboCode बनाते हुए यह बात मेरे लिए लगातार ज़रूरी होती गई है।

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

A ठीक हुआ तो B में समस्या आ गई। B ठीक किया तो A में नया बग आ गया। ऐसे में लक्षण फिर AI को भेज देना और अगली व्याख्या व सुधार का इंतज़ार करना आसान है।

लेकिन कुछ बार ऐसा होने पर भरोसा और कम होने लगता है। हर बदलाव अलग से सही लगता है। सबको जोड़ने पर सिस्टम आख़िर बन क्या गया है?

मैं इसे समझना चाहता हूँ। इस सवाल पर सोचते हुए लगा कि कोड समझने और उसे बनवाने का रिश्ता मेरी शुरुआती सोच से कहीं गहरा है।

प्राकृतिक भाषा में प्रोग्रामिंग ने मुझे सोचने पर मजबूर किया

मशीन भाषा से असेंबली और फिर उच्चस्तरीय भाषाओं तक, हम लगातार अमूर्तन की परतें जोड़ते आए हैं।

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

अब एक और कदम ऊपर बढ़े हैं। हम प्राकृतिक भाषा में ज़रूरत बताते हैं और AI से कोड बनवाते हैं।

पहली नज़र में यह सिर्फ़ अभिव्यक्ति का नया तरीका लग सकता है। लेकिन मुझे लगता है कि यहाँ एक बदलाव अनदेखा नहीं करना चाहिए।

असेंबलर और कंपाइलर तय नियमों के अनुसार कोड बदलते हैं। इसका मतलब यह नहीं कि प्रोग्राम में बग नहीं होंगे। लेकिन उस रूपांतरण को यह अनुमान नहीं लगाना पड़ता कि मैं करना क्या चाहता था।

मॉडल को अनुमान लगाना पड़ता है।

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

बाद में Birgitta Böckeler का एक लेख पढ़ा, जिसमें यही अंतर बताया गया है। बड़े भाषा मॉडल अनुमान के आधार पर परिणाम बनाते हैं; उन्हें सीधे प्राकृतिक भाषा का कंपाइलर नहीं मान सकते। यह मेरी अपनी सोच के काफ़ी क़रीब था।

तो हम क्या कर सकते हैं?

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

लेकिन दस्तावेज़ को कोड से मेल खाना चाहिए। बहुत पहले बदल चुके डिज़ाइन का विस्तृत वर्णन, कोई दस्तावेज़ न होने से भी अधिक परेशानी पैदा कर सकता है।

मुझे नहीं लगता कि इससे निर्माण की सारी अनिश्चितता मिट जाएगी। लेकिन मॉडल को उसी समय अंदाज़ा लगाकर भरने के लिए कम बातें बचेंगी।

क्या मैं सच में जानता हूँ कि बदलना क्या है?

इस विचार को आगे बढ़ाने पर एक और समस्या आती है। लोगों के लिए भी अपनी ज़रूरत साफ़ बताना मुश्किल है।

ख़ासकर जब कोड की जानकारी न हो।

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

ऐसे में AI को बार-बार कहूँ कि “दूसरे फ़ीचर प्रभावित मत करना”, तो वह इसका अर्थ कैसे समझे?

मसलन, “इसे एक जैसा कर दो” का मतलब दिखावट एक जैसी करना भी हो सकता है और डेटा प्रोसेसिंग का तर्क जोड़ना भी। दोनों में बदलाव का दायरा बहुत अलग होगा।

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

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

मुझे डर है कि अंत में ऐसा कोड रह जाएगा जो कहीं-कहीं काम करता है, लेकिन पिछली समस्या ठीक करने के पैबंदों से भरा है। जैसे सिर्फ़ AI ही उसे बदलने को तैयार हो। लोग हाथ लगाने से भी डरें।

ऐसा कोड AI slop की याद दिलाता है। और फिर AI को सौंपने का मतलब भी यह नहीं कि मॉडल पूरा सिस्टम समझता है। वह अगली व्याख्या लिख सकता है, पर इससे यह नहीं होता कि हम आख़िरकार उसे समझ गए।

इसीलिए अब लगता है कि ज़रूरत सही ढंग से बताने से पहले प्रोजेक्ट की मोटी रूपरेखा जानना ज़रूरी है।

शुरू से हर बारीकी समझनी ज़रूरी नहीं। लेकिन इतना जानना चाहता हूँ कि मेरा माँगा हुआ बदलाव कहाँ जाकर बैठेगा।

मैं आर्किटेक्चर की परत पर AI से बात करना चाहता हूँ

मैं यह नहीं मानता कि AI इस्तेमाल करने की शर्त उसके बनाए कोड की हर लाइन हाथ से जाँचना हो।

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

यानी उच्चस्तरीय भाषा में लिखे कार्यान्वयन के ऊपर सिस्टम की समझ की एक और परत तैयार करना चाहता हूँ। अभी इसे “आर्किटेक्चर की परत” कह लेते हैं; नाम को लेकर मेरा कोई विशेष आग्रह नहीं है।

महत्वपूर्ण यह है कि इस परत का संबंध असली कोड से हो।

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

तब AI से करने के लिए अधिक ठोस बातचीत होगी।

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

इन सवालों पर कभी सोचा ही न हो तो शायद चलने वाला कार्यान्वयन स्वीकार कर लूँ। अब कम से कम पहले देखने का अवसर होगा कि वह चीज़ों को बेवजह जटिल तो नहीं बना रहा।

मुझे लगता है कि ऐसी तुलना से मेरी प्रोग्रामिंग भी बेहतर हो सकती है।

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

ये सोचने लायक सवाल हैं। अपना निर्णय बनने लगे तो AI को बदलाव की वजह बताना और उसके किसी दूसरे प्रस्ताव को समझना आसान होगा।

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

धीरे-धीरे ऐसी स्थिति तक पहुँचना चाहता हूँ जहाँ अधिकतर समय पता हो कि कहाँ देखना है, और यह भी पता हो कि अभी क्या समझ में नहीं आया।

FiboCode की कोड विश्लेषण सुविधा बनाने का एक कारण यही है।

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

What Is Code? में Unmesh Joshi भी कहते हैं कि अच्छे अमूर्तन, टाइप, टेस्ट और स्पष्ट नियम मॉडल के लिए कोड समझने व बदलने का आधार बन सकते हैं। मुझे यह दिशा पसंद है। सिस्टम की समझ जहाँ तक हो सके प्रोजेक्ट में रहे, ताकि अगले बदलाव में फिर काम आए।

कुछ समय मैं अब भी कोड पढ़ने में लगाना चाहता हूँ

AI तेज़ी से लिखता है। अगला काम भी उसे सौंपने का मन होता है।

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

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

उस समय का कुछ हिस्सा मैं शांति से कोड पढ़ने में लगाना चाहूँगा।

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

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

चाहता हूँ कि यह समझ धीरे-धीरे जुड़ती जाए। आगे वैसा डिज़ाइन मिले तो उसका तर्क पहचान सकूँ। AI कोई तरीका सुझाए तो अपने ज्ञान के आधार पर सवाल पूछ सकूँ।

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

मैं आगे भी AI के साथ कोड लिखना चाहता हूँ। और प्रोजेक्ट बड़ा हो जाने पर भी समझा सकूँ कि वह कैसे काम करता है।

---

इस विचार का एक सरल चित्र:

कुछ संबंधित सामग्री

• Google का कोड समीक्षा मार्गदर्शन, ख़ासकर पूरे डिज़ाइन और जटिलता की चर्चा, अपने प्रोजेक्ट से तुलना करके पढ़ने लायक है।
• कोडबेस के संज्ञानात्मक ऋण पर Thoughtworks की चर्चा बताती है कि कार्यान्वयन और टीम की समझ कैसे अलग हो सकते हैं।
• Anthropic के सीखने के प्रयोग का शोधपत्र तरीकों और परिणामों को विस्तार से समझाता है।