अभी क्या हो रहा है?

• सॉफ्टवेयर इंडस्ट्री में engineer burnout गहराता जा रहा है, और खासकर junior engineers द्वारा AI tools के दुरुपयोग से code quality और collaboration में समस्याएँ पैदा हो रही हैं
• senior engineers का feedback सीखने का मौका बनने के बजाय AI को देने वाले नए prompt के रूप में इस्तेमाल हो रहा है, और "AI द्वारा लिखा गया code" पूरी टीम की review क्षमता खा रहा है
• कुछ organizations में AI द्वारा बनाए गए अधूरे code को ‘achievement’ की तरह पैक करके पेश किया जाता है, जिससे AI पर निर्भरता को बढ़ावा देने वाला माहौल बन रहा है
• लेखक ने अपने सीधे अनुभव में AI code जवाब मिलने पर असहजता और अटपटापन महसूस किया, और आलोचना की कि AI उल्टा learning और mentoring culture को नुकसान पहुँचा रहा है
• AI startup ecosystem भी आखिरकार आर्थिक अलाभकारीपन, बिजली की खपत, पर्यावरणीय समस्याओं की वजह से टिकाऊ नहीं है, और मौजूदा स्थिति को वह “राजा नंगा है” जैसी धोखाधड़ी से अलग नहीं मानता

---

प्रस्तावना: अस्थिर engineering माहौल

• हाल के समय में engineers के बीच burnout की स्थिति और गंभीर हो रही है
• organizations में senior engineers से ऐसी "vibe(मीम)-based features" की समीक्षा और योगदान की उम्मीद की जाती है जो व्यावहारिक रूप से काम ही नहीं करतीं
• मेरे अनुभव में सबसे अच्छे engineers हमेशा नए team members की growth में उत्साह से मदद करना चाहते हैं

• लेकिन इनका feedback विकास के अवसर के रूप में इस्तेमाल होने के बजाय, शुरुआती developers इसे सिर्फ generative AI को भेजे जाने वाले अगले prompt में बदल देते हैं
• मैंने खुद कई junior engineers को LLM(large language model) tools का (दुरुपयोग की हद तक) इस्तेमाल करते देखा है

संगठन के भीतर के वास्तविक उदाहरण: AI दुरुपयोग का नुकसान

• हाल ही में कंपनी के town hall में मैंने junior engineers को अपना नया काम demo करते देखा
• वे feature के उद्देश्य या उसके काम करने के तरीके को भी ठीक से नहीं समझ पा रहे थे
• लेकिन बड़े organizations में असली नतीजों से अलग “success” दिखाने पर ज़्यादा ध्यान दिया जाता है
• जब एक senior manager ने इनके AI इस्तेमाल का उदाहरण साझा किया, तो उसने गर्व से कहा, “यह Claude द्वारा लिखा गया 4,000 lines का code है,” और उसे तालियाँ मिलीं

• मुझे भी एक मौजूदा feature में छोटा सा सुधार करने का अनुरोध मिला, और code review करते समय मैंने हाल का बदलाव करने वाले junior engineer से context माँगा
• मैंने Github commit URL भेजकर सवाल पूछा, लेकिन संभवतः उसने वही सामग्री LLM में डालकर वापस आए जवाब को copy करके भेज दिया
• इस प्रक्रिया में मुझे एक अजीब-सी दूरी और असहजता महसूस हुई

AI slope और code review की सीमाएँ

• एक दोस्त के अनुभव से पता चला कि एक महीने तक कई engineers LLM द्वारा auto-generated code (vibe-coded PR) को review और merge करने में अपना समय बर्बाद कर रहे थे
• एक अन्य दोस्त ने AI द्वारा बनाए गए “ढीले-ढाले code” को बार-बार review करते-करते थक जाने की बात कही
• AI की वजह से न तो code quality में सुधार हो रहा है, न learning हो रही है; बस दोहराव वाला काम बढ़ रहा है

development culture और मानवीय विकास का असली मूल्य

• हर engineer अपने साथियों और mentors की मदद से एक-एक कदम आगे बढ़ता है
• सीधे सिखाना और लोगों को grow करना ही software engineering culture का सार है
• लेकिन इस तरह का निवेश भी जब तुरंत “latest model” के training data में copy हो जाता है, तो उससे मोहभंग होना स्वाभाविक है
• तब यह बुनियादी सवाल उठता है कि क्या junior engineers के बजाय सिर्फ models को train करना ही बेहतर माना जाएगा

