- Generative AI क्रॉस-डोमेन जनरेशन को संभव बनाता है, जिसमें बिना प्रशिक्षण वाला व्यक्ति किसी दूसरे विशेषज्ञ क्षेत्र का आउटपुट बना सकता है, और शुरुआती लोग बिना समीक्षा-क्षमता के भी अधिक उत्पादक दिखने लगते हैं
- कार्यस्थल पर code, data systems और documents जैसे ऐसे आउटपुट बढ़ते हैं जो ऊपर से प्रगति जैसे दिखते हैं, लेकिन उपयोगकर्ता अक्सर यह समझा नहीं पाता कि वे वास्तव में कैसे काम करते हैं, या शुरुआत से ही schema और goals गलत होते हैं
- AI उस संबंध को तोड़ देता है जिसमें आउटपुट की quality निर्माता की क्षमता का संकेत देती थी, और आउटपुट व क्षमता के अलगाव को पैदा करता है, जिससे उपयोगकर्ता परिणामों का मूल्यांकन किए बिना उन्हें आगे बढ़ाने वाले conduit जैसा बन जाता है
- आंतरिक documents और updates की generation cost कम होने से वे लंबे होते जाते हैं, लेकिन पढ़ने की cost कम नहीं होती; इससे संगठन के भीतर signal ढूँढना और कठिन हो जाता है और यह वेतनभोगी लोगों द्वारा बनाए गए AI slop का नया रूप बन जाता है
- Generative AI उन कामों के लिए उपयुक्त है जहाँ इंसान अंतिम निर्णायक बना रहता है और तेज़ feedback संभव है, जैसे draft, example, summary, brainstorming और proofreading; भरोसेमंद काम देने की क्षमता अब भी कंपनियों की प्रतिस्पर्धी बढ़त बनी हुई है
नौकरी की उत्पादकता जैसे दिखने वाले AI आउटपुट की समस्या
- Generative AI ऐसे परिणाम बना सकता है जो विशेषज्ञता के बिना भी पेशेवर आउटपुट जैसे दिखें, और इसकी विफलता दो रूपों में सामने आती है
- जब किसी क्षेत्र का शुरुआती व्यक्ति अपनी समझ से तेज़ या अधिक उन्नत दिखने वाले परिणाम बनाता है
- जब उस क्षेत्र में प्रशिक्षित न हुआ व्यक्ति किसी दूसरे विशेषज्ञ क्षेत्र का आउटपुट बनाता है
- अब तक के शोध मुख्यतः पहले रूप को मापते रहे हैं, लेकिन अधिक खतरनाक पक्ष वह है जहाँ बिना प्रशिक्षण वाला व्यक्ति दूसरे क्षेत्र का आउटपुट बनाता है, यानी क्रॉस-डोमेन जनरेशन
- सार्वजनिक channels में ऐसे मामले सामने आते हैं जहाँ सहकर्मी Claude जैसे दिखने वाले उत्तर को सीधे paste कर देता है, और उस तकनीक को आत्मविश्वास से संभालता हुआ लगता है जिसे वह वास्तव में समझता नहीं
- ऐसी स्थिति में सामने वाला व्यक्ति वास्तविक बातचीत का सहभागी नहीं, बल्कि model output पहुँचाने वाले माध्यम की तरह काम करता है
क्रॉस-डोमेन जनरेशन
- जो व्यक्ति code लिखना नहीं जानता वह software बना रहा है, और जिसने कभी data system design नहीं किया वह data system design कर रहा है
- इनमें से ज़्यादातर चीज़ें release नहीं होतीं, लेकिन अंदर उत्साह से share की जाती हैं या चुपचाप इस्तेमाल होती रहती हैं, और कभी-कभी ग्राहकों तक भी पहुँच जाती हैं
- अभी कुछ practitioners agentic tools के साथ जटिल काम सही ढंग से कर रहे हैं, लेकिन वे दुर्लभ हैं और ज़्यादातर code generation में मिलते हैं
- व्यक्तिगत स्तर पर AI capability बढ़ी है, लेकिन काम की जगह पर उसका विस्तार ठीक से नहीं हो पा रहा
- एक non-engineering role वाले सहकर्मी ने इस साल की शुरुआत में दो महीनों तक ऐसा system बनाया जिसे औपचारिक data architecture training वाले व्यक्ति को design करना चाहिए था
- वर्तमान मानकों के हिसाब से उसने AI tools का अच्छा उपयोग किया और बहुत सारा code, documentation और ऊपर से प्रगति जैसे दिखने वाले आउटपुट तैयार किए
- लेकिन सवाल पूछे जाने पर वह यह नहीं समझा पाया कि चीज़ वास्तव में कैसे काम करती है
- schema और goals पहले दिन से ही गलत थे, और ये ऐसी गलतियाँ थीं जिन्हें उस क्षेत्र के दो साल के अनुभव वाला व्यक्ति पकड़ लेता
- कई लोग यह जानते थे और बात V.P. स्तर तक पहुँची, लेकिन manager पहले ही momentum की बाहरी छवि में निवेश कर चुका था और उसे हिलाना नहीं चाहता था
- इन tools ने उसे बुरा सहकर्मी नहीं बनाया; उन्होंने बस उसे कई महीनों तक बिना प्रशिक्षण वाले क्षेत्र की विश्वसनीय नकल करने लायक बना दिया
- संगठन के incentives उस नकल को चलते रहने की ओर झुकते हैं
- यह management failure हो सकता है, लेकिन AI को अपनाने की management की इच्छा उन्हें जोखिम स्वीकार करने की ओर ले जाती है
- अगर model आउटपुट का ईमानदार मूल्यांकन करे तो यह समस्या कम हो सकती है, लेकिन व्यवहार में ऐसा नहीं होता
- नतीजतन, शुरुआती लोग अपनी विशेषज्ञता से बाहर के क्षेत्रों में व्यक्तिगत productivity बढ़ा सकते हैं, लेकिन उनके पास यह जाँचने की क्षमता नहीं होती कि आउटपुट सही है या नहीं
conduit समस्या
- इस घटना को अब बढ़ते हुए आउटपुट-क्षमता अलगाव (output-competence decoupling) कहा जा रहा है
- पहले आउटपुट की quality आम तौर पर निर्माता की क्षमता का संकेत होती थी
- शुरुआती व्यक्ति की writing शुरुआती जैसी लगती थी, और शुरुआती का code शुरुआती जैसी तरह से fail होता था
- AI इस संबंध को तोड़ देता है, जिससे शुरुआती लोग ऐसे आउटपुट बना सकते हैं जो अब यह नहीं दिखाते कि वे शुरुआती हैं
- आउटपुट जिस क्षमता को दर्शाता है, वह उपयोगकर्ता की नहीं बल्कि system की क्षमता है
- उपयोगकर्ता परिणामों को आगे भेज सकता है, लेकिन बीच में उनका मूल्यांकन नहीं कर पाता, इसलिए वह एक conduit जैसा हो जाता है
- आउटपुट बनाने की क्षमता और उसका निर्णय करने की क्षमता पहले से अलग थीं, लेकिन वास्तविक काम करने की प्रक्रिया ही judgment को विकसित करती थी
- आउटपुट बनाने वाली पहली क्षमता का बड़ा हिस्सा मशीनों को चला गया
- निर्णय करने वाली दूसरी क्षमता अब भी इंसानों के पास है, लेकिन इसे सीखने या उपयोग करने वालों की संख्या घट रही है
- पहले architecture की आलोचना वे लोग देते थे जिन्होंने प्रशिक्षण लिया हो या ऐसे systems कई बार बनाए और टूटते देखे हों
- अब वैसी आलोचना ऐसे model से आती है जिसके पास न बनाने का embodied memory है, न टूटने का
- धीमापन सिर्फ वास्तविक काम से जुड़ी लागत नहीं था; वही वह प्रक्रिया थी जिससे काम बेहतर होता था, लोग कुशल बनते थे और कंपनी ग्राहकों से एक खास quality का वादा कर पाती थी
- मौजूदा पीढ़ी के agentic systems इस धारणा के आसपास बनाए गए हैं कि इंसान bottleneck है
- मान लिया जाता है कि यदि इंसानी पढ़ने-समझने और निर्णय की देरी हट जाए तो loop तेज़ और साफ़ हो जाएगा
- कई मामलों में यह बिल्कुल उल्टा है; loop के भीतर का इंसान कोई पुराना अवशेष नहीं, बल्कि नतीजे में हित रखने वाला अकेला घटक है
- human-in-the-loop (HITL) से इंसान को हटाना efficiency नहीं, बल्कि उस एकमात्र तंत्र को छोड़ देना है जिससे system खुद को पकड़ सकता है
अंदरूनी AI slop
- कामकाजी documents तेज़ी से लंबे होते जा रहे हैं
- जो requirements document पहले एक पेज का था, वह 12 पेज का हो गया है
- जो status update पहले तीन वाक्यों का था, वह अब summary की summary को bullets में बदलने वाला document बन गया है
- retrospectives, incident reports, design memos, kickoff decks—जो भी आउटपुट लंबा हो सकता है, वह लंबा हो रहा है
- production cost लगभग शून्य के पास आ गई है, लेकिन पढ़ने की cost कम नहीं हुई; बल्कि बढ़ी है
- पाठक को synthesized context में से यह छाँटना पड़ता है कि document असल में क्या कहना चाहता था
- हर व्यक्ति के लिए document लंबा करने का फैसला तर्कसंगत लगता है और उसे अलग से reward भी मिलता है
- Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling के अनुसार, पाठकों को लंबे AI-generated explanations पर अधिक भरोसा हो जाता है, चाहे वे अधिक सटीक हों या नहीं
- नतीजतन, कार्यस्थल के भीतर signal ढूँढना पहले से अधिक कठिन हो जाता है
- checkpoints documents में छिप जाते हैं, और लोग वास्तव में “संक्षिप्त” रखना चाहते हुए भी paperwork में डूब जाते हैं
- यह सार्वजनिक बाज़ार में फैलने वाले AI slop से भी महँगा slop का नया रूप है
- क्योंकि इसे बनाने वालों को वेतन दिया जा रहा है
- जो काम judgment सिखाते थे वे अब tools कर रहे हैं, और जिन entry-level roles में वह सीख होती थी वे इसलिए कम हो रहे हैं क्योंकि tool काम कर सकता है
- कई offices में गतिविधि बहुत है, लेकिन पहले जैसी गतिविधि से निकलने वाले वास्तविक परिणाम कम हैं
- सार्वजनिक चर्चा अब तक मुख्यतः उस AI slop पर केंद्रित रही है जो खुले बाज़ार में जा रहा है, और University of Florida का Generative AI and the market for creative content उसी प्रवाह को देखता है
- लेकिन संगठन के भीतर भी वही dynamics उभर रहे हैं
- समय उन कामों में जा रहा है जिनके लिए AI की ज़रूरत नहीं थी, ऐसे आउटपुट में जिन्हें कोई पढ़ेगा नहीं, और ऐसे processes में जो सिर्फ इसलिए पैदा हुए क्योंकि tools उन्हें सस्ते में बना सकते हैं
- जो बातें पहले कहने की भी ज़रूरत नहीं होती थीं या स्वाभाविक मानी जाती थीं, वे अब deck में समझाई जा रही हैं
प्रतिक्रिया का तरीका
- इस माहौल में जो अनुशासन चाहिए, वह पुराने तरीकों के अधिक करीब है
- tools का इस्तेमाल केवल वहीं होना चाहिए जहाँ उनके परिणामों को ठीक-ठीक verify किया जा सके
- model से confirmation नहीं माँगना चाहिए
- tools हर किसी से सहमत हो जाते हैं, और ऐसी सहमति जिसकी कोई लागत न हो, उसका कोई मूल्य नहीं
- Generative AI उन कामों के लिए सबसे उपयुक्त है जहाँ feedback तेज़ हो, लगभग सही होना काफ़ी हो, और इंसान अंतिम निर्णायक बना रहे
- memo का draft लिखना
- examples बनाना
- ऐसी सामग्री का summary बनाना जिसे पाठक चाहे तो verify कर सके
- University of Illinois की Generative AI Guidance और PLOS Computational Biology की Ten simple rules for optimal and careful use of generative AI in science निम्नलिखित उपयोगों की सिफारिश करती हैं
-
brainstorming
-
proofreading
-
अपने विचारों का पुनर्गठन
-
ऐसे data में pattern detection जिसे आप पहले से समझते हैं
- सभी अनुशंसित उपयोगों में इंसान judgment देता है और tool throughput देता है
- यह सिर्फ human-in-the-loop से भी अधिक मजबूत रुख है
- tool को काम के बाहर रहना चाहिए और केवल बुलाए जाने पर योगदान देना चाहिए; बाकी समय उसे चुप रहना चाहिए
- यह दिशा उन कई agentic systems की वर्तमान दिशा के उलट है
- कंपनियों के लिए भरोसेमंद काम देने की क्षमता अब भी प्रतिस्पर्धी बढ़त है
- जितना अधिक प्रतिस्पर्धी खुद को content generation pipeline में बदलते जाएँ और उम्मीद करें कि ग्राहक ध्यान नहीं देंगे, उतना ही विश्वसनीय काम का मूल्य बढ़ेगा
- समस्याएँ पहले ही सतह पर आने लगी हैं
- Deloitte ने AI hallucinations वाले सरकारी report से जुड़े 440,000 डॉलर की fee का हिस्सा वापस किया
- अगली समस्या किसी hallucinated specification पर आधारित operational system हो सकती है, या कोई senior engineer जो यह समझे कि पिछले एक साल से वह नाममात्र ऐसी चीज़ों की review करता रहा है जिन्हें वह वास्तव में जाँच नहीं सकता था
- जो कंपनियाँ सही तरह से काम करती हैं, वे उस काम की कीमत तय करने की स्थिति में रह सकती हैं
- जो कंपनियाँ खुद को भीतर से खाली कर देती हैं, उन्हें पता चलता है कि ग्राहक उसी चीज़ के लिए भुगतान कर रहे थे जिसे उन्होंने हटा दिया
- कार्यस्थल पर AI को लेकर गलतफहमी और दुरुपयोग व्यापक है
- विशेषज्ञता पर अधिक तेज़ delivery, अधिक output, tools का गहरा integration, और “काम कर दिखाने” वाले सहकर्मी को न रोकने का दबाव है
- आउटपुट जमा होते जाते हैं, लेकिन वास्तविक काम नहीं
- और उस आउटपुट के दूसरे छोर पर ग्राहक deliverable खोल सकता है, summaries की सूची पढ़ सकता है, और फिर खुद जाँचने का निर्णय ले सकता है
1 टिप्पणियां
Hacker News की राय
पहले जहाँ एक पेज का requirement document काफी होता था, वहाँ अब वह बारह पेज का हो जाता है — यह काम के आउटपुट का अनावश्यक फैलाव बहुत गहराई से महसूस हुआ
इससे स्कूल के उन essay की याद आ गई जिनमें 1000 शब्द की न्यूनतम सीमा पूरी करने के लिए जानबूझकर बातों को लंबा किया जाता था, और अब professional formatting, लंबाई, और साफ़ वाक्य भी मेहनत और quality का संकेत नहीं रह गए हैं
इसलिए अब भी productivity improvement का bottleneck शायद वही लोग हैं जो चीज़ों को खुद ध्यान से review करने की परवाह करते हैं
आजकल formatting और ASCII diagrams से भरे 10~30 पेज के spec documents भी असल में बस मुँहज़बानी फेंका गया कोई ढीला-ढाला idea हो सकते हैं, इसलिए उसे उसी तरह लेना सीखना पड़ रहा है
manager शायद मेरी भेजी चीज़ों को chatbot या agent से summarize और evaluate कराएगा, लेकिन अगर मैं खुद summary भेज दूँ तो वह स्वीकार्य नहीं होगा
यह कुछ वैसा ही है जैसे resume के लिए ATS checker होता है, वैसे ही अब मेरी writing के लिए भी AI checker चाहिए होगा, और आखिर में AI द्वारा लिखी चीज़ को दूसरी AI parse करेगी — यह बहुत बड़ी energy waste लगती है
काश अधिक efficient communication के लिए कुछ agreed rules, structure, standards, और procedures होते
यानी search result में ऊपर आने के लिए हर चीज़ को लंबा खींचने वाली writing का उत्पाद
जो लोग ऐसी चीज़ें भेजते हैं, वे वैसे भी follow-up verify नहीं करेंगे, इसलिए समस्या अपने-आप गायब हो जाती है
यहाँ जो स्थिति बताई गई है, वह मेरे अनुभव से भी बहुत मिलती है
हमारी कंपनी में कई ऐसे managers हैं जिन्होंने वर्षों से code नहीं लिखा, और 18 महीने पहले hire किए गए architect ने AI से सब कुछ design किया
senior developers को साफ़ दिख रहा था कि सब कुछ बहुत ज़्यादा overengineered है, लेकिन क्योंकि वह सभी सही terms इस्तेमाल करता था, इसलिए upper management को वह दूसरे senior managers से ज़्यादा competent दिखता था, और जब उसकी आलोचना होती तो वह personal attack पर उतर आता था
करीब 6 महीने बाद कई लोग चले गए, जो बचे वे AI पर पूरी तरह टिक गए, और capable कर्मचारियों के जाने से बने खालीपन को भरने के लिए पिछले 12 महीनों से agentic workflows बना रहे हैं
नतीजा यह है कि पिछले 18 महीनों में कुछ भी मूल्यवान ship नहीं हुआ, badly designed solutions पर बहुत cloud computing cost जला दी गई, और अब hiring freeze लगाकर खर्च कम किया जा रहा है
जब economics इतने बड़े पैमाने पर बदलते हैं, तो यह मानो बाँध हटा देने जैसा है, जिससे बाकी system पर बहुत ज़्यादा stress पड़ता है
अगर organizational leaders इसके संभावित side effects और risk नहीं देख पाते, तो उन्हें भारी नुकसान हो सकता है
इस technology को भले universal improvement की तरह बेचा गया हो, लेकिन लगता है आगे ऐसी कंपनियाँ तेज़ी से बढ़ेंगी और फिर गिरेंगी
जो कंपनियाँ बचेंगी, वे इस बेकाबू घोड़े को साधने का तरीका फैलाएँगी, और आदर्श रूप से भविष्य में कुछ सीख भी मिलेगी
लेकिन अभी जो naïve excitement है, वह चौंकाने वाली है, और नई मिली vibe coding की क्षमता से ज़रूरत से ज़्यादा उत्साहित लोगों का अनंत सितंबर कुछ समय तक चलता रहेगा
उससे पिछली नौकरी में vibe coding अभी practical भी नहीं थी, लेकिन कुछ लोग LLM से हर चीज़ को और ज़्यादा फुलाने में इतने डूबे हुए थे कि किसी भी सवाल का हाँ/ना जवाब मिलना मुश्किल हो गया था
Slack पर एक लाइन का, 20 सेकंड वाला सवाल भेजो, तो जवाब में निष्कर्षहीन दो पेज का धुँधला blog post मिल जाता था, और follow-up सवाल सिर्फ़ और समय बर्बाद करते थे
पिछली नौकरी में मैंने PM को धीरे-धीरे vibe coders का vibe manager बनते देखा
वह technical discussion में घुसकर हर चरण पर AI से direction देता था, और जब हम विरोध करते, तो मामला ऐसा हो जाता कि विषय न समझने वाला कोई व्यक्ति AI के अनुवादित नतीजे के लिए हमसे लड़ रहा है — यह बेहद थकाऊ था
विरोध की अनुमति भी नहीं रही, और AI के कारण नौकरी खतरे में है, ऐसी बातों से दबाव बनाया जाता था
बाद में सबके लिए vibe coding अनिवार्य कर दी गई और उसकी मात्रा तक track की जाने लगी, और वह PM जब PM, engineer, और architect — तीनों भूमिकाएँ निभाने लगा, तो वही एक ही काम के लिए पूरी तरह अलग requirements वाले कई tickets बना देता था
फिर टीम का एक सदस्य एक तरीके से vibe coding करता और दूसरा किसी दूसरे तरीके से implement करता
लगभग 100 million dollar वार्षिक profit कमाने वाली 20 लोगों की profitable team को बेकार और अर्थहीन काम से टूटते देखना बहुत कठिन था, और आखिरकार मैं चला गया
software industry के इन बदलावों को लेकर cynical न बनने की कोशिश करता हूँ, लेकिन यह सचमुच कठिन है
manager, domain को अधूरा समझते हुए, Claude का उपयोग करके expert advice और proposals देता है, और कंपनी के कई non-technical लोग organization-wide इस्तेमाल के लिए internal software tools बनाकर ऐसे demos से पहचान और rewards लेना चाहते हैं
leadership स्वाभाविक रूप से ऐसे proof of concept से प्रभावित होकर approval दे देती है
बहुत ज़्यादा सक्रिय सहकर्मी अंदर की बात समझे बिना expert जैसे दिखने वाले demo दिखाते हैं, और leadership उसे स्वीकार कर लेती है
मैं समझ नहीं पा रहा था कि इस समस्या को कैसे शब्द दूँ, लेकिन इस लेख ने उसे ठीक से पकड़ लिया
हाँ, AI होने पर कम बनाने में थोड़ी और मदद ज़रूर मिलती है
यह बेहद toxic environment लगता है
LLM का उपयोग करके अच्छा software बनाने वाली सबसे productive teams शायद इसे आम तौर पर इन कामों में इस्तेमाल करेंगी
intelligent autocomplete LLM का वही मूल उपयोग है, जहाँ generated code developer के सोचने की प्रक्रिया के विस्तार की तरह काम करता है और वह काम करते समय code context बनाए रखता है — यह सोच को LLM के हवाले करना नहीं है
brainstorming में यह धुँधले concepts, ideas, और directions को नए ढंग से विस्तार देकर creativity को stimulate कर सकता है
problem solving में यह package conflicts, random exceptions, और bug reports जैसी debugging में काफी उपयोगी हो सकता है, और जब बगल में कोई सहकर्मी न हो तो root cause तक पहुँचने में मदद कर सकता है
code review में यह कभी-कभी कुछ ऐसी चीज़ें पकड़ लेता है जो इंसान से छूट जातीं, इसलिए यह ज़्यादा smart lint step जैसा है, लेकिन human code review का विकल्प नहीं
proof of concept में यह समस्या के लिए अलग-अलग approaches generate कर सकता है, जिनसे अधिक सावधानी से बनाए गए समाधान की प्रेरणा मिल सकती है
ऐसे उपयोग development speed बढ़ाते हैं, फिर भी developer की यह ज़िम्मेदारी बनाए रखते हैं कि वह क्या और क्यों बना रहा है
इसके उलट, जो teams agentic coding पर पूरी तरह दाँव लगाती हैं, वे लंबे समय में product और team — दोनों को अनजाने में नुकसान पहुँचाने की अधिक संभावना रखती हैं
हाल में कुछ बार जो जवाब मिले, वे पूरी तरह plausible थे लेकिन पूरी तरह गलत, और कई बार तो विषय से भी बाहर थे
code review में false positives बहुत ज़्यादा हैं, और यह भी नहीं दिखता कि इसमें सुधार क्यों होगा
फिर भी इस दिशा में मदद की संभावना हो सकती है
मैंने तो लगभग एक साल पहले इसे बंद कर दिया और पारंपरिक JetBrains IDE autocomplete पर लौट गया
मेरे अनुभव में AI suggestions ने ठीक वही चीज़ predict की जो मैं चाहता था — ऐसा 1% से भी कम हुआ; उपयोगी भी शायद 10% मामलों में रहा, बाकी या तो गलत था या परेशान करने वाला
methods, variables वगैरह को जल्दी खोजने या navigate करने वाली standard IDE features मेरे लिए विचार को code में बदलने में कहीं ज़्यादा उपयोगी रहीं
हमारी team ने भी कुछ tools आज़माए, लेकिन जो बातें बताई गईं उनमें ज़्यादातर बहुत सतही थीं या समस्या ही नहीं थीं
कम सक्षम team members के code को review करते समय वे गहरे issues चूक गए, जबकि human reviewers ने ऐसे गलत changes पकड़े जिन्हें बेहतर तरीके से हल किया जा सकता था
manager ने उन नतीजों को अपने इस bias की पुष्टि के सबूत की तरह इस्तेमाल किया कि हमें पता नहीं हम क्या कर रहे हैं
वह code review tool के emoji-भरे output को PR comments में paste कर देता था, और जब हम मामूली issues ठीक करते, तो वह “code review round 2” पोस्ट कर देता
morale बहुत गिर गया और कुछ team members ने review करना ही लगभग छोड़ दिया और PR बस approve करने लगे
अपने code की self-check के लिए यह ठीक है, लेकिन process पर थोपे गए hard constraint जैसा नहीं होना चाहिए
code review का मूल उद्देश्य एक-दूसरे के सुधार के लिए समय निवेश करना था, और जब यह मशीन को outsource कर दिया जाता है, तो team के भीतर का social contract टूट जाता है
2 साल पहले कहा जाता था कि यह बस pure autocomplete और बेहतर Google है
AI के pessimists हर साल गलत साबित होते रहे हैं, फिर भी वे इस बात को अनदेखा करते हैं कि उन्होंने कहा था AI कभी वह स्तर हासिल नहीं कर पाएगी जो आज वह कर रही है
software engineering में कुछ कारणों से यह चीज़ विशेष रूप से संभव लगती है
बहुत से software engineers ने अपने पूरे career में कभी असली engineering की ही नहीं, और बड़ी कंपनियों में यह और भी ज़्यादा सच है
वे एक छोटे gear की तरह किसी बड़े machine में फिट हो जाते हैं, किसी ऐसे व्यक्ति द्वारा promotion पाने के लिए बनाई गई configuration language सीखते हैं, उसी configuration को साफ़ और refactor करते हैं, फिर किसी दूसरे internal framework के output को settings knobs घुमाकर “fix” करते रहते हैं — और 5 साल बाद भी वही कर रहे होते हैं
इस industry में quasi-engineering roles भी बहुत हैं
जो लोग कहते हैं कि उन्हें लोगों के साथ काम करना पसंद है इसलिए coding छोड़ दी, या जो product और user workflows से मोहित हो गए — ऐसे लोग बड़ी और छोटी दोनों कंपनियों में .*M positions भरते हैं
बड़ी कंपनियों में गाड़ी इतनी धीमी चलती है कि commit को production तक पहुँचने में महीनों लग जाते हैं; 6 महीने भी सामान्य बात है
कई बड़े और महत्त्वपूर्ण systems में agentic code अभी production तक पहुँचा भी नहीं है
इसलिए AI कुछ दिखावटी नौकरियों को replace कर रही है, code के आसपास रहने वाले लोग अचानक vibe coding का मज़ा ले रहे हैं, और slow-moving कंपनियों में उसके नतीजे अभी फटे नहीं हैं
बाहर से यह productivity boom जैसा दिखता है
“जो लोग code नहीं लिख सकते वे software बना रहे हैं, और जिन्होंने data systems कभी design नहीं किए वे data systems design कर रहे हैं” — यह पढ़कर “बड़ी tech कंपनी में project launch कैसे होता है” याद आ गया
खासकर यह पंक्ति: “launch कंपनी के भीतर एक social construct है. विशेष रूप से, project तभी launch हुआ माना जाता है जब कंपनी के महत्वपूर्ण लोग मान लें कि वह launch हो गया है.”
https://news.ycombinator.com/item?id=42111031
वह अच्छा लेख था, और उसने दिखावे को बनाए रखना तथा दिखना हमेशा महत्त्वपूर्ण होता है — और अक्सर हमारी सोच से कहीं ज़्यादा महत्त्वपूर्ण होता है — इस पर अच्छी चर्चा भी शुरू की थी
workplace में AI adoption के शुरुआती दौर में मैंने देखा कि कुछ सहकर्मी इसे अतिसक्रिय पहल दिखाने के लिए इस्तेमाल कर रहे थे
हर हफ़्ते नया TOD, नया refactoring idea, पुरानी समस्या को चमकदार नए algorithm से हल करने का प्रस्ताव — ऐसी चीज़ें आती थीं
अब यह घटना दोगुनी हो गई है; ज़्यादा proactive दिखने की कोशिश में AI layoffs का डर भी जुड़ गया है, इसलिए समस्या ठीक से define होने से पहले ही लोग solutions बना रहे हैं
उदाहरण के लिए, मुझे कंपनी-स्तर की एक खास architecture समस्या की जाँच का काम दिया गया था, और लगा था कि अगर मैं ठोस समाधान दूँगा तो recognition मिलेगा — लेकिन मैं बहुत देर कर चुका था
intern पहले ही solution निकाल चुका था और TOD लिख चुका था, और अब compete करने की ऊर्जा ही नहीं बची
कल मैंने अपना ज़्यादातर समय LLM-generated code हटाने और उसकी जगह नया code लिखने में बिताया
आम तौर पर LLM की मदद अच्छी रही है, लेकिन इस बार उसने पागलों जैसी thread code की भरमार कर दी, और कई सालों में पहली बार मेरा app crash होने लगा
मेरा app crash नहीं करता
और समस्याएँ हो सकती हैं, लेकिन crash उनमें से एक नहीं है, और मैं इस मामले में बहुत जिद्दी हूँ
मेरे अनुभव का नियम है कि नया thread dispatch करना लगभग कभी ज़रूरी नहीं होता
अक्सर OS SDK को ऐसा करने दिया जा सकता है और उसके फैसले का सम्मान किया जा सकता है, लेकिन खुद worker thread उठाकर debugging की पीड़ा से ज़्यादा फ़ायदा मिलना बहुत दुर्लभ है
यह हर तरह के application पर लागू नहीं होगा, लेकिन मेरे apps पर लागू होता है
LLM को thread बहुत पसंद हैं, शायद इसलिए कि training code में ऐसे लोगों का code बहुत होगा जो चमकदार tech से अति-उत्साहित थे
आखिरकार मैंने UI code को काटकर अपनी तरफ़ से code डाला, तो performance स्पष्ट रूप से बेहतर हुई और crashes भी रुक गए
सबक है: buyer beware
उस बात से पूरी सहमति है कि आप सोचते रह जाते हैं कि उस व्यक्ति से बहस करें या नहीं जो model से copy-paste करके बात कर रहा है
ऐसे लोगों के साथ उसी अंदाज़ में जवाब देने में मुझे थोड़ा मज़ा भी आया है
मैं उनके AI output को अपनी AI में paste करता हूँ, फिर अपनी AI का जवाब वापस paste कर देता हूँ
इस तरह दो इंसान मशीनों की तरह बर्ताव करते हैं ताकि दो मशीनें इंसानों की तरह संवाद करने की cosplay कर सकें
नज़ारा वाकई शानदार था
दोस्तों के बीच proof of concept के लिए AWS पर overengineer करने के बजाय Vercel पर जल्दी launch करना क्यों सही है — इस पर मेरी senior-level दिशा के बारे में एक साधारण सवाल के जवाब में उसने AI की खिचड़ी चार्ट भेज दी
वह इस frame में बहुत फँसा हुआ था कि उसका भाई AWS इस्तेमाल करता है और वह खुद भी उसी दिशा में career चाहता है; इसलिए दोस्तों के साथ किए जा रहे proof of concept के लिए वह तरीका क्यों सही है, इस पर खुद सोचने के बजाय उसने सोच AI को outsource कर दी
उसने मुझसे पूछा कि क्या मैंने पढ़ा, तो मैंने कहा कि AI से summarize कराकर पढ़ लिया, लेकिन जवाब नहीं दिया — और बातचीत जल्दी खत्म हो गई
“यह experts के किसी काम का नहीं” वाली बात थोड़ी short-sighted लगती है
कोई भी कितना ही brilliant क्यों न हो, उसके कुछ weak areas होंगे या कुछ ऐसे उबाऊ हिस्से होंगे जिन्हें automate किया जा सकता है
मेरे मामले में, करियर में जो चीज़ें पहले अड़चन बनती थीं वे थीं एक साथ बहुत सारे tasks को organize करना, organization भर में changes को प्रभावी ढंग से communicate करना, और Jira जैसी जगहों पर documentation और ticket management करना
अब यह सब चिंता का विषय नहीं रहा, और उस हिस्से में efficiency gain बहुत बड़ा रहा है
जिन core कामों में मैं अच्छा हूँ, उनमें typing बहुत तेज़ कर देने के अलावा यह बहुत बड़ी मदद नहीं करता, लेकिन वह भी काफ़ी अच्छा है
और जब मुझे कोई ऐसा काम दिया जाता है जिसमें मैं सहज नहीं हूँ, तो यह आम तौर पर या तो मुझसे बेहतर करता है, या कम-से-कम मुझे ऐसी दिशा में ले जाता है जहाँ मैं ज़्यादा informed decision ले सकूँ
“model से validation मत माँगो. tool हर किसी से सहमत हो जाता है.” — इस बात से सहमत हूँ
LLM में अगर मैं मनमाने ढंग से कह दूँ कि कुछ गलत है, तो वह उस code में भी किसी-न-किसी तरह flaw ढूँढ निकालेगा जिसे मैं सही जानता हूँ
समस्या यह है कि LLM अक्सर चीज़ों को बहुत literally लेता है
planning करने को कहो, तब भी LLM कभी पूरे system को स्वायत्त रूप से design करने में सफल नहीं हुआ
LLM से code बनवाने के बाद अगर अलग-अलग तरीकों से पूछा जाए कि क्या यह सही है, तो वह काफ़ी बार वास्तविक समस्याएँ पकड़ लेता है