- लेखक के अनुसार सबसे बड़ा कारण यह है कि AI tools उन्हें तेज़ नहीं बनाते, इसलिए वे generative AI coding tools का उपयोग नहीं करते
- उनका मानना है कि AI द्वारा बनाए गए code को review और समझने में लगने वाला समय उसे खुद लिखने से ज़्यादा हो सकता है
- code quality और जिम्मेदारी अब भी developer की ही होती है, इसलिए बिना review के AI code का उपयोग करना जोखिमपूर्ण है
- AI को intern की तरह देखने वाले तर्क पर लेखक की आलोचना है कि AI सीख नहीं सकता, इसलिए वह याददाश्त खो चुके intern जैसा है
- open source contribution और AI code के अंतर को समझाते हुए लेखक कहते हैं कि इंसानों के साथ interaction नए ideas देता है, इसलिए उसका मूल्य है
परिचय
- बहुत से लोग मुझसे पूछते हैं कि क्या मैं generative AI coding tools का उपयोग करता हूँ, और उनके बारे में क्या सोचता हूँ
- इस लेख में मैं पक्ष या विपक्ष से हटकर सिर्फ अपना व्यक्तिगत तकनीकी अनुभव साझा कर रहा हूँ
- मैं तकनीकी दृष्टिकोण से उन कारणों को समझाता हूँ जिनकी वजह से AI मेरी coding में मददगार नहीं है
AI तेज़ नहीं है
- generative AI coding tools इस्तेमाल करने पर भी मेरे काम की गति तेज़ नहीं होती
- भले ही AI code लिख दे, code की जिम्मेदारी मेरी ही रहती है, इसलिए project में शामिल करने से पहले मुझे पूरे code का सावधानी से review करना और उसे पूरी तरह समझना पड़ता है
- code review में भी code लिखने जितना समय और ध्यान लग सकता है, और industry में यह कहावत भी है कि "code पढ़ना, code लिखने से कठिन है"
- AI द्वारा लिखे गए code पर "black box" की तरह भरोसा करना बहुत गैर-जिम्मेदाराना विकल्प है। अगर code में defect हो, तो कानूनी और आर्थिक जिम्मेदारी भी programmer पर ही आती है
- quality में गिरावट और risk में बढ़ोतरी के बिना AI से productivity या revenue बढ़ाना संभव नहीं है
AI leverage tool नहीं है
- कुछ लोग दावा करते हैं कि AI coding tools efficiency को कई गुना बढ़ा देते हैं, लेकिन लेखक के अनुसार यह सिर्फ व्यक्तिपरक धारणा है
- कुछ users AI-generated code को बिना review के या सिर्फ आंशिक review के साथ इस्तेमाल करके समय बचाते हैं, लेकिन मैं यह प्रक्रिया छोड़ नहीं सकता, इसलिए यह मेरे लिए उपयोगी नहीं है
- नई language या technology सीखने में AI का उपयोग efficient होने के दावे से भी मैं सहमत नहीं हूँ। नई चीज़ें सीखने की प्रक्रिया ही programming का आनंद है
- मैं वास्तव में Rust, Go, TypeScript जैसी कई languages खुद सीखता हूँ, और इस तरह के अनुभव को AI को सौंपता नहीं हूँ
- क्योंकि आखिरकार हर code की जिम्मेदारी मेरी ही होती है
AI code, human code से अलग है
- मुझे अक्सर यह सवाल मिलता है: "open source contribution भी तो ऐसा code है जो मैंने नहीं लिखा, फिर AI code को अलग तरह से क्यों देखते हो?"
- वास्तव में मैं open source PRs पर भी समय लगाकर बहुत ध्यान से review करता हूँ। लेकिन users के साथ collaboration नए ideas और motivation तक ले जाता है
- कुछ लोग कहते हैं कि कई AI agents चलाकर bug issues को solve करने वाले PRs पाना game changer है, लेकिन आखिरकार code review का bottleneck इंसान ही है, इसलिए यह उल्टा और धीमा हो जाता है
- AI tools के फैलने के साथ low-quality PRs अक्सर बनने लगे हैं। AI code में एक सूक्ष्म अजनबीयत होती है, और PR submit करने वाले से सवाल पूछो तो कई बार जवाब नहीं मिलता
- जिम्मेदार code contribution और open source community के साथ संवाद, human code की अहम विशेषताएँ हैं
AI और intern का अंतर
- AI की तुलना intern से की जाती है, लेकिन दोनों मूल रूप से अलग हैं
- intern का शुरुआती code भले ही बहुत review और समय माँगे, लेकिन वह feedback के जरिए तेज़ी से बढ़ता है
- intern की growth में किया गया निवेश अंततः उसे ऐसा महत्वपूर्ण teammate बना देता है जिसे स्वतंत्र रूप से काम सौंपा जा सके
- AI tools हर नए task पर ज्ञान भूलकर फिर से शुरू करते हैं, वे न तो विकसित हो सकते हैं और न ही अनुभव जमा कर सकते हैं
- यह ऐसे intern जैसा है जो कभी बेहतर ही नहीं होता, इसलिए productivity बढ़ाने में योगदान नहीं दे सकता
निष्कर्ष
- इस लेख के माध्यम से लेखक generative AI coding tools अपनाने पर आने वाली तकनीकी समस्याओं को स्पष्ट रूप से सामने रखना चाहते हैं
- AI coding में 'free lunch' जैसी कोई चीज़ नहीं है
- AI से तेज़ी या productivity बढ़ने के दावे या तो quality standards घटाकर अतिरिक्त risk स्वीकार करने से आते हैं, या फिर AI बेचने वालों के हित से
- programmers को यह याद रखना चाहिए कि वे हमेशा अंतिम जिम्मेदार व्यक्ति होते हैं
5 टिप्पणियां
मैं copilot (claud) + codex (o3/4o/codex-mini 3 मॉडल simultaneous mcp) के agent mode पर पूरी तरह settle हो चुका हूँ, लेकिन मेरा मानना है कि इसे इस्तेमाल करने वाले व्यक्ति और project की प्रकृति के अनुसार इसका असर बहुत अलग-अलग हो सकता है.
मैं 5-6 workspaces में एक साथ काम चला देता हूँ और जो पहले पूरा होता है उसे उसी क्रम में check करता हूँ; model open source code के अंदर तक देखकर verification कर सकता है, इसलिए मुझे यह काफी अच्छा लगता है. अगर lunch time पर काम डाल दूँ, तो एक-दो काम तब तक खत्म मिलते हैं. कभी-कभी यह रात भर भी चलता है, लेकिन copilot rate limit एक black box है...
High-performance kernel, पूरे call stack का simplification, readability सुनिश्चित करना जैसी ऐसी tasks, जिनमें इंसानों को context switching ज़्यादा होने की वजह से समय लगता है, उन्हें भी यह कर लेता है अगर prompt और goal ठीक से दिए जाएँ (क्योंकि यह इंसान से ज़्यादा code memory में रख सकता है). इसलिए ऐसे code में patch review करना आसान हो जाता है... और जिन लोगों ने API usage की गलतियों या open source project के अपने bugs की वजह से होने वाली failures झेली हैं, उनके लिए Agent से पक्का verification करवाना मानसिक सुकून के लिए भी अच्छा है...
लेकिन आखिरकार, इसे इस्तेमाल करने वाले developer को patch समझ में आना चाहिए. और उसे prompt देना भी आना चाहिए. अनुभव से जल्दी problem को formulate करके सामने रखना आना चाहिए, तभी वहाँ से शुरुआत हो सकती है. जैसे formulas के बिना high-performance kernel development संभव नहीं है. समस्या chip/OS level की है, application level की है, या remote resource की दिक्कत है—इसका अंदाज़ा लगाना अभी भी senior की भूमिका लगता है.
Copilot, ChatGPT जैसे टूल्स और Cursor आदि को कुछ हद तक इस्तेमाल करने के अपने अनुभव में, ये डेवलपमेंट टूल्स के template या snippet स्तर की भूमिका के लिए तो अच्छे हैं, लेकिन agent या coworker के स्तर के नहीं हैं।
मैं
cursorका उपयोग कर रहा हूँ.chat mode में agent की बजाय ask को पसंद करता हूँ, क्योंकि मैं चाहता हूँ कि समीक्षा के बाद ही यह मेरे code पर लागू हो, और कुल मिलाकर लेख में बताए गए ऐसे नुकसान से मैं सहमत हूँ.
फिर भी मैं generative AI का इस्तेमाल जारी रखूँगा, क्योंकि कई बार यह ऐसे ideas या code बना देता है जिनके बारे में मैंने सोचा भी नहीं होता, इसलिए संदर्भ के उद्देश्य से यह पर्याप्त रूप से मूल्यवान है.
मेरे व्यक्तिगत अनुभव में, generative coding tools के इस्तेमाल को लेकर मेरी राय भी लगभग ऐसी ही है.
Hacker News राय
कुछ लोग हर बार जब कोई नई भाषा या तकनीक सीखते हैं, तो उनके मन में सवाल उठते हैं; पहले वे Google search करते थे या Stack Overflow पर सवाल डालकर जवाब का इंतज़ार करते थे। अब वे सीधे ChatGPT या Gemini से पूछते हैं और बहुत तेज़ जवाब पाते हैं, जिससे उत्पादकता काफ़ी बढ़ जाती है। मैं इस बात पर ज़ोर देना चाहता हूँ कि सिर्फ़ सवालों के तेज़ जवाब मिल जाने से भी सीखने की प्रक्रिया तेज़ हो जाती है।
ChatGPT और Gemini सही जवाब इसलिए दे पाते हैं क्योंकि उन्होंने Stack Overflow सहित वेब पर पहले से मौजूद ज्ञान पर प्रशिक्षण लिया है। अगर सभी उपयोगकर्ता सिर्फ़ AI का ही इस्तेमाल करके सवाल पूछेंगे, तो भरोसेमंद सार्वजनिक ज्ञान स्रोत धीरे-धीरे खत्म हो सकते हैं। यह किसी हद तक उस विश्वकोश-युग की वापसी जैसा है, जब जानकारी इकट्ठा करना और बेचना बहुत महंगा काम था। साथ ही, लेखक की आलोचना उन AI coding tools से है जो सीधे code लिखते हैं; इसे सवालों के जवाब देने वाले tools से अलग करके समझाना चाहिए।
पहले एक बार मैं एक अनजान API इस्तेमाल कर रहा था और program crash हो गया था। मैंने stack trace को Gemini में डाला, तो तुरंत वजह का सुराग मिल गया और सिर्फ़ दो लाइन बदलकर समस्या हल हो गई। ऐसे अनुभव से ही AI की उपयोगिता साफ़ महसूस होती है। किसी अनजान क्षेत्र में बेवकूफ़ी भरी गलती के कारण लंबे समय तक फँसे रहने की ज़रूरत न पड़े, यही इसकी बड़ी ताकत है।
Search अब धीरे-धीरे blog spam को प्राथमिकता देने लगा है; ऐसे में बेहतर है कि अच्छी official docs या user guide से मूल बातें सीखी जाएँ। अच्छे API docs पढ़ते-पढ़ते पूरी design और अतिरिक्त features भी स्वाभाविक रूप से समझ में आने लगते हैं। Blog examples या tutorials से तत्काल समस्या भले हल हो जाए, लेकिन असली skill improvement में ज़्यादा मदद नहीं मिलती। वह बस होमवर्क किसी और से करवा लेने जैसा है, इसलिए मुझे नहीं लगता कि ChatGPT सच में self-learning को बढ़ावा देता है।
कठिन समस्याओं में AI के नतीजों को verify करना ज़रूरी है। मैंने AI autocomplete बंद कर रखा है क्योंकि व्यवहार में वह उतना efficient नहीं था और उलटे बेवजह की edits बढ़ जाती थीं। हैरानी की बात है कि पूरी तरह offline local models से भी काफ़ी उपयोगी संदर्भ मिल जाते हैं। Google में built-in Gemini का output भी खास अच्छा नहीं है। मेरी सबसे बड़ी चिंता यह है कि अगर लोग सिर्फ़ AI से जानकारी लेने लगें, तो Stack Overflow जैसे असली knowledge repositories गायब हो सकते हैं।
छोटे boilerplate tools के लिए AI एकदम सही है। Browser extension या Tampermonkey scripts जैसी साधारण चीज़ों में तो docs देखे बिना ही काम शुरू किया जा सकता है। बहुत जटिल न होने वाले code autocomplete या छोटे-मोटे बदलावों में भी AI काफ़ी उपयोगी है। ऐसे छोटे projects, जिन्हें मैं सामान्यतः शुरू भी नहीं करता, उन्हें जल्दी निपटाया जा सकता है।
खुद code लिखने का एक संभावित फ़ायदा यह है कि समस्या का एक मज़बूत mental model दिमाग में बनता है। बाद में समस्या-समाधान या नए feature integration के समय यह 'अचेतन' सीख बहुत असरदार होती है। असली skill तभी बढ़ती है जब अपने हाथ से करके देखने की यादें जमा होती हैं। जिन संगठनों को मैंने देखा, वहाँ LLM अपनाने के बाद भी productivity में कोई वास्तविक कई-गुना बढ़त नहीं दिखी। कहीं ऐसा तो नहीं कि हम सिर्फ़ दिमाग कम लगाने और आसान रास्ता चुनने को ही productivity समझ बैठे हैं?
मुझे लगता है कि यह बात बहुत अच्छी तरह से कही गई है कि लोग कम mental energy लगाकर समस्याएँ हल करने के आदी हो जाते हैं और उसी भ्रम को productivity समझ लेते हैं। Google Research ने 2024 में LLM productivity effect पर प्रयोग किया था; उसमें पाया गया कि किताब से सीखने वाले समूह की तुलना में LLM इस्तेमाल करने वाला समूह उलटे ज़्यादा समय ले रहा था, और केवल content novices के scores थोड़ा बेहतर हुए। लेकिन कई प्रतिभागियों ने खुद को अधिक तेज़ और अधिक सटीक समझा, और शोधकर्ताओं ने इसका कारण 'cognitive load reduction' बताया। संबंधित पेपर: https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
अगर कम mental energy लगाकर कोई ज़्यादा देर तक काम कर सकता है, तो क्या वह वास्तव में कुल मिलाकर ज़्यादा काम नहीं कर पाएगा? अभी भी high-difficulty काम में 3-4 घंटे की सीमा महसूस होती है। अगर marathon चलने की रफ़्तार से पूरी की जा सके, तो कुल output बढ़ सकता है — ऐसा भी एक नज़रिया है।
मैं इस बात से सहमत हूँ कि traditional coding और AI coding दो अलग skills हैं। मैं भी इस दावे को लेकर बहुत skeptical हूँ कि AI coding को replace कर देगा। लेकिन मेरा मानना है कि prompt management और context maintenance जैसी 'AI coding' के भीतर भी एक उल्लेखनीय learning curve है, और बहुत से लोग इसकी value को कम आँकते हैं। जैसे hand-drawn art और photography — दोनों के उद्देश्य ही अलग हो सकते हैं। मेरी पसंदीदा शैली यह है: 'मुश्किल काम AI करे, और मैं overall design और coordination संभालूँ।'
LLM-based coding सिर्फ़ साधारण autocomplete से आगे की चीज़ है; यह task definition-feedback-iteration के चक्र के साथ किसी काम को outsource करने जैसा अनुभव देता है। अंतर सिर्फ़ speed में है (जहाँ LLM बेहतर है) और reliability में (जहाँ इंसान बेहतर है), लेकिन लंबी अवधि में यह सीमा भी धुंधली हो सकती है। महत्वपूर्ण बात यह है कि मैं मूलतः वह व्यक्ति हूँ जो काम की बारीकियों को खुद संभालना चाहता है। मैंने यह पेशा इसलिए चुना क्योंकि मुझे infrastructure और programming सीखना और गहराई से समझना पसंद है। इसलिए मैं manager की भूमिका से बचता हूँ और कम कमाई हो तो भी खुद बनाना पसंद करता हूँ। शायद जब AGI सचमुच एक colleague की तरह हो जाए, तब मैं फिर दिलचस्पी लूँगा। संभव है कि भविष्य में 'AI' नाम भी इतना विशेष न लगे।
भले ही AI coding की learning curve उम्मीद से बड़ी हो, फिर भी यह piano जैसा नहीं है जिसमें कई साल लगाने पड़ें। आज के सबसे अनुभवी AI coders के पास भी मुश्किल से 3 साल का अनुभव है, और models लगातार बदल रहे हैं, इसलिए पुराना अनुभव अक्सर current-generation models पर ठीक से लागू नहीं होता। किसी master से सीखने वाली संरचना का न होना भी एक सीमा है।
क्या AI coding skill सच में long term में मूल्यवान है? मुझे संदेह है कि मौजूदा AI tools की skillset भविष्य की पीढ़ियों तक कितनी transfer होगी। अभी efficiency बढ़ भी जाए, तब भी model और tool बदलने पर वह बेकार हो सकती है — यह ध्यान में रखना चाहिए।
मेरा मानना है कि AI coding skill सीखने के लिए कुछ मिनट या ज़्यादा से ज़्यादा एक घंटा काफ़ी है। रूपक के तौर पर कहूँ तो यह GDB या UNIX जैसा क्षेत्र नहीं है जिसमें एक-एक किताब पढ़कर गहराई में जाया जाए। जैसे drawing और photography को उनके मूल सिद्धांत और लक्ष्य अलग होने के कारण भ्रमित नहीं किया जाता, वैसे ही AI coding भी पारंपरिक coding से पूरी तरह अलग गतिविधि है।
मैं इस आत्मविश्वास से सहमत नहीं हूँ कि जो लोग direct coding पसंद करते हैं, वे सिर्फ़ इसलिए ऐसा करते हैं क्योंकि उनकी AI coding skill कमज़ोर है। अभी तक छोटे भुगतान और free trials से जो ROI देखा है, उसी से काफ़ी निर्णय लिया जा सकता है।
व्यवहार में एक ऐसी संस्कृति भी बन रही है जहाँ AI code review या result verification करने के बजाय, AI द्वारा बनाया गया code सीधे PR में डाल दिया जाता है और review किसी दूसरे पर छोड़ दिया जाता है। ऐसी स्थिति में GenAI सच में उपयोगी कम और काम टालने का साधन ज़्यादा बन जाता है।
ऐसा अनुभव मुझे भी हुआ है। जब manager की क्षमता कम होती है, तो वह यह पहचान नहीं पाता कि वास्तव में value कौन बना रहा है। मैं coding agents से सचमुच बहुत value पाता हूँ, लेकिन जिन संगठनों में क्षमता की कमी है, वहाँ कमजोर output को reward करने वाली संरचना गंभीर समस्या है।
अगर submitter का PR बार-बार AI output को ज्यों का त्यों लाता रहे, तो feedback जमा करके team lead को ज़रूर मुद्दा उठाना चाहिए — यही सही रुख है।
Claude Code अक्सर इस्तेमाल करने वाले व्यक्ति के तौर पर, मैं 100% सहमत हूँ कि किसी और द्वारा लिखे code की review करने में, उसे खुद लिखने की तुलना में लगभग उतना ही समय लग सकता है। LLM उपयोगी तो है, लेकिन जैसे-जैसे आप control छोड़ते जाते हैं, असली release तक पहुँचने में उलटे ज़्यादा समय लग सकता है। RSI symptoms कम करने में मदद मिली, लेकिन time-saving effect कई बार सोची गई तुलना में बढ़ा-चढ़ाकर बताया जाता है।
जब पूछा गया कि क्या code को ज़रूर review करना चाहिए, तो आमतौर पर मैं AI output की सिर्फ़ spot review करता हूँ, spec document AI से लिखवाता हूँ, और फिर final review तथा testing मैं खुद बहुत ध्यान से करता हूँ। सच तो यह है कि ज़्यादातर open source library code को भी हम शुरुआत से line-by-line review नहीं करते।
इसमें एक छिपा हुआ मान लेना है: 'जो code मैंने खुद लिखा है, उसे किसी अलग नज़र से review करने की ज़रूरत नहीं।' जबकि वास्तव में भविष्य का मैं भी उस code का एक संभावित पाठक हूँ। AI coding इस mindset को मजबूर करती है — यानी साफ़ acceptance criteria तय करना और tests व consistent rules के ज़रिए verify करना। नतीजतन यह और अधिक robust तथा recordable development culture को बढ़ावा देती है।
Claude Code के साथ bug debugging में, अगर पहले test लिख दिए जाएँ, तो AI का कुछ मिनट में fix कर देना अब सामान्य बात है। नई search feature आने के बाद जटिल काम भी 5 मिनट में निपट सकते हैं; इस हिस्से में समय की बचत मुझे बहुत स्पष्ट महसूस होती है।
RSI symptoms के समाधान के रूप में हाथों को हमेशा गरम रखने की सलाह भी दी गई।
यह जिज्ञासा भी उठी कि 'मैं हर चीज़ को conversational interface से नहीं करना चाहता; क्या hybrid UI अपनाने के उदाहरण हैं?'
Generative AI coding tools काम के आसान हिस्सों को ही तेज़ करते हैं, और कठिन हिस्सों को उलटे और कठिन बना देते हैं। वास्तव में coding पर लगने वाला समय इतना बड़ा हिस्सा नहीं होता कि सिर्फ़ उसी को 100 गुना तेज़ कर देने से कुल productivity बहुत बदल जाए। इसलिए मैं उस पर ज़्यादा समय देना नहीं चाहता।
अगर कोई engineer पहले से किसी खास stack और problem domain को पूरी तरह समझता है, तो उसे शायद किसी tool की ज़रूरत ही न हो, और न ही किसी learning की। लेकिन व्यवहार में यह तर्क बहुत उपयोगी नहीं है। अंततः tool selection एक व्यक्तिगत optimization है।
मैं AI से algorithm लिखवाता हूँ, code के कारण समझवाता हूँ, API calls करवाता हूँ, और कुछ specific functions implement करवाता हूँ। पूरा codebase नहीं सही, पर debugger के साथ इसका उपयोग धीरे-धीरे बढ़ता जा रहा है।
'क्या आप plumber हैं?' जैसा हल्का-फुल्का मज़ाक भी किया गया।
लेखक की यह बात कि 'खुद code लिखने जितना ही समय, या उससे भी ज़्यादा, किसी और का लिखा code review करने में लग सकता है' — इससे मैं, जिसने security audit जैसे बारीक code review का अनुभव किया है, भी सहमत हूँ। लेकिन अगर AI बहुत साधारण routine कामों में विशेषज्ञ हो जाए, तो शायद code को विस्तार से देखे बिना, eBPF verifier जैसी व्यापक verification ही काफ़ी हो। अगर issue बहुत complex हो, तो PR को सीधे reject किया जा सकता है। साधारण दोहराव वाले code में इंसानों को उतनी बारीकी से जाँचने की ज़रूरत भी कम हो सकती है।
फिर भी, क्या यह सच में efficient तरीका है — इस पर संदेह है। अगर दर्जनों PR खोलकर सिर्फ़ एक पास कराना है, तो बेहतर है कि किसी teammate का code ही लिया जाए। समय, पैसे और environmental resources की बर्बादी करने वाली संरचना वांछनीय नहीं लगती।
अगर सचमुच सिर्फ़ 'repetitive Go function' ही लिखनी है, तो सवाल यह भी है कि क्या वह code लिखना ही ज़रूरी था। inefficient, कम reusable code — जिसे किसी आम library की एक-दो lines से पूरा किया जा सकता हो — उसे AI से बनवाने का मुझे खास कारण नहीं दिखता।
जिन लोगों की code पढ़ने की speed, लिखने की speed से ज़्यादा है, उनके लिए GenAI उपयोगी हो सकता है; और जिनके लिए लिखना ही तेज़ है, उन्हें इसकी उतनी ज़रूरत नहीं।
यह सवाल भी उठा कि AI द्वारा लिखे गए code को इंसान द्वारा लिखे code से अलग तरीके से verify क्यों किया जाना चाहिए।
दोहराव वाले और साधारण tasks को IDE template bindings और variable autocomplete से भी अच्छी तरह संभाला जा सकता है, और यह तरीका मुफ़्त भी है — इस बात पर ज़ोर दिया गया।
Intern और AI coding assistants की तुलना पर चर्चा में कहा गया कि intern असली code, business और system history सीखता है, जबकि AI को बार-बार context समझाना पड़ता है। यह सीमा अभी भी बनी हुई है।
एक नज़रिया यह है कि महत्वपूर्ण context को mdc files में सहेज दिया जाए, ताकि अगला contributor भी उसका संदर्भ ले सके; इससे documentation और knowledge continuity उलटे बेहतर हो सकती है।
कुछ LLMs में system prompt के 14k तक लंबे हो जाने की यही वजह बनती है।
Intern सचमुच CARE करता है — ऐसा भी कहा गया।
महत्वपूर्ण business context को सीधे system prompt में डालने का तरीका भी संभव है।
मौजूदा AI models मूलतः पहले से मौजूद data patterns को ही सीखते हैं। वे सफल उदाहरणों के templates को जोड़ते हैं; वे जड़ों से बिल्कुल नया समाधान निकालने की संरचना नहीं रखते। किसी समस्या को देखकर वे सबसे मिलते-जुलते पुराने अनुभव से जवाब खोजने की कोशिश करते हैं, न कि first-principles के आधार पर शुरुआत से सिद्धांतगत approach अपनाते हैं। Human experts first-principles — यानी मूल सिद्धांतों से तार्किक ढंग से सोचना, जिसमें AI को कठिनाई होती है — में निपुण होते हैं। AI similarity को प्राथमिकता देती है और इसलिए अक्सर घिसे-पिटे समाधान देती है; खासकर जहाँ innovation चाहिए या जहाँ प्रचलित परंपराएँ काम नहीं करतीं, वहाँ इसकी सीमाएँ साफ़ दिखती हैं। Context poisoning से निपटने में भी इंसान कहीं अधिक efficient है।
मैं AI-generated code को लेकर बहुत उत्साहित नहीं हूँ, लेकिन repetitive और boring boilerplate कामों में AI N गुना तेज़ है — और यह अंतर अनुभव में बहुत बड़ा लगता है। एक वास्तविक उदाहरण लें: मैंने ChatGPT से React Context आधारित modal structure का उदाहरण माँगा, तो उसने hooks, provider आदि के साथ पूरा ढाँचा तुरंत निकाल दिया। इससे लगभग 30 मिनट की बचत हुई। ऐसे repetitive कामों के लिए महीने के 20 डॉलर बिल्कुल बेकार नहीं लगते।
ऐसे मामलों में कई बार library docs के examples उठाकर भी इस्तेमाल किया जा सकता है, और 5 मिनट में खुद सबसे ज़रूरी basic implementation पूरा किया जा सकता है। लेकिन generated code अक्सर मौजूदा स्थिति के हिसाब से एक complete solution दे देता है, इसलिए बाद में gradual structural improvement या refactoring में उलटे असुविधा हो सकती है।
मैं भी मुख्यतः boilerplate या ad-hoc scripts के लिए AI का उपयोग करता हूँ। जटिल वास्तविक समस्याएँ अभी AI को पूरी तरह सौंपना मुश्किल है। खासकर जिन समस्याओं में system के भीतर गहराई तक जाना पड़े, वहाँ इंसान को खुद करना पड़ता है, और उस प्रक्रिया में मिलने वाली insight महत्वपूर्ण होती है। मुझे लगता है कि project जितना बड़ा होता है और जितने अधिक integrated elements होते हैं, AI की सीमाएँ उतनी अधिक स्पष्ट हो जाती हैं।