नतीजा स्वीकार करने से पहले AI के कोड बदलावों की समीक्षा करें

रिपॉज़िटरी में मौजूद कोड की समीक्षा करें, केवल एजेंट के सारांश की नहीं। प्रभावी लगने वाले विवरण के साथ अधूरा सुधार, कभी न चला टेस्ट या असंबंधित बदलाव भी हो सकते हैं। परिणाम स्वीकार करने से पहले माँगा गया व्यवहार, वास्तविक परिवर्तन और जाँच का प्रमाण अलग करें।

Mono Code से आप प्रोजेक्ट फ़ाइलें खोल सकते हैं, कोडिंग एजेंट के साथ काम कर सकते हैं और एडिटर में ही Git बदलाव देख सकते हैं। यह गाइड छोटे, पूरे हो चुके बदलाव की समीक्षा के बारे में है; कनेक्ट होने का तरीका रिमोट कोडिंग गाइड बताती है। रिपॉज़िटरी और कमांड हमेशा आपके अपने कंप्यूटर, यानी होस्ट, पर रहते हैं। Mono अभी उपलब्ध नहीं है; आप प्रतीक्षा सूची में जुड़ सकते हैं।

1. स्वीकार करने की शर्त दोबारा लिखें

एक ठोस उदाहरण लें: काल्पनिक टास्क फ़ॉर्म केवल स्पेस वाला शीर्षक स्वीकार कर लेता है। सुधार को ऐसा इनपुट रोकना है और सामान्य शीर्षक का व्यवहार बचाए रखना है। पैच देखने से पहले लिखें कि क्या सही रहना चाहिए:

• खाली और केवल व्हाइटस्पेस वाले शीर्षक सबमिट नहीं होने चाहिए।
• सामान्य शीर्षक अब भी सफलतापूर्वक सबमिट होना चाहिए।
• उपयोगकर्ता को उपयोगी सत्यापन संदेश दिखना चाहिए।
• फ़ॉर्म का असंबंधित व्यवहार तय दायरे में रहना चाहिए।

यह छोटी सूची डिफ़ के पास रखें। इससे एजेंट के किसी भी स्पष्टीकरण से सहमत होने के बजाय बदलाव का आकलन करने का आधार मिलता है। मूल अनुरोध अस्पष्ट था तो व्यापक कार्यान्वयन स्वीकार करने से पहले व्यवहार स्पष्ट करें।

2. रिपॉज़िटरी की स्थिति समझें

होस्ट, प्रोजेक्ट फ़ोल्डर और ब्रांच की पुष्टि करें। बदली फ़ाइलों की सूची का एजेंट के काम से पहले रिकॉर्ड की गई स्थिति से मिलान करें। उपयोगकर्ता की पहले से मौजूद एडिट केवल उसी फ़ाइल में दिखने के कारण एजेंट का काम नहीं बन जातीं।

सही होस्ट के टर्मिनल में ये केवल-पढ़ने वाले कमांड मदद कर सकते हैं:

git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file

उदाहरण पथ को वास्तविक पथ से बदलें। सामान्य git diff बिना स्टेज किए बदलाव दिखाता है; --cached कमिट की तुलना में स्टेज किए बदलाव दिखाता है। अनट्रैक्ड फ़ाइलों की अलग समीक्षा चाहिए। Git diff दस्तावेज़ ये तुलनाएँ समझाते हैं। साफ़ वर्किंग ट्री यह नहीं बताती कि एजेंट पहले ही कुछ कमिट कर चुका है या नहीं; ऐसा हुआ हो तो संबंधित इतिहास देखें।

3. पैच और उसके आसपास का कोड पढ़ें

Mono के एडिटर में किनारे की पट्टी जोड़ी और बदली गई पंक्तियों को चिह्नित करती है, और किसी निशान पर टैप करने से उस हिस्से का डिफ़ खुलता है। यह एक बदलाव देखने का आसान तरीका है, सारे बदलाव पढ़ लेने का प्रमाण नहीं। निशान न दिखे या पुराना हो, तो इसका मतलब यह नहीं कि फ़ाइल नहीं बदली।

