रचनाकार अपने ही काम का मज़ाक उड़ाते हैं: उदाहरण और पैटर्न

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

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

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

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

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

पिछले हफ्ते मैं अपने लिखे हुए automation code को debug कर रहा था। वही code जो manual data processing की ज़रूरत खत्म करता है, जिसमें पहले हमारी टीम के रोज़ कई घंटे जाते थे। उसे ठीक करते-करते मुझे एहसास हुआ कि मैं AI की मदद से ऐसा बेहतर code लिख रहा हूँ जो इंसानी काम को और कुशलता से replace करता है।

मैं AI का इस्तेमाल बेहतर automation बनाने में कर रहा हूँ, और वह automation इंसानी काम खत्म कर रही है। तभी उसकी irony मेरे सामने साफ़ हुई: मैं खुद को obsolete बना रहा हूँ, उन tools की मदद से जो मुझे obsolete बनाने के लिए ही बने हैं।

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

जब कॉमेडियन कॉमेडी को dissect करते हैं: पेशेवर self-awareness की कला

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

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

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

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

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

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

यह self-destruction सुंदर लगने लगती है। वह बाहर से खड़े होकर कॉमेडी का विश्लेषण नहीं कर रहा। वह कॉमेडी के भीतर से कॉमेडी को खत्म कर रहा है, और किसी तरह इससे analysis और comedy दोनों से बेहतर चीज़ बनती है।

मैं इस impulse को पहचानता हूँ। मेरा पसंदीदा code वह है जो मेरा काम मेरे लिए करके मेरा काम आसान कर देता है। मेरे सबसे सफल systems, systems की ज़रूरत ही कम कर देते हैं। अपनी ही अप्रासंगिकता बनाना सही लगता है।

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

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

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

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

मैं ऐसे systems बनाने को लेकर obsessed हो गया जहाँ मैं गायब हो जाऊँ और कुछ भी न टूटे। हर process जिसे मैंने document किया, हर workflow जिसे मैंने set up किया, हर decision framework जो मैंने बनाया, सबका मक़सद यही था कि company मेरे बिना भी चल सके।

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

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

ज़्यादातर managers information छुपाते हैं और dependencies बनाते हैं, क्योंकि उन्हें replace हो जाने का डर होता है। वे bottleneck बन जाते हैं। इसका उल्टा काम करता है: अपने bottleneck status को खत्म करने पर सक्रिय रूप से काम करना आपको बिल्कुल अलग तरह से valuable बना देता है।

अब जब मैं teams manage करता हूँ, तो वही "fire myself" logic अपनाता हूँ। मैं जो भी बनाता हूँ, उसे इस तरह बनाता हूँ कि अगर मैं कल गायब हो जाऊँ, तो भी टीम आराम से चलती रहे। अच्छी management आख़िरकार manager को replaceable बना देती है।

ऐसे game designers जो optimization को ही game बना देते हैं: Factorio phenomenon

गेम्स की एक पूरी category है जिसे automation simulators कहा जाता है, जहाँ पूरा point यही होता है कि आप खुद को अनावश्यक बना दें।

"Factorio" को ही ले लीजिए। आप शुरुआत में अपने हाथों से ore निकालते हैं, basic items एक-एक करके craft करते हैं। लेकिन लक्ष्य यह नहीं कि आप यह हमेशा करते रहें। लक्ष्य यह है कि आप ऐसी factory बनाएँ जो यह सब आपके सोते समय अपने आप करती रहे।

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

यह बहुत संतोषजनक लगता है। गेम की दुनिया में आप सचमुच अपनी ही अप्रासंगिकता की ओर काम कर रहे होते हैं, और यह progression, essential होने से लेकर पूरी तरह unnecessary हो जाने तक, reward loop का केंद्र है।

Factorio में सफलता इस बात से मापी जाती है कि गेम को आपकी कितनी कम ज़रूरत है। एक perfectly optimized factory कई घंटों तक खिलाड़ी की कोई intervention के बिना चल सकती है। आपने कुछ इतना efficient बना दिया कि आपकी मौजूदगी optional हो गई।

गेम designers ने ऐसा system बनाया जिसमें ultimate achievement खिलाड़ी को redundant बना देना है। उन्होंने automation के concept को entertainment में बदल दिया। लोग ऐसे jobs से घर आते हैं जहाँ शायद उन्हें खुद replaceable महसूस होता है, और फिर वे खुशी-खुशी ऐसा game खेलते हैं जो खुद को replace करने के बारे में है।

यह सिर्फ़ game mechanic नहीं है। यही वही drive है जो engineers को code लिखने वाला code लिखने की तरफ धकेलती है, managers को self-running teams बनाने की तरफ, और comedians को jokes की pointlessness पर jokes लिखने की तरफ।

गेम designers ने कुछ बुनियादी बात समझ ली। हमें ऐसे systems बनाने में गहरा संतोष मिलता है जो हमें अनावश्यक बना देते हैं। Smart code और code की ज़रूरत घटाता है। Effective automation manual work की ज़रूरत हटाती है। Well-designed systems, systems की ज़रूरत कम करते हैं। Factorio ने बस इस engineering satisfaction को एक game में बदल दिया।

