जब मैं AI कोड को अस्वीकार करता हूँ, भले ही वह काम करता हो
जब “काम करने वाला” कोड भी अस्वीकार कर दिया जाता है
- कई लोग तर्क देते हैं कि “यह चल रहा है और परीक्षण हरे हैं” सिर्फ एक न्यूनतम मानक है।
- अस्वीकार करने के सामान्य कारण: दृष्टिकोण समझा नहीं सकते, diff समस्या की तुलना में बहुत बड़ा है, समय से पहले abstractions, तर्क/maintainability को समझना कठिन, या AI output पर अपने ही समझने से ज़्यादा भरोसा करना।
- कई लोग बताते हैं कि अच्छा reviewer मानव-लिखित code के साथ भी बिल्कुल यही व्यवहार करेगा (जैसे juniors या contractors द्वारा लिखा गया code)।
जोखिम, जवाबदेही, और डोमेन
- safety-critical या उच्च-मूल्य वाले systems के लिए (payments, infrastructure, core backends) internal tools, hobby projects, या simple static sites की तुलना में अधिक scrutiny की मांग की जाती है।
- on-call और support की अपेक्षाएँ: अगर आप 3am पर code debug या explain नहीं कर सकते, तो आपको उसे ship नहीं करना चाहिए।
- कुछ लोगों को critical systems के लिए ऐसे AI code को merge करना अनैतिक लगता है जिसे उन्होंने सच में review नहीं किया है।
AI-generated code की गुणवत्ता
- आम शिकायतें: अत्यधिक abstractions, over-engineering, duplicate utilities, अनावश्यक columns/fields, proper backend/DB उपयोग के बजाय front-end data munging, और जटिल domains में “code salad।”
- LLMs को entropy बढ़ाने वाला बताया जाता है, जो मजबूत constraints के बिना converge करने के बजाय diverge करते हैं।
- सूक्ष्म bugs (जैसे ML data leakage, accounting corner cases) AI से छूट जाना आसान है और novices के लिए पहचानना कठिन।
- अन्य लोग इसका प्रतिवाद करते हैं कि average agents पहले ही बुनियादी structure और cleanliness में कई “enterprise” programmers से बेहतर हैं।
Workflows और guardrails
- कुछ लोग जटिल harnesses बनाते हैं: “AI-isms” के लिए custom linters, strict pre-commit checks, scripts द्वारा enforced TDD, multi-model cross-review, और समय-समय पर AI-assisted audits।
- अन्य लोग AI को मुख्यतः pair-programmer की तरह उपयोग करते हैं: plans, छोटे snippets, syntax help, languages/frameworks के बीच porting, या comment-level pseudocode का विस्तार।
- कुछ लोग खुलकर AI code merge करते हैं जिसे वे पूरी तरह समझते नहीं, tests और failures पर तेज प्रतिक्रिया पर निर्भर रहते हुए; अन्य इसे जोखिमपूर्ण या गैर-जिम्मेदाराना कहते हैं।
संगठनात्मक गतिशीलताएँ और प्रोत्साहन
- मौजूदा खराब incentives—बड़े, तेज commits और cowboy behavior को पुरस्कृत करना—AI के साथ और बढ़ जाते हैं, जिससे tech debt तेज़ी से जमा होती है।
- कुछ लोग “software bankruptcy” जैसी विफलताओं, या कम-से-कम धीमी delivery, senior churn, और rewrite के प्रयासों की उम्मीद करते हैं जो शायद विफल भी हो सकते हैं।
मध्य मार्ग और दीर्घकालिक चिंताएँ
- इस पर बहस कि क्या no AI और full agentic development के बीच एक स्थिर “middle ground” मौजूद है।
- deskilling, comprehension debt, और भविष्य के ऐसे systems जिने कोई नहीं समझता—इनकी चिंता।
- अन्य लोग AI को एक “faster keyboard” मानते हैं और तर्क देते हैं कि असली बाधा अभी भी human understanding और architecture है, जिसे outsource नहीं किया जाना चाहिए.