AI कोडिंग

• प्रोग्रामिंग के लिए AI की भूमिका संरचना पारंपरिक compiler जैसी है
• English prompt प्रोग्रामिंग भाषा के रूप में असटीक और अक्षम विशेषताएँ रखता है
• AI के productivity बढ़ाने के प्रभाव को वास्तव में बढ़ा-चढ़ाकर बताया जाता है या गलत समझा जाता है
• AI tools डेवलपमेंट प्रक्रिया को बदलते हैं, लेकिन वास्तविक नवाचार बेहतर language और tools से उभर सकता है
• LLM अपनाने का मतलब डेवलपर का प्रतिस्थापन नहीं है; बल्कि यह मौजूदा डेवलपमेंट वातावरण की सीमाओं को दिखाता है

---

AI और compiler की समानता

• लेखक का कहना है कि उम्र बढ़ने के साथ उन्होंने अब दूसरों को मनाने की कोशिश छोड़ दी है
• वे इस बात पर ज़ोर देते हैं कि बहुत से लोगों की सच्चाई में रुचि नहीं होती, वे केवल उन मान्यताओं का पालन करते हैं जिनसे उन्हें लाभ मिलता है
• 'Perception is reality(धारणा ही वास्तविकता है)' कहने वालों पर आलोचनात्मक दृष्टि प्रस्तुत की गई है
• self-driving car पर खर्च किए गए अरबों डॉलर को गलत विश्वास के कारण हुई बर्बादी बताया गया है
• यह मानना कि AI कोडिंग कर सकता है, उस नज़रिये जैसा है जिसमें compiler को कोडिंग करने वाला माना जाता है

AI कोडिंग, compiler जैसा ही एक मॉडल

• यह तर्क समझाया गया है कि प्रोग्रामिंग AI का सबसे उपयुक्त मॉडल compiler है
• उपयोगकर्ता prompt (code) इनपुट करता है और उसके परिणामस्वरूप compiled output प्राप्त करता है
• फर्क यह है कि Frprompt को English में इनपुट किया जाता है, लेकिन English में स्पष्टता की कमी है, specification नहीं है, और कई अन्य कमियाँ हैं
• नया काम या जटिल कार्य करते समय अंततः prompt की लंबाई और विस्तार बढ़ते जाते हैं
• AI का output non-deterministic होता है, और prompt के किसी एक हिस्से में बदलाव पूरे परिणाम को प्रभावित कर सकता है

AI कोडिंग पर आलोचनात्मक नज़रिया

• AI कोडिंग इसलिए सकारात्मक दिखती है क्योंकि मौजूदा tools, languages और libraries की गुणवत्ता कमजोर है
• "AI" तकनीक की वजह से पहले की तुलना में बेहतर search, optimization और pattern extraction tools संभव हुए हैं
• वास्तव में कोडिंग प्रोग्रामर स्वयं करता है; केवल code लिखने की भाषा बदल गई है
• यदि कोई कंपनी LLM से डेवलपर को बदल सकती है, तो इसका मतलब है कि उस कंपनी का codebase और hiring standard बहुत निम्न स्तर का है
• AI compiler या spreadsheet की तरह धीरे-धीरे कुछ कामों को अपने हाथ में ले सकता है

AI एक tool है, अंततः बेहतर language और library की ज़रूरत

• AI को एक tool के रूप में देखने के लिए बहुत सोच-विचार और सावधानी की ज़रूरत पर ज़ोर दिया गया है
• गलत अपेक्षाओं या भ्रम में निवेश करने से अरबों डॉलर की बर्बादी हो रही है
• “vibe coding” जैसे झूठे productivity tools पर बाज़ार की अतिप्रतिक्रिया का उल्लेख किया गया है
• यह भ्रम है कि AI वास्तव में productivity को 20% बढ़ाता है, जबकि एक study (paper) का हवाला दिया गया है कि वास्तव में यह 19% तक धीमा कर देता है
• वास्तविक प्रगति programming languages, compilers और libraries में innovation से आ सकती है

[GN⁺]

Hacker News राय