हम अपना ही replacement program कर रहे हैं (और यह काम कर रहा है)

एक साल से ज़्यादा समय से मैं अपना ज़्यादातर code Cursor IDE में AI voice commands के ज़रिए लिख रहा हूँ। कल मैंने लगभग बीस मिनट तक अपने कंप्यूटर से बात करके एक product page बना लिया, typing करके नहीं।

मैं कुछ समय से CTO के रूप में काम कर रहा हूँ और systems बना रहा हूँ।

पिछले 8 महीनों में मैं कुछ automation systems पर काम कर रहा हूँ:

1. ऐसा system जो database schema से basic CRUD APIs generate करता है, ताकि हमें बार-बार वही boilerplate न लिखना पड़े
2. एक scraper जो API docs पढ़ता है और integration code लिखता है (लगभग 70% बार manual fixes के बिना काम कर जाता है)
3. requirements से simple mobile apps generate करने का एक experiment (अभी काफ़ी rough है, लेकिन हैरान करने वाली हद तक functional है)

ये ऐसे AI assistants नहीं हैं जो chat में programmers की मदद करते हों। ये ऐसे systems हैं जहाँ LLM codebase का ज़्यादातर हिस्सा अपने आप लिखते हैं, और programmers सिर्फ़ review करते हैं और जो ठीक करना हो उसे ठीक करते हैं। हम अभी भी ज़रूरी हैं, लेकिन हमारी भूमिका code लिखने से बदलकर code generation orchestrate करने की हो गई है।

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

मैं वही pattern पहचानता हूँ जिसके बारे में मैंने comedians और game designers के संदर्भ में लिखा। इन systems के manual work को कितनी साफ़-सुथरी तरह replace करने में एक खास संतोष है।

जब लोग मुझसे पूछते हैं कि क्या programmers गलती से ऐसा software बना देंगे जो उन्हें replace कर दे, तो मुझे पूरा यक़ीन है कि हम बनाएँगे। गलती से नहीं। जानबूझकर। सिर्फ़ उसकी elegance के लिए।

इंजीनियर अपनी ही अप्रासंगिकता को engineer करें, इससे ज़्यादा recursive बात क्या होगी। हम ऐसे systems बनाते हैं जो हमें गैर-ज़रूरी बना दें। हमें ठीक-ठीक पता है कि हम क्या कर रहे हैं, और फिर भी हम करते रहते हैं, क्योंकि automation की elegance का विरोध करना मुश्किल है।

यह irony मुझसे छिपी नहीं है। मैं AI का इस्तेमाल ऐसे systems लिखने में कर रहा हूँ जो human programmers को replace करते हैं, और साथ ही इस पूरी process की साफ़-सुथरी कार्यक्षमता में मुझे सचमुच आनंद मिलता है। हर बार जब मैं एक और manual step हटाता हूँ, हर बार जब मैं किसी ऐसी चीज़ को automate करता हूँ जिसमें पहले human judgment चाहिए होती थी, तो मुझे वही संतोष मिलता है जो एक perfectly optimized algorithm से मिलता है।

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

मुझे नहीं लगता कि यह रातोंरात होगा। यहाँ बहुत बड़ा last-mile problem है। edge cases संभालने के लिए AI systems को fine-tune करने में हमारी सोच से ज़्यादा समय लगेगा। और अभी के लिए, इन systems को बेहतर बनाना भी engineers के ही जिम्मे है।

लेकिन automation की सुंदरता इतनी compelling है कि इंजीनियर अपने ही हितों के खिलाफ जाकर भी खुद को eliminate करने की तरफ बढ़ेंगे।

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

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

Bo Burnham कॉमेडी का इस्तेमाल कॉमेडी को खत्म करने में करता है। मैं ऐसे management systems बनाता हूँ जो managers को अनावश्यक बनाते हैं। गेम designers ऐसा entertainment बनाते हैं जिसमें खिलाड़ियों को ही गैर-ज़रूरी किया जाता है। इंजीनियर ऐसा code लिखते हैं जो इंजीनियरों को replace करता है।

यह masochism या career suicide नहीं है। इसमें कुछ और गहरा है।

मेरी theory यह है कि असल में हो क्या रहा है: हम इंजीनियरों को replace करने वाली AI इसलिए नहीं बना रहे क्योंकि हमें बनानी ही है। हम यह इसलिए कर रहे हैं क्योंकि यह हमारे सामने आया सबसे दिलचस्प problem है।

मैं जिन भी engineers को जानता हूँ, वे इस field में इसलिए आए क्योंकि उन्हें puzzles solve करना पसंद है। और ultimate puzzle क्या है? ऐसा system बनाना जो puzzles आपसे बेहतर solve कर सके।

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

कुछ engineers कहते हैं कि उन्हें AI के उनकी jobs ले लेने की चिंता है। लेकिन देखिए कि वे अपने spare time में वास्तव में क्या बना रहे हैं। वे job protection नहीं बना रहे, वे automation बना रहे हैं।

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