बिना अपनी धार खोए किसी असली प्रोजेक्ट पर AI

स्पष्ट व्यक्तिगत नियमों और no-go क्षेत्रों के साथ विवेकपूर्ण pair programming स्थापित करें ताकि सहायता कभी निर्भरता में न बदले।

9 मिनट · 3 प्रश्न

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

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

आप एक वरिष्ठ कोड समीक्षक हैं, कठोर पर सहायक। मैंने अभी यह कोड खुद लिखा है और मुझे ऐसी समीक्षा चाहिए जो मुझे सुधरने में मदद करे, न कि इसे दोबारा लिखे।

संदर्भ: [LANGUAGE, प्रोजेक्ट की बाधाएँ, कोड को क्या करना चाहिए]।

[PASTE YOUR CODE]

समीक्षा के नियम:
1. कभी भी कोड को पूरा दोबारा न लिखें, एक पूरा फ़ंक्शन तक नहीं।
2. हर टिप्पणी को वर्गीकृत करें: संभावित बग / उत्पादन जोखिम / पठनीयता / शैली।
3. हर संभावित बग के लिए, वह सटीक इनपुट परिदृश्य बताएँ जो उसे ट्रिगर करता है, बिना समाधान दिए - मैं इसे खुद ढूँढना चाहता हूँ।
4. अंत में मुझसे एक डिज़ाइन विकल्प के बारे में पूछें जो मैंने चुना था और जो आपको संदिग्ध लगता है।

प्रारूप: क्रमांकित सूची, सबसे गंभीर टिप्पणी पहले। अधिकतम 8 टिप्पणियाँ।

अनुबंध की दूसरी धारा: no-go क्षेत्र। पहले से तय कर लें कि प्रोजेक्ट के कौन से हिस्से ऐसे हैं जहाँ AI कभी एक भी पंक्ति नहीं लिखता, चाहे परिस्थिति कुछ भी हो। तीन श्रेणियाँ आवश्यक हैं। पहली, सुरक्षा-महत्वपूर्ण कोड - authentication, session management, cryptography, data migrations - जहाँ एक विश्वसनीय पर गलत उत्तर बहुत महँगा पड़ता है। अगली, व्यावसायिक मूल (business core), वह तर्क जो आपके उत्पाद को मूल्यवान बनाता है: यही वह चीज़ है जिसे आपको गहराई से जानना चाहिए। अंत में, और यह सबसे कम सहज है, किसी नई अवधारणा से आपका पहला संपर्क: अगर आप AI को अपना पहला Mutex, अपना पहला saga या अपना पहला worker लिखने देते हैं, तो आप उसे कभी सचमुच नहीं सीखेंगे। इन क्षेत्रों में AI की एक भूमिका बनी रहती है: समझाना, सवाल उठाना, समीक्षा करना। कभी उत्पादन नहीं करना।

आप navigator मोड में मेरे pair programming साथी हैं: आप मार्गदर्शन करते हैं, मैं चलाता हूँ। मैं इस समस्या पर अटका हुआ हूँ:

[DESCRIBE THE PROBLEM + त्रुटि संदेश या संबंधित स्निपेट पेस्ट करें]

पूर्ण नियम:
1. मुझे एक पंक्ति से लंबा कोड देना निषिद्ध है।
2. सुकराती प्रश्नों के साथ आगे बढ़ें: मुझे परिकल्पनाएँ बनाने में मदद करें, फिर वह परीक्षण डिज़ाइन करें जो उन्हें सत्यापित करता है।
3. अगर मैं गलत दिशा में जाता हूँ, तो स्पष्ट रूप से कहें और समझाएँ कि क्यों, पर सही दिशा मुझे खुद खोजने दें।
4. जब मैं उसे ढूँढ लूँ, तो मुझसे मूल कारण को दो वाक्यों में दोबारा बताने को कहें, और अगर मेरे शब्द अस्पष्ट हों तो उन्हें सुधारें।

शुरुआत मुझसे यह पूछकर करें कि मैंने पहले क्या-क्या आज़माया है और उससे मैंने क्या निष्कर्ष निकाला।

अंतिम धारा: मापन। बिना किसी मापदंड वाला अनुबंध छह सप्ताह भी नहीं टिकता। सही मापदंड प्रॉम्प्ट की मात्रा नहीं है, यह आपका समझ का ऋण (comprehension debt) है: इस सप्ताह repo में commit किए गए ऐसे कोड ब्लॉकों की संख्या जिन्हें आप याददाश्त से दोबारा नहीं लिख सकते थे या विस्तार से समझा नहीं सकते थे। इस गिनती को ईमानदारी से रखें, हर शुक्रवार। अगर यह लगातार दो सप्ताह बढ़ती है, तो अनुबंध को कस लें: no-go क्षेत्रों को चौड़ा करें, सख्त "मैं टाइप करता हूँ, यह समीक्षा करता है" पर लौटें। अंतिम परीक्षा विमानन जैसी ही रहती है: सप्ताह में एक दिन स्वचालन बंद कर दें, और देखें कि आप अभी भी क्या कर सकते हैं।

ज्ञान जांच

सुनिश्चित करें कि आपको इस पाठ के मुख्य बिंदु याद हैं।

1. "मैं टाइप करता हूँ, यह समीक्षा करता है" नियम का ठोस अर्थ क्या है?
   • AI कोड लिखता है और आप मान्य करने से पहले उसकी ध्यानपूर्वक समीक्षा करते हैं
   • आप पहला मसौदा खुद लिखते हैं, फिर AI केवल एक समीक्षक के रूप में आता है
   • आप AI को कोड बोलते हैं, जो उसे बस लिख देता है
2. किसी नई अवधारणा से पहला संपर्क no-go क्षेत्रों का हिस्सा क्यों होना चाहिए?
   • क्योंकि AI उन्नत अवधारणाओं पर व्यवस्थित रूप से गलत होता है
   • क्योंकि अगर AI किसी अवधारणा का आपका पहला कार्यान्वयन लिखता है, तो आप उसका मानसिक मॉडल कभी नहीं बना पाते
   • क्योंकि नई अवधारणाएँ प्रशिक्षण डेटा में शामिल नहीं होतीं
3. AI पर अत्यधिक निर्भरता का सबसे अच्छा संकेतक क्या है?
   • हर दिन भेजे गए प्रॉम्प्ट की संख्या
   • यह तथ्य कि आप पहले से तेज़ कोड करते हैं
   • स्वीकार किए गए कोड की वह मात्रा जिसे आप पंक्ति-दर-पंक्ति समझा न सकें
   • संपादक के बजाय असिस्टेंट में बिताया गया समय