आप स्वाद के लिए यूनिट टेस्ट नहीं कर सकते
क्या software design या UX में subjective “taste” को tests या code में पकड़ा जा सकता है, खासकर जब AI agents implementation का ज़्यादा काम कर रहे हों? टिप्पणीकारों का कहना है कि quality के कुछ पहलू style guides, linters, snapshot tests, या thumbs‑up/thumbs‑down डेटा पर प्रशिक्षित ML models के ज़रिए formalize किए जा सकते हैं, लेकिन judgment का एक बड़ा, context-dependent हिस्सा rules या unit tests में externalize होने से बचता है। इससे TDD और automated evaluation की सीमाओं, design और architecture के final arbiters के रूप में humans की भूमिका, और LLMs कितनी दूर तक केवल smart लेकिन inexperienced collaborators से आगे जा सकते हैं, जैसे व्यापक प्रश्न उठते हैं।
“स्वाद” की प्रकृति और क्या इसे टेस्ट किया जा सकता है
- कई लोग तर्क देते हैं कि आप स्वाद के लिए पूरी तरह यूनिट टेस्ट नहीं कर सकते क्योंकि:
- स्वाद spec का वह हिस्सा है जिसे आप भूल गए थे या जिसे आप स्पष्ट रूप से कह नहीं सकते।
- नियमों के लिए अपवाद चाहिए, और उन अपवादों के लिए संदर्भगत निर्णय चाहिए; जो बचता है वही “स्वाद” है।
- आप केवल एक छोटा, नियम-जैसा हिस्सा बाहरी रूप से व्यक्त कर सकते हैं; बाकी निहित ही रहता है।
- दूसरे लोग जवाब देते हैं कि कुछ हिस्से कोड किए जा सकते हैं:
- Pairwise “hot or not” तुलना ML scoring functions को प्रशिक्षित कर सकती हैं।
- Style guides, pattern languages, और UI guidelines कुछ साझा मानक पकड़ते हैं।
- Linters और scripts conventions (नामकरण, brand colors, layer boundaries) लागू कर सकते हैं।
AI, LLMs, और व्यक्तिगत/संगठनात्मक स्वाद
- LLMs को शक्तिशाली बताया गया है, लेकिन वे “smart new hire” स्तर पर अटके हुए हैं:
- स्थायी, व्यक्तिगत long-term memory नहीं।
- RL / feedback सामान्य शैली की ओर औसत कर देता है, किसी एक व्यक्ति के स्वाद की ओर नहीं।
- मॉडल अक्सर आत्मविश्वास के साथ लेकिन बेस्वाद या जोखिम भरे निर्णय लेते हैं, जब तक उन्हें कड़ाई से govern न किया जाए।
- सुझाए गए दृष्टिकोण:
- हर व्यक्ति/टीम के लिए अलग preference models प्रशिक्षित करें; जहाँ वे असहमत हों वहाँ fail करें।
- Agents के साथ human “gates” या validation tickets का उपयोग करें, काम बंद करने से पहले।
- LLMs को junior devs मानें; decisions को ADRs/docs में encode करें और उन्हें उनका पालन करने दें।
Testing philosophy और TDD की सीमाएँ
- Tests को ऐसा माना जाता है कि वे चीज़ों को “गलत नहीं” होने देते हैं, न कि उन्हें “अच्छा” या tasteful बनाते हैं।
- भारी TDD और low-level unit tests की आलोचना की जाती है:
- Correctness आसानी से compose नहीं होती; higher levels पर emergent behavior दिखाई देता है।
- Over-mocking और 100% coverage targets confidence कम करते हैं और बदलाव धीमा करते हैं।
- दूसरे लोग उपयुक्त abstraction levels पर और bugs के लिए TDD का बचाव करते हैं।
- Graphics/UI के लिए snapshot tests और visual regression सुझाए जाते हैं, लेकिन वे “feels right” को नहीं पकड़ते।
UX, visuals, और “feel”
- कई लोग नोट करते हैं कि AI-generated UIs/images अक्सर सस्ते या अटपटे लगते हैं।
- कुछ लोग सोचते हैं कि neural nets पर्याप्त labeled examples मिलने पर “tacky” जैसी qualities पहचान सकते हैं।
- Tools objective aspects (colors, layout consistency) टेस्ट कर सकते हैं, लेकिन subjective UX friction के लिए अभी भी humans चाहिए।
Intuition, anthropomorphism, और pragmatism
- मानव intuition (जैसे structural failure को महसूस करना) को स्वाद जैसा बताया गया है: अनुभव-आधारित, लेकिन encode करना कठिन।
- AI collaborators के साथ “we” का प्रयोग subtle anthropomorphizing की चिंता उठाता है।
- कई आवाज़ें “good enough” को स्वीकार करने, AI को support tool की तरह उपयोग करने, और final taste तथा governance humans के पास रखने की वकालत करती हैं।