• ऐसा संसार एक बेहद अंधकारमय vision है

AI का इस्तेमाल न करने का प्रयोग और निष्कर्ष

• लेखक सीधे तौर पर यह प्रयोग सुझाता है: “AI का इस्तेमाल बंद करके देखिए”
• उसने खुद हाल में अपना computer reset करते समय Claude Pro subscription भी बंद कर दिया
• कुछ searches, Stack Overflow और official docs पढ़ने की प्रक्रिया ने उल्टा कहीं अधिक भरोसेमंद निष्कर्ष तक पहुँचने में मदद की
• उसे लगा कि LLM के नतीजों की तुलना में उसकी अपनी समझ accuracy और reliability दोनों में बेहतर है

generative AI tools का आर्थिक मूल्य, और उनकी मूलभूत सीमाएँ

• लेखक सवाल उठाता है: “क्या AI सच में उपयोगी है?”
• वस्तुनिष्ठ रूप से देखें तो उसके मूल्य पर गंभीर सवाल खड़े होते हैं
• AI startups का सामान्य क्रम कुछ ऐसा है:
  • “AI” को किसी मौजूदा क्षेत्र में लागू किया जाता है, और efficiency के नाम पर नए startups उभरते हैं
  • AI startup venture capital से funding जुटाने में सफल हो जाता है
  • AI service providers (OpenAI आदि) को usage fees चुकाई जाती हैं
  • AI startup खुद मुनाफा नहीं कमा पाता
• सिर्फ इस प्रक्रिया को देखें तो यह पारंपरिक VC ecosystem से बहुत अलग नहीं लगता, लेकिन असली फर्क यह है कि service providers (OpenAI आदि) भी अब तक मुनाफा नहीं कमा पाए हैं
• यह technology खुद मूल रूप से अल्पदक्ष है और बड़े पैमाने पर विस्तार के लिए अनुकूल नहीं है
• अत्यधिक बिजली की खपत और पर्यावरणीय दुष्प्रभाव भी गंभीर समस्याएँ हैं

समापन: वास्तविकता को पहचानने की ज़रूरत

• कोई चाहे तो उम्मीद कर सकता है कि Moore's law फिर से जीवित हो जाए, या ब्रह्मांड के ठंडा पड़ने से पहले सब अमीर बन जाएँ
• लेकिन वास्तविकता का सामना करने पर generative AI business एक तरह का मृगतृष्णा है और “राजा नंगा है” जैसी स्थिति को दिखाता है

[ahwjdekf]

तकनीक की सबसे अग्रिम सीमा, यानी परमाणु बम, के बारे में यह चिंता थी कि विश्वयुद्ध के बाद मानवता फिर आदिम युग में लौट जाएगी; आज software development के क्षेत्र में यह बात अभी वास्तविक समय में होती हुई दिख रही है।

[dicebattle]

लगता है बस हद से ज़्यादा vibe coding को रोकना होगा। असिस्टेंट के साथ काम करते हुए और कुछ बारीक लेकिन सरल algorithm लिखने में, इससे बेहतर कुछ और मिलना मुश्किल लगता है।

[GN⁺]

Hacker News राय

