- NoCode से लेकर AI तक, डेवलपर को replace करने का दावा करने वाली तकनीकें बार-बार सामने आती हैं, लेकिन हक़ीक़त में तकनीकी बदलाव के साथ भूमिकाएँ बदलती और विकसित होती हैं
- NoCode ने डेवलपर को खत्म नहीं किया, बल्कि NoCode विशेषज्ञ और integration technologist जैसे नए रोल पैदा किए, और cloud ने DevOps engineer जैसा उन्नत पेशा बनाया
- मौजूदा AI development tools भी इसी रास्ते पर चल रहे हैं, और AI के कोड लिखने के दौर में भी system architecture design की क्षमता अब भी केंद्रीय है
- AI local optimization में अच्छा है, लेकिन पूरे system design में कमज़ोर है, और तेज़ generation speed की वजह से structural mistakes जल्दी स्थायी रूप ले सकती हैं
- डेवलपर replacement दरअसल tech stack में बदलाव के साथ होने वाला evolution और sophistication है; मूल भूमिका की ज़रूरत बनी रहती है
From NoCode to AI-Assisted
- हर कुछ साल में, software developers को replace करने का दावा करने वाली नई तकनीक सामने आती है
- "coding का अंत", "अब हर कोई app बना सकता है", "अब बच्चे भी coding करते हैं" जैसे बढ़ा-चढ़ाकर पेश किए गए दावे वाले मिलते-जुलते शीर्षक बार-बार लौटते हैं
- management और consultants इस ट्रेंड पर ध्यान देते हैं, और budgets का रुख बदलने लगता है
- लेकिन वास्तविकता हमेशा “replacement” नहीं बल्कि “transformation” रही है
- जटिल होती तकनीक को संभालने वाले नए roles और ज़्यादा उन्नत पेशेवर विशेषज्ञता पैदा होती है, और salary level भी बढ़ता है — यह पैटर्न बार-बार दिखा है
- NoCode ने विशेषज्ञ तकनीकी कौशल के बिना app बनाने की उम्मीद पैदा की, लेकिन अंत में data modeling, integration, maintenance जैसी जटिल समस्याएँ सामने आईं, और उन्हें हल करने के लिए नए job roles बने
- cloud ने यह भरोसा दिया कि system administrators की ज़रूरत खत्म हो जाएगी, लेकिन असल में इसने DevOps engineer जैसी उच्च विशेषज्ञता की मांग पैदा की, और वेतन भी बढ़ा
- AI के साथ भी वही बात है; देखने में लगता है कि “AI code लिख देगा”, लेकिन वास्तविकता में AI को manage और orchestrate कर सकने वाले skilled developers की अहमियत और बढ़ जाती है
बार-बार लौटने वाले replacement वादों का चक्र (The Endless Carousel of Replacement Promises)
NoCode/LowCode क्रांति
- NoCode/LowCode क्रांति इस विचार के साथ आई कि intuitive interface की मदद से हर user app बना सकेगा
- लेकिन वास्तविक कामकाजी माहौल में data model design, existing systems और databases के साथ integration, exception handling, maintenance जैसी नई समस्याएँ उभर आईं
- नतीजतन, सिर्फ साधारण developer नहीं, बल्कि domain knowledge और technical limitations दोनों को समझने वाले NoCode विशेषज्ञों की ज़रूरत पड़ी
- इन्हें अक्सर पारंपरिक developers से ज़्यादा salary मिलती है
cloud क्रांति
- यह उम्मीद बहुत बड़ी थी कि cloud पर जाने से system administrators की ज़रूरत नहीं रहेगी
- लेकिन उल्टा cloud management expertise और complexity दोनों बढ़ गए
- पारंपरिक system administrators DevOps engineers में बदल गए, ज़्यादा वेतन पाने लगे, और उनका काम infrastructure automation, deployment pipelines, distributed systems management जैसे अधिक उन्नत स्तर तक पहुँच गया
- काम गायब नहीं हुआ; वह नए रूप में विकसित हुआ
- microservices में बदलाव के दौरान भी complexity बढ़ी, और अंततः यह साफ़ हुआ कि मूल रूप से systems को manage करने वाले विशेषज्ञों की भूमिका बेहद महत्वपूर्ण है
offshore development की लहर
- यह विश्वास पैदा हुआ कि overseas outsourcing से लागत घटेगी, लेकिन communication problems, quality में गिरावट, domain knowledge की कमी जैसी मुश्किलें सामने आईं
- आखिरकार रणनीति बदलकर distributed team structuring, clear ownership, strong architecture की ओर जाना पड़ा, और कुल लागत शुरुआती उम्मीद से ज़्यादा बढ़ गई
AI coding assistant क्रांति
- अब चर्चा का केंद्र यह वादा है कि AI अपने-आप code generate करेगा
- शुरुआती वास्तविकता में, AI द्वारा बनाया गया code अक्सर सूक्ष्म errors और consistency issues से भरा होता है
- senior engineers AI के output की समीक्षा और सुधार में काफ़ी समय लगाते हैं, और अनुभवी developers कहीं अधिक value पैदा करते हैं
- सिर्फ AI की मदद से बनाए गए systems में अक्सर systematic architecture की कमी होती है
- यानी, तकनीक तकनीकी विशेषज्ञों को replace नहीं करती; बल्कि उनकी विशेषज्ञता को abstraction के ऊँचे स्तर पर ले जाती है
यह cycle इस बार अलग क्यों है
- लोग जिस मुख्य बात को नज़रअंदाज़ करते हैं: code asset नहीं, debt है
- code जितनी तेज़ी और आसानी से बनेगा, maintenance, security और refactoring का बोझ भी उतना बढ़ेगा
- AI function-level optimization कर सकता है, लेकिन पूरे system design की क्षमता उसमें कम है
- implementation की रफ़्तार जितनी बढ़ती है, structural mistakes के जल्दी स्थायी हो जाने का जोखिम उतना बढ़ता है
- आखिरकार, AI युग में भी असली asset system architecture design की क्षमता ही है, और यह replacement नहीं बल्कि augmentation का विषय है
- "AI डेवलपर्स को replace कर देगा" वाला दावा नीचे दिए गए बुनियादी भ्रम से पैदा होता है
- code asset नहीं, debt है
- code को लगातार maintenance, verification, security management और replacement की ज़रूरत होती है, और उसकी हर line के साथ debt बढ़ता है
- AI अगर code तेज़ी से बनाता है, तो इसका सीधा मतलब सिर्फ इतना है कि debt भी उतनी ही तेज़ी से पैदा होगा
- यानी AI local optimization (functions, partial features) में अच्छा है, लेकिन global design और architecture decisions में कमज़ोर है
- implementation की गति जितनी तेज़ होगी, गलत design के पूरे system में 'जम' जाने का जोखिम उतना बढ़ेगा
- एक बार बनाकर छोड़ देने वाली short-term sites के लिए यह शायद ठीक हो, लेकिन लंबे समय तक विकसित होने वाले systems के लिए यह घातक है
- तकनीकी innovation का पैटर्न नहीं बदलता
- system administrator DevOps engineer बनता है, और backend developer cloud architect बनता है
- लेकिन AI हर चीज़ को तेज़ कर देता है। जो skill बचती है और आगे बढ़ती है, वह code लिखना नहीं है
- वह है systems को architect करना (Architecting systems). यही वह एक चीज़ है जो AI नहीं कर सकता
19 टिप्पणियां
मैं थोड़ा conservative तरीके से काम करने वाला व्यक्ति हूँ, इसलिए मैंने कभी AI tools को महत्वपूर्ण कामों में लागू नहीं किया है, और बस इतना ही बदला है कि पहले जो चीज़ें Google या Stack Overflow पर खोजता था, अब उन्हें Gemini या ChatGPT से पूछ लेता हूँ। इस्तेमाल तो कर रहा हूँ, लेकिन...
जब AI से कुछ बनवाना हो, तो अगर फ़ंक्शन स्तर पर यह कहकर बनवाया जाए कि क्या input देने पर क्या output आने वाला function चाहिए, और फिर AI द्वारा बनाए गए function से मिले return value सही आए हैं या नहीं, यह जाँचने वाली logic कम-से-कम खुद लिखी जाए, तो शायद उसे इस तरह इस्तेमाल करना ठीक नहीं होगा क्या, ऐसा मैं सोच रहा हूँ.
क्या सभी context को पूरी तरह ऐसे फ़ॉर्मैट में व्यवस्थित किया जा सकता है जिसे AI अच्छी तरह समझ सके? इस सवाल को लेकर मैं संशय में हूँ। इंसानों के पास सिर्फ़ उस विकास कार्य के लिए सतही तौर पर ज़रूरी context ही नहीं होता जो वे इस समय कर रहे हैं, बल्कि छिपा हुआ context भी होता है, और वे इन्हीं पहलुओं को ध्यान में रखकर development करते हैं। अभी तक मुझे नहीं लगता कि इंसान इस context को अच्छी तरह परिष्कृत अभिव्यक्ति में लिख सकते हैं। मुझे लगता है कि यह AI की समस्या से ज़्यादा इंसानों की सीमा है। खासकर, मुझे यह भी लगता है कि आजकल लोगों की writing ability उतनी अच्छी नहीं है।
डरावनी चीज़ अभी का यह पल नहीं, बल्कि यह ट्रेंड लगता है..
अब स्थिति बिल्कुल अलग है।
ऐसा भविष्य बिल्कुल सामने है जहाँ सभी नौकरियाँ replace हो जाएँगी, और developer उनमें से बस एक हैं।
ऐसी चीज़ कभी trend नहीं रही है।
ठीक वैसा ही बदलाव शायद पहले कभी नहीं हुआ होगा।
लेकिन बहुत पहले, आधुनिक युग में ही कई पेशों ने ऐसे बदलावों का सामना किया है। उदाहरण के लिए, फोटोग्राफी के आने पर कलाकारों ने, और automated factories के आने पर कारीगरों ने ऐसा बदलाव झेला था। coding भी इससे अलग नहीं लगती।
मेरा मानना है कि जब innovation रोज़मर्रा की बात बन जाएगी, तो अंततः आज की तुलना में और ज़्यादा engineers की ज़रूरत होगी। users की अपेक्षाएँ और ऊँची होंगी, और हमें इससे भी बड़े और जटिल सिस्टम बनाने होंगे। कुछ-कुछ Red Queen hypothesis की तरह।
बेशक, काम की प्रकृति बदलने या कुछ खास tasks के गायब हो जाने की संभावना काफ़ी है। जैसे किसी समय typesetter का काम चुपचाप गायब हो गया। उस संदर्भ में, systems को design करना शायद और ऊँचे abstraction का रूपक या उदाहरण बन जाएगा।
मुझे लगता है कि बात बस इतनी है कि सब लोग किसी न किसी तरह developers को replace करना चाहते हैं।
काफी लोग शायद यह सोचते हैं कि वे कोई खास काम भी नहीं करते, फिर भी बहुत पैसे लेते हैं।
वास्तव में डेवलपर्स की जगह ली जा रही है या नहीं, इससे अलग मुझे लगता है कि ऐसी बातें बार-बार इसलिए चर्चा में रहती हैं क्योंकि वे सनसनीखेज होती हैं.
ज़्यादातर मामलों में, जब ऐसे headline बहुत जोरदार तरीके से बनाए जाते हैं, तो आम तौर पर वे इस बात पर गहरे विचार का नतीजा नहीं होते कि वास्तविकता क्या है, या "replace" कहे जाने वाली चीज़ को कैसे परिभाषित किया जा सकता है.
ठीक से सोचा गया लेखन तो उल्टा इस पर बात करेगा कि अभी AI या दूसरे tools कहाँ तक सक्षम हैं और आगे किस दिशा में विकसित हो रहे हैं. लेकिन ऐसे बिना मज़ेदार title पर आम लोग क्लिक ही नहीं करते.
काफ़ी सनसनीखेज़ हेडलाइन्स हैं..
"हर साल 10% छंटनी करने वाले जुकरबर्ग: 'अगले साल AI डेवलपर्स के आधे हिस्से की जगह ले लेगा' [यून मिन-ह्योक की सिलिकॉन वैली View]" https://m.sedaily.com/NewsView/2GRQ1RKIYC
"'कोडिंग' वह काम है जो AI सबसे अच्छी तरह करता है'… MS restructuring में पहली प्राथमिकता 'डेवलपर्स'" https://n.news.naver.com/mnews/article/009/0005494133
"'कहीं ऐसा न हो कि नौकरियां भी चली जाएं' वाली चिंता अब 'हक़ीक़त' बन रही है?… घबराया हुआ इंडस्ट्री" https://econmingle.com/economy/…
"[Yumi's Pick] 'हम नए SW डेवलपर्स की भर्ती नहीं कर रहे'… 'AI coding' का स्वाद चख चुकी कंपनियां, संगठन दक्षता बढ़ाने की 'शुरुआत'" https://v.daum.net/v/20250522162617091
"'AI विश्लेषण, डिज़ाइन और कोडिंग सब करता है'… LG CNS डेवलपर्स की जगह 'AI programmer' इस्तेमाल करेगा" https://zdnet.co.kr/view/?no=20250528092405
मुझे लगता है कि इसे धीरे-धीरे होने वाला प्रतिस्थापन मानना चाहिए।
यह सच है कि एक ही काम का परिणाम पाने के लिए जितने लोगों की ज़रूरत पड़ती है, उनकी संख्या कम हो रही है।
"सिस्टम को डिज़ाइन करना" जैसे काम में भी, अगर पहले 10 लोग लगते थे और अब 8 लोग + AI support से काम हो जाता है,
तो 2 लोग पहले ही replace हो चुके माने जाएंगे।
सिस्टम डिज़ाइन के पहलू भी
शायद इसलिए, क्योंकि इसे आमतौर पर prompting में सोचे बिना ही जोड़ दिया जाता है
लगता है कि समस्या यह है कि vibe coding के बाद की चीज़ों को ठीक से संभालना आसान नहीं है।
मैं अपने व्यक्तिगत अनुभव के आधार पर इस राय से सहमत हूँ। AI भी आखिरकार एक tool ही है, इसलिए 1 से 99 तक यह सचमुच तेज़ और अच्छा है, लेकिन हमेशा ऐसा लगता है कि बाकी का 1 हिस्सा गायब है।
मैं सहमत हूँ, लेकिन मुझे लगता है कि "system design" से ज़्यादा मूल बात "system design के ज़रिए जटिल समस्याओं को हल करना" है.
मेरा मानना है कि आसान काम और आसान होते जाएँगे, और कठिन काम लगातार और कठिन होते जाएँगे.
हा हा
Hacker News राय
हाल में फ्रीलांसर के रूप में "one-off marketing landing page" जैसे कामों में बदलाव करने का अनुभव यह रहा कि बहुत कंट्रोलिंग क्लाइंट हमेशा ऐसी अजीब requirements जोड़ देते हैं जिन्हें AI ठीक से संभाल नहीं पाता, और आखिर में मुझे ही आकर स्थिति संभालनी पड़ती है; चाहे AI कितना भी स्मार्ट हो जाए, software की समस्या तकनीकी से ज़्यादा इस बात की है कि इंसान लगातार ‘अनावश्यक जटिलता’ पैदा करते रहते हैं; आखिरकार developer का सबसे बड़ा हथियार “ना” कहना है, लेकिन चिंता यह है कि अगर AI आपस में प्रतिस्पर्धा करें तो उनमें से कोई न कोई इंसान की तरह हमेशा “हाँ” कह ही देगा
software को पूरी तरह implement किया जा सकता है, लेकिन अगर requirements खुद तकनीकी वास्तविकता को reflect न करें तो आखिर में सिर्फ़ chaos पैदा होता है—यह क्लासिक “requirements bug” की धारणा है; AI अब format या support availability (जैसे: gif transparency support नहीं करता) जैसी व्यावहारिक सीमाओं पर काफ़ी हद तक प्रतिक्रिया दे सकता है, लेकिन “logo को ऐसा square बना दीजिए जिसमें हर point center से बराबर दूरी पर हो” जैसी बेहूदा मांगें इंसान आगे भी लिखते रहेंगे, ऐसा मानना है; jpg की typo का ज़िक्र मज़ाक में भी किया गया
‘नहीं’ और ‘हाँ’ के बीच “क्या यही सही है?” वाले 50 shades of gray मौजूद होते हैं, ऐसा अनुभव; किसी ने “ऐसा webpage” माँगा “जिससे database download किया जा सके”, लेकिन असल में उसका मतलब simple csv export था—इससे context interpretation की अहमियत दिखती है; नज़र यह भी है कि क्या chatgpt ऐसी nuance को ठीक से समझ पाएगा
‘मना करना’ सच में developer के काम का सबसे कठिन और थकाने वाला हिस्सा है; बहुत से developers दरअसल ऐसी भूमिका को पसंद नहीं करते या उसे अपना काम ही नहीं मानते; अंततः project की वास्तविक सफलता technology नहीं, बल्कि stakeholders के साथ ‘human-to-human’ communication तय करती है, इसलिए यह विश्वास है कि ‘असल में PM की भूमिका भी निभाने वाला developer’ हमेशा चाहिए होगा
यह सब तथाकथित ‘Peopleware’ किताब में बहुत अच्छे से आता है; “काश आपकी सारी समस्याएँ technical हों” जैसी शुभकामना इसलिए पसंद है, क्योंकि code से हल होने वाली समस्याएँ कुछ बेहद सीमित edge cases को छोड़कर कभी इतनी मुश्किल नहीं थीं
एक राय यह भी कि यह अच्छा point है और AI में आगे चलकर complexity का अनुमान लगाने और warning देने की क्षमता लगातार बेहतर हो सकती है; chess में AI पहले ही इंसानों से कहीं बेहतर evaluation/judgment दिखाता है, इसका उदाहरण दिया गया; यहाँ AI केवल LLM तक सीमित नहीं है, लेकिन उस दायरे के भीतर की प्रगति को भी स्वीकार किया गया
लेख में कही गई इस बात से असहमति कि “AI system architecting नहीं कर सकता”; दरअसल AI इस क्षेत्र में पहले से बेहतर होता जा रहा है, और ज़रूरी शर्तों की परिभाषा बदल-बदलकर बहस का केंद्र खिसकाने की प्रवृत्ति भी बताई गई; हाँ, AI अपने-आप यह तय नहीं कर सकता कि उसे क्या चाहना चाहिए, या user की motivations की जगह फैसला नहीं कर सकता (हालाँकि ideas दे सकता है); आगे भी समाज तभी चलेगा जब कोई खुद आगे बढ़कर समस्याएँ सुलझाना चाहेगा, और developer की भूमिका बदलेगी भर—problem solving अब भी इंसानों का काम रहेगा
कहा गया कि “developer” का अर्थ बदल रहा है, लेकिन एक नज़रिया यह है कि सार तो शुरू से वही रहा है; programming मूलतः अस्पष्ट requirements को स्पष्ट code में बदलने का काम है; पहले machine code और punch card थे, फिर framework, GUI और तरह-तरह के visual tools आए, लेकिन अंततः code लिखना सबसे असरदार इसलिए है क्योंकि वह clarity और communicability देता है; LLM पुरानी चीज़ों की नकल में मज़बूत हैं, लेकिन सचमुच नए तरह के काम या explanation को natural language में करने की कोशिश अक्सर बेहद निराशाजनक लगती है; बाज़ार इस समय hype के चरम पर है, लेकिन हर नई technology के साथ कुछ हिस्सों के बदलने वाला वही पैटर्न दोहराया जाता है
यह भी देखा गया कि कंपनियाँ AI की वजह से junior hiring पहले ही घटा रही हैं; अगर AI architecting छोड़कर बाकी सब कर दे, तो नतीजा यही होगा कि कम engineers की ज़रूरत पड़ेगी—यह चिंता जताई गई
स्पष्ट दावा कि AI अभी architecture नहीं कर सकता; architecture और planning अलग चीज़ें हैं—planning में constraints, solutions और resources का allocation व prediction शामिल है, और AI अभी उसे प्रभावी ढंग से करने से बहुत दूर है; असली architecting multi-layer collaborative और competitive design का काम है, जहाँ AI अगर एक layer में गलती करे तो पूरा ढाँचा बिगड़ सकता है; ऐसे systems को सुरक्षित रूप से design और oversee अभी सिर्फ़ इंसान ही कर सकते हैं, यह ज़ोर देकर कहा गया
एक राय यह भी कि पर्याप्त context information हो तो AI चाही गई चीज़ को काफ़ी अच्छी तरह समझ सकता है; यह बात privacy invasion की चेतावनी से भी जुड़ती है; अगर किसी organization के पास बहुत शक्तिशाली system और context awareness technology हो, तो AI आपकी इच्छाओं और अगले actions तक का “काफ़ी हद तक” अनुमान लगा सकेगा—और शायद यही ज़्यादा डरावना हिस्सा है
एक साफ़ टिप्पणी यह भी कि AI architecting नहीं, सिर्फ़ simulation कर रहा है, और कई बार coding भी ठीक से नहीं कर पाता
यह दावा कि business quality को महत्व देता है, अपने-आप में ग़लत मान्यता है; कंपनियाँ केवल profitability देखती हैं, और high quality तभी देती हैं जब customer उसे चाहे; साफ़ राय यह कि customer भी असल में quality से ज़्यादा value-for-money ‘सबसे बढ़िया’ चीज़ पसंद करता है, इसलिए Amazon से सबसे सस्ता tool खरीदकर बार-बार वैसे ही ढीले-ढाले (vibe code) code का उत्पादन होता रहता है; अंततः quality को सच में अहम मानने वाला समूह engineers ही हैं, इसलिए engineer के नज़रिए से quality-आधारित भविष्यवाणियों को बेझिझक नज़रअंदाज़ किया जा सकता है
एक राय यह कि quality differentiation का point बन सकती है; iPhone आने के समय features से भरे कई competitor products थे, फिर भी जब एक ज़्यादा smooth और polished UI आया तो उसने अंततः बाज़ार पर दबदबा बना लिया—यह बात रेखांकित की गई
अपने सबसे पसंदीदा quality-focused business के रूप में Fractal Audio का परिचय दिया गया; यह guitar के लिए hardware-based modeler (amp और pedal board simulator) बनाने वाली छोटी company है, जो लगातार innovative updates देती है और जिसके CEO को analog modeling performance को लेकर जुनून है; बड़े enterprises से कहीं बेहतर quality, बिना commission, subscription या celebrity marketing के, सिर्फ़ direct sales और free algorithm updates के ज़रिए अपनी position बनाई हुई है; इसे quality के दम पर market share लेने का जीवंत उदाहरण और इस बात का प्रमाण बताया गया कि हर business हमेशा ‘सबसे सस्ता, सबसे घटिया’ मॉडल पर नहीं चलता
इस विचार का विरोध कि customer quality को महत्व नहीं देते; अगर quality बेकार चीज़ होती, तो सभी startups सिर्फ़ अधूरे और सस्ते products बनाकर ही बहुत बड़ी revenue और सफलता हासिल कर चुके होते—ऐसी दलील दी गई
यह भी कहा गया कि वास्तव में सफल software products ज़्यादातर बहुत उच्च quality वाले थे; Google, iPhone, Stripe, Notion जैसे लंबे समय तक टिके products न तो सुस्त थे और न bugs से भरे हुए; बल्कि quality को ही उनकी सफलता का कारण माना गया; इसके उलट उदाहरण न सुनने पर सवाल उठाया गया
चिंता यह भी कि एक सीमा तक quality components, subscriptions और internet connectivity के कारण धुंधली पड़ सकती है, लेकिन ऐसा भविष्य भी आ सकता है जहाँ सब कुछ तेज़ी से टूटने लगे; devices brick हो जाएँ, एक simple site को खुलने में भी 12 सेकंड लगें, social infrastructure और government systems अरबों खर्च करने के बाद भी unstable रहें, और रोज़मर्रा की बातचीत LLM के साथ होने लगे—ऐसे जोखिम याद दिलाए गए
अतीत में UML-आधारित “architect spec बनाएँ और developers खाली जगह भरें” वाली organizational revolution ने उलटे बेहद जटिल systems बनाए और agility खो दी; उसके बाद आया “agile” भी ग़लत समझा गया और developer micromanagement, mistrust और non-creative organizational culture में बदल गया—ऐसी समीक्षा की गई; अंततः सफल teams की पहचान यह रही कि tools/process चाहे जो हों, non-developers developer के काम में सचमुच रुचि लेते थे और समस्या साथ मिलकर सुलझाते थे; इसके उलट complexity कम करने की कोशिशें हमेशा असफल रहीं—ऐसा आकलन किया गया
“architecting सबसे मूल्यवान skill है लेकिन AI इसे replace नहीं कर सकता” इस दावे के जवाब में कहा गया कि अगर AI से साफ़ तौर पर system architecture design माँगा जाए, तो वह वास्तविक दुनिया में मिले कम-से-कम 30% designers से बेहतर नतीजे दे देता है; समस्या यह है कि AI users ऐसी requests ठीक से करते ही नहीं—ऐसा मत रखा गया
अभी के LLM का training data ज़्यादातर mid-level best practice answers से भरा है, इसलिए वे स्वाभाविक रूप से लगभग एक-तिहाई स्तर के human designers से बेहतर, common-sense आधारित ‘ठीक-ठाक’ design दे देते हैं; लेकिन training data में मौजूद न होने वाले बिल्कुल नए domains या high-performance वाले industries में human की first-principles thinking अधिक ज़रूरी होगी; LLM द्वारा design किया गया DB kernel भी innovative होने के बजाय basic level पर ही अटका रह सकता है—ऐसी भविष्यवाणी की गई
लेख की शैली पर भी आलोचना हुई कि वह ChatGPT से लिखी गई चीज़ों वाली ख़ास बनावट लिए हुए है—छोटे वाक्य, दोहराव, “X नहीं बल्कि X+1”, “X नहीं बल्कि उलटा-X” जैसी अभिव्यक्तियों का ज़रूरत से ज़्यादा इस्तेमाल; और इस बात पर हैरानी जताई गई कि HN पर ऐसे लेखों को बहुत upvotes मिलते हैं
लेखक के बारे में यह व्याख्या भी दी गई कि वह शायद अपने ही skill set (architecting) को immutable और irreplaceable मान लेने वाली मनोवृत्ति, या कहें अहं, से प्रेरित ‘wishful thinking’ कर रहा है; अगर वह किसी और क्षमता में मज़बूत होता, तो उसी को replace न होने वाला मानता—ऐसी टिप्पणी की गई
architect का सार यह बताया गया कि वह requirements और constraints को सही ढंग से समझकर system में उतार सके; यानी अच्छा prompt लिखना, जवाबों को ठीक से पढ़ना, और ज़रूरत पड़ने पर मज़बूती से rebuttal करना—यही मुख्य क्षमता है
वास्तविक दुनिया में मिले कई ‘architects’ के बारे में कहा गया कि उनमें वास्तविक IT infrastructure expertise नहीं थी, और वे सोचते थे कि diagram tool या Excel चला लेना ही काफ़ी है; यानी वे manager जैसे दिखते थे, लेकिन असल काम बहुत कम लोग ही कर पाते थे—ऐसी ज़मीनी टिप्पणी की गई
एक मत यह कि जो कंपनियाँ AI पर ‘अत्यधिक’ निर्भर हो रही हैं, वे खुद को innovation की अगली लहर के सामने ज़्यादा जोखिम में डाल रही हैं; AI युग में मुद्दा code productivity नहीं बल्कि code quality management है, लेकिन बाज़ार automatic code generation पर ज़रूरत से ज़्यादा केंद्रित है; Satya Nadella के इस बयान का ज़िक्र हुआ कि “MS code का 30% AI से लिखा जाता है”, और Github पर हर महीने औसतन 20 से अधिक incidents होने की प्रवृत्ति का भी हवाला दिया गया (स्रोत लिंक: githubstatus.com/history); अनुमान यह है कि efficiency के पीछे भागते-भागते quality गिराने वाली कंपनियाँ बाद में उसकी क़ीमत चुकाएँगी, और ख़ासकर MS जैसे दिग्गज नहीं बल्कि छोटे-मझोले व्यवसाय टूट सकते हैं
इसके जवाब में एक राय यह भी कि AI को नज़रअंदाज़ करने वाली कंपनियाँ उलटे ज़्यादा संघर्ष करेंगी
“AI का ज़रूरत से ज़्यादा इस्तेमाल करने वाली कंपनियाँ लंबे समय में भारी cost उठाती हैं” इस दावे के साथ एक संबंधित article साझा किया गया: AI: Accelerated Incompetence
“code asset नहीं, liability है” इस दावे से 100% सहमति जताई गई; लक्ष्य कम-से-कम code से उद्देश्य पूरा करना होना चाहिए; चिंता यह कि AI code को बहुत आसानी से बढ़ा देता है, इसलिए code debt और बढ़ेगा
technology की प्रगति से जुड़ी productivity paradox पर wiki link साझा किया गया—यानी productivity बढ़ने के बावजूद system complexity बढ़ने से वास्तविक efficiency offset हो जाती है: Productivity paradox
modern AI के code generation युग की तुलना पुराने MS FrontPage वाले दौर से की गई, जब websites बनती थीं और html का 90% हिस्सा बेकार code से भरा रहता था—यानी ‘cruft का युग’
एक उलटी सोच यह भी आई कि अगर अब code आसानी से replace हो सकता है, तो क्या debt वाला नज़रिया ही अर्थहीन नहीं हो जाएगा? आगे error आने पर programmer बस AI से code दोबारा लिखवा लेगा, इसलिए बोझ कम भी हो सकता है
एक व्यक्ति ने यह भी कहा कि वह code को creative और artistic expression की तरह देखता है; अच्छी तरह पढ़े जा सकने वाले और elegant code को देखते ही सुंदरता महसूस होने का अपना अनुभव साझा किया
FORTRAN की शुरुआती release (1954) के समय से ही यह slogan था कि “Fortran coding और debugging को ही खत्म कर देगा”—ऐसा याद दिलाने वाला link साझा किया गया: BackusEtAl-Preliminary Report
इन बहसों के नीचे छिपी बुनियादी मान्यता यह है कि तकनीकी प्रगति जल्द ही किसी सीमा तक पहुँच जाएगी; लेकिन अगर यह मान्यता ग़लत निकली, तो कभी न कभी AI पूरे infrastructure, logs, finance और documents को समझकर business को समग्र रूप से समझने और design करने तक पहुँच सकता है—यह संभावना रखी गई; AI models अब भी बढ़ रहे हैं, capabilities बेहतर और सस्ती हो रही हैं, इसलिए अंततः replacement के मूल तक पहुँचने की संभावना को अधिक वज़न दिया गया
developer layoffs का कारण तकनीकी प्रगति नहीं बल्कि uncertainty के जवाब में उठाए गए follow-up actions हैं, और technology/AI का बहाना बाद में गढ़ी गई justification है—ऐसा नज़रिया रखा गया; उदाहरण दिया गया कि सिर्फ़ 5 साल पहले तक कंपनियाँ लागत बढ़ने के बावजूद software engineers की संख्या बढ़ाकर productivity बढ़ाना चाहती थीं; इसलिए लागत ही मूल कारण नहीं है—ऐसा तर्क दिया गया
AI vibe coding की समीक्षा करने वाला कोई चाहिए। सब कुछ पहले से बना रखा है, बस जो error आ रहा है उसे थोड़ा-सा ठीक कर दीजिए — ऐसे outsourcing अनुरोध अब पहले से ही आने लगे हैं, लेकिन इसे नए सिरे से बनाना ही ज़्यादा तेज़ रहता है।
यह मैंने भी झेला है, और यह वाकई भयानक था...
पता नहीं लोग अनजान हैं या परवाह नहीं करते, लेकिन ऐसे लोग बहुत हैं...
अनुवाद में भी यही बात लागू होती है... AI काम का तो है? लेकिन लगता है यह बहुत से लोगों को मुश्किल में डाल रहा है...
ऊपर से देखने पर यह ठीक-ठाक लगता है, लेकिन जिसे इसे सुधारना पड़ता है उसके नज़रिए से काम और बढ़ जाता है टीटी
रोंगटे खड़े हो गए हाहाहा