यह एक तरह से हाल की श्रृंखला का एक परिशिष्ट/साइड-क्वेस्ट है। यह मुख्य पोस्ट में साफ-साफ फिट नहीं हो पाया, इसलिए मैं इसे अलग से प्रकाशित कर रहा हूँ। इसका संक्षिप्त उल्लेख [व्हाय सॉफ्टवेयर फैक्ट्रीज़ फेल](https://x.com/dexhorthy/status/2080697380379427275) भाग 2: [टर्निंग द लाइट्स बैक ऑन](https://x.com/dexhorthy/status/2081058573556306030) में किया गया है।
लाभ (Leverage) की तलाश
AI से पहले भी, किसी फीचर को शिप करने में लगने वाले समय का केवल 25-50% ही कोड लिखने में लगता था। बाकी समय अलाइनमेंट/प्लानिंग, कोड-रिव्यू/रीवर्क, और सॉल्यूशन के टेस्टिंग/वेरिफिकेशन में खर्च होता था।
अगर आप AI का उपयोग केवल कोड लिखने के लिए कर रहे हैं, तो आप कोडिंग के 2-4 घंटे घटाकर 10-20 मिनट कर रहे हैं, लेकिन आपने बाकी किसी भी चीज़ को गति नहीं दी है।
लेकिन अगर आप प्लानिंग और अलाइनमेंट के लिए AI का उपयोग करते हैं, तो आप वास्तव में 2-3 गुना तेज़ी प्राप्त कर सकते हैं।
AI कोडिंग लाभ में 80/20 नियम
मान लेते हैं कि अगर आप अपनी फैक्ट्री में बिना सोचे-समझे दो-लाइन का प्रॉम्प्ट डाल देते हैं, तो पूरी तरह मर्ज करने योग्य परिणाम मिलने की संभावना लगभग 50% है, और इसे रीवर्क करने की संभावना 50% है।
अब मान लेते हैं कि आप 10 साल के अनुभव वाले प्रिंसिपल इंजीनियर हैं। आपके दिमाग में 100 रिपॉजिटरी वाला पूरा कोडबेस डाउनलोड है। इसलिए आप एक दोपहर हाथ से एक पूरी तरह से विस्तृत स्पेसिफिकेशन लिखने में बिताते हैं। अब आपकी संभावनाएँ बेहतर हैं, लेकिन फिर भी लगभग 10% संभावना है कि आपको कुछ महत्वपूर्ण फिर से करना पड़ेगा।
और सबसे अंत में: हर लाइन खुद लिखें। एजेंट के लिए कुछ भी गलत करने को नहीं बचा है, इसलिए रीवर्क की संभावना शून्य हो जाती है।
नोट इस उदाहरण के लिए मैं
"आपको कुछ बदलने की संभावना" को "बदलाव कितना दर्दनाक होगा" से भारित करके
एक प्रतिशत संख्या में बदलने जा रहा हूँ, लेकिन जाहिर है कि ये दो अलग-अलग चर हैं। अगर मॉडल के एक बटन स्टाइल को गलत करने की 50% संभावना है, लेकिन उसे ठीक करना एक सस्ता प्रॉम्प्ट है, तो हमारा संयुक्त "अपेक्षित दर्द" कम है।
अपेक्षित दर्द = P(आपको इसे बदलना होगा) × बदलाव कितना दर्दनाक है
अगर आप इसे चित्रित करें, तो पहले से किए गए प्रयास और अपेक्षित दर्द के बीच एक विपरीत संबंध है।
आप ऐसा नहीं करना चाहते कि किसी कार्य की योजना बनाने में 6 घंटे बिताएँ, जिसमें से आप पहले 10 मिनट में 80% अपेक्षित दर्द को खत्म कर सकते थे।
आपको ऐसा उन सवालों पर अत्यधिक ध्यान केंद्रित किए बिना करना होगा जिनका जवाब बिना एक स्तर नीचे जाए नहीं दिया जा सकता। उदाहरण के लिए, अगर आपने "प्रोडक्ट" स्तर पर कुछ काम किया है और सभी खुले सवालों का जवाब नहीं दिया है, तो संभव है कि आपको वहीं रुकना होगा और यह समझने के लिए तकनीकी विवरणों के स्तर पर ज़ूम करना होगा कि क्या संभव है। इसके लिए कोई सही प्रक्रिया नहीं है।
हम इसी को लाभ (leverage) कहते हैं - और इसके लिए व्यावहारिक होना ज़रूरी है। अगर आप प्लानिंग के कई चरण कर रहे हैं, 50,000 फीट के दृश्य से 10,000 फीट के दृश्य तक ज़ूम इन कर रहे हैं, तो आप प्रत्येक चरण में थोड़ा सा स्टीयरिंग करना चाहेंगे ताकि यह सुनिश्चित हो सके कि आप अधिकतम संभावित अपेक्षित दर्द को खत्म कर रहे हैं।
शुभकामनाएँ।
