2026 में हम कोड क्यों लिखते हैं

• software engineer की भूमिका अब सिर्फ code लिखने से आगे बढ़कर software factory को बनाना और बनाए रखना हो गई है, लेकिन system को समझने और बेहतर बनाने के लिए अब भी सीधे code के साथ काम करना ज़रूरी है
• prompts, AGENTS.md, और knowledge base के ज़रिए agents को guide करके, और tests, linting, type systems, तथा evaluation के ज़रिए नतीजों को सुरक्षित रखकर, कम क्षमता वाले models से भी काफ़ी उपयोगी बदलाव करवाए जा सकते हैं
• सीधे coding करने से आप English जैसे मध्यवर्ती स्तर से गुज़रे बिना execution environment में सोच सकते हैं, जिससे वे vulnerabilities, कमज़ोर tests, और अनावश्यक exceptions अधिक स्पष्ट दिखते हैं जो सिर्फ passive code review में छूट सकते हैं
• agents compiler से ज़्यादा किसी नए शामिल हुए intern जैसे होते हैं; वे मौजूदा code और अस्पष्ट requirements का सतर्कता से पालन करते हैं, और इंसानी एकबारगी गलतियों को भी wrapping और indirect layers के ज़रिए बढ़ा सकते हैं
• automation की productivity का लाभ उठाते हुए भी ownership और judgment बनाए रखने के लिए ज़रूरी है कि इंसान पहले खुद approaches आज़माएँ, patterns स्थापित करें, और फिर agents से उन्हें दोहरवाएँ

---

एजेंट्स के साथ काम करने वाली software factory

• software engineer अब सिर्फ software ही नहीं, बल्कि ऐसी assembly line भी बनाए रखते हैं जहाँ कोई भी prompt के ज़रिए बदलाव माँग सके और उसे तुरंत deploy किया जा सके
  • prompts, skills, AGENTS.md, और knowledge base के माध्यम से agents की सफलता के लिए ज़रूरी infrastructure पहले से तैयार किया जाता है
  • tests, linting, type systems, evaluation, और दूसरे AI की मदद से होने वाले automatic evaluation द्वारा नतीजों को बाद में सुरक्षित किया जाता है
• अगर पर्याप्त constraints और ताज़ा context दिया जाए, तो कम बुद्धिमत्ता वाले models भी रास्ते से भटके बिना उपयोगी बदलाव कर सकते हैं; ऐसे में लग सकता है कि इंसानों को code पढ़ने या खुद लिखने की ज़रूरत नहीं रही
• लेकिन भले ही Fable-स्तर की बुद्धिमत्ता वाले agents मौजूद हों, सीधे coding करने से आप English जैसी मध्यवर्ती layer के बिना सीधे execution environment में सोच पाते हैं
• agents द्वारा बनाए गए diff और patches को सिर्फ निष्क्रिय रूप से पढ़ते रहने भर से system architecture के साथ गहरा जुड़ाव बनाना मुश्किल है
  • code को सीधे संभालने पर यह महसूस होता है कि उसके ऊपर features जोड़ते समय क्या-क्या टूट सकता है
  • code को व्यवस्थित करके और कई exceptions न जुड़ें ऐसी सुसंगत architectural principles को दस्तावेज़ित करके software factory को भी अधिक स्थिर बनाया जा सकता है
  • debugging के दौरान test strategy की कमज़ोरियों को पहचानकर ठीक किया जाए, तो नए तरह के bugs की पूरी श्रेणी को रोका जा सकता है
• सीधे coding करना software को समझने का एकमात्र तरीका नहीं है, और न ही Magnetized Needle and a Steady Hand की तरह चरम manual काम पर अड़े रहने की ज़रूरत है
  • भले ही वास्तविक code का ज़्यादातर हिस्सा AI बनाए, सीधे coding करना फिर भी एक उपयोगी tool बना रहता है

सीधे coding से बची रहने वाली सोचने की क्षमता और ownership

• अगर आप सिर्फ code पढ़ने और approve करने वाले reverse centaur की भूमिका तक सीमित रह जाएँ, तो concentration और ownership दोनों कम हो जाते हैं, low-quality code का review पार करना आसान हो जाता है, और बारीक tuning भी मुश्किल हो जाती है
  • अगर details पर ध्यान न दिया जाए, तो vulnerabilities जमा होती जाती हैं, और लंबे समय में low-quality code agents पर भी बुरा असर डालता है
  • अगर इंसान पहले खुद approaches आज़माएँ और फिर agents से स्थापित patterns दोहरवाएँ, तो वे नतीजों में लगातार शामिल और मालिकाना महसूस कर सकते हैं
