जब मैं AI कोड को अस्वीकार करता हूँ, भले ही वह काम करता हो
इंजीनियर तेजी से उस AI-generated code का विरोध कर रहे हैं जो “काम तो करता है” लेकिन समझने, तर्क करने, या maintain करने में कठिन है, और उनका कहना है कि ऐसा code ship करना जिसे आप समझा नहीं सकते, गैर-जिम्मेदाराना है—खासकर critical systems में। टिप्पणीकर्ता AI tools को boilerplate, prototyping, और cross-language translation के लिए उपयोगी मानते हैं, लेकिन चेतावनी देते हैं कि unchecked agent use tech debt को तेज़ करता है, shallow review habits को बढ़ावा देता है, और senior developers को opaque changes से बोझिल कर सकता है। कई लोग AI को एक बहुत तेज junior developer की तरह treat करने की वकालत करते हैं: tight constraints, मजबूत testing, और स्पष्ट ownership के तहत उपयोगी, लेकिन कभी भी human judgment या accountability का विकल्प नहीं।
जब “काम करने वाला” कोड भी अस्वीकार कर दिया जाता है
- कई लोग तर्क देते हैं कि “यह चल रहा है और परीक्षण हरे हैं” सिर्फ एक न्यूनतम मानक है।
- अस्वीकार करने के सामान्य कारण: दृष्टिकोण समझा नहीं सकते, 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 नहीं किया जाना चाहिए.