• संगठन में AI को अपनाना सिर्फ़ तकनीकी समस्या नहीं, बल्कि change management की समस्या भी है—यह बात रेखांकित की गई। भरोसे और transparency पर आधारित एक सक्षम टीम को ऐसा process बनाना होगा जो मानवीय expertise और LLM की ताकतों को संतुलित ढंग से जोड़े, तभी असली असर दिखेगा। छोटे टीमें भी AI की मदद से बड़े नतीजे ला रही हैं। लेकिन अधिकांश संगठन, खासकर बड़े enterprise, healthy organizational culture के बिना AI को अपनाते हैं, जिससे AI उल्टा इसी विषाक्तता को और बढ़ा देता है। कुछ corporate executives तो "Story Point" को सिर्फ़ time unit समझते हैं और AI को हर चीज़ को आधा कर देने वाले tool की तरह देखते हैं। मूल रूप से वे maintainable software बनाने की प्रक्रिया से कटे हुए हैं और AI को बस जल्दी-जल्दी मुनाफ़ा बढ़ाने के रास्ते की तरह समझते हैं। हाल की एक research में यह भी सामने आया कि AI pilot projects में से 95% ROI हासिल नहीं कर पाए, और इसे आधुनिक management की अक्षमता के उदाहरण के रूप में देखा गया

  • यह भी कहा गया कि शायद AI को बस बढ़ा-चढ़ाकर आंका गया है। "छोटी टीमों के बड़े नतीजे" वाले दावे में किन ठोस टीमों की बात हो रही है, इस पर जिज्ञासा जताई गई
  • इस बात पर थकान जताई गई कि AI की समस्याओं को सिर्फ़ "पहले से मौजूद समस्याएँ" कहकर माफ़ कर दिया जाता है। मानसिक स्वास्थ्य पर असर हो या organizational culture की गड़बड़ी, इसमें tool की भी ज़िम्मेदारी मानी गई। यह माना गया कि tools और systems भी असर डालते हैं, वे निरपेक्ष नहीं होते
  • "छोटी टीम बड़े काम कर रही है" जैसे दावों पर ठोस उदाहरणों के बजाय सिर्फ़ success stories सुनने को लेकर निराशा जताई गई
  • यह राय दी गई कि जहाँ management structure पहले से ही बुरी तरह बिगड़ा हुआ है, वहाँ AI लागू करना ऐसा है जैसे Vikings के झुंड को automatic rifles दे देना। इससे बस संगठन के टूटने की रफ़्तार तेज़ होगी। असली कारण technology से ज़्यादा, कई सदस्यों या कुछ प्रमुख managers की सामाजिक और नैतिक विफलता है—इस पर ज़ोर दिया गया
  • यह भी कहा गया कि "Story Point" को समय समझने वाले executives बहुत हैं, और development, QA, PM, executive—हर role में यह गलती देखी गई है

• "Prompstitudes(सिर्फ़ prompt पर निर्भर office workers)" के उभरने पर चर्चा हुई। एक बार एक सहकर्मी ने मेरी राय समझने की कोशिश किए बिना सिर्फ़ ChatGPT का जवाब आगे बढ़ा दिया था, और उससे वैसा ही "अतिक्रमण हुआ" जैसा लेख में कहा गया था। इन्हें अयोग्य से ज़्यादा LLM पर अत्यधिक निर्भर माना गया—जैसे casino में slot machine लगातार चलाने वाले बुज़ुर्ग

• हाल की एक बातचीत में यह बहुत साफ़ महसूस हुआ कि जवाब सीधे ChatGPT से आया था, और उसी वजह से अजीब-सी खीझ हुई। वक्ता ने कहा कि अनदेखा किया जाना शायद इससे बेहतर होता। खासकर समस्या यह थी कि LLM पूरी confidence के साथ ग़लत बातें ज़ोर देकर कहता है। छोटी-छोटी चीज़ें भी, जैसे configuration और implementation में नाम का थोड़ा फ़र्क, LLM को पूरी तरह भटका सकती हैं। इंसानों के विपरीत, LLM अपनी गलतियों से सीखता या उन्हें समझता नहीं, इसलिए लगातार ग़लत दिशा में बहता जाता है। वक्ता को तो ख़राब human code से जूझना भी मानसिक रूप से इससे बेहतर लगता है

  • एक PM के साथ काम करने का अनुभव साझा किया गया जिसने AI से PRD लिखा था। जब उससे content के बारे में पूछा गया, तो उसका जवाब था, "मुझे नहीं पता, AI ने लिखा है।" नतीजा यह हुआ कि PM ने असल idea communicate करना छोड़ दिया और सिर्फ़ document-writing performance भर रह गया। requirements को समझना और interpret करना पूरी तरह वक्ता के सिर आ गया, इसलिए उसने टीम छोड़ दी
  • "LLM पूरी confidence के साथ ग़लत होता है"—इस बात से सहमति जताई गई। कहा गया कि जैसे कुछ charismatic सहकर्मी जानकार बनने का दिखावा करते हैं, वैसे ही LLM भी कई बार काफ़ी भरोसेमंद अंदाज़ में ग़लत बात कह देता है
  • इस हफ्ते का एक बहुत विचित्र अनुभव भी साझा किया गया। एक ऐसी specialist spec, जिसे वक्ता खुद भी पूरी तरह नहीं जानता था, Claude से internal proposal review करवाया गया और उसने कई errors निकाले। यह बात कंपनी के उस spec owner को यह कहकर भेजी गई कि "यह LLM का सुझाव है, बकवास भी हो सकता है"। लेकिन उस व्यक्ति ने भी वही संदेश अपने LLM में डालकर जवाब लिया और वापस भेज दिया। नतीजतन ऐसा लगा कि सब लोग AI के assistant बनकर रह गए हैं। अगर software development का भविष्य यही है, तो यह उत्साहजनक नहीं लगता
  • यह भी कहा गया कि ख़राब human code, ख़राब LLM code से कहीं बेहतर है। मानव-लिखित code में कम से कम यह अंदाज़ा लगाया जा सकता है कि लेखक क्या करना चाहता था। लेकिन LLM-generated code शुरुआत से अंत तक टूटा हुआ हो सकता है, और कई बार ऐसी functions या concepts भी गढ़ देता है जो अस्तित्व में ही नहीं हैं। इंसान आम तौर पर इतना reality से कटा हुआ code नहीं लिखते। LLM code समझने के लिए कभी-कभी पूरा codebase फिर से सीखना पड़ता है
  • "LLM को लगता है कि वह गलती नहीं करता"—इस अभिव्यक्ति पर यह आपत्ति आई कि LLM न तो सच में मानता है, न सोचता है, न महसूस करता है। वह सिर्फ़ सांख्यिकीय रूप से सबसे उपयुक्त language tokens जोड़ता है और थोड़ी randomness के साथ creativity की नकल भर करता है