• English एक underspecified language है, जो computation को सटीक रूप से व्यक्त करने के लिए पर्याप्त नहीं है
  • algorithmic काम में ideas को executable steps के रूप में सोचना ज़रूरी होता है
  • स्थिति के अनुसार design space वाले low-level languages या अधिक सीमित computational environment वाले high-level languages चुनकर आवश्यक precision को नियंत्रित किया जा सकता है
• अगर coding agents को compiler की तरह माना जाए, तो यह सोच बन सकती है कि खराब तरीके से लिखा code भी deploy कर देना ठीक है
  • agents compiler से ज़्यादा नए शामिल हुए intern जैसे हैं
  • वे मौजूदा code को पढ़ते हैं, जो अधूरा या निम्न-गुणवत्ता का हो सकता है, और अस्पष्ट change descriptions के आधार पर नए बदलाव बनाते हैं
  • इंसान interns के समूह को अपनी सोच और पसंद पूरी तरह नहीं सौंपते; इसलिए उन्हें सिर्फ consumer बनकर नहीं रहना चाहिए, बल्कि सीधे शामिल होना चाहिए
• agents के लिए Boy Scout Rule को अपने-आप निभाना कठिन है, यानी code को उससे बेहतर स्थिति में छोड़ना जितना उन्होंने उसे पाया था; और यह ज़िम्मेदारी उन्हें सौंपना भी बोझिल लगता है
  • वे मौजूदा change को यथासंभव सुरक्षित बनाने की दिशा में झुकते हैं और पुराने decisions को conservatively बनाए रखते हैं
  • एक codebase में, जब एक इंसान ने अनजाने में कुछ state के लिए browser local storage का उपयोग किया, जबकि बाकी state backend database में रखी जा रही थी, तो agents ने उसी decision को बनाए रखने के लिए wrapping और indirect layers जोड़ दिए, जिससे code lines लगभग 3 गुना बढ़ गईं
  • इस तरह की conservatism इंसानों के एकबारगी गलत फैसलों को बढ़ा सकती है
• code को सीधे हटाने और explore करने की प्रक्रिया, सिर्फ English में निर्देश देने की तुलना में, बेहतर architecture तक पहुँचने में मदद करती है
  • code पर जितना अधिक ध्यान दिया जाए, उतनी ही सोचने की क्षमता, author होने की संवेदना, और software factory को चलाने की योग्यता मज़बूत होती है
• software factory में architectural patterns से लेकर algorithms और performance तक details महत्वपूर्ण होती हैं
  • agents ने evaluation, measurement, और guardrails की ज़रूरत बढ़ा दी है, और व्यक्तिगत projects में भी CI को बाद का काम नहीं बल्कि शुरुआत में जोड़ने के लिए प्रेरित किया है
  • इससे software development की स्थिति काफ़ी सुधरी है, लेकिन हर assembly line में अब भी कमज़ोरियाँ बनी हुई हैं
• car factory में भी कभी assembly line को खोलकर देखना पड़ता है, कभी internal combustion engine की details में उतरकर 10% सुधार निकालना पड़ता है, और कभी field issues जल्दी क्यों नहीं पकड़े गए यह जानने के लिए पूरे दिन brake pad tests को देखना पड़ता है
  • software में भी details और overall structure को जोड़ने के लिए इस पर मनमानी सीमाएँ नहीं खींची जानी चाहिएँ कि आप किन चीज़ों को सीधे छू सकते हैं

[choijaekyu]

