क्या इंजीनियर इतने अच्छे AI सिस्टम बना सकते हैं कि वे आखिरकार इंजीनियरों की ही जगह ले लें? और अगर हाँ, तो वे ऐसा करना क्यों चाहेंगे?

ज़रा सोचिए। कोड हम ही लिखते हैं। हमें ठीक-ठीक पता है कि ये सिस्टम क्या कर सकते हैं और क्या नहीं। हमें मालूम है कि हमारे काम के कौन-से हिस्से सबसे पहले स्वचालित होंगे, और कौन-से शायद कभी पूरी तरह बदले नहीं जा सकेंगे। इसलिए अगर हम अपनी ही जगह लेने वाली चीज़ बना रहे हैं, तो हम यह पूरी समझ के साथ कर रहे हैं कि हम क्या नष्ट कर रहे हैं।

मेरा मानना है, हाँ, हम यह ज़रूर करेंगे। इसलिए नहीं कि हमें करना पड़ेगा, बल्कि इसलिए कि हम करना चाहते हैं।

कॉमेडियन पूरे-पूरे सेट यह समझाने में बिताते हैं कि कॉमेडी बेमानी है। गेम डिज़ाइनर ऐसे खेल बनाते हैं जिनका लक्ष्य खिलाड़ी को अनावश्यक बना देना होता है। मैनेजर ऐसे सिस्टम खड़े करते हैं जो उनकी अपनी अहमियत खत्म करने के लिए ही बनाए जाते हैं।

अपनी ही अप्रासंगिकता गढ़ने में एक अजीब-सा आकर्षण है। आप अपने हुनर में जितने बेहतर होते जाते हैं, उतना ही उसे गैर-ज़रूरी बना देने का खिंचाव महसूस होने लगता है।

पिछले हफ्ते मैं अपने लिखे हुए ऑटोमेशन कोड की एक गड़बड़ी ठीक कर रहा था। वही कोड जो हाथ से होने वाली डेटा प्रोसेसिंग की ज़रूरत खत्म करता है, जिसमें पहले हमारी टीम के रोज़ कई घंटे चले जाते थे। उसे ठीक करते-करते मुझे एहसास हुआ कि मैं AI की मदद से ऐसा बेहतर कोड लिख रहा हूँ जो इंसानी काम को और अधिक कुशलता से हटाता है।

मैं AI का इस्तेमाल बेहतर ऑटोमेशन बनाने में कर रहा हूँ, और वही ऑटोमेशन इंसानी काम को खत्म कर रहा है। तभी विडंबना पूरी ताकत से लगी: मैं खुद को अप्रासंगिक बना रहा हूँ, उन औज़ारों की मदद से जो मुझे ही अप्रासंगिक बनाने के लिए बने हैं।

अपने ही महत्व को काटने की यह आत्म-विघातक प्रवृत्ति हर जगह दिखती है। बड़े रचनाकार किसी न किसी तरह अपनी ही अहमियत को कमजोर करने की तरफ खिंचते हैं, और अजीब बात यह है कि इससे उनका काम कम नहीं, बल्कि ज़्यादा मूल्यवान बन जाता है।

जब कॉमेडियन कॉमेडी को चीर-फाड़ करते हैं: पेशेवर आत्म-जागरूकता की कला

मुझे याद है, जब मैंने Bo Burnham का "Make Happy" देखा था, तो अचानक कुछ साफ़ हो गया। सामने एक कॉमेडियन था, जो अपने सेट का आधा हिस्सा यही समझाने में लगा रहा था कि कॉमेडी बेमानी है।

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

लेकिन "Make Happy" का असर अलग था। Burnham पूरे शो में इस बारे में बात करता रहा कि वह एक ऐसा कॉमेडियन है जिसने ज़िंदगी में कभी कुछ और किया ही नहीं। "Real life" पर उसके सारे चुटकुले पूरी तरह गढ़े हुए थे। उसका एकमात्र असली अनुभव यही था कि उसके पास असली अनुभव नहीं थे, और वह उसी पर चुटकुले बनाता था।

अंत अपनी ईमानदारी में लगभग निर्मम था। उसने कहा कि कॉमेडियन मंच पर आत्मविश्वासी दिखते हैं, लेकिन असल में उन्हें कुछ पता नहीं होता और वे कुछ कर भी नहीं सकते। फिर उसी स्वीकारोक्ति को उसने चुटकुले में बदल दिया। उसकी असुरक्षा भी मंचित थी।