• "क्या AI tools वाकई उपयोगी हैं?" इस सवाल पर एक व्यक्ति ने कहा कि वह इन्हें दूसरों से अलग तरह से इस्तेमाल करता है, इसलिए उसे फ़ायदा होता है। वह 1983 से development कर रहा है, अब retired है और ज़्यादातर अकेले काम करता है। उसने कई tools आज़माए, लेकिन अब सिर्फ़ ChatGPT और Perplexity का इस्तेमाल करता है। वह AI से सीधे code नहीं लिखवाता, बल्कि LLM द्वारा सुझाए गए code को reference या starting point की तरह इस्तेमाल करता है। कभी-कभी उसे ज्यों का त्यों भी ले लेता है, लेकिन अधिकतर मामलों में edit और rewrite करता है। जब LLM लगातार ख़राब output देने लगे, तो वह उसे छोड़कर नया approach अपनाता है। इस संदर्भ में वह सोचकर घबरा जाता है कि कोई junior engineer सिर्फ़ LLM code कॉपी करके आगे बढ़े। उसके लिए सबसे बड़ी value यह है कि यह "तुरंत जवाब देने वाला StackOverflow" जैसा है। कोई भी बेवकूफ़ी भरा सवाल बिना झिझक पूछ सकते हैं और जल्दी ठीक-ठाक जवाब मिल जाता है। हाल में iOS पर PassKey implementation सीखते समय उसने ChatGPT के example code को starting point बनाया और हर line समझते हुए सीखा। शुरुआत का code और अंतिम तैयार code पूरी तरह अलग थे, और इस प्रक्रिया से उसकी तकनीकी समझ गहरी हुई

  • एक और व्यक्ति ने कहा कि वह भी AI को ठीक इसी तरह इस्तेमाल करता है। वह अपने एक personal project को लगभग पूरा करने के करीब है, जो उसने शुरुआत में कुछ भी जाने बिना शुरू किया था, और अब codebase को अच्छी तरह समझता है
  • इसी तरह छोटे कामों और personal projects में LLM के उपयोग का एक और अनुभव साझा किया गया। LLM पहले एक "फेंक देने लायक code" लिख देता है, और उसकी सीमाओं को परखते-परखते समस्या-क्षेत्र को बेहतर समझा जा सकता है। अंततः इससे व्यक्ति अधिक confidence के साथ खुद implementation कर पाता है