• मैं लगभग 50 साल का हूँ, और 90 के दशक के आखिर से पेशेवर तौर पर कोड लिख रहा हूँ। मेरे दिमाग में प्रोजेक्ट सीधे आकार ले लेते हैं, इसलिए मुझे ठीक-ठीक पता होता है कि क्या बनाना है। सैलरी भी काफ़ी अच्छी मिलती है। ऊपर से देखने पर मैं AI-विरोधी लोगों का एकदम क्लासिक उदाहरण लग सकता हूँ, लेकिन असल में ऐसा नहीं है। मैं कुछ भी बना सकता हूँ, लेकिन तरह-तरह के बेसिक कामों से अक्सर ऊब जाता हूँ। इसलिए मुझे यह सचमुच बहुत पसंद है कि AI का इस्तेमाल करके बोरिंग हिस्सों को जल्दी पार करूँ और उस मुख्य काम पर ध्यान दूँ जो मुझे पसंद है। AI development ऐसा है जैसे junior और mid-level के बीच के किसी developer को कुछ वाक्यों में अपनी सोच समझाकर उससे एक घंटे का काम करवा लेना। हाँ, यह गंभीरता से सोचने वाली बात है कि इससे असली junior developers बढ़ नहीं पाएँगे और भविष्य के senior developers का pool घट सकता है, लेकिन वह अलग मुद्दा है

  • आपने कहा कि आप AI से बोरिंग हिस्से फटाफट निपटा लेते हैं, लेकिन कुछ अनुभवी senior developers ऐसे भी हैं जो उलटे मुश्किल हिस्सों से डरते हैं और इसलिए AI के प्रति नकारात्मक हैं। बहुत से developers को बोरिंग और आसान हिस्सों में मनोवैज्ञानिक सुरक्षा मिलती है, और AI आने के बाद काम लगातार मुश्किल चीज़ों की श्रृंखला बन सकता है। अगर कोई senior सिर्फ़ लंबे अनुभव वाला है लेकिन उसकी वास्तविक क्षमता कमज़ोर है, तो लगातार चुनौतीपूर्ण काम करते-करते वह जल्दी थककर टूट सकता है। कंपनियाँ AI लाकर बस गति बढ़ाना चाहती हैं, लेकिन वे यह नज़रअंदाज़ करती हैं कि इंसानों को cognitive rest भी चाहिए। अगर सिर्फ़ बहुत कठिन काम ही बचे रहें तो यह लोगों के लिए अच्छा नहीं है। हाँ, जो developers repetitive और आसान कामों से ऊब जाते हैं, वे AI के साथ फिर से तरोताज़ा हो सकते हैं। आख़िरकार, हर व्यक्ति के लिए अलग दृष्टिकोण चाहिए

  • मैं भी आपसे थोड़ा छोटा हूँ, लेकिन मेरी सोच लगभग पूरी तरह वही है। शायद उससे भी ज़्यादा। अब मुझे दिलचस्प ideas को हकीकत बनाने वाला code लिखने में नहीं, बल्कि idea निकालने और experiment करने में ही मज़ा आने लगा है। इसलिए coding मैंने इसलिए की क्योंकि करनी पड़ती थी; यह मूल रूप से वह चीज़ नहीं थी जो मैं करना चाहता था। अगर मुझे अपने ideas को साकार करना होता था, तो मजबूरी में code लिखना पड़ता था। AI brainstorming partner के रूप में शानदार है। अगर आप उसे खुशामदी न होने के लिए कहें, तो वह सचमुच ईमानदारी से बता देता है कि मैं कहाँ over-engineering कर रहा हूँ। Debugging भी यह वाकई बहुत अच्छा करता है। इसलिए मैं कंप्यूटर से बात करके architecture और approach पर brainstorming करता हूँ, specs बनाता हूँ, और फिर implementation AI को दे देता हूँ। अगर मेरी सोच ग़लत हो तो AI के साथ तेज़ी से iterate करता हूँ। Iteration इतनी तेज़ है कि गलती हो भी जाए तो फ़र्क नहीं पड़ता। पहले अगर design ग़लत होता था तो पूरा codebase बदलना पड़ता, इसलिए लोग उसे झेलते रहते थे, लेकिन Agentic coding tools की वजह से अब पूरा codebase बदलना भी समस्या नहीं है। नए technical domains में भी, जहाँ मैं expert नहीं था, AI की वजह से मैं असरदार ढंग से घुस पाया और बहुत जल्दी कौशल बढ़ाया। सच कहूँ तो अभी मैं अपने programming career में सबसे ज़्यादा खुश हूँ। Tools हर हफ़्ते, और कभी-कभी हफ़्ते में कई बार, बेहतर हो रहे हैं

  • यह मेरे अनुभव से भी पूरी तरह मेल खाता है। मेरा experience भी लगभग इतना ही है। मैं भी AI को personal projects और company work दोनों में सक्रिय रूप से इस्तेमाल करता हूँ। पहला, AI कम पक्षपात वाला idea sounding board बन जाता है। तेज़ feedback loop और direction validation अब सचमुच ज़रूरी लगते हैं। दूसरा, यह typing और समय दोनों बचाता है। ‘बेसिक काम’ एक बार में कहो तो कम से कम 80% तक बिल्कुल सही कर देता है। यह 100% complete नहीं होता, लेकिन बचा हुआ समय इतना ज़्यादा होता है कि कुल मिलाकर फ़ायदा ही फ़ायदा है। AI इस्तेमाल करते समय मैं हमेशा guardrails रखता हूँ, instructions को जितना हो सके उतना specific और detailed देता हूँ, और हमेशा output खुद review करने की आदत डाल रहा हूँ

  • मुझमें आपसे लगभग 10 साल कम अनुभव है, लेकिन स्थिति मिलती-जुलती है। फिर भी मैं ज़्यादा relate नहीं कर पाता। मेरे लिए जैसे ही कोई हिस्सा बोरिंग होने लगता है, उसे automate या generalize करना इतना कठिन और challenging हो जाता है कि असल में बोरिंग काम बचता ही नहीं। उलटे, कई बार मैं खुद typing करूँ तो ज़्यादा तेज़ होता हूँ। non-trivial हिस्सों में खुद code लिखते समय मुझे बेहतर structure या automation ideas सूझते हैं। इसलिए ऐसा code बहुत कम होता है जिसे मैं किसी और को सौंपना चाहूँ। और शायद मैं ऐसा इसलिए सोच पाता हूँ क्योंकि मैं एक ही कंपनी में लंबे समय से हूँ। अगर मुझे लगातार नए code काम करने पड़ते, तो शायद मेरी राय अलग होती

  • मैं भी 50s में हूँ, 90s से coding कर रहा हूँ, और इतनी कमाई कर चुका हूँ कि ज़िंदगी में तीन बार से ज़्यादा इस्तेमाल कर सकूँ। 30 साल के career में मैंने सबसे बेहतरीन developers में जो common trait देखा, वह था ‘परफेक्ट आलस’। अजीब लग सकता है, लेकिन महान engineers में साझा गुण अगर कोई था, तो वही आलस था। यह लगभग चमत्कारिक लगता है कि आलस productivity में कैसे बदल जाता है। वजह यह है कि वे repetitive कामों को हर हाल में automate करते हैं। अगर कोई चीज़ दो बार की, तो तीसरी बार automation ज़रूरी है—यह उनका नियम होता है। AI के आने से automation का स्तर ही पूरी तरह बदल गया है। अब वे सारे काम भी automate हो सकते हैं जो पहले नहीं हो सकते थे। मैंने AI के इस्तेमाल के अनगिनत तरीके खोजे हैं, और सिर्फ़ मैं ही नहीं, मेरे आलसी सहकर्मी भी इसका बेहतरीन उपयोग करते हैं। अब AI के बिना काम की कल्पना करना मुश्किल है। यह इसलिए नहीं कि यह ‘जादू’ है, बल्कि इसलिए कि मेरे जैसे आलसी इंसान के लिए हर automatable काम AI कर देता है

