शायद अभी software development सीखने का सबसे अच्छा समय है

 (substack.com)
43 पॉइंट द्वारा GN⁺ 2025-06-19 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • AI code agents के आगमन से ऐसा लग सकता है कि developers की भूमिका खत्म हो जाएगी, लेकिन तर्क यह है कि अभी development सीखने का सबसे अच्छा समय है
  • developer सिर्फ code लिखने वाला व्यक्ति नहीं है, बल्कि वह समस्या के मूल को पहचानने और वास्तविकता व requirements के बीच संतुलन बनाने वाला होता है
  • AI ऊपर-ऊपर से काम करता हुआ code जल्दी बना देता है, लेकिन असल में अक्सर गलत समस्या हल कर देता है या भ्रम पैदा करता है
  • जो developer fundamentals सीखते हैं और AI का सही इस्तेमाल करना जानते हैं, वे उल्टा और भी अधिक productivity और impact हासिल करेंगे
  • बदलाव अपरिहार्य है, इसलिए AI का उपयोग करना जानने वाले human experts का महत्व और बढ़ेगा

What do you do while awaiting the agents writing your code?

  • जब code agents काम कर रहे होते हैं, लेखक उस दौरान exercise करता है या नए agents आज़माता है
  • लेकिन कई agents को एक साथ संभालना आसान नहीं है, और कभी-कभी बिना ठीक से समझे बार-बार "ठीक कर दो!!" जैसी request दोहरानी पड़ती है
  • ऐसे माहौल में भी आनंद लेने वाला लेखक, developers के अंत की चेतावनी देने वाले माहौल के उलट, कहता है कि यही सबसे अच्छा समय है

Developers are highly-paid farmers. LLMs are the combine harvesters.

  • Tom Blomfield के tweet का उद्धरण

    "Developers उच्च-वेतन वाले किसान हैं, और LLMs combine harvesters हैं"

  • AI की वजह से एक developer अब पहले की तुलना में बहुत अधिक काम कर सकता है, और यह क्षमता तेज़ी से फैल रही है
  • यह धारणा मौजूद है कि AI human developers की भूमिका को replace कर सकता है, लेकिन उल्टा tools की तरह इसका इस्तेमाल करना जानने वाले लोग और ज़्यादा महत्वपूर्ण हो रहे हैं
  • इसका मतलब developers की भूमिका का गायब होना नहीं, बल्कि उसका और शक्तिशाली हो जाना है

1. It’s your moat, too

  • यह बात कि developer कंपनी की competitiveness (moat) हैं, उल्टा खुद developers पर भी लागू होती है
  • AI की वजह से competitors भी मज़बूत हो रहे हैं, ऐसे में मौजूदा developers को निकालना लगभग आत्मघाती कदम है
  • जब competitors AI का उपयोग करके अपना क्षेत्र बढ़ा रहे हों, तब सिर्फ बचाव में लगे रहना आपको पीछे छोड़ सकता है
  • developers अब helicopter या combine harvester से लैस सैनिकों जैसे हैं, और जो कंपनियाँ इन्हें अच्छी तरह इस्तेमाल करेंगी वही जीतेंगी

2. AI grants wishes, developers discover

  • AI user की सतही मांगों को तेज़ी से implement कर देता है, लेकिन ज़्यादातर असली समस्याएँ coding नहीं बल्कि definition और design की समस्याएँ होती हैं
  • वास्तविकता की समझ की कमी और गलत requests के कारण कई बार बिल्कुल उल्टे-सीधे नतीजे बन जाते हैं
    • उदाहरण: blockchain-आधारित app है, लेकिन वास्तविकता यह है कि password sharing हो रही है और 2FA भी नहीं है
    • उदाहरण: customer portal है, लेकिन असली data अब भी Excel में manually save किया जाता है
  • AI आपको "आरामदेह जवाब" दे सकता है, लेकिन यह पहचानने वाला expert चाहिए कि क्या वह सच में उपयोगी जवाब है
  • AI का इस्तेमाल करके सीखना संभव है, लेकिन अगर fundamentals कमज़ोर हों तो आखिरकार सिर्फ भटकने में ज़्यादा समय लगता है
  • GDPR या security जैसे complex concepts को भी AI implement कर सकता है, लेकिन users अक्सर उनके मतलब को पूरी तरह नहीं समझते
  • developers अभी भी ज़रूरी हैं क्योंकि वे मूल मुद्दा खोजते हैं और गलत requests को छाँटते हैं
  • AI सिर्फ learning assistant है, असली developer बनने के लिए foundational knowledge और वास्तविक दुनिया की समझ ज़रूरी है