उसका गाना "Art is Dead" इसे बिल्कुल साफ़ पकड़ता है। पूरा गाना इस बारे में है कि कलाकार दरअसल ध्यान चाहने वाले लोग होते हैं जिन्होंने सीख लिया है कि उन्हें जो चाहिए, वह कैसे पाया जाए। वह अपनी ही कला की निरर्थकता पर गा रहा है, और उसी समय सचमुच अर्थपूर्ण कला रच भी रहा है।

मुझे यह बहुत पसंद आया। लेकिन सच में मैं एक ऐसे कॉमेडियन को देख रहा था जो तर्क दे रहा था कि कॉमेडियन होने ही नहीं चाहिए। Burnham ने समझ लिया था कि कॉमेडी से कॉमेडी को कैसे खत्म किया जाए।

यह आत्म-विघटन सुंदर हो उठता है। वह बाहर खड़े होकर कॉमेडी का विश्लेषण नहीं कर रहा। वह कॉमेडी के भीतर से ही कॉमेडी को खत्म कर रहा है, और किसी तरह उससे ऐसी चीज़ बनती है जो सिर्फ़ विश्लेषण या सिर्फ़ कॉमेडी, दोनों में से किसी एक से भी बेहतर है।

मैं इस खिंचाव को पहचानता हूँ। मेरा पसंदीदा कोड वही है जो मेरा काम मेरे लिए करके उसे आसान बना दे। मेरी सबसे सफल प्रणालियाँ नई प्रणालियों की ज़रूरत ही कम कर देती हैं। अपनी ही अप्रासंगिकता गढ़ना किसी गहरे अर्थ में सही लगता है।

ऐसे सिस्टम बनाना जो मुझे नौकरी से निकाल सकें (और मुझे यह क्यों पसंद है)

मैं उम्मीद से पहले लोगों की टीम सँभालने लगा, ज़्यादातर संयोग से, क्योंकि जिन छोटे प्रोजेक्ट्स पर मैं काम कर रहा था, उन्हें मेरे अकेले से ज़्यादा हाथों की ज़रूरत थी।

जब दूसरे लोग आपके साथ काम करते हैं, तो आप जल्दी समझ जाते हैं कि तालमेल अपने आप में एक अलग समस्या बन जाता है। आप बस ज़्यादा लोगों को काम पर नहीं लगा सकते और उम्मीद नहीं कर सकते कि सब कुछ अपने आप सुचारु रूप से चलता रहेगा।

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

मैं ऐसे सिस्टम बनाने के जुनून में पड़ गया था जहाँ मैं गायब हो जाऊँ और कुछ भी न टूटे। हर प्रक्रिया जिसे मैंने दर्ज किया, हर कार्यप्रवाह जिसे मैंने खड़ा किया, हर निर्णय-ढाँचा जो मैंने बनाया, सबका मक़सद यही था कि कंपनी मेरे बिना भी चल सके।

दो-एक बार इसका बहुत बुरा उल्टा असर भी हुआ। मुझे उन परिस्थितियों से हटा दिया गया जहाँ से मैं वास्तव में हटना नहीं चाहता था। निकला यह कि जब आप खुद को बदले जा सकने लायक बना देते हैं, तो कभी-कभी लोग सचमुच आपको बदल भी देते हैं।

लेकिन ज़्यादातर बार यह तरीका मेरी उम्मीद से बेहतर निकला। मैं जितना बेहतर खुद को गैर-ज़रूरी बनाने में हुआ, उतना ही ज़्यादा ज़रूरी बन गया।

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

अब जब मैं टीम सँभालता हूँ, तो मैं उसी "खुद को निकाल दो" वाली सोच पर चलता हूँ। मैं जो भी बनाता हूँ, उसे इस तरह बनाता हूँ कि अगर मैं कल गायब हो जाऊँ, तो भी टीम आराम से चलती रहे। अच्छा प्रबंधन आख़िरकार मैनेजर को बदले जा सकने लायक बना देता है।

जब गेम डिज़ाइनर ऑप्टिमाइज़ेशन को खेल बना देते हैं: Factorio की परिघटना

खेलों की एक पूरी श्रेणी है जिसे ऑटोमेशन सिमुलेटर कहा जाता है, और उसका पूरा मक़सद यही होता है कि आप खुद को अनावश्यक बना दें।

"Factorio" को ही ले लीजिए। आप शुरुआत में अपने हाथों से अयस्क निकालते हैं, बुनियादी चीज़ें एक-एक करके बनाते हैं। लेकिन लक्ष्य यह नहीं कि आप यह हमेशा करते रहें। लक्ष्य यह है कि आप ऐसी फैक्ट्री बनाएँ जो यह सब आपके सोते समय अपने आप करती रहे।