• मुझे लगता है कि यह Hacker News पर अक्सर दिखने वाली AI groupthink का बेहद चरम उदाहरण है। Geohot शीर्ष 99.999% developers में हो सकता है, लेकिन जिन 99.999% developers को वह समझ नहीं पाता, वे अब भी कहीं ज़्यादा बुनियादी काम कर रहे हैं। यह expert paradox है। अगर सब expert स्तर के होते, तो वे expert कहलाते ही नहीं। मैंने बहुत से ऐसे developers देखे हैं जो AI की तरह व्यवहार करते हैं। वे अपने बनाए codebase को भी समझा नहीं पाते, न ही उसे लगातार maintain कर पाते हैं। यह ऐसा है जैसे कोई aerospace engineer Kinder Surprise toy बनाने वाले का मज़ाक उड़ाए कि उसे fluid simulation नहीं आती

  • मुझे यह सोचकर हैरानी होती है कि कुछ लोग मानते हैं कि HN AI के प्रति नकारात्मक है। मेरी नज़र में comments और popular posts देखें तो HN कुल मिलाकर technology को लेकर काफ़ी आशावादी है

  • self-driving company शुरू करने वाला व्यक्ति अगर यह रुख़ लेता है, तो यह भी बहुत असंगत लगता है। अगर AI models code नहीं लिख सकते, तो क्या वे driving जैसी उससे कहीं मुश्किल चीज़ को replace कर पाएँगे, इस पर संदेह होता है

  • लेख की शुरुआत में ही इसका जवाब दिया गया है। बात यह है कि कई सामान्य programming workflows इतनी आम हैं कि वे संभव हैं, लेकिन अगर नया काम करना हो तो language level जितनी detail में समझाना पड़ता है

  • मैं aerospace क्षेत्र में काम करता हूँ, और यहाँ के engineers भी कोई ख़ास बेहतर नहीं हैं। लेकिन बहुत चिंता की ज़रूरत नहीं है। कंपनी में ऐसे लोगों को ऐसे पदों पर भेज दिया जाता है जहाँ वे कोई नुकसान न पहुँचाएँ, और ज़्यादातर लोग management में चले जाते हैं

  • मुझे नहीं पता Geohot सच में शीर्ष 99.999% developers में है या नहीं। “Programming AI के लिए आदर्श model compiler है। उसे prompt (=code) दो, और वह compiled code निकाल दे। ज़्यादातर IDE की तरह feedback के साथ interactive तरीके से इस्तेमाल करने की बजाय prompt tweak → recompile बेहतर है।” क्या यह सचमुच सही है, इस पर मुझे शक है