• यह राय दी गई कि LLM technical सवालों के जवाब देने और नए approaches सुझाने में बहुत अच्छा है। beginners भी StackOverflow की तरह judge हुए बिना या अटककर नहीं, खुलकर सवाल पूछ सकते हैं। Copilot का autocomplete अच्छा है, जिससे code लिखने की गति बढ़ती है और documentation comments या code lines अपने-आप पूरी हो जाती हैं। ऐसे छोटे-छोटे सहारे आसानी से review किए जा सकते हैं। लेकिन अगर LLM को पूरा complex code सौंप दिया जाए, तो chaos पैदा होता है और अक्सर debugging में ज़्यादा समय जाता है। यह भी माना गया कि beginners अगर LLM पर ज़्यादा निर्भर हो जाएँ, तो मज़बूत development skills बनाना मुश्किल हो जाएगा

• एक व्यक्ति ने कहा कि वह hobby development में Zed इसलिए इस्तेमाल करता है क्योंकि AI वहाँ ज़रूरत से ज़्यादा चालाक बनने की कोशिश नहीं करता। जब ज़रूरत हो तभी AI features को सहज रूप से बुलाया जा सकता है, और बाकी समय वह सामान्य रूप से coding करता है। काम की जगह पर VSCode AI बहुत अधिक बाधा डालता है। समस्या दो तरह की है: पहली, interaction बहुत आसानी से टूट जाता है—popup पर क्लिक, या ग़लती से बहुत बड़ा autocomplete insert हो जाना; दूसरी, flow टूट जाता है। AI autocomplete कभी-कभी उपयोगी होता है, लगभग एक-तिहाई बार, लेकिन बाकी समय यह सोच की मूल धारा तोड़ देता है और AI output को जाँचते-जाँचते ध्यान बिखर जाता है। Zed में यह समस्या नहीं लगी, इसलिए वक्ता को लगा कि उसने programming का आनंद फिर से पा लिया है। निष्कर्ष यह रहा कि असली समस्या AI feature से कम, उसके implementation तरीके से ज़्यादा पैदा होती है

  • एक अन्य व्यक्ति ने Zed के बारे में गहरी सहमति जताई। वह JupyterLab और Kate में काम करता था, लेकिन Zed इस्तेमाल करने के बाद उसका नज़रिया बदल गया। Zed में IDE/editor केंद्र में रहता है, जबकि AI या Jupyter kernel जैसी अतिरिक्त सुविधाएँ ज़रूरत पड़ने पर ही चुपचाप मदद करती हैं। ये additions असली text editing या coding में बाधा नहीं डालते। उसके अनुसार Zed team ने अच्छा balance पाया है

• AI को UX prototype बनाने में बहुत उपयोगी बताया गया। कम समय में तुरंत clickable result तैयार हो जाता है, जिससे कई बार iteration करके सिर्फ़ दिशा तय की जा सकती है, और बाद में उस code को फेंककर नया development किया जाता है। यह तरीका शुरुआत में ही ग़लत दिशा में बहुत समय बर्बाद होने से बचाता है। हालांकि, अभी AI से पूरे के पूरे meaningful apps बनवा लेना अभी भी दूर की बात लगती है

  • यह भी कहा गया कि जिन क्षेत्रों में व्यक्ति सामान्यतः कम काम करता है, जैसे PowerShell scripts, वहाँ AI बहुत मददगार है। उदाहरण के तौर पर, registry settings report के लिए एक script चाहिए थी और Claude ने उसे पूरी तरह सही लिख दिया, जिससे एक घंटा बच गया
  • एक और व्यक्ति ने कहा कि AI errors समझाने में बहुत अच्छा है। यह सही solution ढूँढने या नए ideas तक पहुँचने में काफ़ी मदद करता है
  • "prototype को फेंककर दोबारा development करना"—इस बात को महत्वपूर्ण बताते हुए यह भी कहा गया कि वास्तविक दुनिया में PM अक्सर यह हिस्सा भूल जाते हैं, और prototype ही production में चला जाता है। फिर भी, अगर किसी के पास AI को इस्तेमाल करने का अच्छा तरीका है, तो यह अच्छी बात है
  • इस use case, process और tools के बारे में और विस्तार से सुनने की इच्छा जताई गई, क्योंकि यह व्यक्ति और उसकी team के लिए व्यावहारिक रूप से उपयोगी हो सकता है

