AI के लिए उपयोगी पहला काम चुनें

ऐसा काम चुनें जिसे आप जाँच सकें

पहले उपयोगी काम से आपको सीखना चाहिए कि tool आपके environment में कैसे काम करता है। उसका परिणाम ऐसा भी होना चाहिए जिसका आप निरीक्षण कर सकें। ज्ञात दोष का छोटा सुधार अक्सर दोनों शर्तें पूरी करता है।

केवल प्रभावशाली demo दिखाने के लिए काम न चुनें। बड़ा redesign कई दिखाई देने वाले बदलाव कर सकता है, जबकि गलत धारणाएँ छिपी रह जाएँ। छोटा काम दिखा सकता है कि agent instructions पढ़ता है, दायरे का पालन करता है और failed checks की सही रिपोर्ट देता है या नहीं।

सबसे आसान काम चुनना जरूरी नहीं है। ऐसा काम चुनें जिसका सही परिणाम आपकी team पहचान सके और समझा सके कि वह सही क्यों है।

संभावित कामों की तुलना करें

Reporting application के लिए तीन काल्पनिक अनुरोध लें।

व्याख्या वाला काम reasoning और प्रमाण जाँचने में मदद करता है। Regression test में नियंत्रित कार्रवाई जुड़ती है। Architecture का काम बाद में उपयोगी हो सकता है, लेकिन उसके लिए कहीं अधिक स्पष्ट brief और मजबूत review प्रक्रिया चाहिए।

पहले अभ्यास के लिए regression test चुनें। मनगढ़ंत तारीखें और local branch इस्तेमाल करें। स्पष्ट बताएँ कि production access, dependency upgrades और असंबंधित refactoring दायरे से बाहर हैं।

काम पूरा होने की शर्त लिखें

“Date handling सुधारें” में बहुत कुछ व्याख्या पर छूट जाता है। स्पष्ट शर्त दें: “Input में अमान्य calendar date हो तो validation error लौटाएँ। मान्य तारीखों के लिए documented output बनाए रखें।”

मान्य और अमान्य input के उदाहरण दें। मौजूदा test command पहचानें। Files बदलने से पहले agent से वर्तमान व्यवहार जाँचने को कहें। बदलाव के बाद दोष और प्रमाण की संक्षिप्त व्याख्या माँगें।

काम के परिणाम को गतिविधि से अलग रखें। “Agent ने test लिखा” गतिविधि बताता है। “Test ज्ञात दोष को अस्वीकार करता है” प्रमाण बताता है। सही और गलत दोनों code पर pass होने वाला test इच्छित सुरक्षा सिद्ध नहीं करता।

काम की प्रक्रिया देखें

अभ्यास के दौरान दर्ज करें कि agent को कहाँ अतिरिक्त context चाहिए। जाँचें कि वह repository के संबंधित instructions पढ़ता है या नहीं। ध्यान दें कि वह दायरे से बाहर files बदलता है या नए प्रमाण के बिना असफल तरीका दोहराता है।

हर छोटी पसंद तुरंत न सुधारें। Agent को अधिकृत और पलटे जा सकने वाले काम पूरे करने दें, ताकि आप परिणाम का आकलन कर सकें। अगली कार्रवाई सीमा पार करे या आगे का काम अनसुलझी requirement पर निर्भर हो, तो हस्तक्षेप करें।

काम पूरा होने पर diff का review करें और संबंधित checks चलाएँ। Agent का समय और अपना तैयारी व review का समय, दोनों दर्ज करें। इन observations से अगला काम चुनने और instructions सुधारने में मदद मिलती है।

एक बार में एक सीमा बढ़ाएँ

अभ्यास सफल हो तो जटिलता का एक पहलू बढ़ाएँ। एक function से दो संबंधित modules पर जा सकते हैं। कोई documented integration जोड़ सकते हैं। Permissions और verification की requirements स्पष्ट रखें।

अभ्यास असफल हो तो दायरा बढ़ाने से पहले कारण पहचानें। अधूरा context, अस्पष्ट requirement, अनुपलब्ध test environment और मॉडल की सीमा के लिए अलग-अलग सुधार चाहिए। अधिक autonomy चारों समस्याएँ हल नहीं करती।

Prototype उपयोग में बना रहे तो रखरखाव का जिम्मेदार व्यक्ति तय करें। Vulnerability की नई जानकारी के कारण code बदले बिना भी कार्रवाई जरूरी हो सकती है। लगातार vulnerability management देखें।