• इस बहस के अहम बिंदुओं में से एक यह है कि “programming के प्रकार” को थोड़ा और ठोस तरीके से परिभाषित करने की ज़रूरत है। जैसे अगर कोई robot कुछ बना रहा हो और आप बस इतना पूछें, “robot अच्छा है या बुरा?”, तो बात का मतलब नहीं बनता; बहस आगे बढ़ाने के लिए पहले यह पूछना होगा कि “किस चीज़ के लिए?”

• मुझे लगता है कि इस लेख में कई समस्याएँ हैं। पहली, यह दावा कि “AI coding एक compiler है।” compiler specification के अनुसार किसी language को deterministically transform करता है, जबकि LLM coding tools constraints (tests/types/linters/CI आदि) के तहत बार-बार code को search, generate और modify करने वाले program synthesizers हैं। वास्तव में ये SWE-bench Verified जैसे बड़े open source issues भी end-to-end हल कर लेते हैं। दूसरी, यह दावा कि “programming language अंग्रेज़ी है।” असलियत में यह code, tests, specs, API, JSON schema, diff, IDE tools आदि का संयोजन है, और English सिर्फ़ glue का काम करती है। लेखक सबसे कमज़ोर interface को अलग करके उसी पर हमला करता है। तीसरी, non-determinism को समस्या बताना। वास्तविक दुनिया में fuzzing, SAT/SMT आदि में बहुत से probabilistic elements होते हैं, लेकिन अंतिम determinism और correctness बाहरी specs (tests, type systems, CI आदि) से आते हैं। और यह कहना कि LLM लोकप्रिय इसलिए हैं क्योंकि languages या libraries ख़राब हैं, एक ग़लत false dichotomy है। उदाहरण के लिए Rust, TypeScript जैसी languages बेहतर होने पर भी LLM अब भी API खोजने, repo tracing, repetitive code लिखने, migration, test writing, refactoring जैसी चीज़ों में मदद करते हैं। आख़िर में, लेखक सिर्फ़ “और बेहतर language या compiler बनाओ” जैसा विकल्प देता है, जबकि आधुनिक teams पहले से ही AI के साथ मिलकर बड़ा मूल्य पा रही हैं। इसलिए AI coding और LLM को “prompt से चलने वाला जादुई English compiler” मानकर अंधविश्वास करना नहीं, बल्कि अपने constraints (types, tests, CI आदि) के आधार पर मदद करने वाले “junior pair programmer” की तरह इस्तेमाल करना कहीं ज़्यादा व्यावहारिक है

  • (लेखक स्वयं) मैं इस राय से सहमत हूँ। अगर ब्लॉग पोस्ट मैंने इसी तरह लिखी होती, तो शायद वह लोकप्रिय नहीं होती। “LLM coding tools search-based program synthesizers हैं” — मेरे हिसाब से यह लगभग compiler की परिभाषा के काफ़ी करीब ही है। हाँ, ज़्यादातर compilers पर्याप्त search नहीं करते और heuristics पर बहुत निर्भर रहते हैं, लेकिन मुझे लगता है कि यह सिर्फ़ इसलिए है क्योंकि runtime integration नहीं होता। “Engineering tools में कई चीज़ें non-deterministic होती हैं” — यह सही है, लेकिन जैसे SAT solver में randomness आने से solve time बदल सकता है, correctness नहीं। Fuzzer तो testing के लिए होते हैं, इसलिए उनसे मूल रूप से पूर्णता की उम्मीद नहीं की जाती। मैंने production में deploy किया गया fuzzer नहीं देखा। “Determinism बाहरी tests या specs से आता है” — इससे मैं पूरी तरह सहमत हूँ। मेरा सपना ऐसा language है जिसमें implementation नहीं, सिर्फ़ behavior को spec के रूप में बताया जाए। कुछ-कुछ Halide के schedule concept को और सामान्य बनाने जैसा। कंप्यूटर खुद implementation method खोज ले। मुझे लगता है AI ऐसे tools दे सकता है। ज़रूरी नहीं कि वह LLM ही हो, लेकिन सख़्त specs ज़रूरी हैं। और वह अपने-आप में programming ही है। इसी नज़रिए से मैं AI को “जादुई English compiler” के रूप में देखने के खिलाफ़ हूँ। अगर tool की strengths और limits समझकर उसे work assistant की तरह इस्तेमाल किया जाए, तो यह वाकई बहुत अच्छा workflow है

  • शानदार जवाब। पूरी तरह सहमत हूँ

  • ऐसी समस्याओं वाला लेख लिखना कोई हैरानी की बात नहीं। लेखक George Hotz, यानी Geohot है