क्योंकि token की कीमत नहीं है :(

[GN⁺]

Hacker News की राय

• अगर आप कोड लिख नहीं सकते, तो उसे रिव्यू भी नहीं कर सकते — यह बात साफ लगती है; फिर भी कुछ लोग और कंपनियाँ मानती हैं कि Claude लिख देगा और Codex रिव्यू कर देगा। लेकिन फिर भी परिणाम assembly या compiled binary में नहीं, बल्कि Python, Java जैसी high-level language में क्यों चाहिए? आखिरकार इंसान को कोड पढ़ पाने योग्य होना चाहिए
  डेवलपर से उम्मीद करना कि वह कोड पढ़े, debug करे और तर्क लगाए, लेकिन उसी क्षमता को विकसित करने की ट्रेनिंग न देना — यह विरोधाभासी रवैया है

  • Claude से assembly न लिखवाने की वजह यह है कि assembly में CRUD app बनाने की training material लगभग नहीं है। यह अच्छा नहीं लगता कि LLM नौकरियाँ खा जाएँ, लेकिन यह भी सच है कि सबसे advanced models इंटरनेट पर बार-बार दोहराए और document किए गए कामों में अच्छे हैं, और पिछले कई दशकों में software development का बड़ा हिस्सा standardized CRUD apps बनाने का ही था
    अगर पूरी रचनात्मकता LLM को सौंप दी जाए, तो क्या industry आगे भी विकसित हो पाएगी — इस पर संदेह है
  • कोड लिखना दरअसल सोचने की क्रिया है, इसलिए अगर कोड लिखना बंद कर देंगे तो सोचना भी रुक जाएगा। भले ही हम कहें कि हम अब higher level पर सोचते हैं, उस high-level design में भी LLM हमसे बेहतर हो जाएगा, इसलिए मौजूदा बढ़त अस्थायी ही है
  • आखिरकार यह सोचने के तरीके का अंतर लगता है। कुछ लोगों के लिए code, English explanation से ज़्यादा सटीक और पढ़ने में आसान होता है, इसलिए अनुभवी डेवलपर सिर्फ सरसरी नज़र से भी उसका व्यवहार समझ लेते हैं; जबकि कुछ लोगों को code पढ़ना कठिन लगता है और वे natural language को ज़्यादा सहज पाते हैं
    इसका मतलब यह नहीं कि कोई एक तरीका बेहतर है; हो सकता है कम details पर ध्यान देने वाले लोग दुनिया चलाएँ, या हर समस्या में ज़रूरी सूक्ष्मता का स्तर अलग हो
  • लगता है Casey Muratori और Demetri Spanos ने इसे किसी वीडियो में कवर किया था; binaries से बचने की वजह LLM पर अविश्वास से ज़्यादा हर मशीन की अलग machine code और offsets, और context समझने की कठिनाई है। जैसे Ghidra द्वारा decompile किया गया C code और डेवलपर द्वारा लिखा गया C source समझने में अलग होते हैं, वैसे ही high-level language कोड के इरादे को व्यक्त कर सकती है
    compiler LLM को ऐसा कोड लिखने में मदद करता है जो सच में compile और run हो सके, लेकिन अगर machine code सीधे output किया जाए तो उसके चलने की संभावना बहुत कम होती है। और हाँ, अगर आप खुद कोड लिख ही नहीं सकते, तो रिव्यू करना और भी कठिन हो जाता है
  • कुछ लोग सचमुच यह तर्क भी देते हैं कि Claude को assembly या binary सीधे output करनी चाहिए। लेकिन high-level language की तुलना में, जिसे कई मशीनों के assembly में compile किया जा सकता है, उसकी portability कम होने की संभावना है

• “इतनी व्यापक और सटीक project spec, जिससे program generate किया जा सके, industry उसे क्या कहती है? Code” — CommitStrip
  अगर सही तरह लिखा गया हो, तो code का सार यह होना चाहिए कि वह underlying business logic को सबसे सरल रूप में व्यक्त करे। यह ज़रूरी नहीं कि हर supporting layer का पूरा review किया जाए, लेकिन अगर code पढ़ा ही नहीं गया, तो business logic को भी पूरी तरह समझ लिया गया है — ऐसा कहना मुश्किल है

  • मूल लिंक
  • इस विषय पर लिखी दूसरी पोस्ट में भी spec की जगह code इस्तेमाल करने की सलाह दी गई थी। एजेंट को code के रूप में निर्देश देना, या उसे follow करने के लिए examples बना देना भी ठीक है
    https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
  • इसलिए Lisp की ज़रूरत है। पहले ऐसी programming language बनाई जाए जिसमें business logic के मूल तत्व ही language के मूल तत्व हों, और फिर उस नई language में business क्या करता है, यह बताने वाला एक सरल program लिखा जाए

• असली सवाल यह है कि manual coding के लिए पैसे कौन देगा। ग्राहक code के लिखे जाने या generate होने के लिए नहीं, बल्कि समस्या के समाधान के लिए पैसे देता है; इसलिए जो सबसे कम लागत और कम झंझट में समाधान देगा, वही काम ले जाएगा, और AI tools द्वारा timeline compress करने का फायदा नज़रअंदाज़ करना मुश्किल है
  मैं 1990s से इस industry में हूँ, और औसत डेवलपर्स द्वारा औसत नतीजे बनाना हमेशा आम बात रही है। Handwritten code को हम ज़रूरत से ज़्यादा romanticize करते हैं, लेकिन असली codebases समय के साथ maintain करना मुश्किल और bugs से भरे हो जाते थे, और बुरी तरह किए गए projects कोई नई बात नहीं हैं

  • उल्टा, मुझे लगता है कि कम मात्रा में code खुद लिखना productivity बढ़ाता है। अगर एक दिन लगाकर architecture को manually फिर से व्यवस्थित कर लिया जाए, तो token cost में हज़ारों dollars और कई हफ्तों की परेशानियाँ बच सकती हैं
    अभी हालात ऐसे हैं जैसे दोनों हाथ बाँधकर software factory बनाने की कोशिश की जा रही हो
  • औसत डेवलपर्स अब औसत नतीजे 10 गुना ज़्यादा बना रहे हैं
  • healthcare, aviation, nuclear जैसे वे regulated industries जहाँ software quality महत्वपूर्ण है — वहाँ manual coding के लिए पैसे दिए जाते रहें, यही उम्मीद है। हालाँकि यह बाज़ार अपेक्षाकृत छोटा है

• फोकस करने और समझने के लिए सिर्फ दूर से agent को देखते रहना और code को passively पढ़ना काफ़ी नहीं है; code को खुद करके अनुभव करना पड़ता है। आखिरकार बात अपने mental model को train करने की है
  Coding करते समय अवचेतन मन बार-बार ऐसे फ़ैसले करता है जैसे “यह सही लग रहा है”, और यह क्षमता सिर्फ दोहराव और गहरे focus से बनती है; सिर्फ code review या docs पढ़ने से इसकी सीमा है। ऐसा mental model बन जाए तो production incident में सिर्फ error message देखकर भी कारण तुरंत समझ में आ सकता है, लेकिन generated code में वही बात धीमी, conscious reasoning से देर तक खोजनी पड़ती है
  अगर LLM सच में उपयोगी होना है, तो हमें मानना होगा कि वह पूरी code maintenance अपने ऊपर लेकर किसी external library की तरह काम कर सकता है; नहीं तो समस्याएँ लगातार आती रहेंगी

  • इंसानों के साथ भी ऐसा separation पहले आज़माया गया था, और वह इतना बुरी तरह विफल हुआ कि ivory tower architect जैसा तंज पैदा हो गया। असली systems में implement न हो सकने वाले सैद्धांतिक designs बनते हैं, implementation team या LLM architecture को bypass करते हैं, और architect तथा implementer के बीच उलझी बहसों में development बहुत धीमा पड़ जाता है
  • observability के क्षेत्र में कहा जाएगा कि अगर सिर्फ dynamic runtime behavior से root cause ढूँढना कठिन है, तो system को और पारदर्शी और observable बनाना चाहिए। लोग टीम बदल सकते हैं या छोड़ सकते हैं, इसलिए किसी एक उत्कृष्ट व्यक्ति के mental model पर निर्भर न रहना — यह सिद्धांत पहले से ही सही था
    अभी नहीं पता कि कौन-सा पक्ष सही है; मैं अभी इस पर और समझ बना रहा हूँ

• 2026 में भी AI-generated code अब भी बहुत खराब है। चाहे Fable हो या custom Pi/opencode LeetCode harness, नतीजे भयानक हैं; और अगर आप अपने code और AI code की quality के बीच का फर्क नहीं पहचान पा रहे, तो यह अच्छी खबर नहीं है

  • मेरा code AI से खराब था, या अब भी है, लेकिन कम से कम मुझे पैसे तो मिलते हैं, इसलिए वह बुरी खबर ज़्यादा मायने नहीं रखती

• एजेंट से Boy Scout नियमों का पालन करवाने के लिए profile execution, code coverage की जाँच, critical review, और report व follow-up tasks लिखने जैसी बातें नियमों में स्पष्ट रूप से डाल दी गई थीं। आज के cutting-edge LLMs मेरे साथ काम कर चुके 90% लोगों से कहीं बेहतर तरीके से ऐसे नियमों का पालन करते हैं, इसलिए यह बुरा है या नहीं, इस पर मुझे संदेह है

  • एजेंट अभी बदलावों को जितना संभव हो उतना सुरक्षित बनाने की ओर झुकता है। एक बार मैंने कॉफी पीने से पहले ही लापरवाही में browser local storage इस्तेमाल करने को कह दिया, तो उसने बाकी state पूरी तरह backend database में होने के बावजूद उस गलत फैसले को बचाए रखने के लिए wrapping और indirection layers जोड़कर code lines लगभग तीन गुना बढ़ा दी थीं
    एजेंट conservative होता है, इसलिए वह इंसानी एकबारगी गलती को बढ़ा सकता है। इसे हल करने के कई तरीके हैं और हर किसी की सोच अलग होती है, इसलिए code पढ़े बिना काम करने का तरीका भी संभव है और सीधे पढ़कर-लिखकर काम करने का तरीका भी, लेकिन LLM से गुजरे बिना code की precision से मिलने वाला फायदा भी बड़ा है

• मुझे code खुद लिखना पड़ता है, क्योंकि नहीं तो LLM जरूरत से बहुत ज्यादा code बना देता है। समस्या को पूरी तरह समझना और generalize करना जरूरी है, ताकि “Hello World” पर 10 हज़ार lines और 5 abstraction layers न चिपक जाएँ
  LLM token predictor है, इसलिए जितनी ज्यादा problems solve करनी होंगी, उतने ज्यादा code tokens output करने की उसकी प्रवृत्ति होगी

  • LLM पूरे सिस्टम को समग्र रूप से सोचने के बजाय code को defensive wrapping में लपेटना पसंद करता है, इसलिए वह आसानी से फूला हुआ हो जाता है। इसके विपरीत, इंसानी developer काम करते हुए आसपास के code को भी साफ़ कर सकता है और Boy Scout नियम का पालन कर सकता है
  • Peter Naur ने दशकों पहले समझाया था कि programming source code, spec, और docs को मशीन की तरह पैदा करने का काम नहीं है, बल्कि यह एक गहरी मानसिक थ्योरी बनाने वाली मानवीय गतिविधि है कि सिस्टम का हर हिस्सा वास्तविक समस्या से कैसे जुड़ता है। Programming का असली output वह shared mental model है जो developers के बीच बनता है
    समस्या रखने वाला पक्ष इंसान होता है, इसलिए अगर समस्या को समझा न जाए तो LLM X/Y problem में फँस सकता है और वास्तविक जरूरत से असंबंधित समस्या हल कर सकता है। LLM libraries या high-level languages की तरह गैर-मुख्य हिस्सों को बेहतर abstract करता है, लेकिन समस्या के core को अब भी औपचारिक रूप से व्यक्त करना पड़ता है
    constraints एक-एक करके जोड़ते हुए मनचाहा परिणाम पाने वाली vibe coding भी आखिरकार ढीली-ढाली और अनौपचारिक programming ही है। बेहतर यही है कि समस्या के peripheral हिस्से LLM को दिए जाएँ और core को खुद लिखा और समझा जाए
  • मेरे काम का 99% C# है, लेकिन LLM की वजह से अब मैं बिना कुछ किए खुद को हमेशा से चाहा हुआ low-level programmer कह सकता हूँ
  • मैंने उससे कहा कि कंपनी के दूसरे modules की तरह K8s पर चलने वाला project सेट कर दे, तो LLM ने Hello World implementation के unit tests तक लिख दिए
  • एक आधुनिक अमेरिकी model को मैंने client-side information दिखाने जैसा मामूली काम दिया, तो उसने शुरुआती handshake में server से client तक वह जानकारी भेजने के लिए दोनों तरफ का code बदल दिया, और वह सच में चल भी गया। लेकिन वह जानकारी पहले से ही client पर मौजूद थी, इसलिए client code की सिर्फ एक line बदलनी थी
    ऊपर से देखें तो उसने request पूरी तरह solve कर दी, लेकिन code अनावश्यक और भद्दा था। Usage-based token बेचने वाली कंपनियों के पास ऐसी Rube Goldberg-शैली के solutions बनाने की आर्थिक प्रेरणा होती है जो समस्या को बस मोटे तौर पर हल करें लेकिन ज्यादा से ज्यादा tokens खपा दें, और tokens सिर्फ generation के समय नहीं, बल्कि बाद में नए bugs मिले हुए विशाल code को सँभालते समय भी ज्यादा खर्च होते हैं
    जो लोग copy-paste code का मजाक उड़ाते थे, उनका अब ऐसे ही भद्दे तरीके से जोड़े गए code पर मोहित होना मजेदार लगता है

• नवंबर 2022 के ChatGPT 3.5 से अब तक की प्रगति देखकर मुझे शक है कि क्या 4 साल बाद भी मैं code review कर रहा होऊँगा। AI के बारे में चरमपंथी न होते हुए भी, अगर अभी की रफ्तार बनी रहती है तो 5~10 साल बाद आज के रूप वाला software engineering और development काफी हद तक गायब हो सकता है
  इंसानों के हिस्से शायद सिर्फ UI design बचे, और बाकी सब abstract होकर AI असली काम संभाल ले

  • अगर कोई मशीन एक ही बार में इच्छा पूरी करती हो, तो single request आसान है, लेकिन software हज़ारों इच्छाओं का संचय है, और हर कोने में यह चाहिए, वह नहीं चाहिए जैसी सूक्ष्म decisions लेनी पड़ती हैं। मौजूदा LLM तरीके में इन सभी decisions को अब भी इंसानों को manage करना पड़ता है, लेकिन भविष्य में ऐसे तरीके आ सकते हैं जिनकी आज कल्पना भी नहीं की जा सकती
  • हम मान लेते हैं कि प्रगति इसी रफ्तार से चलती रहेगी, लेकिन देखने में तो यह कुछ हद तक plateau phase में दाखिल हो चुकी लगती है। Models जितने बड़े होते हैं, लागत उतनी ही geometric रूप से बढ़ती है, और लगातार बड़े models train करने का कारोबार लाभदायक नहीं है, यह बात भी अब काफी साफ़ दिख रही है
  • मुझे अभी से वह भविष्य नापसंद है जिसमें हम उन अयोग्य इंसानों को भी सीधे दोष नहीं दे पाएँगे जिन्होंने ऐसी websites बनाई हैं जहाँ हर काम के लिए JavaScript चाहिए और input box में टाइप करना तक ढंग से नहीं होता। अगर function से ज्यादा appearance को महत्व देने वाली management और वैसे ही websites से भरे training data के कारण LLM वही कचरा कहीं बड़े पैमाने पर produce करे, तो यह किसी अस्तित्वगत संकट जैसा लगेगा
    वेब पहले ही काफी खराब है, कम से कम अभी जितना तो रहने दो कि हम अयोग्य इंसानों को दोष दे सकें

• KPI के दबाव से अलग, मौका मिलते ही मैं code खुद लिखता हूँ, और AI से बस थोड़ा ज्यादा स्मार्ट code autocomplete जैसी उम्मीद रखता हूँ

• मैं code खुद लिखता हूँ क्योंकि मुझे coding से प्यार है और इससे सच में खुशी मिलती है। जो काम पसंद है उसे छोड़ने की कोई वजह नहीं है

  • कंप्यूटर को काम बताकर उसे किसी भी दूसरे साधन से अरबों गुना तेज़ी से करते देखना एक जादुई आकर्षण रखता है
  • program design करना और code लिखना मुझे इतना पसंद था कि मैं इसी क्षेत्र में आया। AI का उपयोग करने में मैं पीछे रह गया हूँ और मुझे और सीखना है, लेकिन हाथ से coding करना मैं कभी बंद नहीं करना चाहता
  • अगर coding करते हुए पैसे मिलना ही खुशी है, तो कंपनी वह इनाम बंद कर सकती है। अगर visa बनाए रखने के लिए आप उसी आय पर निर्भर हैं, तो मजबूरन बदलाव के मुताबिक ढलकर coding छोड़ देने की संभावना बहुत ज्यादा है