नये कागज और कलम, नये कलाकार
जब कोड एक मध्यवर्ती कलाकृति बन जाता है, तो सॉफ़्टवेयर का लेखक कौन होता है?
लगभग छह महीने के इंजीनियरिंग कार्य में, मैंने केवल प्राकृतिक भाषा, उत्पाद दस्तावेज़, वास्तुशिल्प बाधाएं, रनटाइम परिणाम और स्वीकृति प्रतिक्रिया का उपयोग करके कोडिंग एजेंटों के साथ कई अप्रकाशित उत्पाद बनाए। उत्पादों में डेस्कटॉप ऐप्स, ब्राउज़र एक्सटेंशन, बैकएंड सेवाएं और डेटाबेस शामिल हैं।
मैंने कोड की एक भी पंक्ति नहीं लिखी. न ही मैंने एक पढ़ा.
लेकिन इसका मतलब यह नहीं है कि मैंने उत्पाद एआई को सौंप दिये। मैंने फिर भी तय किया कि उन्हें कौन सी समस्याएँ हल करनी चाहिए, परिभाषित किया कि सिस्टम को कैसे काम करना चाहिए, निर्णय लिया कि कौन सी सीमाएँ पार नहीं की जा सकतीं, सत्यापित किया कि क्या परिणाम विश्वसनीय थे, और अंतिम सॉफ़्टवेयर की ज़िम्मेदारी ली। जो बदलाव आया वह केवल कार्यान्वयन के साथ मेरा इंटरफ़ेस था।
इसने मुझे उस प्रश्न पर पुनर्विचार करने के लिए मजबूर किया जो एक बार सरल लगता था: यदि कोई अब हाथ से कोड नहीं लिखता है, लेकिन फिर भी काम को परिभाषित करता है, यह तय करता है कि यह सफल होगा या नहीं, और इसके लिए ज़िम्मेदार है, तो क्या वे अभी भी सॉफ़्टवेयर के लेखक हैं?
यह अभ्यास यह साबित नहीं करता है कि सभी सॉफ़्टवेयर इस तरह से बनाए जा सकते हैं। इससे यह भी साबित नहीं होता कि ये अप्रकाशित उत्पाद बाज़ार में सफल होंगे। लेकिन हम जिस प्रकार के एप्लिकेशन बनाते हैं, उनके लिए कोडिंग एजेंटों पर केंद्रित वर्कफ़्लो अब केवल तेजी से प्रोग्राम करने का एक तरीका नहीं है। यह एक इंजीनियरिंग दृष्टिकोण बनता जा रहा है जो योजना, कार्यान्वयन, परीक्षण, सुधार और पुनरावृत्ति को बनाए रख सकता है।
महत्वपूर्ण परिवर्तन यह नहीं है कि "एआई कोड लिख सकता है।" कार्यान्वयन सॉफ़्टवेयर निर्माण के सबसे दुर्लभ भागों में से एक हुआ करता था; अब यह पृष्ठभूमि में जाने लगा है।
जब कार्यान्वयन अब सबसे दुर्लभ हिस्सा नहीं रह गया है, तो मानव कार्य का क्या होगा?
यही इस निबंध का प्रश्न है.
एआई की सीमा बढ़ रही है
AI कभी भी एक निश्चित शब्द नहीं रहा है। लोग किसी चीज़ को AI कहते हैं जबकि कंप्यूटर अभी तक इसे विश्वसनीय रूप से नहीं कर सकता है; एक बार जब क्षमता परिपक्व हो जाती है और रोजमर्रा के उत्पादों में प्रवेश कर जाती है, तो यह जल्दी ही सामान्य तकनीक बन जाती है और एआई की तरह दिखना बंद हो जाती है।
मेरा अपना मार्ग भी इसी सीमा का अनुसरण करता रहा है। मिडिल स्कूल और विश्वविद्यालय में, मैंने पहिये वाले रोबोटों पर काम किया, सेंसर और फीडबैक नियंत्रण का उपयोग करके उन्हें पथों का अनुसरण करने, बाधाओं से बचने और गठन में समन्वय करने के लिए प्रेरित किया। ग्रेजुएट स्कूल के दौरान, मैंने कंप्यूटर विज़न का अध्ययन किया और साथ ही नव स्थापित SenseTime में शुरुआती संस्थापक कर्मचारी के रूप में शामिल हुआ। मैंने स्मार्टफोन और हाई-स्पीड रेल सहित बड़े पैमाने के अनुप्रयोगों में चेहरे की जीवंतता का पता लगाने और औद्योगिक दृष्टि प्रौद्योगिकियों को लाने में मदद की। आज, सामान्य प्रयोजन के फाउंडेशन मॉडल और उनके द्वारा संचालित एजेंटों ने सीमा को फिर से आगे बढ़ा दिया है। ये प्रणालियाँ अब केवल पृथक समस्याओं का समाधान नहीं करतीं। वे लक्ष्यों को समझना शुरू कर रहे हैं, उपकरणों का उपयोग कर रहे हैं और फीडबैक के जवाब में कार्य करना जारी रख रहे हैं; मेरा काम इन उत्पादों की ओर भी बढ़ गया है। पीछे मुड़कर देखें, तो गति को नियंत्रित करने और छवियों को समझने से लेकर संपूर्ण कार्यों को पूरा करने तक, मशीनें काम की लंबी और अधिक संपूर्ण श्रृंखलाएं अपना रही हैं।
इस निबंध में, फिर, एआई मुख्य रूप से सामान्य प्रयोजन फाउंडेशन मॉडल द्वारा संचालित एजेंटों को संदर्भित करता है, जिसमें प्रतिनिधि उदाहरण के रूप में कोडिंग एजेंट होते हैं। उनका विकास दीर्घ-क्षितिज कार्यों के स्वायत्त निष्पादन, क्रमिक आत्म-विकास और यहां तक कि अपने स्वयं के उत्तराधिकारियों को प्रशिक्षित करने की क्षमता की ओर इशारा करता है।
2025 में, आंद्रेज कारपैथी ने प्रोग्रामिंग की एक ढीली शैली का वर्णन करने के लिए "वाइब कोडिंग" का उपयोग किया: एआई को बताएं कि आप क्या चाहते हैं, जेनरेट किए गए कोड को स्वीकार करें, त्रुटि संदेशों को वापस फ़ीड करें, और यहां तक कि यह भी भूल जाएं कि कोड मौजूद है। [1] लेकिन यहां तक जाने देने की एक पूर्व शर्त है: विफलता की लागत कम होनी चाहिए। उस समय, गंभीर उत्पादों के लिए, हम अभी भी कर्सर का उपयोग करते थे। मानव डेवलपर्स ने काम का नेतृत्व किया और कोड के लिए जिम्मेदार बने रहे; एजेंट ने सहायता की.
2026 की शुरुआत में, हमने सीमा को फिर से आगे बढ़ते देखा। करपैथी ने बाद में काम करने के नए तरीके को "एजेंट इंजीनियरिंग" कहा: डेवलपर्स अब केवल कोड को पूरा करने के लिए एआई का उपयोग नहीं करते हैं, बल्कि समीक्षा और गुणवत्ता की जिम्मेदारी बरकरार रखते हुए इंजीनियरिंग कार्यों को पूरा करने के लिए एजेंटों को व्यवस्थित और पर्यवेक्षण करते हैं। [2] नाम महत्वपूर्ण नहीं है। जो बात मायने रखती है वह यह है कि एआई एक समय में एक सुझाव देने से लेकर बाधाओं के भीतर निरंतर कार्रवाई की ओर बढ़ रहा है।
कुछ सॉफ़्टवेयर निर्माताओं के लिए, इरादे व्यक्त करने के लिए प्राकृतिक भाषा और दस्तावेज़ पहले से ही एक नई परत बन रहे हैं।
कोड एक मध्यवर्ती कलाकृति बनता जा रहा है
कंप्यूटिंग का इतिहास अमूर्त परतों को जोड़ने का इतिहास भी है।
लोगों ने पहले स्विच और पैच केबल वाली मशीनें संचालित कीं। फिर मशीन कोड, असेंबली और उच्च स्तरीय प्रोग्रामिंग भाषाएँ आईं। प्रत्येक नई परत ने नीचे दी गई कुछ जटिलताओं को छुपाया और लोगों को उनके इरादों के करीब काम करने दिया।
कोडिंग एजेंट सॉफ़्टवेयर विकास में एक नई अमूर्त परत जोड़ते हैं। वे एक गैर-नियतात्मक सुपर-कंपाइलर की तरह हैं: एक पारंपरिक कंपाइलर औपचारिक रूप से निर्दिष्ट प्रोग्राम को मशीन निर्देशों में अनुवादित करता है, जबकि एक कोडिंग एजेंट मानव इरादे को इंटरफेस, डेटा, सेवाओं और कोड में प्रकट करने का प्रयास करता है।
अंतर मायने रखता है. मानव भाषा अस्पष्ट है. आवश्यकताएँ अक्सर अधूरी होती हैं, और बाधाएँ टकराव पैदा कर सकती हैं। एक एजेंट यांत्रिक रूप से किसी वाक्य को एक सही परिणाम में अनुवादित नहीं कर सकता है। इसे समझ, योजना, कार्यान्वयन, निष्पादन और सत्यापन के माध्यम से चक्रित करना होगा।
प्राकृतिक भाषा ने प्रोग्रामिंग भाषाओं का स्थान नहीं लिया है। अधिक सटीक रूप से, प्राकृतिक भाषा और दस्तावेज़ लोगों द्वारा बनाए रखा जाने वाला एक इरादा परत बन रहे हैं, जबकि कोड तेजी से एजेंटों द्वारा उत्पन्न और बनाए रखा गया कार्यान्वयन माध्यम के रूप में कार्य करता है।
यह कोड को एक मध्यवर्ती आर्टिफैक्ट की तरह बनाता है, लेकिन "मध्यवर्ती" का मतलब महत्वहीन नहीं है। कोड को अभी भी सही, सुरक्षित और रखरखाव योग्य होना चाहिए। इसे किसी व्यक्ति द्वारा पंक्ति दर पंक्ति लिखने और पढ़ने की आवश्यकता नहीं हो सकती है। अधिकांश प्रोग्रामर कंपाइलर द्वारा उत्सर्जित मशीन कोड का निरीक्षण नहीं करते हैं, लेकिन प्रोग्राम जो करता है उसके लिए वे जिम्मेदार रहते हैं।
इससे वह बदल जाता है जिसे हमें स्पष्ट करने की आवश्यकता है।
दस्तावेज़ीकरण कोड की व्याख्या हुआ करता था। हमारे काम में, संबंध उल्टा होने लगा है: दस्तावेज़ों से अधिक कोड उत्पन्न और सत्यापित किया जा रहा है। उत्पाद क्यों मौजूद है, सिस्टम को कैसे काम करना चाहिए, किन सीमाओं को पार नहीं किया जा सकता है, और कौन से सबूत बताते हैं कि यह इसकी आवश्यकताओं को पूरा करता है - ये चीजें, जिन्हें एक बार कोड के साथ अनुलग्नक के रूप में माना जाता था, अब सॉफ्टवेयर का स्रोत बन रही हैं।
फिर: "बातचीत सस्ती है। मुझे कोड दिखाओ।"
अब: "कोड सस्ता है। मुझे दस्तावेज़ दिखाओ।"
हाथ से कोड न लिखने से अभिव्यक्ति की मांग कम नहीं होती है। यह उन्हें ऊपर उठाता है. अतीत में, एक अस्पष्ट विचार को लंबी कार्यान्वयन प्रक्रिया के बाद सामने आने और स्पष्ट होने का समय मिलता था। अब एक एजेंट इसे तुरंत एक कार्यशील, प्रतीत होने वाली पूर्ण प्रणाली में बदल सकता है। अस्पष्टता दूर नहीं हुई है. इसे केवल कार्यान्वयन में दबा दिया गया है, जहां यह बाद में विफलताओं और नुकसान के रूप में सामने आएगा।
एआई हमें सोचने की ज़रूरत से मुक्त नहीं करता। वह केवल कार्यान्वयन की व्यस्तता के पीछे अस्पष्ट विचारों को छिपाना कठिन बना देता है।
"कागज़ और कलम" का दूसरा भाग
2025 में, वांग जियान ने एआई की तुलना मानवता के "नए कागज और कलम" से की: स्वयं विचार नहीं, बल्कि मानव विचार का विस्तार। [3] मुझे यह रूपक पसंद है।
इसमें एक दिलचस्प ऐतिहासिक समरूपता शामिल है। 1948 में, एलन ट्यूरिंग ने नियमों के एक सेट का पालन करते हुए कागज, पेंसिल और रबर से लैस एक व्यक्ति की कल्पना की, जिसका व्यवहार एक सार्वभौमिक मशीन के समान माना जा सकता है। [4] तब लोगों ने यह समझाने के लिए कागज और पेंसिल का उपयोग किया कि कोई व्यक्ति किसी मशीन का अनुकरण कैसे कर सकता है। लगभग अस्सी साल बाद, दिशा उलट गई लगती है। मशीन नया कागज और कलम बन रही है, जो लोगों को चलने योग्य दुनिया में अपने इरादे प्रकट करने में मदद कर रही है।
यह रूपक मुझे विश्वविद्यालय की भी याद दिलाता है। सोने के अलावा, मैंने शायद अपना एक तिहाई समय सॉफ्टवेयर और हार्डवेयर के बीच इधर-उधर घूमने में बिताया: ऑपरेटिंग सिस्टम स्थापित करना, वातावरण कॉन्फ़िगर करना, उपकरण सीखना, माइक्रोकंट्रोलर के साथ छेड़छाड़ करना, पहिये वाले रोबोटों को डीबग करना और उन्हें गठन में समन्वय स्थापित करना, और जो भी डेमो मुझे रुचिकर लगे उसे बनाना। मैंने इस प्रक्रिया का आनंद लिया, लेकिन मैंने अक्सर रचना करने की तुलना में रचना की तैयारी में अधिक समय बिताया - जैसे एक चित्रकार हमेशा कागज की तलाश में रहता है, रंगद्रव्य बनाता है, और ब्रश की मरम्मत करता है।
एआई को नया कागज और कलम कहने का मतलब यह नहीं है कि यह सब कुछ कर सकता है। कागज उपन्यास नहीं लिखता. रंगद्रव्य अच्छी तस्वीर नहीं बनाता, और कैमरा अच्छी फिल्म नहीं बनाता। उपकरण अभिव्यक्ति की लागत कम करते हैं, लेकिन वे यह तय नहीं करते कि क्या व्यक्त करने लायक है।
कोडिंग एजेंट कागज और कलम की तुलना में कहीं अधिक सक्रिय हैं। वे सुझाव देते हैं, कार्य निष्पादित करते हैं और सीमित दायरे में चुनाव करते हैं। लेकिन जब तक वे किसी कार्य के उद्देश्य और परिणामों की जिम्मेदारी नहीं ले सकते, तब तक अधिक भागीदारी उन्हें स्वचालित रूप से लेखक नहीं बनाती।
मुझे "नए कागज़ और कलम" के दूसरे भाग में रुचि है:
यदि हमारे पास नया कागज और कलम है, तो हमें किस प्रकार के कलाकारों की आवश्यकता है?
सॉफ्टवेयर निर्माण का केंद्र आगे बढ़ रहा है
यह विचार कि प्रोग्रामर कलाकार हैं, नया नहीं है।
1974 में, डोनाल्ड नुथ ने "कंप्यूटर प्रोग्रामिंग एक कला के रूप में" में बताया कि प्रोग्रामिंग के लिए ज्ञान, कौशल और रचनात्मकता की आवश्यकता क्यों है, और यह कैसे सौंदर्य की वस्तुओं का उत्पादन कर सकता है। [5] 2003 में, पॉल ग्राहम ने "हैकर्स एंड पेंटर्स" में तर्क दिया कि हैकर्स और पेंटर्स दोनों निर्माता हैं। सॉफ़्टवेयर निर्माताओं के लिए, कंप्यूटर अभिव्यक्ति का एक माध्यम है जैसे किसी चित्रकार के लिए पेंट या किसी वास्तुकार के लिए कंक्रीट। [6]
एआई पहली बार प्रोग्रामर को कलाकार नहीं बना रहा है। यह वहां बदल रहा है जहां कला मुख्य रूप से घटित होती है।
एक प्रोग्रामर की अधिकांश कलाएँ कोड के अंदर घटित होती थीं: चाहे एक एल्गोरिथ्म सरल हो, एक अमूर्त सुरुचिपूर्ण हो, या एक प्रणाली जो यथासंभव कम संरचना के साथ पर्याप्त संभावनाओं को समाहित करने में सक्षम हो। इस तरह की सुंदरता गायब नहीं होगी क्योंकि एजेंट आ गए हैं।
लेकिन जैसे-जैसे अधिक कार्यान्वयन कार्य एजेंटों के पास जाता है, मानव निर्माण का केंद्र ऊपर की ओर बढ़ता है। सॉफ़्टवेयर की कला समग्र रूप से कार्य में व्यक्त की जाएगी: कौन सी समस्याएँ चुननी हैं, किसके जीवन को समझना है, क्या क्रम स्थापित करना है, कौन सी संभावनाएँ छोड़नी हैं, उपयोगकर्ताओं को कैसे प्रतिक्रिया देनी है, और कार्य को उनके जीवन में कैसे प्रवेश करना चाहिए।
उत्पाद और अनुभव के स्तर पर सृजन सदैव अस्तित्व में रहा है। परिवर्तन यह है कि जब कार्यान्वयन अब हमारा अधिकांश ध्यान नहीं लेता है, तो ये चिंताएँ अधिक सॉफ़्टवेयर निर्माताओं का मुख्य कार्य बन सकती हैं।
सुरुचिपूर्ण कोड अभी भी मायने रखता है, लेकिन कोड कभी भी सॉफ़्टवेयर की संपूर्ण सुंदरता नहीं रहा है। लोगों और एआई द्वारा मिलकर बनाए गए सॉफ़्टवेयर को केवल चलने वाले कोड के ढेर के रूप में नहीं देखा जाना चाहिए, बल्कि सॉफ़्टवेयर के संपूर्ण कार्य के रूप में देखा जाना चाहिए।
यह "नए कलाकारों" द्वारा निहित परिवर्तन है।
मौजूदा पेशेवर शब्दों में, भूमिका एक उत्पाद प्रबंधक और एक वास्तुकार के संयोजन से मिलती जुलती है: दोनों से पूछना कि क्या बनाया जाना चाहिए और किसके लिए, और सिस्टम कैसे सहन कर सकता है और इसकी सीमाएं कहां हैं। लेकिन ये शीर्षक पर्याप्त नहीं हैं. सॉफ्टवेयर के लेखक को स्वाद, सहानुभूति, समझौता करने की क्षमता और समग्र परिणाम की जिम्मेदारी लेने की इच्छा की भी आवश्यकता होती है।
यहां "कलाकार" कोई अधिक महान उपाधि नहीं है, न ही यह आवश्यक रूप से किसी एक व्यक्ति का वर्णन करता है। यह एक संपूर्ण कार्य के लिए जिम्मेदार लेखक की भूमिका है, और एक टीम इसे साझा कर सकती है।
इंजीनियरिंग कार्य को विश्वसनीय रूप से अस्तित्व में रहने देती है। कला यह निर्धारित करती है कि इसका अस्तित्व क्यों है और यह मानव जीवन में कैसे प्रवेश करती है।
इंजीनियरिंग ख़त्म नहीं होगी, और ज़िम्मेदारी को आउटसोर्स नहीं किया जा सकता
नया कलाकार एक अच्छा विचार प्रस्तावित नहीं करता है और फिर बाकी सब कुछ खत्म करने के लिए एआई की प्रतीक्षा करता है।
कागज और कलम के व्यापक हो जाने के बाद भी, लेखन के लिए अभी भी प्रशिक्षण की आवश्यकता थी; कैमरों के व्यापक हो जाने के बाद, फोटोग्राफी के लिए अभी भी निर्णय की आवश्यकता थी। कोडिंग एजेंट कार्यान्वयन की लागत को कम करते हैं, लेकिन वे जटिल प्रणालियों में वास्तुकला, सुरक्षा, प्रदर्शन, गुणवत्ता या रखरखाव को स्वचालित रूप से हल नहीं करते हैं।
तथ्य यह है कि मैं कोड नहीं पढ़ता इसका मतलब यह नहीं है कि मैंने इंजीनियरिंग नियंत्रण छोड़ दिया है। नियंत्रण बिंदु बदल गए हैं: कार्यान्वयन लाइन का निरीक्षण करने से लेकर सिस्टम लक्ष्यों, वास्तुशिल्प सिद्धांतों, डेटा सीमाओं, अनुमति मॉडल, परीक्षण मानकों, अवलोकन और स्वीकृति-परीक्षण परिणामों को परिभाषित करने तक।
इससे काम कम सख्त नहीं होता. यह अन्यत्र सख्ती बरतता है। क्या परीक्षण वास्तविक जोखिमों को कवर करते हैं? क्या रनटाइम परिणाम दिखाते हैं कि सिस्टम अपनी बाधाओं को पूरा करता है? क्या एजेंट के स्पष्टीकरण के लिए कोई सबूत है? यदि कोई सुविधा चलती है, तो क्या वह शिप करने के लिए भी तैयार है? एआई इनमें से प्रत्येक कार्य में भाग ले सकता है, लेकिन एक व्यक्ति को अंततः यह तय करना होगा कि क्या सबूत भरोसेमंद हैं और गलत होने के परिणाम भुगतने होंगे।
बुनियादी ढांचे, सुरक्षा-महत्वपूर्ण सिस्टम और निम्न-स्तरीय सॉफ़्टवेयर सहित कुछ क्षेत्रों में लोगों को कोड के अंदर गहराई से काम करने की आवश्यकता बनी रहेगी। उन्हें कम संख्या में ऐसे लोगों की आवश्यकता हो सकती है जो वास्तव में निचली परतों को पहले से कहीं अधिक समझते हैं। एक नई अमूर्त परत अपने नीचे की परतों को कभी नहीं मिटाती। उच्च-स्तरीय भाषाओं ने असेंबली को समाप्त नहीं किया, और क्लाउड कंप्यूटिंग ने ऑपरेटिंग सिस्टम को समाप्त नहीं किया। एक नई परत अधिक रचनाकारों को हर बार कुछ बनाते समय हर निचली परत को पार करने से बचने देती है।
कोड न लिखने या न पढ़ने का मेरा निर्णय एक बंधी हुई प्रथा है, यह हर किसी के लिए एक नियम नहीं है। इसका मूल्य यह नहीं है कि यह साबित करता है कि कोड अप्रचलित है। इससे मुझे यह देखने में मदद मिलती है कि काम के कौन से हिस्से अभी भी नहीं सौंपे जा सकते हैं जब कोड ही एकमात्र इंटरफ़ेस नहीं रह गया है जिसके माध्यम से लोग सॉफ़्टवेयर को नियंत्रित करते हैं।
पहला है निर्णय. दूसरी जिम्मेदारी है.
अधिक शक्तिशाली उपकरण भी बड़े पैमाने पर औसत दर्जे का उत्पादन कर सकते हैं। जब कार्यान्वयन सस्ता हो जाता है, तो हमें सबसे पहले अधिक दोहराव वाला, अपरिष्कृत सॉफ़्टवेयर मिल सकता है जो किसी वास्तविक आवश्यकता को पूरा नहीं करता है। कागज और कलम स्वतः ही साहित्य का निर्माण नहीं करते। कोडिंग एजेंट स्वचालित रूप से सॉफ़्टवेयर पुनर्जागरण उत्पन्न नहीं करेंगे।
एआई कमी को दूर नहीं करता; वह केवल उसे दूसरी जगह ले जाता है।
सॉफ़्टवेयर उत्पादन मुख्य रूप से प्रोग्रामिंग कौशल, इंजीनियरिंग संसाधनों और कार्यान्वयन समय से बाधित होता था। जैसे-जैसे वे बाधाएं कम होती जाती हैं, यह निर्णय करना कि कौन सी समस्याएं मायने रखती हैं, उत्पाद अंतर्ज्ञान, सिस्टम की समझ, स्वाद, लोगों की समझ और परिणामों की जिम्मेदारी लेने की इच्छा अपेक्षाकृत कम हो जाती है।
जैसे-जैसे "इसे कैसे बनाएं" सस्ता होता जाता है, "क्या बनाएं" अधिक महंगा होता जाता है।
कोड के लेखकों से लेकर सॉफ्टवेयर के लेखकों तक
ब्रेट टेलर ने आर्य असेमनफ़र के एक अवलोकन का हवाला दिया: एआई आपके लिए मसौदा तैयार कर सकता है, लेकिन आप अभी भी लेखक हैं। [7] एडी उस्मानी ने वास्तुकार और प्रधान संपादक के रूप में डेवलपर की नई भूमिका का वर्णन किया है। [8]
एक लेखक को हर वह कार्य नहीं करना पड़ता जो किसी कृति का निर्माण करता हो। आर्किटेक्ट हर ईंट नहीं रखते, और निर्देशक फिल्म सेट पर हर कैमरा संचालित नहीं करते। लेकिन उन्हें पता होना चाहिए कि काम क्या होना चाहिए, यह आकलन करना चाहिए कि क्या यह सफल होगा, और समग्र रूप से काम की जिम्मेदारी लेनी चाहिए।
यही बदलाव सॉफ्टवेयर में भी हो रहा है.
हम सॉफ़्टवेयर के लेखक की पहचान यह पूछकर करते थे कि कोड किसने लिखा है। भविष्य में, लेखकत्व प्रश्नों के विभिन्न सेटों पर निर्भर हो सकता है: समस्या को किसने परिभाषित किया? प्रतिबंध किसने स्थापित किये? महत्वपूर्ण समझौता किसने किया? किसने निर्णय लिया कि कार्य पूरा हो गया? और दुनिया में इसके प्रवेश के बाद जो होता है उसकी ज़िम्मेदारी कौन लेता है?
इससे सॉफ्टवेयर की आर्थिक इकाई भी बदल सकती है। अतीत में, सॉफ़्टवेयर निर्माण को उचित ठहराने के लिए किसी आवश्यकता को आम तौर पर पर्याप्त लोगों द्वारा साझा करना पड़ता था। जब कार्यान्वयन लागत काफी कम हो जाती है, तो एक टीम, एक परिवार या यहां तक कि एक व्यक्ति का विशेष वर्कफ़्लो अपने स्वयं के सॉफ़्टवेयर की गारंटी दे सकता है। हर किसी को प्रोग्रामर बनना ज़रूरी नहीं है, लेकिन अधिक लोग सॉफ़्टवेयर के लेखक बन सकते हैं।
एआई मानव नियंत्रण बिंदुओं और सृजन के केंद्र को एक अमूर्त परत पर ले जाते हुए अधिक कार्यान्वयन कार्य को नीचे की ओर धकेलता है। प्रोग्रामर अब केवल कोड के लेखक नहीं रहेंगे। तेजी से, वे सॉफ्टवेयर के संपूर्ण कार्यों के लेखक बन जाएंगे - मेरा मतलब है "नए कलाकार"।
नये कागज और कलम आ गये हैं। लेकिन एक नया पुनर्जागरण अपने आप नहीं आएगा। यह इस बात पर निर्भर नहीं करता है कि कितने कोड एजेंट उत्पन्न कर सकते हैं, बल्कि इस बात पर निर्भर करता है कि क्या हमारे पास किसी प्रश्न का उत्तर देने के लिए "यह कैसे बनाया जा सकता है?" से अधिक कठिन निर्णय और जिम्मेदारी लेने की इच्छा है।
क्या बनाने लायक है और हम कैसे चाहते हैं कि लोग इसका अनुभव करें?
संदर्भ
[1] आंद्रेज कारपैथी, “वाइब कोडिंग” का परिचय देने वाली एक्स पोस्ट, 2025-02-02।
[2] आंद्रेज कारपैथी, “एजेंटिक इंजीनियरिंग” का प्रस्ताव देने वाली एक्स पोस्ट, 2026-02-04।
[3] लियू निंगक्सिन, "वांग जियान: इनोवेशन 'अपूर्णता' और 'सीमाओं को पार करने' से आता है", 21वीं सदी बिजनेस हेराल्ड, 2025-09-25।
[4] एलन एम. ट्यूरिंग, "इंटेलिजेंट मशीनरी", राष्ट्रीय भौतिक प्रयोगशाला रिपोर्ट, 1948।
[5] डोनाल्ड ई. नुथ, "एक कला के रूप में कंप्यूटर प्रोग्रामिंग", एसीएम के संचार, 17(12), 1974, पीपी. 667-673।
[6] पॉल ग्राहम, "हैकर्स एंड पेंटर्स", मई 2003।
[7] ब्रेट टेलर, "एआई आपका घोस्ट राइटर है, लेकिन आप लेखक हैं", लिंक्डइन, 2026-02-10।
[8] एडी उस्मानी, वाइब कोडिंग से परे, ओ'रेली मीडिया, अगस्त 2025।