• मैं Openpilot भी बहुत इस्तेमाल करता हूँ, और claude code भी। मैं दोनों tools को लगभग एक ही स्तर पर रखता हूँ। Openpilot highway जैसी साधारण परिस्थितियों में घंटों तक सचमुच बहुत अच्छी driving करता है। claude code intuitive refactors, boilerplate, scaffolding, git bisect जैसे repetitive काम मेरे input के बिना भी कर देता है। लेकिन दोनों ही आख़िरकार ‘driver’ को replace नहीं करते। claude code programming का level 2 autonomy जैसा है

• METR research को उसके title की वजह से बहुत लोकप्रियता मिली। शायद बहुत कम लोगों ने उसे सच में ध्यान से पढ़ा—क्योंकि वह काफ़ी लंबा था। लेकिन data में Cursor या AI इस्तेमाल का सबसे ज़्यादा अनुभव रखने वाले सिर्फ़ एक व्यक्ति में 50% speed increase देखा गया। इससे संकेत मिलता है कि familiarity के बाद ही performance साफ़ दिखती है। और छोटा sample होने की वजह से statistical variation भी बड़ा है। बाद में दूसरे एक व्यक्ति के speed difference को गलत record किया गया था, यह correction भी आया, लेकिन फिर भी नतीजों के मतलब पर सवाल बने रहते हैं। study में मापी गई inefficiencies ऐसी चीज़ें हैं जिन्हें बेहतर LLMs, parallel agents जैसी उन्नत तकनीकों से काफ़ी हद तक दूर किया जा सकता है। study के समय इस्तेमाल हुए tools पुराने Claude 3.7 दौर के थे, Claude Code से पहले के। और 20% कम काम करने जैसा ‘subjective feel’ भी अपने-आप में काफ़ी मूल्यवान है। जब काम मज़े से हो, तो समय जल्दी बीतता है

