2026 की शुरुआत में, AI का डेवलपर उत्पादकता पर असर मापने की कोशिश कर रहे शोधकर्ताओं को एक बेहद मानवीय समस्या मिली: कुछ डेवलपर ऐसे काम लेना ही नहीं चाहते थे जिन्हें शायद AI के बिना करना पड़े।
शोधकर्ताओं ने इसे selection effect कहा। मुझे यह एक छोटी-सी स्वीकारोक्ति जैसा लगता है।
बहुत समय पहले की बात नहीं है जब AI सिर्फ़ side panel में रहने वाला एक प्रयोग था। Autocomplete काम न करे या कोई regular expression परेशान करने लगे, तभी हम उसे खोलते थे। आज बहुत-से डेवलपरों के लिए AI बस कमरे का हिस्सा है। सुबह editor खोलते समय, वर्षों से अनछुए repository को संभालते समय, और देर रात test लाल होते समय—वह वहीं मौजूद रहता है।
हम panel बंद कर सकते हैं। Agent को रोक सकते हैं। हमें आज भी code लिखना आता है।
फिर AI के बिना काम करना अभी से एक हाथ कम होने जैसा क्यों लगने लगा है?
AI ने हमारा काम नहीं, हमारे ठहराव अपने हाथ में लिए
AI ने software development में आकर यह घोषणा नहीं की कि वह हमारी जगह लेगा। वह एक-एक छोटी राहत बनकर आया।
पहले उसने वही line पूरी की जिसे हम लिखने वाले थे। फिर वह test लिखा जिसे हम टालते आ रहे थे। उसने अनजान function समझाया, stack trace को साधारण भाषा में बदला और documentation में छुपी वह setting ढूँढ़ निकाली जिसे हम दोबारा पढ़ना नहीं चाहते थे।
इनमें से कुछ भी निर्भरता जैसा नहीं लगा। लगा कि काम आगे बढ़ रहा है।
उस आख़िरी बार को याद कीजिए जब आपका AI assistant उपलब्ध नहीं था। बेचैनी शायद इस बात की नहीं थी कि आप language भूल गए हैं। वह पहली चाल से पहले की ख़ामोशी थी। कहाँ देखना है, यह खुद तय करना था। अनिश्चितता को अकेले संभालना था। Error को इतनी देर देखना था कि कोई अनुमान आकार ले सके।
कभी ये ठहराव सामान्य थे। अब वे रुकावट लगते हैं।
शायद AI ने सबसे गहराई से यही बदला है। उसने सिर्फ़ जवाब बनाने का तरीका नहीं बदला; उसने यह भी बदल दिया कि हम किसी सवाल के साथ अकेले कितनी देर रह पाते हैं।
राहत सचमुच राहत है
AI पर निर्भरता को ऐसे देखना आसान है जैसे डेवलपर अनुशासन छोड़कर आलस चुन रहे हों। लेकिन यह उस अनुभव को नहीं समझता जो काम के भीतर इस tool के साथ बनता है।
Software development में हैरान करने जितनी निजी झिझक छुपी होती है। एक senior engineer जो किसी सामान्य command की syntax भूल गया है। एक नया teammate जिसे डर है कि एक और सवाल सबकी शंका को सच कर देगा। दूसरी भाषा में काम करने वाला developer जो समस्या पूरी तरह समझता है, पर उसे जल्दी शब्द नहीं दे पाता। वह व्यक्ति जो दस साल पुराने codebase में आया है, जहाँ हर महत्वपूर्ण निर्णय किसी और की याद में बंद है।
AI उन सबके साथ धैर्य रखता है।
एक ही सवाल दोहराने पर वह आह नहीं भरता। यह नहीं कहता, “तुम्हें यह पहले से आना चाहिए।” वह रात दो बजे भी उपलब्ध रहता है और खाली screen को ऐसी किसी चीज़ में बदल देता है जिससे बहस की जा सके। जवाब अधूरा हो, तब भी कुछ मिल जाना शुरुआत के भावनात्मक बोझ को बदल देता है।
यह मायने रखता है। कभी-कभी जो productivity दिखती है, वह असल में राहत होती है: अटकने का डर कम, शर्म कम, और उस मशीन के सामने अकेलापन कम जो खुद को समझाती नहीं।
कई डेवलपरों के लिए AI ने उस काम के लिए ऊर्जा लौटाई है जिसे वे सच में पसंद करते हैं। वह boilerplate, दोहराए जाने वाले tests, migration का ढाँचा और API client का सौवाँ रूप संभाल सकता है। तब दिमाग़ दिलचस्प समस्या तक कम थका हुआ पहुँचता है।
इसे सिर्फ़ shortcut कहकर नज़रअंदाज़ नहीं करना चाहिए। जो tool लोगों को खोजने और प्रयोग करने का साहस दे, वह सचमुच मूल्यवान है।
मुश्किल यह है कि सुकून और निर्भरता एक ही जड़ से उगते हैं।
हम उसी का इस्तेमाल करते हैं जिस पर पूरा भरोसा नहीं
डेवलपर सर्वे बार-बार यही अजीब रिश्ता दिखाते हैं: हम AI का लगातार उपयोग करते हैं, पर उसके दिए जवाबों पर पूरी तरह भरोसा नहीं करते।
जिसने एक आत्मविश्वासी जवाब को सिर्फ़ एक edge case पर टूटते देखा है, वह इस तनाव को समझता है। Code सही दिखता है। Names साफ़ हैं। Explanation शांत है। तीसरा test fail होने पर पता चलता है कि model ने कोई method गढ़ लिया, business rule गलत समझा या हमारी असली समस्या से आसान समस्या हल कर दी।
फिर भी अगली बार अटकने पर हम दोबारा पूछते हैं।
यह पाखंड नहीं है। भरोसा एक ही चीज़ नहीं होता।
अंतिम निर्णय हम AI को न दें, लेकिन पहली दिशा उससे ले सकते हैं। Patch पर भरोसा न हो, पर उस बातचीत पर भरोसा हो सकता है जो सोच की गाँठ ढीली करती है। जवाब पर शक हो सकता है, फिर भी विश्वास रहता है कि खाली screen की जगह कुछ तो होगा।
AI वह सहकर्मी बन गया है जिसे हम main branch में सीधे merge करने की अनुमति कभी नहीं देंगे, लेकिन कमरे से जाते ही जिसकी कमी महसूस होती है।
हम तेज़ चलते हैं क्योंकि अगला कदम तुरंत दिखाई देता है। वह हमारा भार उठा पाएगा या नहीं, यह जाँचना अब भी हमारी ज़िम्मेदारी है।
जब संघर्ष जाता है, तो उसके साथ क्या चला जाता है
कुछ ज्ञान तभी बनता है जब हम अटकते हैं।
AI से पहले कोई अनजान error हमें stack trace से caller तक, वहाँ से documentation तक और अंत में ऐसी धारणा तक ले जाता था जिसके होने का हमें पता भी नहीं था। यह रास्ता कुशल नहीं था। मगर इसी रास्ते से codebase सिर्फ़ files का संग्रह नहीं, एक परिचित जगह बनता था।
हम उन systems को याद रखते हैं जिन्होंने कभी हमारा विरोध किया था।
पूरा दोपहर खा जाने वाला bug सिखाता है कि state सच में कहाँ रहती है। Production incident बताता है कि उबाऊ लगने वाली safeguard क्यों मौजूद है। जिस library को हमने तीन बार गलत समझा, वही बाद में किसी और को समझाने वाली library बनती है।
AI जब प्रतिरोध हटाता है, तो वह वह कहानी भी हटा सकता है जिसके कारण सीख याद रहती है।
नई library सीख रहे डेवलपरों पर हुए एक शुरुआती अध्ययन ने एक सहज बात दिखाई: जिन्होंने पूरा काम AI को सौंप दिया, उन्होंने उन लोगों से कम सीखा जिन्होंने AI से concepts पूछे और अपनी समझ जाँची। असली अंतर “AI या no AI” नहीं था; अंतर यह था कि tool ने सोच को बदला या सोच में साथ दिया।
Junior डेवलपरों के लिए यह खास तौर पर कठिन है। अनुभवी engineer संदिग्ध abstraction को इसलिए पहचानते हैं क्योंकि वे पहले गलत abstraction बना चुके हैं। उन्हें साफ़-सुथरी patch भी system से बाहर की लग सकती है क्योंकि वे उसकी चोटें जानते हैं। लेकिन अगर हर खुरदुरा किनारा छूने से पहले चिकना कर दिया जाए, तो अगली पीढ़ी यह instinct कहाँ से पाएगी?
Mentorship कभी सिर्फ़ जवाब देने का नाम नहीं था। वह धीरे-धीरे judgment सौंपना था: किस बात की चिंता करनी है, कब रुकना है, कौन-सा compromise बाद में महँगा पड़ेगा, और चलने वाली solution भी अभी तैयार क्यों नहीं है।
AI इन सभी विचारों को समझा सकता है। लेकिन किसी इंसान के आपके सीखने तक आपके पास रहने के चुनाव का एहसास वह अभी नहीं बना सकता।
Shortcut असली हो सकता है। समझ को फिर भी वह दूरी तय करनी पड़ती है।
Code पर कभी लिखने वाले की उँगलियों के निशान होते थे
एक और बदलाव मापना कठिन है, क्योंकि वह लोगों के बीच होता है।
इंसान का लिखा code अक्सर अपने लेखक के निशान रखता है। कोई अजीब helper function उस incident की याद लिए हो सकता है जिसने उसे ज़रूरी बनाया। कोई असहज comment बता सकता है कि लेखक कहाँ अनिश्चित था। Review में हम सिर्फ़ बदलाव नहीं देखते; उसके पीछे की सोच फिर से बनाते हैं। सवाल पूछते हैं और उस रास्ते से गुज़रा इंसान जवाब देता है।
AI से बना code उस रास्ते के बिना आ सकता है।
वह साफ़ और तकनीकी रूप से विश्वसनीय दिख सकता है, फिर भी अजीब तरह से बिना मालिक का लगता है। लेखक बता सकता है कि उसने क्या माँगा था, पर हमेशा यह नहीं कि नतीजा इसी आकार में क्यों आया। तब reviewer वह काम भी करता है जो पहले लिखने वाला साझा करता था: मंशा फिर बनाना, धारणाएँ जाँचना और उस निर्णय के छुपे किनारे ढूँढ़ना जिसे लेना किसी को याद नहीं।
AI-generated pull requests पर होने वाली कई community चर्चाओं के नीचे यही बेचैनी है। शिकायत सिर्फ़ यह नहीं कि code खराब हो सकता है। खराब code पुराना परिचित है। गहरी असहजता यह है कि लोगों के बीच का सामाजिक समझौता बदल गया है।
एक व्यक्ति कुछ मिनटों में बड़ा बदलाव बना सकता है। दूसरे को उसे समझने के लिए अब भी मानवीय ध्यान देना पड़ता है। Keyboard पर बचा समय चुपचाप code review, maintenance, security या उस रात लौट आता है जब system टूटता है और किसी को समझाना पड़ता है कि generated patch आखिर करना क्या चाहती थी।
Code हमेशा communication रहा है। जब generation लगभग मुफ्त हो जाती है, तो attention दुर्लभ संसाधन बन जाता है। और attention इंसानों की होती है।
शायद हुनर ख़त्म नहीं, अपनी जगह बदल रहा है
कुछ डेवलपरों के लिए यह बदलाव नुकसान नहीं लगता। उन्हें लगता है कि अब वे उस स्तर पर काम कर सकते हैं जहाँ वे हमेशा करना चाहते थे।
वे कम lines लिखते हैं और समस्या को आकार देने में अधिक समय देते हैं। एक design चुनने से पहले कई विकल्प देखते हैं। User, architecture, failure modes और agent की सीमाओं पर सोचते हैं। हुनर हर हिस्सा खुद बनाने से पूरे काम को दिशा देने की ओर जाता है।
यह सचमुच विकास हो सकता है। Assembly ने machine code की जगह ली या frameworks ने हाथ से बनाई infrastructure की, तब हम developer होना बंद नहीं हुए। Software हमेशा abstraction के सहारे ऊपर बढ़ा है।
लेकिन हर abstraction उस व्यक्ति पर टिकी होती है जो नीचे की परत समझता है।
AI को दिशा देने वाले developer को अब भी taste चाहिए। Reviewer को अब भी mental model चाहिए। Architect को अब भी समझना होगा कि साफ़ diagram का सामना धीमे network, खराब message, थकी team या डरे हुए user से हो तो क्या होता है।
अगर AI implementation का बड़ा हिस्सा लिखता है, तो मानवीय judgment कम महत्वपूर्ण नहीं होता। बस उसे नज़रअंदाज़ करना आसान और विकसित करना कठिन हो जाता है।
इस भविष्य का आशावादी रूप वह नहीं जहाँ developer कम मायने रखते हैं। वह है जहाँ हम उन चीज़ों को और जानबूझकर सँभालते हैं जिन्हें सिर्फ़ इंसान उठा सकते हैं: context, care, doubt, responsibility, और यह पहचानना कि तकनीकी रूप से सही जवाब इस system और इन लोगों के लिए गलत हो सकता है।
साथ रहें, पर खुद को पीछे न छोड़ें
क्या हम अब भी AI के बिना काम कर सकते हैं?
व्यक्ति के रूप में, हाँ। कल panel बंद कर सकते हैं। Profession के रूप में जवाब अब जटिल है। Expectations बदल रही हैं। Codebases generated काम से भर रहे हैं। नए developer career के बीच में नहीं, शुरुआत से AI से मिलते हैं। जो assistant कभी इस्तेमाल नहीं करता, उसे भी AI से आया code review और maintain करना होगा।
AI से पहले की software industry में अकेले लौटने का कोई निजी रास्ता नहीं है।
लेकिन शायद दूर जाना आज़ादी का सही पैमाना नहीं। अधिक महत्वपूर्ण सवाल है: tool के रहते क्या हम काम के भीतर मौजूद रह सकते हैं?
मौजूद रहने का मतलब है tests हरे होने पर भी patch पढ़ना। जवाब काम करने लगे तब भी “क्यों” पूछना। जिसे समझा नहीं सकते, उसे merge न करना। Junior को संघर्ष का समय देना और उसे waste न कहना। Reviewer के उस अदृश्य काम को पहचानना जो system को विश्वसनीय दिखने वाली गलतियों से बचाता है।
इसका अर्थ ऐसे पल बचाना भी है जब कोई assistant तुरंत जवाब न दे। शुद्धता साबित करने के लिए नहीं, अपनी सोच की आवाज़ फिर सुनने के लिए।
हममें से अधिकतर AI का उपयोग जारी रखेंगे। राहत सच है। संभावनाएँ सच हैं। बेचैनी, निर्भरता और यह शांत डर भी सच है कि जिस काम से हम प्रेम करते थे उसका कुछ हिस्सा फिसल रहा है।
हमें इनकार और समर्पण में से एक नहीं चुनना।
Software का भविष्य इस बात से तय नहीं होगा कि AI कितने प्रतिशत code लिखता है। वह छोटे पलों से तय होगा: क्या हम स्वीकार करने से पहले समझते हैं, सिर्फ़ जवाब forward करने के बजाय सिखाते हैं, दूसरे के attention की रक्षा करते हैं, और generated code के वास्तविक दुनिया तक पहुँचने पर ज़िम्मेदारी लेते हैं।
AI रह सकता है।
हमें यह सुनिश्चित करना होगा कि हम भी बने रहें।