शीर्षक वाले उदाहरण में सत्यापन शर्त खोजें और उसके बाद क्या होता है देखें। क्या वह सामान्यीकृत मान जाँचती है? क्या त्रुटि दिखाई देती है? क्या सबमिशन रुकता है? केवल नई शर्त स्वीकार करने के बजाय आसपास का कोड और उसे बुलाने वाला मार्ग पढ़ें।

नई फ़ाइलें, हटाया कोड, डिपेंडेंसी बदलाव और असंबंधित फ़ॉर्मैटिंग जाँचें। छोटा स्पष्टीकरण बड़े अस्पष्ट डिफ़ को उचित नहीं ठहराता। पंक्तियाँ कट रही हों या बदलाव भरोसे से पढ़ने के लिए बहुत चौड़ा हो तो होस्ट या बड़ी स्क्रीन पर जाएँ।

4. टेस्ट को व्यवहार से मिलाएँ

वास्तव में चलाए गए कमांड, उसका परिणाम और छोड़ी जाँचें पूछें। “टेस्ट पास होने चाहिए” अनुमान है, दर्ज परिणाम नहीं। पास हुई टेस्ट-सूट में भी बताई गई समस्या का प्रासंगिक केस होना चाहिए।

दिखने वाले संदेश के लिए मैन्युअल जाँच उचित हो सकती है; स्वचालित रिग्रेशन टेस्ट सत्यापन नियम बचा सकता है। ऐसा प्रमाण चुनें जो बदलाव दिखाए, केवल कार्यान्वयन दोहराने वाले टेस्ट न जोड़ें। वातावरण में टेस्ट संभव न हों तो सीमा साफ़ लिखें और तय करें कि बची जाँच कहाँ होगी।

5. दूसरी मेहनत खोए बिना निष्कर्षों पर काम करें

सटीक प्रतिक्रिया दें: “केवल स्पेस वाला इनपुट रुकता है, लेकिन त्रुटि लेबल नहीं दिखता” या “इस सत्यापन सुधार में डिपेंडेंसी फ़ाइल क्यों बदली, स्पष्ट करें”। सिर्फ “फिर कोशिश करो” के बजाय व्यवहार और फ़ाइल बताएँ।

दूसरा काम मौजूद हो तो छोटे अनचाहे बदलाव को हटाने के लिए व्यापक reset या restore कमांड से बचें। लक्षित सुधार माँगें और नया डिफ़ देखें। सुधार के बाद प्रभावित जाँचें दोहराएँ; पहले की सफलता बाद की एडिट सत्यापित नहीं करती।

कमांड की अनुमति और कोड की स्वीकृति अलग निर्णय हैं। टेस्ट कमांड की मंजूरी कमिट, मर्ज या डिप्लॉय की मंजूरी नहीं है। कार्रवाई के लिए अनुमति समीक्षा गाइड देखें।

6. समीक्षा योग्य हस्तांतरण छोड़ें

निष्कर्ष एक छोटे नोट में रखें:

माँगा गया व्यवहार: खाली टास्क शीर्षक अस्वीकार करना।
समीक्षित फ़ाइलें: वास्तविक पथ लिखें।
प्रमाण: कमांड, परिणाम और जरूरी मैन्युअल जाँचें।
खुले प्रश्न: जो अब भी सत्यापित नहीं हुआ।
अगला निर्णय: बदलाव स्वीकार करना, सुधार माँगना या निर्णय टालना।

कमिट और रिलीज़ की कार्रवाइयाँ स्पष्ट रखें। बातचीत बचानी हो तो Markdown में निर्यात करें, लेकिन वास्तविक प्रोजेक्ट फ़ाइलें भी रखें। बातचीत का रिकॉर्ड चर्चा बताता है; रिपॉज़िटरी और सत्यापित जाँचें बताती हैं कि सच में क्या बदला।