AI को झूठ बोलने से रोकने का परफेक्ट तरीका - leceipts

AI coding tools का इस्तेमाल करते समय एक अजीब तरह से बार-बार दोहराई जाने वाली स्थिति सामने आती है.

आप bug समझाते हैं
→ “समस्या ठीक कर दी”
→ चलाकर देखें तो फिर भी टूटा हुआ

यह सिर्फ AI की समस्या नहीं है,
बल्कि human code review में भी दिखने वाला एक परिचित pattern है.
• “शायद इससे हो जाएगा”
• “local में तो ठीक चलता है”
• “test नहीं चलाए, लेकिन समस्या नहीं लग रही”

leceipts इसे रवैये या culture का मुद्दा नहीं मानता,
बल्कि process के ज़रिए हल करने की कोशिश करता है.

हर बार code change करते समय, यह नीचे दी गई बातों को structured तरीके से दर्ज करना अनिवार्य करता है:
• Root cause: समस्या क्यों हुई
• Change: वास्तव में कौन-सा बदलाव किया गया
• Recurrence prevention: वही समस्या दोबारा न हो, इसके लिए क्या किया गया
• Verification: कैसे verify किया गया, और उसका परिणाम क्या था
• Remaining risk: कौन-से हिस्से अभी भी पूरी तरह जांचे नहीं गए

यहाँ सबसे अहम चीज़ “Verification” है.
सिर्फ “test किया” कहना काफी नहीं है,
बल्कि किस तरीके से जांच की गई और उसका नतीजा क्या रहा, यह भी दर्ज करना पड़ता है.

जब यह structure बन जाता है, तो कुछ बदलाव दिखाई देते हैं

1. AI की झूठी दावेदारी पर रोक
   “fixed” कहने के बजाय, असली execution result दर्ज करना पड़ता है
   → अगर चलाकर नहीं देखा, तो वह तुरंत सामने आ जाता है
2. human code review की quality बेहतर होती है
   PR का विवरण “अंदाज़” नहीं, बल्कि “सबूत” पर केंद्रित हो जाता है
3. debugging history एक asset बन जाती है
   क्यों टूटा और कैसे ठीक किया गया, यह जमा होता रहता है
   → वही समस्या दोबारा होने से रोकने में मदद मिलती है
4. ‘Done’ का मानदंड स्पष्ट हो जाता है
   सिर्फ fix करना ≠ पूरा होना
   verification खत्म होने पर ही काम पूरा माना जाता है

दिलचस्प बात यह है कि यह कोई नया test framework या
जटिल tool नहीं है.

बस
“समझाने के तरीके को अनिवार्य बनाकर development process बदलना”
यही इसका approach है.

जितना AI coding बढ़ेगा,
उतना लग सकता है कि ऐसा “verification-केंद्रित workflow” आगे चलकर default बन जाए.