• AI को अपने लिए सिर्फ़ एक tool मानने वाले एक व्यक्ति ने कहा कि वह high-level developer नहीं है, लेकिन personal project में जहाँ अटकता है, वहाँ AI से ideas और feedback लेता है। महत्वपूर्ण बात यह है कि वह code writing AI को नहीं सौंपता, सिवाय बहुत simple boilerplate के। उसके लिए खुद code लिखना problem-solving, creation और learning से मिलने वाली खुशी का हिस्सा है

  • इसके जवाब में एक व्यक्ति ने कहा कि उसका हाल का project AI के बिना पूरा ही नहीं हो पाता। repository setup से लेकर PoC तक, भले ही सब कुछ शुरुआत में कच्चा था, AI ने उसे संभव बनाया। Django, JS और web development का अनुभव न होने के बावजूद AI की मदद से पहले working result मिला, फिर धीरे-धीरे उसे सुधारते हुए समझ भी बढ़ती गई

• हाल की एक code review के दौरान एक जटिल function देखा गया जो prepareData नाम के multidimensional array को मिलाता और filter करता था। जब reviewer ने सहकर्मी से पूछा, "यह क्या करता है?" तो उसने कहा कि समय बचाने के लिए LLM से पूछ लो। इस बुनियादी सवाल का भी जवाब न देने वाले रवैये पर निराशा जताई गई

  • इस पर हल्के मज़ाक में कहा गया कि LLM से जवाब लेकर वही सहकर्मी को भेज दो, और 20 बार feedback का आदान-प्रदान होने पर जब वह समझ न पाए, तो उससे भी कह दो कि वह LLM से पूछ ले

• यह चिंता जताई गई कि 10 साल बाद नए developers सीधे senior बनना चाहेंगे, बिना कभी खुद code लिखने का अनुभव लिए

  • जवाब में कहा गया कि यह समस्या AI से पहले ही शुरू हो चुकी थी। 10+ साल का अनुभव न हो तो नौकरी मिलना मुश्किल था, और industry ने युवा पीढ़ी की upskilling में असफलता दिखाई। कंपनियाँ जब भी नए लोगों को व्यवस्थित रूप से प्रशिक्षित करने की कोशिश करतीं, किसी crisis के आते ही सबसे पहले juniors की layoffs होतीं, और फिर जल्दबाज़ी में seniors की hiring—यह चक्र बार-बार दोहराया गया
  • इस पर मज़ाक में कहा गया कि अब senior तो 3 साल के अनुभव में ही बन जाता है, और 10 साल नहीं, 3 साल में staff developer बनने का माहौल बनता जा रहा है
  • यह भी कहा गया कि "Vibe coding" जैसा concept 9 महीने पहले ही उभरा है, और शायद अगले 2 साल के भीतर लोग खुद code लिखना या maintain करना लगभग छोड़ देंगे
  • फिर भी, domain expertise रखने वाले developers द्वारा लिखा गया software हमेशा रहेगा, और जब तक LLM code perfect नहीं हो जाता, high-quality code की demand बनी रहेगी
  • अंत में यह राय भी आई कि junior developers बहुत ज़्यादा हैं, जबकि ऐसा meaningful काम कम है जिससे उन्हें वास्तविक अनुभव मिले। पहले कम लागत वाले PoC या scripting tasks उन्हें दिए जा सकते थे, लेकिन अब AI वह भूमिका किसी हद तक निभा रहा है, जिससे मौके घट रहे हैं। साथ ही यह भी जोड़ा गया कि तब भी juniors बहुत थे और positions कम थीं

[happyiminjay]

शुरुआती development phase में environment setup और छोटे function unit के module development में AI बहुत प्रभावी है, लेकिन इसके अलावा code और prompt ठूंसकर की जाने वाली vibe coding maintainability के नज़रिए से एक आपदा है। शुरुआत में कुछ बार यह सफल हो सकती है, लेकिन आखिरकार हर बार समस्या आने पर तब तक AI से N बार कोशिश करवानी पड़ती है जब तक वह अपनी समस्या खुद हल न कर दे, और इस डर के साथ जीना पड़ता है कि पता नहीं यह solution कोई दूसरा bug पैदा कर दे।

[ulsoft]

डेवलपर की क्षमता के अनुसार
अगर बुनियादी समझ वाला व्यक्ति इसे इस्तेमाल करे, तो AI का उपयोग करके high-quality development संभव है
और अगर बुनियादी समझ न हो, तो बात पूरी तरह भटक जाती है
ठीक वैसे ही जैसे किसी रसोइए में बुनियादी कौशल होना या न होना फर्क पैदा करता है