3. Software is kinda the last problem anyway

  • AI जिन अंतिम समस्याओं को हल करेगा उनमें software की समस्या भी हो सकती है, और अब भी बहुत सी software समस्याएँ बाकी हैं
  • AI tools लगातार बढ़ रहे हैं, और अच्छे व बुरे tools में फर्क कर पाने की क्षमता महत्वपूर्ण होती जा रही है
  • यह सीखने के लिहाज़ से सबसे आसान समय है, tools भी भरपूर हैं, और समस्याएँ हल करने के मौके भी बहुत हैं
  • ऐसे समय में यह कहना कि "AI सब कर देगा, तो developers कम कर देते हैं", दरअसल अपनी growth potential को खुद काट देने वाला फैसला है
  • AI के साथ बढ़ी developer पीढ़ी भविष्य में बहुत ताकतवर होगी, इसलिए आज का investment महत्वपूर्ण है

अभी सीखना आसान है, productivity ऊँची है, और human intervention की ज़रूरत अधिक है। AI के फैसलों को verify करने और उनकी जिम्मेदारी लेने वाले human experts की भूमिका आगे और महत्वपूर्ण होगी

निष्कर्ष

  • तकनीक हमेशा बदलती रहती है, और उसकी दिशा का सटीक अनुमान हमेशा संभव नहीं होता
  • लेकिन इंसानों की भूमिका अब भी महत्वपूर्ण है, और AI की गलत धारणाओं व त्रुटियों को verify करने और उनकी जिम्मेदारी लेने का काम इंसानों को करना होगा
  • सिर्फ AI का इस्तेमाल करना काफी नहीं है, उसे ठीक से संभालना जानने वाले human experts की निश्चित रूप से ज़रूरत है
  • आखिरकार developer किसी रोमांटिक तकनीकी अंत के नहीं, बल्कि एक नई शुरुआत के मोड़ पर खड़े हैं

संबंधित पढ़ाई

3 टिप्पणियां

 
draupnir 2025-06-20

मैं इससे पूरी तरह सहमत हूँ। मैं इस बात से सहमत हूँ कि धीरे-धीरे no-code tools के ज़रिए किए जा सकने वाले काम बढ़ेंगे, लेकिन जो लोग पहले से कुछ हद तक development जानते हैं या development सीखना चाहते हैं, उनके लिए AI की मदद लेना... लगता है कि यह अभी ही विस्फोटक रूप से बेहतर हो चुका है। जो लोग एक निश्चित स्तर की complexitiy को जिज्ञासा के साथ अपनाते हैं, उनके ज्ञान या अनुभव के बढ़ने की रफ़्तार, उस दिन का इंतज़ार करने से कहीं तेज़ और ज़्यादा मज़ेदार होगी जब बिना जाने भी काम किया जा सकेगा।
 
fanotify 2025-06-19

लेकिन (कम-से-कम घरेलू स्तर पर) कंपनियाँ इसे इस तरह लागू कर रही हैं

OOO group AI-केंद्रित रूप से संगठन का पुनर्गठन कर रहा है. ... सेवा maintenance जैसे अनिवार्य कामों के लिए कंबोडिया डेवलपमेंट सेंटर के डेवलपर्स का उपयोग किया जा रहा है, और डेवलपर्स सहित कुछ घरेलू कर्मचारियों को AI प्रशिक्षण पूरा कराने के बाद product team में स्थानांतरित करने की प्रक्रिया चल रही है. MMM OOO के vice chairman के अनुसार, डेवलपर्स सहित नई भर्तियाँ फिलहाल रोक दी गई हैं.