मैंने दोस्तों को काम के बाद पूरी शाम कन्वेयर बेल्ट और रोबोटिक सिस्टम जमाते देखा है। जो काम उन्होंने कल हाथ से किया था, आज वह मशीनें कर रही हैं। जो चीज़ पिछले हफ्ते तक उनका ध्यान मांगती थी, वह अब उनके किसी दखल के बिना चल रही है।

यह बेहद संतोषजनक लगता है। खेल की दुनिया में आप सचमुच अपनी ही अप्रासंगिकता की ओर काम कर रहे होते हैं, और यह प्रगति, अहम होने से लेकर पूरी तरह अनावश्यक हो जाने तक, खेल का केंद्रीय सुख-चक्र बन जाती है।

Factorio में सफलता इस बात से मापी जाती है कि खेल को आपकी कितनी कम ज़रूरत है। एक पूरी तरह अनुकूलित फैक्ट्री कई घंटों तक खिलाड़ी के किसी दखल के बिना चल सकती है। आपने कुछ इतना कुशल बना दिया कि आपकी मौजूदगी वैकल्पिक हो गई।

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

यह सिर्फ़ खेल की एक युक्ति नहीं है। यही वह खिंचाव है जो इंजीनियरों को कोड लिखने वाला कोड लिखने की तरफ धकेलता है, मैनेजरों को अपने-आप चलने वाली टीमें बनाने की तरफ, और कॉमेडियनों को चुटकुलों की निरर्थकता पर चुटकुले लिखने की तरफ।

गेम डिज़ाइनरों ने एक बुनियादी बात समझ ली। हमें ऐसे सिस्टम बनाने में गहरा संतोष मिलता है जो हमें अनावश्यक बना देते हैं। अच्छा कोड और ज़्यादा कोड की ज़रूरत घटाता है। असरदार ऑटोमेशन हाथ से होने वाले काम की ज़रूरत हटाता है। सोच-समझकर बनाए गए सिस्टम, सिस्टम की ज़रूरत कम करते हैं। Factorio ने बस इस इंजीनियरिंग वाले संतोष को एक खेल में बदल दिया।

हम अपनी ही जगह लेने वाली प्रणालियाँ प्रोग्राम कर रहे हैं (और यह काम कर रहा है)

एक साल से ज़्यादा समय से मैं अपना ज़्यादातर कोड Cursor IDE में AI को आवाज़ी निर्देश देकर लिख रहा हूँ। कल मैंने लगभग बीस मिनट तक अपने कंप्यूटर से बात करके एक प्रोडक्ट पेज बना लिया, टाइप करके नहीं।

मैं काफ़ी समय से CTO की भूमिका में काम कर रहा हूँ और तरह-तरह की प्रणालियाँ बना रहा हूँ।

पिछले 8 महीनों में मैं कुछ ऑटोमेशन प्रणालियों पर काम कर रहा हूँ:

  1. एक ऐसी व्यवस्था जो डेटाबेस स्कीमा से बुनियादी CRUD API खुद बना देती है, ताकि हर बार वही घिसा-पिटा ढांचा दोबारा न लिखना पड़े
  2. एक ऐसा औज़ार जो API docs पढ़कर जोड़ने वाला कोड लिख देता है (लगभग 70% मामलों में बिना हाथ लगाए चल जाता है)
  3. ज़रूरतों के लिखित विवरण से साधारण मोबाइल ऐप तैयार करने का एक प्रयोग (अभी काफ़ी कच्चा है, लेकिन उम्मीद से ज़्यादा काम का निकला है)

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

मैं सिर्फ़ यह सब दूसरे प्रोग्रामरों के साथ होते हुए नहीं देख रहा। मैं खुद ऐसी प्रणालियाँ बना रहा हूँ।

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

जब लोग मुझसे पूछते हैं कि क्या प्रोग्रामर अनजाने में ऐसा सॉफ़्टवेयर बना देंगे जो उनकी ही जगह ले ले, तो मुझे पूरा यक़ीन है कि हम ऐसा करेंगे। अनजाने में नहीं। पूरे इरादे से। सिर्फ़ इसलिए कि ऐसा समाधान अपनी बनावट में बेहद सुघड़ लगता है।

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

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

अपनी ही जगह लेने वाली चीज़ बनाना गहराई से संतोष देने वाला अनुभव है, खासकर जब आप उसे सचमुच अच्छे से बनाते हैं।

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

