YAGNI कभी किस लागत के बारे में था ही नहीं

AI, पुनर्गठन, और अवसर लागत

• कुछ लोगों का तर्क है कि AI ने पुनर्गठन, टेस्ट जोड़ने, और परिष्कृत zero-downtime migrations करने की लागत को बहुत कम कर दिया है, जिससे “आसान, सुरक्षित बदलाव” मुख्य अनुकूलन लक्ष्य बन गया है।
• दूसरे इसका विरोध करते हैं कि AI ज़्यादातर टाइपिंग और boilerplate को तेज़ करता है, न कि असली bottlenecks (coordination, risk management, approvals) को।
• बड़े संगठनों में deployment frequency bureaucracy और risk controls से सीमित रहती है; AI contract deadlines या governance को नहीं बदलता।
• यह चिंता भी है कि AI-generated tests और code अक्सर brittleness बढ़ाते हैं और safe refactoring को और कठिन बना देते हैं, खासकर जब agents को ठीक से guide नहीं किया गया हो।

YAGNI, पूर्वानुमान, और विकल्प (Option) सादृश्य

• मूल तनाव: YAGNI कहता है “अनुमानित features/structures मत बनाओ”; आलोचक कहते हैं कि यह स्वयं भविष्य के बारे में एक prediction है (“you aren’t gonna need it”).
• समर्थक ज़ोर देते हैं: आप सामान्यतः भविष्य की ज़रूरतों का अनुमान लगाने की अपनी क्षमता को ज़्यादा आँकते हैं; abstractions वास्तविक use cases देखने के बाद बनाना बेहतर होता है (“rule of 3”).
• विरोधियों का कहना है कि YAGNI अक्सर एक reflexive “no” बन जाता है जो वैध future-facing design को रोक देता है, खासकर जब developers domain को नहीं समझते या stakeholders को ignore करते हैं।
• लेख का financial-option analogy बहस का विषय है: कुछ लोग unwritten code को flexibility बचाए रखने वाला मानते हैं; दूसरे कहते हैं कि केवल implemented behavior का मूल्य होता है, और “scaffolding” सिर्फ paid option premium है जो शायद कभी payoff न दे।

Abstractions, Technical Debt, और Testing

• एक पक्ष का दावा है कि अधिकांश tech debt over-generalized, unused abstractions से आता है जो भविष्य के बदलावों को constrain करते हैं।
• दूसरा पक्ष rushed, under-architected code की ओर इशारा करता है जिसमें layer violations और कमजोर tests होते हैं, जो बाद में “load-bearing messes” बन जाते हैं।
• AI-driven test generation की आलोचना की जाती है कि यह बड़े, brittle test suites बनाता है; mutation testing को कुछ लोग code change पकड़ने पर अत्यधिक केंद्रित मानते हैं, जिससे refactor cost और बढ़ती है।

Process Context: Agile, Waterfall, और Domain Constraints

• Hardware/chip और safety-critical domains को ऐसे क्षेत्र के रूप में रेखांकित किया गया है जहाँ agile/YAGNI-style thinking ठीक से फिट नहीं बैठती, क्योंकि बदलाव की लागत बहुत अधिक होती है; अधिक पारंपरिक, waterfall-like प्रक्रियाएँ और independent verification मानक बनी रहती हैं।
• दूसरे लोग नोट करते हैं कि “shift left” और iterative practices agile branding से बहुत पहले से मौजूद थीं; agile ने मुख्यतः उन्हें पैक करके लोकप्रिय बनाया।

लेख और AI उपयोग पर प्रतिक्रिया

• कई टिप्पणीकारों को लेख का मुख्य भाग असंगत या “word soup” लगता है, और वे इसका कारण उसके स्पष्ट रूप से AI-generated हिस्से को मानते हैं।
• कुछ इसे “agent optimization” में एक उपयोगी प्रयोग मानते हैं; अन्य इसे एक distraction समझते हैं जो मूल YAGNI argument को कमजोर करता है।