कहीं पहचान न हो जाए इसलिए मैंने masking की है, लेकिन यह एक वास्तविक लेख है: https://news.nate.com/view/20250610n33754
 
GN⁺ 2025-06-19
Hacker News राय

  • सच कहूँ तो, मुझे लगता है कि AI टूल्स का एक बड़ा और कम चर्चा किया गया फ़ायदा उनका “मनोवैज्ञानिक सहारा” होना है। जब काम में अटक जाते हैं, तब थोड़ी प्रेरणा या हौसला मिल जाना बहुत मायने रखता है। जवाब बिल्कुल परफ़ेक्ट न भी हो, तब भी वह आपको फिर से आगे बढ़ने लायक बना देता है। यह एहसास कि आप अकेले काम नहीं कर रहे, लोगों की सोच से कहीं ज़्यादा महत्वपूर्ण है

    • यह व्यक्ति पर निर्भर हो सकता है, लेकिन मैं तो LLM से 30 मिनट बात करके ही पूरी तरह थक जाता हूँ। ऐसा लगता है जैसे किसी ऐसे बेवकूफ से बात कर रहा हूँ जो खुद को बहुत जानकार समझता है। LLM को आपस में बात करते देखो तो बातचीत तुरंत बिगड़ती दिखती है, उसमें मुझे कोई प्रेरणा नहीं मिलती। Google पर खोजकर ऊपर आने वाले कभी-कभी ग़लत LLM सारांशों को नज़रअंदाज़ करना और असली विशेषज्ञ वेबसाइटों से जवाब ढूँढना कहीं ज़्यादा भरोसेमंद लगता है। वहाँ आमतौर पर उस कोड के मूल लेखक भी मिल जाते हैं जिसे LLM ने कॉपी किया होता है
    • मैंने छात्रों से AI पर चुटकुले बनाकर लाने को कहा था। मुझे लगता है कि हास्य लोगों के डर को ईमानदारी से बाहर लाने के सबसे अच्छे तरीकों में से एक है। एक छात्र ने लिखा, “उस दिन मैं जल्दी दफ़्तर पहुँचा, तो मॉनिटर चालू था और किसी ने छुआ भी नहीं था, फिर भी कोड लिखा जा रहा था। मैं भागकर बॉस के पास गया और कहा कि किसी ने मेरी मशीन में लॉग इन करके कोड लिखना शुरू कर दिया है। बॉस ने चिंतित चेहरे से कहा कि मुझे भ्रम हुआ है, वह कोई हैकर नहीं बल्कि कंपनी का नया एजेंट है। उसने बताया कि जब मैं सो रहा था, तब उसने वह ऐप बना दिया जिसकी हमें ज़रूरत थी। और जिस प्रमोशन का मैं हमेशा इंतज़ार करता था, उसकी खुशख़बरी भी है — मुझे prompt manager बना दिया गया है। तनख़्वाह आधी हो जाएगी, लेकिन अब दिन भर बस TikTok देखना होगा।” ऐसी बातों में मुझे असली मनोवैज्ञानिक सुकून ढूँढना मुश्किल लगता है
    • कुछ स्थितियों में जवाब जल्दी ढूँढ लेने के बजाय, खुद को थोड़ा और गहराई से सोचने के लिए मजबूर करना सीखने वाले के लिए बेहतर होता है। आसानी से हार न मानना और समस्या को बेहतर समझने की कोशिश करना भी एक महत्वपूर्ण क्षमता है। TikTok पीढ़ी जैसे तत्काल संतुष्टि वाले दौर में अफ़सोस होता है कि ऐसी गहरी सोच शायद और कम होती जाएगी। मुझे यह भी समस्या लगती है कि प्रबंधन भी इस तरह के व्यवहार को बढ़ावा दे रहा है। तेज़ नतीजे ही सबसे महत्वपूर्ण मूल्य बनते जा रहे हैं, और दीर्घकालिक सोच या सही दिशा से ज़्यादा गति पर ज़ोर दिया जा रहा है
    • मुझे तो ऐसा कोई मनोवैज्ञानिक सहारा बिल्कुल महसूस नहीं हुआ। उल्टा, मेरा मनोबल ही टूटता हुआ लगा। “AI से पूछ लो” वाली अपेक्षा के कारण सहयोग भी कम हुआ है, और आगे जूनियर या मिड-लेवल लोगों की भर्ती भी कम होती दिख रही है, इसलिए करियर विकास के मौके भी उतने ही घटते नज़र आ रहे हैं
    • मुझे लगता है इसके फ़ायदे और नुकसान दोनों हैं। LLM की वजह से flow state में जाना आसान होता है, यह सचमुच मदद करता है, लेकिन साथ ही यह तनाव निकालने की जगह भी बन जाता है। जब LLM बहुत हास्यास्पद बर्ताव करता है, तो मैं जानबूझकर उससे काफ़ी बुरा व्यवहार करके अपना तनाव निकाल लेता हूँ। इंसानों पर निकालने से तो यह बेहतर ही है। हाँ, Skynet से मुझे शायद कभी अच्छा व्यवहार नहीं मिलेगा

  • “अच्छी ख़बर है, बॉस! हमने एक नई तकनीक बना ली है जिससे गैर-विशेषज्ञ भी सीधे अंग्रेज़ी में कोड लिखकर डिप्लॉय कर सकते हैं! अब महंगे डेवलपर रखने की ज़रूरत नहीं पड़ेगी!” “अरे, ज़रा दिखाओ तो!” “जी, यह रही। इसका नाम COBOL है”

    • FORTRAN(Formula Translator) भी एक तरह का “AI” था, जो automatic programming की कोशिश करने वाला एक शुरुआती प्रोजेक्ट था। 1954 से पहले लगभग सारी प्रोग्रामिंग machine code या assembly language में होती थी, और कहा जाता है कि प्रोग्रामरों को प्रोग्राम को कुशल बनाने के लिए काफ़ी रचनात्मक होना पड़ता था। FORTRAN ऐसा सिस्टम था जिसमें आप गणितीय संकेतों में expression लिखते थे और कंप्यूटर खुद तेज़ प्रोग्राम बना देता था (संदर्भ लिंक1) (संदर्भ लिंक2)
    • मैंने इसे मज़ाक में कहा था, लेकिन मुझे लगता है कि सब लोग जानते हैं कि यह असल में सच भी है। SQL के बारे में भी ऐसा ही दावा किया गया था — declarative language में आप बताते हैं कि आपको क्या चाहिए, और कंप्यूटर उसे खुद संभाल लेता है। और वह भी अंग्रेज़ी में ही लिखा जाता है
    • यह सचमुच बहुत बढ़िया अभिव्यक्ति है, और मैं इससे सहमत हूँ। मैं यह ज़ोर देकर कहना चाहता हूँ कि तकनीकी innovation वह चीज़ है जो पाई को इस तरह बड़ा करती है जैसा पहले संभव नहीं था। जैसे digital camera के आम होने से हर कोई फ़ोटोग्राफ़र बन सकता है, या YouTube पर रचनात्मकता का विस्फोट हुआ — वैसे ही LLM और programming के साथ भी है। अंततः मैं इसे ज़्यादा apps और ज़्यादा developers पैदा करने वाली एक फ़ायदेमंद दिशा मानता हूँ
    • हम अक्सर भूल जाते हैं कि ऐसी high-level languages की वजह से वे लोग भी programming में आ सके जिन्हें पहले “गैर-विशेषज्ञ” माना जाता था
    • मुझे लगता है कि कुछ दशकों बाद हम कह रहे होंगे, “यह है Dreamweaver”

  • कई बार कंपनियों की बढ़ा-चढ़ाकर की गई प्रतिक्रियाएँ और मीडिया द्वारा हवा दिए गए रामबाण समाधान देख लेने के बाद, मुझे काफ़ी अंदेशा है कि यह AI लहर भी पहले जैसी ही दिशा में जाएगी। कंपनियाँ आख़िरकार ज्ञान-आधारित काम करने वालों के ख़िलाफ़ फ़ैसले लेती हैं, लेकिन executives की compensation कम नहीं होती। फिर भी, यह लहर TFA लेखक जैसे बुद्धिमान और बेहद प्रेरित builders के लिए एक बहुत बड़ा अवसर लगती है। अगर आपकी मौजूदा नौकरी ख़तरे में है या जा चुकी है, तो शायद यही वह समय है जब आप वह कर सकते हैं जो अब तक व्यस्तता या थकान के कारण नहीं कर पाए। इस प्रक्रिया में आप ऐसी आय का अच्छा स्रोत भी बना सकते हैं जो कंपनियों के रहमोकरम पर निर्भर न हो, और कुछ लोग तो ऐसी चीज़ भी बना सकते हैं जिसे कंपनियाँ बाद में बड़ी रकम देकर खरीदना चाहें

    • मैंने तो शुरू भी कर दिया है। मैं लंबे समय से अपने लिए voice notes रिकॉर्ड करता रहा हूँ, लेकिन अब तक या तो उन्हें बस पढ़ता था या जमा होने देता था। रिकॉर्ड करना आसान है, लेकिन उनमें से जानकारी निकालना मुश्किल है। इन दिनों मैं ऐसा software बना रहा हूँ जो इन voice notes से तेज़ी से जानकारी निकाल सके। यह सिर्फ़ भविष्य के इतिहासकारों के लिए ही नहीं, मेरे अपने काम के लिए भी सीधा उपयोगी होगा। अगर AI न होता, तो मेरे पास ऐसे प्रोजेक्ट पर ध्यान देने का समय नहीं होता। कोड और architecture का ज़्यादातर हिस्सा मेरे अपने हाथ से आता है, लेकिन AI ने गति दे दी है
    • “अगर नौकरी चली गई है या ख़तरे में है, तो अब वह बनाओ जिसके बारे में तुम अब तक सोचते रहे” — यह सलाह बुरी नहीं है, लेकिन जिन्हें अभी नौकरी नहीं मिल रही या आगे software jobs कम होने वाली हैं, उनके लिए यह घातक भी हो सकती है। कुछ साल पहले लोग कहते थे कि AI नौकरियाँ नहीं छिनेगा, लेकिन मैं तब भी कह रहा था कि लोगों को जल्दी से दूसरी skills सीखनी चाहिए। अगर डेवलपर की नौकरी नहीं मिल रही, तो emergency savings ख़त्म होने से पहले घर पेंट करना या carpet installation सीखना ज़्यादा व्यावहारिक survival strategy हो सकती है। यह याद रखना चाहिए कि startup से बड़ा पैसा कमाने या उससे लगातार जीवनयापन कर पाने की संभावना बेहद कम है। ख़ासकर अगर आप परिवार पाल रहे हैं, तो मैं यही कहूँगा कि लापरवाही से इतना बड़ा जोखिम न लें

  • मैं काफ़ी लिखता हूँ, लगभग डायरी की तरह, लेकिन आमतौर पर साझा नहीं करता। पहले ही बता दूँ कि मेरी लिखाई कुछ हद तक scribble जैसी होती है। फिर भी, आजकल software developers की value को बहुत ज़्यादा निराशावादी नज़र से देखने वाली प्रवृत्ति में थोड़ा संतुलन लाना चाहता था, इसलिए साझा कर रहा हूँ

    • मैं तुम्हारी लिखी चीज़ें और ज़्यादा बार पढ़ना चाहूँगा। nuclear fusion पर पोस्ट हो तो भी चलेगा
    • लिखाई सचमुच प्रभावशाली थी। ऐसा लगा जैसे किसी पुराने डेवलपर ब्लॉगर को पढ़ रहा हूँ। कृपया आगे भी पोस्ट करते रहना
    • पढ़ने में बहुत अच्छा लगा। इसे लिखने के लिए धन्यवाद
    • हास्य ताज़गी भरा था, अच्छा लगा
    • आजकल डेवलपर ब्लॉग बहुत ज़्यादा गंभीर हो गए हैं, इसलिए ऐसी चतुर व्यंग्यात्मक शैली देखकर खुशी हुई और आभार भी

  • मैं security क्षेत्र में हूँ, डेवलपर नहीं, लेकिन degree के दौरान software development सीखा था। अगर सिर्फ़ शीर्षक देखकर अपनी राय दूँ, तो मुझे लगता है कि जब basics आसानी से सीखे जा सकते हों, तब कुछ भी सीखने का यही सबसे अच्छा समय होता है। पहले bug ठीक करने, concepts समझने, उन्हें लागू करने का तरीका खोजने के लिए ऑनलाइन forums में बहुत समय भटकना पड़ता था। LLM tutor की तरह काम कर सकता है — कई सवालों के जवाब देना, code feedback देना, concepts समझाना, error कहाँ है बताना वगैरह। सच तो यह है कि हम रोज़मर्रा में जिन चीज़ों को “बेवकूफ़ी भरे सवाल” मानते हैं, असल में अक्सर वही चीज़ें खोज रहे होते हैं। हाँ, intermediate या उससे ऊपर के लोगों पर यह फ़ायदा कैसे लागू होता है, इस बारे में मैं अभी पूरी तरह आश्वस्त नहीं हूँ

    • मुझे भी लगभग इन्हीं कारणों से काफ़ी मदद मिली है। मैं LLM के साथ ideas उछाल सकता हूँ, या पूछ सकता हूँ, “क्या मैंने इसे सही समझा है? मैं कहाँ ग़लत हूँ?” मुश्किल समस्याओं के बिल्कुल आख़िरी हिस्से तक इसकी सटीकता पर मैं भरोसा नहीं करता, लेकिन reasoning की दिशा अक्सर सही लगती है। इससे अटके हुए हिस्से जल्दी खुल जाते हैं, और मैं खुद से ज़्यादा विविध और गहरे सवाल पूछने लगता हूँ, इसलिए सीखने की रफ़्तार तेज़ हो जाती है
    • intermediate स्तर से ऊपर LLM का सबसे अच्छा उपयोग शायद खुद learning के रूप में नहीं, बल्कि accelerator या catalyst के रूप में करना है

  • मैं मानता हूँ कि agriculture वाली उपमा दिलचस्प है, लेकिन अगर Jevons paradox सचमुच लागू होना है, तो demand curve बहुत elastic होना चाहिए, जबकि food वास्तव में inelastic होता है। अभी सबसे बड़ा अज्ञात यह है कि software की माँग और कितनी बढ़ सकती है, और AI की capability की सीमा आख़िर कहाँ तक है

    • फिर भी एक बात साफ़ है। 19वीं सदी के आख़िर में बने बड़े-बड़े मकान साफ़ दिखाते हैं कि वह दौर किसानों के लिए कभी “बहुत ऊँची मज़दूरी” वाला रहा होगा। लेकिन असल में combine harvester के आविष्कार के 50 से 75 साल बाद जाकर वह समृद्धि आई। अगर यह उपमा सही है, तो आज के डेवलपर शायद भविष्य के LLM युग की तुलना में अभी भी काफ़ी ग़रीब हों। लेकिन एक अहम फ़र्क यह है कि पुराने किसान अपने काम के मालिक थे, जबकि आधुनिक software engineers ज़्यादातर किसी कंपनी के कर्मचारी हैं। इसलिए अगर इतिहास खुद को दोहराता है, तो इस बार भी मालिकों के जीतने की संभावना ज़्यादा है
    • food demand भी elastic होती है। अगर beef महँगा हो जाए, तो chicken, pork, tofu, beans जैसे substitutes की demand बढ़ जाती है। फल या non-essential चीज़ों में demand elasticity और भी ज़्यादा होती है, और उपभोक्ता खर्च में उनका हिस्सा भी काफ़ी है। अगर सस्ता cereal बहुत आम हो जाए, तो लोग गुणवत्ता छोड़ने का समझौता कुछ हद तक करते हैं, और स्वाभाविक रूप से उच्च-गुणवत्ता वाले उत्पादों की माँग भी बढ़ती है। मुझे लगता है कि LLM के विकास के साथ software बाज़ार में भी quality और premium software की माँग लगातार बढ़ेगी
    • खाने की calories की माँग अपने आप में inelastic है, लेकिन जब कुल भोजन प्रचुर हो जाता है, तो नतीजा यह निकल सकता है कि लोग environment damage, inefficiency और ethical विवादों से भरे “meat production” की तरफ़ शिफ्ट कर जाते हैं
    • यह राय भी मौजूद है कि विकसित देशों में households द्वारा food waste की दर काफ़ी ऊँची होने से food demand सहज अनुमान से कहीं ज़्यादा elastic हो सकती है

  • रूपक (metaphor) भले ही विश्वसनीय लगें, लेकिन उन्हें वास्तव में समर्थन देने वाले सबूत की ज़रूरत होती है। “कृषि मशीनरी” एक सही उपमा हो सकती है, लेकिन यह CAD tools द्वारा mechanical engineering drawings को हाथ से बनाने वाले दौर के प्रतिस्थापन जैसा मामला भी हो सकता है। और जब engineers पूरी तरह CAD से replace नहीं हुए, तो मेरे हिसाब से यह ज़रूरी नहीं कि बात agriculture जैसी अत्यधिक productivity shift वाले नतीजे तक ही पहुँचे

  • मैं इस लेख की पूरी framing से सहमत नहीं हूँ। ख़ासकर मुझे नहीं लगता कि efficiency gain combine harvester जितना विशाल है। लेकिन असली महत्वपूर्ण बदलाव यह है कि value सिर्फ़ “coding skill” में नहीं, बल्कि domain knowledge, business logic की समझ, और technical तथा non-technical stakeholders के बीच अच्छे से आना-जाना करते हुए मूल समस्या हल करने की क्षमता में शिफ्ट हो रही है। मुझे लगता है कि outsourcing की लहर के समय, लगभग 20 साल पहले, हमने यह बदलाव पहले भी देखा था

    • combine वाली उपमा आकर्षक इसलिए लगती है क्योंकि गेहूँ के खेत जैसी चौड़ी सपाट सतह पर उत्पादन बढ़ने की तस्वीर साफ़ दिखती है, लेकिन इसमें यह बात छूट जाती है कि code की lines बढ़ा देना अपने आप में ज़रूरी नहीं कि उपयोगी भी हो

  • मूल रूप से यह बहुत पुराना दोहराया जाने वाला पैटर्न है। Low-code और No-code tools आने के बाद गैर-विशेषज्ञों द्वारा बनाए गए solutions का आख़िरकार cleanup engineers को ही करना पड़ा है। मैंने भी ऐसे cleanup work से काफ़ी ठीक-ठाक career बनाया है

    • ChatGPT से बना Node/React app अब नए तरह का “VBA macro भरा हुआ Excel” बनता जा रहा है
    • मौजूदा AI स्तर पर तो मुझे लगता है कि ऐसे मौके और बढ़ेंगे

  • इन सब बातों को जोड़कर देखें तो कंपनियों को डेवलपर layoffs रोकने चाहिए। लेकिन वास्तव में layoffs पहले से हो रहे हैं। आजकल संगठनों में जो बात ज़्यादा दिखती है वह यह है: “अगर remote है, तो कम वेतन वाले क्षेत्र से लोगों को रख लो”, और “AI से डेवलपर replace कर दो” वाली सोच भी साफ़ तौर पर मौजूदा HR strategy से जुड़ रही है। और इससे भी बुनियादी बात यह है कि पिछले 20 सालों में डेवलपर्स का काफ़ी काम आख़िरकार ऐसे काम में गया है जिसका वास्तविक उपभोक्ता प्रभाव बहुत कम था, मानो बस ‘ध्यान की लूट’ जैसा कुछ

    • मैं पलटकर पूछना चाहूँगा कि इसका अर्थ कैसे निकाला जाए। ज़्यादातर संगठनों में औसत से कम क्षमता वाले लोगों को निकालना और उसी compensation band में औसत से ऊपर के लोगों को भर्ती करना प्रभावी होता है। और जितना ज़्यादा उच्च-क्षमता वाले लोग AI की मदद से अपनी effectiveness बढ़ाएँगे, यह अंतर उतना ही बड़ा होगा। आगे चलकर “टॉप टैलेंट को ज़्यादा फ़ायदा” देने वाली प्रवृत्ति और मज़बूत होना लगभग तय है