• दिक्कत यह है कि AI labs अब तक AI को बहुत बढ़ा-चढ़ाकर बेचती रही हैं। “AI सच में सोचता है, यह सिर्फ़ pattern matching नहीं है” जैसे नारे बहुत सुनने को मिलते हैं। मैं AI tools बनाता भी हूँ और इस्तेमाल भी करता हूँ, और मेरे अनुभव में इसे pattern matching आधारित ‘next-token predictor’ की तरह देखना कहीं ज़्यादा उपयोगी है। अगर आप context में बहुत ज़्यादा अनावश्यक जानकारी भर दें, तो AI अक्सर generalize नहीं कर पाता। यह आख़िरकार pattern matching, next-token prediction जैसा ही व्यवहार है। मैं मानता हूँ कि “AI technology आज के बहुत अच्छे tools में योगदान दे सकती है,” लेकिन यह बड़े पैमाने की search/optimization और मौजूदा patterns के reuse का परिणाम है। उदाहरण के लिए, अगर आप Claude code से एक simple CRUD API लिखने को कहें, तो वह 1 मिनट में दे देता है और मेरा 1 घंटा बचा देता है। अगर आप लाखों बार पहले से implement हुए किसी algorithm को माँगें, तो वह तुरंत सही code दे देता है। AI को अगर अपने domain expertise के भीतर इस्तेमाल करें, तो यह सचमुच बहुत अच्छा काम करता है। इसके बाहर नतीजे अच्छे नहीं होते

  • यह intelligence के स्तरों का फ़र्क है। यह ज्ञान का नहीं, बुनियादी reasoning क्षमता का अंतर है। हम किसी खास काम में लगने वाली cognitive effort को कम करके आँकते हैं। लेकिन कभी-कभी AI हमारी उम्मीद से ज़्यादा ‘thoughtful’ behavior भी दिखाता है। तब यह सचमुच जादू जैसा लगता है

  • CRUD या boilerplate जैसी चीज़ें कुछ हद तक tooling से भी हल हो सकती हैं। लेकिन कई काम ऐसे हैं जो व्यावहारिक रूप से सिर्फ़ AI से संभव लगते हैं। उदाहरण के लिए, जब मुझे trace-level logs के पूरे ढेर का test के साथ analysis करना होता है, तो सैकड़ों lines को खुद पढ़ना बहुत समय लेता है, लेकिन AI से “test run करो और root cause ढूँढो” कहने पर काफ़ी उपयोगी नतीजा मिल जाता है। आजकल यह अक्सर मेरा पहला step बन गया है

