- इस आम धारणा के विपरीत कि AI डेवलपर्स को ‘मैनेजर’ या ‘एडिटर’ बना देगा, लेखक ‘सर्जन की तरह कोडिंग करने’ का दृष्टिकोण सुझाते हैं और मुख्य काम पर फोकस करने की शैली पर ज़ोर देते हैं
- जैसे सर्जन सहायक स्टाफ के समर्थन से सर्जरी के केवल सबसे अहम हिस्से पर ध्यान देता है, वैसे ही AI टूल्स के जरिए सहायक काम डेलीगेट करके डेवलपर मूल समस्या-समाधान पर केंद्रित रह सकता है
- मुख्य काम (जैसे UI prototyping) अभी भी इंसान सीधे करते हैं, लेकिन documentation, bug fixing, code exploration जैसे दोहराए जाने वाले काम AI agent संभाल सकते हैं
- AI को साधारण दोहराव वाले काम सौंपने से status hierarchy की समस्या के बिना grunt work डेलीगेट किया जा सकता है, और 24x7 उपलब्धता के कारण देर रात या लंच टाइम में भी काम दिया जा सकता है
- यह तरीका Andrej Karpathy के ‘autonomy slider’ कॉन्सेप्ट से जुड़ता है, जो संकेत देता है कि काम की autonomy के स्तर के अनुसार AI उपयोग की रणनीति बदलनी चाहिए
सर्जन की तरह कोडिंग करना: मुख्य अवधारणा
- AI डेवलपर को मैनेजर या एडिटर बना देगा — इस सामान्य भविष्यवाणी से असहमति जताते हुए, लेखक सर्जन (Surgeon) की तरह काम करने का तरीका सुझाते हैं
- सर्जन खुद ऑपरेशन करता है, लेकिन सपोर्ट टीम की मदद से तैयारी और सहायक काम करवाकर केवल उन मुख्य कार्यों पर ध्यान देता है जिनमें उसकी विशिष्ट विशेषज्ञता चाहिए
- डेवलपर भी AI को सहायक स्टाफ की तरह इस्तेमाल कर मुख्य रचनात्मक काम पर फोकस कर सकता है
- लेखक, जो UI prototyper हैं, AI टूल्स की मदद से अपने समय का 100% सार्थक काम में लगाने को लक्ष्य बताते हैं
- AI से किए जा सकने वाले सहायक काम डेलीगेट करके productivity को अधिकतम किया जा सकता है
वे सहायक काम जो AI को डेलीगेट किए जा सकते हैं
- सहायक कामों की सूची जिन्हें AI पर्याप्त रूप से कर सकता है
- बड़े बदलाव से पहले codebase से जुड़ी guide लिखना
- बड़े बदलाव के प्रयास के लिए ‘spike’ code draft बनाना
- स्पष्ट specification वाले TypeScript errors या bugs को ठीक करना
- मौजूदा विकसित हो रही feature के लिए documentation लिखना
- ऐसे काम asynchronously background में चलाए जा सकते हैं
- लंच टाइम या रात के दौरान भी AI काम करता रह सकता है, और अगले दिन तुरंत review किया जा सकता है
- इससे “तैयार ऑपरेशन थिएटर में प्रवेश करने वाले सर्जन” की तरह, सारी तैयारी पूरी होने के बाद मुख्य coding पर फोकस किया जा सकता है
autonomy slider पर ध्यान दें (Mind the autonomy slider)
- AI के उपयोग का तरीका मुख्य काम और सहायक काम के बीच काफी अलग होता है
- मुख्य design और prototyping अभी भी इंसान सीधे करते हैं, जहाँ तेज़ feedback loop और high visibility महत्वपूर्ण हैं
- दूसरी ओर, सहायक कामों में AI को लंबे समय तक autonomous तरीके से काम करने देना अधिक प्रभावी है
- लंबे unsupervised sessions के लिए लेखक Claude Code को, और हाल में Codex CLI को पसंद करते हैं
- यह अंतर Andrej Karpathy के ‘autonomy slider’ कॉन्सेप्ट से मिलता-जुलता है
- autonomy के स्तर के अनुसार ज़रूरी tools और mindset बदलते हैं, और इन्हें गड़बड़ाना जोखिमभरा है
AI और ‘software surgeon team’ की अवधारणा
- “software surgeon” की अवधारणा 1975 में Fred Brooks की "『The Mythical Man-Month』" में Harlan Mills द्वारा प्रस्तावित एक पुराना विचार है
- इसमें एक ‘chief programmer’ केंद्र में होता है, और ‘copilot’ व administrative staff उसका समर्थन करते हैं
- पहले यह सहायक भूमिका इंसान निभाते थे, लेकिन अब AI इसे आर्थिक रूप से व्यावहारिक रूप में बदल रहा है
- लेखक के अनुसार इस बदलाव का मतलब केवल लागत घटाना नहीं है
- यह status hierarchy की समस्या को कम करता है
- दोहराए जाने वाले और उबाऊ ‘grunt work’ को AI को सौंपकर, टीम में असंतुलित काम-बाँटने की समस्या कम की जा सकती है
- AI 24x7 उपलब्ध है, इसलिए यह इंसानी intern के लिए असंभव रात के शोध या code analysis जैसे काम भी कर सकता है
Notion और ‘सर्जन की तरह काम करने’ का विस्तार
- लेखक बताते हैं कि उनके कार्यस्थल Notion में यह दृष्टिकोण वास्तव में लागू हो रहा है
- कंपनी स्तर पर AI coding tools के उपयोग को सक्रिय रूप से समर्थन दिया जा रहा है, और codebase भी उसी के अनुरूप डिज़ाइन किया गया है
- खासकर बड़े codebase में नए जुड़े डेवलपर्स के लिए इसका productivity लाभ बड़ा है
- product के नज़रिए से भी Notion प्रोग्रामर्स से आगे बढ़कर सभी knowledge workers तक ‘सर्जन की तरह काम करने’ का तरीका फैलाना चाहता है
- मुख्य लक्ष्य मुख्य काम को डेलीगेट करना नहीं, बल्कि कम-महत्वपूर्ण सहायक और दोहराए जाने वाले कामों की पहचान कर उन्हें डेलीगेट करना है, ताकि लोग सबसे महत्वपूर्ण काम पर फोकस कर सकें
7 टिप्पणियां
ऐसा लगता है कि इसका मतलब है कि मुख्य काम पर फोकस करें, और आसपास के काम AI को सौंप दें। इस बात से मैं काफ़ी हद तक सहमत हूँ, और कुछ ऐसे काम जो core domain नहीं हैं लेकिन कुछ SaaS से बदले जा सकते हैं, या admin काम, उन्हें AI से बदलना संभव लगता है.
और ज़्यादा बहस की बात शायद यह होगी कि क्या मुख्य काम को AI से बदला जा सकता है। आख़िरकार रुझान उसी दिशा में जाएगा जहाँ नतीजे बेहतर होंगे। IOI या LeetCode के सवाल हल करते हुए देखें तो AI कभी-कभी इंसानों से कहीं बेहतर coding क्षमता दिखाता है। जल्दबाज़ी में अनुमान लगाना मेरी क्षमता से बाहर लगता है, इसलिए शायद हमें इंतज़ार करके देखना चाहिए।
यह उपमा मूल बात को समझे बिना की गई पूरी तरह गलत तुलना है.
सर्जरी एक ऐसा काम है जिसे वापस नहीं लिया जा सकता, जबकि प्रोग्रामिंग ऐसा काम है जिसे वापस लिया जा सकता है (यानी save and load संभव है).
अगर सर्जरी भी reversible हो जाए, तो सर्जन भी ऑपरेशन करना जानने वाले जूनियर कर्मचारियों से काम करवाएँगे, और खुद पीछे से design, review और management करना ज़्यादा efficient होगा. गलती हो जाए तो बस वापस कर देंगे, बात खत्म.
सहमत हूँ। इसी तरह मुझे लगता है कि लोग अक्सर software engineering को construction engineering समझ बैठते हैं.
अगर सच में किसी सर्जन की तरह कोडिंग करनी है, तो क्या कोडिंग सिर्फ उन्हीं लोगों को करने नहीं देनी चाहिए जिन्होंने Computer Science में graduation किया हो? Computer Science में सीटें बढ़ें तो programmers एकजुट होकर हड़ताल भी करें......
कोडिंग सहायक क्यों नहीं है!?
हाहाहाहाहाहाहाहाहाहाहाहाहाहाहाहा
Hacker News राय
अगर कोई नया सर्जन यह भरोसा करके ऑपरेशन शुरू करे कि नर्स या एनेस्थीसिया डॉक्टर उसकी गलतियाँ रोक देंगे, तो वह बहुत जल्दी मरीज को मार सकता है
सिर्फ़ इसलिए कि सर्जिकल टीम की ज़रूरत होती है, इसका मतलब यह नहीं कि सीनियर सर्जन की ट्रेनिंग ज़रूरी नहीं है
समस्या तब होती है जब अनुभवहीन सर्जन यह सोचता है, “नर्स स्कैल्पेल पकड़ा देगी, तो मुझे ख़ुद सीखने की क्या ज़रूरत है”
अगर आखिरकार मरीजों की क़ीमत पर सीखना ही पड़े तो ठीक, लेकिन अगर ऐसा न करना पड़े तो पहले मेडिकल स्कूल जाना चाहिए
इसलिए पूरी पोस्ट में Dunning-Kruger effect महसूस होता है (एक cognitive bias जिसमें कम क्षमता वाला व्यक्ति अपनी क्षमता को वास्तविकता से कहीं अधिक आँकता है)
मैं लंबे समय से कहता आया हूँ कि सॉफ़्टवेयर इंजीनियरों को The Mythical Man-Month पढ़नी चाहिए
पिछले 25 सालों में waterfall से agile की ओर बदलाव की तरह विकास के तरीक़े तेज़ी से बदले हैं
लेकिन LLM-आधारित development (Codex, Claude Code आदि) करते हुए उल्टा 70~80 के दशक के development pattern की ओर वापसी जैसा महसूस होता है
अब हम मानो कैथेड्रल डिज़ाइन करने की तरह architecture पर सोच सकते हैं, और बारीक implementation दूसरों को सौंप सकते हैं
सर्जरी में एक समय पर एक ही व्यक्ति काम करता है, लेकिन सॉफ़्टवेयर पर कई लोग एक साथ काम कर सकते हैं
यह ज़्यादा sports team जैसा है, और हमारी practice व coaching की कमी के कारण polish आने में समय लगता है
अब coding से ज़्यादा design पर ध्यान देना संभव हो गया है
असल में अगर आप ऊँची इमारत बना रहे हों, तो स्टील की quality और bolts कहाँ से आए इस तक पर ध्यान देना पड़ता है
इन्हें नज़रअंदाज़ करना ख़तरनाक है
यह उपमा शाब्दिक और रूपक—दोनों अर्थों में ग़लत है
सर्जन सिर्फ़ मज़दूर नहीं होता, बल्कि पूरे ऑपरेशन को मैनेज करने वाला प्रबंधक होता है, और व्यवहार में एनेस्थीसिया डॉक्टर सबसे अहम होता है
साथ ही “grunt work” जैसा विचार भी मूल रूप से ग़लत नज़रिए से आता है
ख़ुद को सर्जन और दूसरों को सहायक स्टाफ़ मानना आत्मकेंद्रित दृष्टिकोण है
Brooks के “Chief Programmer” कॉन्सेप्ट की तरह, lead developer टीम के support की बदौलत काम कर पाता है
लेखक juniors को सिर्फ़ निचले दर्जे के कामगार नहीं, बल्कि mentees के रूप में देखता है
उपमा पूरी तरह सटीक नहीं है, लेकिन AI coding tools पर इसका संदेश सम्मान के योग्य है
उदाहरण के तौर पर यह भी कहा गया कि इतिहास में एनेस्थीसिया के बिना भी सर्जरी हुई है
जैसे framework समझाने के लिए programmers को carpenter से तुलना करना, जबकि असली कारीगर हर हिस्से को पूरी तरह polish नहीं करता
यह उपमा मुझे पसंद आई, इसलिए मैं इसे आगे इस्तेमाल करने का सोच रहा हूँ
एक और उपमा classical painter’s studio की हो सकती है
Rembrandt और Rubens के यहाँ शिष्य canvas तैयार करते थे और कुछ हिस्सों में रंग भी भरते थे, जबकि उस्ताद सिर्फ़ मुख्य हिस्से ख़ुद बनाता था
इसके उलट, romantic era के बाद यह आदर्श उभरा कि कलाकार अकेले सब कुछ पूरा करे
कुछ programmer Turner की तरह अकेले सृजन करना चाहते हैं, लेकिन मैं Rembrandt की तरह बड़ा चित्र बनाना चाहता हूँ और details AI या juniors को सौंपना चाहता हूँ
code quality अच्छी होनी चाहिए ताकि user feedback पर तेज़ी से प्रतिक्रिया दी जा सके
बात सिर्फ़ “जल्दी code लिखकर ख़त्म कर देने” की नहीं, बल्कि ऐसी संरचना की है जो बदलाव की लागत कम करे
अगर Rembrandt-स्टाइल approach से अच्छा code निकलता है तो ठीक है, लेकिन उसके सबूत अभी कम हैं
मैंने भी कुछ महीनों तक Claude इस्तेमाल किया है, और मुझे लगा कि ख़ुद coding करना ज़्यादा efficient है
लेकिन इस बार जब मैंने MySQL 8→9 में बड़े DB का upgrade किया, तो Claude से संभावित समस्याओं वाली queries ढूँढने को कहा, और हैरानी की बात यह रही कि ज़्यादातर सही निकलीं
वह परफेक्ट नहीं था, लेकिन उसने debugging time बहुत कम कर दिया
ऐसा लगा कि LLM का ख़ुद code लिखने से ज़्यादा मूल्य risk points पहचानने में है
पुराने codebase में stack trace दे दो, तो LLM शुरुआती debugging direction बता देता है
performance issue ठीक करते समय भी उससे यह verify कराया जा सकता है कि अलग code paths एक ही result दे रहे हैं या नहीं
अभी code writing की क्षमता autocomplete के स्तर की है, लेकिन efficiency साफ़ तौर पर बढ़ती है
Dan North की Software Faster प्रस्तुति याद आ गई
“सॉफ़्टवेयर में भी सर्जरी की तरह, समस्या हल करने के लिए जितना न्यूनतम ज़रूरी हो उतना ही करो” — यह बात प्रभावशाली लगी थी
लेकिन यह लेख उस दर्शन से काफ़ी दूर है
इसलिए अब मुझे लगता है कि मैं अक्सर amputation surgery करने वाला सर्जन बन गया हूँ
Chief Programmer Team संरचना फिर से लोकप्रिय होती दिख रही है
इस बार फ़र्क़ इतना है कि टीम में इंसानों की जगह AI agents भी शामिल हैं
Fred Brooks का विचार फिर से ध्यान खींच रहा है
अगर 10x developer को एक सक्षम टीम दे दी जाए, तो meetings या Jira management में बर्बाद होने वाला समय घट सकता है
जब उन्हें ऊँची तनख़्वाह दी जाती है, तो उनके समय का अधिकतम मूल्य निकालना चाहिए
autonomy spectrum, या delegation spectrum, को समझना AI coding tools का अच्छा उपयोग करने की कुंजी है
इंजीनियर delegation के उतने आदी नहीं होते, लेकिन founders इसे अक्सर जल्दी सीख लेते हैं
“सर्जन महत्वपूर्ण काम पर ध्यान देता है” इस अभिव्यक्ति पर कहा गया कि वास्तव में सभी support tasks बराबर महत्वपूर्ण होते हैं
विनम्र रहकर अपने आसपास के support को सम्मान देना चाहिए, और उन्हें भी उसी तरह support करना चाहिए