लेकिन ऑटोमेशन की खूबसूरती इतनी मोहक है कि इंजीनियर अपने ही हितों के खिलाफ जाकर भी खुद को हटाने वाली दिशा में बढ़ेंगे।

हम अपनी ही अप्रासंगिकता बना रहे हैं, क्योंकि यह इतना सुघड़ काम है कि इसे अधूरा छोड़ना मुश्किल है।

पैटर्न के पीछे का पैटर्न

Bo Burnham कॉमेडी का इस्तेमाल कॉमेडी को खत्म करने में करता है। मैं ऐसी प्रबंधन प्रणालियाँ बनाता हूँ जो मैनेजरों को अनावश्यक बना देती हैं। गेम डिज़ाइनर ऐसा मनोरंजन रचते हैं जिसमें खिलाड़ियों को ही गैर-ज़रूरी कर दिया जाता है। इंजीनियर ऐसा कोड लिखते हैं जो इंजीनियरों की जगह लेता है।

यह आत्म-पीड़न या पेशेवर आत्महत्या नहीं है। इसमें कुछ और गहरा है।

मेरी समझ में असल बात यह है: हम इंजीनियरों की जगह लेने वाली AI इसलिए नहीं बना रहे कि कोई मजबूरी है। हम यह इसलिए कर रहे हैं क्योंकि हमारे सामने आई समस्याओं में यही सबसे दिलचस्प समस्या है।

मैं जिन भी इंजीनियरों को जानता हूँ, वे इस क्षेत्र में इसलिए आए क्योंकि उन्हें पहेलियाँ सुलझाना पसंद है। और सबसे बड़ी पहेली क्या है? ऐसा सिस्टम बनाना जो पहेलियाँ आपसे बेहतर सुलझा सके।

यह वैसा ही है जैसे Burnham कॉमेडी के भीतर से कॉमेडी को खत्म करता है। आप समस्या को देखते हैं और उसे हल किए बिना रह नहीं पाते। क्या आप ऐसा कोड लिख सकते हैं जो आपसे बेहतर कोड लिखे?

कुछ इंजीनियर कहते हैं कि उन्हें डर है AI उनकी नौकरियाँ ले लेगा। लेकिन ज़रा देखिए कि वे अपने खाली समय में सचमुच क्या बना रहे हैं। वे नौकरी बचाने वाली युक्तियाँ नहीं बना रहे, वे ऑटोमेशन बना रहे हैं।

हम इंजीनियरिंग के काम को स्वचालित करेंगे क्योंकि यह चुनौती इतनी दिलचस्प है कि इसे अनदेखा नहीं किया जा सकता। और जब यह काम करेगा, तो हमें उस पर गर्व होगा।

Artículos Relacionados

[hi]
[Article]
Cursor IDE में एआई के लिए नियम: विशेषज्ञ एआई सहायक हेतु दिशानिर्देश

Cursor IDE में एआई के लिए नियम: विशेषज्ञ एआई सहायक हेतु दिशानिर्देश

Cursor IDE में मेरे आजमाए हुए नियम, जो एआई कोडिंग को साफ शैली, सख्त त्रुटि-प्रबंधन और सुव्यवस्थित कार्यप्रवाह के साथ लगातार अधिक भरोसेमंद बनाते हैं।

[hi]
[Article]
Claude Code के नियम: कृत्रिम बुद्धिमत्ता के लिए CLAUDE.md निर्देश

Claude Code के नियम: कृत्रिम बुद्धिमत्ता के लिए CLAUDE.md निर्देश

मैं Claude Code में अपने वैश्विक `CLAUDE.md` नियम अलग रखता हूँ, ताकि निजी पसंद और परियोजना-विशेष निर्देश साफ़ रहें और एजेंट हर रिपॉज़िटरी में एक जैसा काम करे।

[hi]
[Article]
n8n और LLM की मदद से ईमेल वर्गीकरण अपने-आप कैसे करें

n8n और LLM की मदद से ईमेल वर्गीकरण अपने-आप कैसे करें

n8n और GPT-5-nano पर आधारित मेरा तीन महीने से परखा हुआ तरीका, जो तय करता है कि किस ईमेल को संग्रहित करना है, क्या पढ़ना है और किसका जवाब देना है।

लेखक परिचय

Kirill Markin

Kirill Markin

व्यावहारिक इंजीनियरिंग प्रबंधक

ozma.io के पूर्व संस्थापक

एआई और डेटा इंजीनियर

9,500+
subscribers

Compartir este artículo