• मुझे लगता है आपकी बात में कुछ सच्चाई है। लेकिन business world में ‘व्यवस्था को फिर से जमाने की इच्छा’ बहुत प्रबल होती है। बहुत सारा पूँजीगत पैसा कम समय में ज़ोरदार returns चाहता है, और fund managers अगर trend न पकड़ें तो निकाल दिए जाते हैं। CIO और CEO के साथ भी यही है। AI अपनाने की दौड़ nuclear arms race की तरह अब रुकने वाली नहीं लगती। मूल रूप से यह किसी के लिए भी बहुत अच्छी चीज़ नहीं है। लेकिन जब बाकी सब इसमें कूद रहे हैं, तो मैं भी बाहर नहीं रह सकता। कारों के आने से पहले भी इंसान काफ़ी खुश थे। लेकिन कार आने के बाद शहरों का ढाँचा बदल गया, इमारतों के बीच दूरी बढ़ी, और commute सामान्य बात बन गया। AI भी उसी तरह हमारे काम करने के context को ही बदल देगा। अब यह उम्मीद बन रही है कि हर कोई AI इस्तेमाल करे, और एक समय के बाद यह ‘बेसिक requirement’ जैसा लगने लगता है। और आगे बढ़ें तो विज्ञान-तकनीक से बने बहुत कम products वास्तव में इंसानी “ज़रूरत” थे। technology अक्सर पहले समस्या पैदा करती है, फिर उसे समाधान के रूप में पैक करके बेचती है। समस्या पहले थी ही नहीं; solution आने के बाद वह समस्या बनती है। यही business को चलाने वाली मुख्य शक्ति है

• AI coding पर बहुत से opinion pieces बेहद अनुभवी software engineers, यानी कहें तो ‘ivory tower’ के नज़रिए से लिखे हुए लगते हैं। (उस research में भी “16 अनुभवी open source developers” ही थे) लेकिन non-experts के लिए ये tools अविश्वसनीय रूप से मूल्यवान हैं। मेरे पास भी थोड़ा coding अनुभव है, लेकिन यह मेरा मुख्य पेशा नहीं है (मैं visual artist हूँ)। पहले जिन कामों में कई दिन लगते थे, वे अब आधे दिन में हो जाते हैं। मैंने दो महीने पहले नौकरी छोड़ी और अब game development पर ध्यान दे रहा हूँ। बजट बहुत बड़ा नहीं है, लेकिन Claude और ChatGPT का subscription मैं हर हाल में रखूँगा। और रात 1 बजे बिस्तर पर पड़े-पड़े कोई idea लिखकर तुरंत Codex को दे देना, फिर सुबह उठकर उसे चलाकर देखना—यह सचमुच जादू जैसा है। पहले “क्या यह सच में सबसे अच्छा तरीका है?” जैसी चिंता से शुरुआत करने में हिचक होती थी, लेकिन अब refactor आसान है, इसलिए वह डर कम हो गया है। फ़ायदा सिर्फ़ code लिखने में नहीं, बल्कि मनोवैज्ञानिक बाधा कम करने में भी है। हाँ, मैं समझता हूँ कि ज़्यादातर आलोचना असल में इन tools की marketing exaggeration और “अब सारे engineers निकाल दिए जाएँगे” वाली चर्चा पर है

• मैं 72 साल का हूँ, और 40 साल developer के रूप में काम कर चुका हूँ। पहले जैसी गहरी एकाग्रता अब कठिन है, लेकिन AI की वजह से मैं अब भी चीज़ें बना रहा हूँ। मैं project की specs तय करता हूँ और agent implementation से लेकर testing तक संभाल लेता है। अब मैं सिर्फ़ आनंद के लिए coding करता हूँ

  • मुझे भी AI से prototypes तेज़ी से बनाना बहुत पसंद है। पहले मैं browser extension बनाना चाहता था, तो Claude की मदद से 10 मिनट में एक simple version बना लिया। उसके बाद मैंने खुद थोड़ा-थोड़ा UI सुधारा, और weekend की एक सुबह बिताकर उसे एक और हल्का, ज़्यादा predictable, ज़्यादा refined extension बना दिया। मेरा extension repetitive responses की list दिखाता है, और यह toggle करने देता है कि कौन-सा response localhost API को भेजना है। वहाँ से work queue processing होती है, sqlite db update होता है, LM Studio GPT-OSS 20b से मुख्य जानकारी analyze होती है, और आख़िर में Telegram पर summary भी भेजी जाती है। मेरे दिमाग में ideas काफ़ी साफ़ होते हैं, लेकिन experiment या PoC का समय मिनटों में सिमट जाना सचमुच बहुत उपयोगी है। मेरे जैसे काफ़ी सक्षम developer के लिए इसका मतलब यह है कि अब मैं अकेले पहले से कहीं ज़्यादा काम कर पाता हूँ