इकाई 12 / 12

एआई कोडिंग उपकरण और वर्कफ़्लो एकीकरण

लाभ:

  • संपादक पूर्णता, चैट सहायक, सीएलआई एजेंट और सीआई स्वचालन श्रेणियों को कार्यों में मैप करने की क्षमता
  • जोखिम के अनुसार स्वायत्तता स्तर को समायोजित करने और सीएलआई एजेंटों पर 'पहले योजना बनाएं' अनुशासन लागू करने की क्षमता
  • एक मान्य उपकरण, सत्यापन गेट, पारदर्शिता और जवाबदेही के आधार पर एआई के उपयोग को एक टीम प्रणाली में बदलने की क्षमता

अब तक हमने व्यक्तिगत कार्यों (कोडिंग, समीक्षा, परीक्षण, डिबगिंग) में एआई का उपयोग करना सीखा है। इस अंतिम इकाई में, हमने टुकड़ों को एक साथ रखा है: विभिन्न एआई कोडिंग टूल को जानना, सही टूल को सही काम से मिलाना, और उन्हें आपके दैनिक विकास प्रवाह में सुरक्षित रूप से एम्बेड करना - संपादक से संस्करण नियंत्रण तक, सीआई/सीडी पाइपलाइन से टीम प्रशासन तक। लक्ष्य गन्दी "एआई से हर समय पूछें" आदत को एक सुसंगत और श्रव्य कार्य प्रणाली में बदलना है।

हम वाहन प्रकारों को तटस्थ श्रेणियों के साथ कवर करते हैं (विशिष्ट उत्पाद नाम जल्दी से बदलते हैं; श्रेणी क्या मायने रखती है यह मायने रखता है)। प्रत्येक श्रेणी में एक "मीठा स्थान" और एक जोखिम प्रोफ़ाइल होती है; किस कार्य को कितनी स्वायत्तता देनी है, यह जानना ही निपुणता है।

एआई कोडिंग टूल्स की श्रेणियाँ

1. इन-एडिटर पूर्णता। प्लगइन्स जो आपके आईडीई (विकास वातावरण जहां आप कोड लिखते हैं) में टाइप करते समय लाइनें/ब्लॉक सुझाते हैं। अच्छी जगह: इन-स्ट्रीम स्पीड, बॉयलरप्लेट कोड। जोखिम: संकीर्ण संदर्भ, बिना सोचे-समझे सुझाव स्वीकार करना।

2. चैट/साइड पैनल सहायक। आपके कोडबेस के हिस्से में दृश्यता के साथ आईडीई में एम्बेडेड चैट इंटरफ़ेस। प्रिय स्थान: विवरण, रिफैक्टर, परीक्षण, बग विश्लेषण। जोखिम: आपके द्वारा दिए गए संदर्भ तक सीमित, सत्यापन की आवश्यकता है।

3. सीएलआई एजेंट (एजेंट उपकरण)। कमांड लाइन से चलने वाले उपकरण कई फाइलों को पढ़ और संशोधित कर सकते हैं, कमांड चला सकते हैं और मल्टी-स्टेप कार्यों को अपने आप निष्पादित कर सकते हैं। अच्छी बात: बहु-फ़ाइल परिवर्तन, दोहराए जाने वाले कार्य, "यह प्रॉपर्टी जोड़ें" प्रकार की नौकरियां। जोखिम: उच्च स्वायत्तता = उच्च प्रभाव; यदि अनियंत्रित छोड़ दिया जाए, तो यह व्यापक और सत्यापित करने में कठिन परिवर्तन उत्पन्न करता है।

4. लाइन/स्वचालन एकीकरण। सीआई (सतत एकीकरण) बॉट जो पीआर पर स्वचालित समीक्षा टिप्पणियाँ छोड़ते हैं, परीक्षण का सुझाव देते हैं, या चेंजलॉग तैयार करते हैं। मीठा स्थान: बिना थकान, स्थिरता के पहली छलनी। जोखिम: शोर, झूठा आत्मविश्वास।

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

चरण दर चरण: एआई को वर्कफ़्लो में एम्बेड करना

  1. कार्य को टूल पर मैप करें. छोटा इन-स्ट्रीम जोड़ → पूर्णता; समझें/पुनःकारक/परीक्षण → चैट करें; बहु-फ़ाइल, दोहराव वाला कार्य → सीएलआई एजेंट; सतत प्रथम फ़िल्टर → सीआई एकीकरण।
  2. स्वायत्तता का स्तर चुनें. एजेंट को कितनी आज़ादी है? केवल पढ़ने योग्य सुझाव या फ़ाइल संशोधन + आदेश निष्पादन? जोखिम के लिए समायोजन करें.
  3. संदर्भ का पोषण करें. टूल में प्रोजेक्ट नियम (शैली, वास्तुकला, "क्या न करें") को स्थायी रूप से शामिल करें; किसी प्रोजेक्ट अनुदेश फ़ाइल को बार-बार समझाने के बजाय उसका उपयोग करें।
  4. सत्यापन द्वार बनाए रखें. एआई परिवर्तन मानव परिवर्तन की तरह है: यह संकलन, परीक्षण, समीक्षा और (यदि महत्वपूर्ण हो) विशेषज्ञ अनुमोदन से गुजरता है। एआई ओपनिंग पीआर अनुमोदन को बायपास नहीं करता है।
  5. मापें और समायोजित करें. देखें कि वास्तव में क्या गति होती है, कहाँ सुधार का बोझ बढ़ता है; जो उपयोग काम नहीं करते उन्हें काट-छाँट करें।

तीन मिनी मामले

केस 1 - सीएलआई एजेंट ने मल्टीफ़ाइल नाम बदलने का काम संभाला। एक टीम 60 फ़ाइलों में फैली एक अवधारणा का नाम बदल देगी। उन्होंने एक सीएलआई एजेंट को कार्य दिया, पहले एक योजना मांगी, योजना को मंजूरी दी, फिर बदलाव किया और पूरा परीक्षण सूट चलाया। एजेंट 3 फ़ाइल में एक एज केस चूक गया; परीक्षणों ने इसे पकड़ लिया, इसे ठीक कर दिया। यह कार्य, जिसमें मैन्युअल रूप से लगभग 3 घंटे लगे, पर्यवेक्षण के साथ 50 मिनट में पूरा हो गया।

केस 2 - अनियंत्रित स्वायत्तता का उलटा असर हुआ। एक अन्य डेवलपर ने एक एजेंट को "इस मॉड्यूल को सुधारने" के लिए कहा और इसे जारी कर दिया; एजेंट ने 18 फ़ाइलें संशोधित कीं और दो निर्भरताएँ जोड़ीं। परिवर्तन इतना व्यापक था कि इसकी समीक्षा नहीं की जा सकी और इसे वापस लेना पड़ा। सबक: एजेंटों को संकीर्ण दायरा, स्पष्ट स्वीकृति मानदंड और पहले योजना बाद में करने का अनुशासन दें।

केस 3 - सीआई समीक्षा बॉट पहला फ़िल्टर बन गया। एक टीम ने एक बॉट बनाया जो पीआर पर स्वचालित एआई समीक्षा टिप्पणियाँ छोड़ता है। एक बार जब बॉट ने अशक्त चेक चूक और शैली के मुद्दों को पकड़ लिया, तो मानव समीक्षक अपना समय व्यावसायिक तर्क के लिए समर्पित करने में सक्षम हो गए। हालाँकि, टीम ने यह स्पष्ट कर दिया कि बॉट ने "अनुमोदन" प्रदान नहीं किया: कम से कम एक मानव अनुमोदन की अभी भी आवश्यकता थी। शोर को कम करने के लिए, उन्होंने नाव को केवल उच्च/मध्यम तीव्रता वाले शोर के लिए ट्यून किया।

चार प्रतिलिपि योग्य टेम्पलेट

सीएलआई एजेंट के लिए "पहले योजना बनाएं" अनुशासन:

कार्य: {{स्पष्ट, संकीर्ण कार्य}}स्वीकृति मानदंड: {{मापन योग्य परिणाम}}बाधा: केवल {{निम्नलिखित निर्देशिका/फ़ाइलों}} पर काम करें; नई निर्भरता जोड़ना। सबसे पहले परिवर्तन के बिना एक योजना प्रस्तुत करें: कौन सी फ़ाइलें, क्या परिवर्तन होगा, कौन से परीक्षण चलाने हैं। मेरे द्वारा योजना स्वीकृत करने की प्रतीक्षा करें. फिर इसे चरण दर चरण लागू करें, प्रत्येक चरण पर परीक्षण चलाएं।

प्रोजेक्ट अनुदेश फ़ाइल (उपकरणों का सतत संदर्भ):

इस परियोजना में एआई टूल के लिए लगातार नियम:- भाषा/संस्करण: {{...}}। शैली: {{...}}.- वास्तुशिल्प बाधा: {{उदा. परतों के बीच दिशा}}.- कभी नहीं: रहस्य एम्बेड करना, उत्पादन डेटा का उपयोग करना, {{निषिद्ध लाइब्रेरीज़}}.- प्रत्येक परिवर्तन परीक्षण योग्य होना चाहिए; बिना पूछे सार्वजनिक एपीआई हस्ताक्षर बदलना। - जब संदेह हो तो रुकें और पूछें।

कार्य-उपकरण मानचित्रण निर्णय:

मैं निम्नलिखित कार्य को परिभाषित करता हूं: {{कार्य}}। मुझे किस वर्ग के टूल के साथ यह करना चाहिए: (ए) संपादक पूर्णता, (बी) चैट सहायक, (सी) सीएलआई एजेंट, (डी) सीआई स्वचालन? अपना तर्क, जोखिम और स्वायत्तता का अनुशंसित स्तर (केवल सुझाव/फ़ाइल बदलें/रन कमांड) लिखें।

सीआई समीक्षा बॉट आचार संहिता:

पीआर समीक्षा में टिप्पणियों के रूप में केवल उच्च और मध्यम गंभीरता के निष्कर्षों को छोड़ें। प्रत्येक निष्कर्ष: श्रेणी, गंभीरता, सुझाया गया सुधार। शैली प्राथमिकता स्तर पर नोट्स को एक अलग, एकल सारांश टिप्पणी में एकत्रित करें। आप सहमति नहीं देते; मानव अनुमोदन आवश्यक है.

कमजोर संकेत/मजबूत संकेत

कमजोर: (सीएलआई एजेंट से) "भुगतान मॉड्यूल को बेहतर बनाएं।"
मजबूत: (सीएलआई एजेंट के लिए) "केवल src/भुगतान/ के तहत चलाएं। कार्य: रिफंड() फ़ंक्शन से पुनरावर्ती सत्यापन तर्क को एक ही सहायक में निकालें; व्यवहार और हस्ताक्षर नहीं बदलते हैं। पहले योजना प्रस्तुत करें और मेरी मंजूरी की प्रतीक्षा करें; फिर परीक्षण/भुगतान/पैकेज निष्पादित करें और चलाएं। नई निर्भरता जोड़ें।"

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

वाहन वर्ग

वह किसमें सर्वश्रेष्ठ है

स्वायत्तता

निरीक्षण भार

संपादक पूर्णता

छोटा इन-स्ट्रीम जोड़

कम

प्रकाश (तत्काल पढ़ना)

चैट सहायक

समझें, परीक्षण करें, रिफैक्टर करें

मध्यम

माध्यम (आउटपुट सत्यापन)

सीएलआई एजेंट

बहु-फ़ाइल, पुनरावर्ती

उच्च

भारी (योजना + पूर्ण समीक्षा)

सीआई स्वचालन

सतत प्रथम फ़िल्टर

मध्यम

माध्यम (नियम + मानव अनुमोदन)

टीम प्रशासन: व्यक्तिगत कौशल से साझा प्रणाली तक

व्यक्तिगत आधार पर एआई का अच्छी तरह से उपयोग करना एक शुरुआत है; वास्तविक परिपक्वता टीम स्तर पर एक सुसंगत प्रणाली है। यह प्रणाली कई स्तंभों पर आधारित है: अनुमोदित उपकरणों की सूची (कौन से उपकरण किस डेटा के साथ उपयोग किए जा सकते हैं - इकाई 10 से), सत्यापन द्वार (एआई परिवर्तन एक ही निर्माण/परीक्षण/समीक्षा द्वार के माध्यम से होता है - इकाई 11 से), पारदर्शिता (यह बताते हुए कि परिवर्तन एआई-संचालित है, जहां आवश्यक हो वहां पता लगाने की क्षमता प्रदान करता है), और जिम्मेदारी की स्पष्टता (जो व्यक्ति हस्ताक्षर करता है और जवाबदेह है वह स्पष्ट है)। यह ढांचा गति बनाए रखते हुए जोखिम को सीमित करता है और यह सुनिश्चित करता है कि नई टीम के सदस्य समान अनुशासन के साथ काम करें।

सावधानी: किसी टूल की स्वायत्तता जितनी अधिक होगी - विशेष रूप से सीएलआई एजेंट जो फ़ाइलों को संशोधित कर सकते हैं, कमांड चला सकते हैं - उतनी ही अधिक इसे उत्पादन वातावरण, गोपनीय डेटा और हार्ड-टू-रिवर्ट ऑपरेशंस तक पहुंचने से सीमित किया जाता है। विनाशकारी आदेशों (स्थायी विलोपन, परिनियोजन) को मानवीय अनुमोदन से जोड़ें।

सामान्य गलतियां

  • कार्य-मतलब असंगति. संपादक पूर्णता या किसी भारी एजेंट के साथ एक छोटे अनुलग्नक के साथ बहु-फ़ाइल कार्य करने का प्रयास कर रहा हूँ।
  • एजेंट को रिहा करना. संकीर्ण दायरे में और "पहले योजना" के बिना दिए गए एजेंट कार्य अनपेक्षित परिवर्तन उत्पन्न करते हैं।
  • एआई के लिए सत्यापन द्वार ढीले करना। "एआई ने यह किया, चलो जल्दी से आगे बढ़ें" सबसे खतरनाक अपवाद है; दरवाजे सबके लिए समान हैं.
  • हर बार संदर्भ मैन्युअल रूप से देना। प्रोजेक्ट नियमों को स्थायी निर्देश फ़ाइल में न लिखने से असंगतता और दोहराव पैदा होता है।
  • सीआई बॉट के अनुमोदन को मानव अनुमोदन समझ लेना। बॉट एक फ़िल्टर है; जवाबदेह मानव अनुमोदन अनिवार्य है.

सारांश

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

आवेदन कार्य

तीन वास्तविक कार्यों की सूची बनाएं जिन्हें आप अगले सप्ताह करेंगे। आप किस वाहन वर्ग और किस स्तर की स्वायत्तता का चयन करेंगे, यह बताने के लिए प्रत्येक के लिए "कार्य-से-वाहन मिलान निर्णय" टेम्पलेट का उपयोग करें। फिर सीएलआई एजेंट (या चैट सहायक) के लिए "पहले योजना बनाएं" अनुशासन के साथ एक संकीर्ण कार्य चलाएं: योजना को मंजूरी दें, इसे लागू करें, परीक्षण चलाएं और मानव पीआर की तरह परिवर्तन की समीक्षा करें। अंत में, अपनी टीम के लिए 5-सूत्रीय "एआई उपयोग नियम" का मसौदा तैयार करें (अनुमोदित उपकरण, डेटा नियम, सत्यापन गेट, स्वायत्तता सीमा, जवाबदेही)।

जांच सूची

  • [ ] मैं एआई कोडिंग टूल श्रेणियों और प्रत्येक की विशेषता के बीच अंतर कर सकता हूं।
  • [ ] मैं कार्य को सही वाहन वर्ग और उचित स्वायत्तता स्तर पर मैप करता हूं।
  • [ ] मैं टूल को स्थायी प्रोजेक्ट संदर्भ (निर्देश फ़ाइल) देता हूं।
  • [ ] मैं सीएलआई एजेंटों पर संकीर्ण दायरा और "पहले योजना बनाएं" अनुशासन लागू करता हूं।
  • [ ] मैं एआई परिवर्तनों को मानव परिवर्तनों के समान सत्यापन द्वारों से गुजरता हूं।
  • [ ] मैं टीम स्तर पर एक मान्य टूल, डेटा नियम, पारदर्शिता और जवाबदेही ढांचे की वकालत करता हूं।

मॉड्यूल परीक्षा

1. जब कोडिंग सहायक कोड तैयार करता है तो उसका अंतर्निहित बड़ा भाषा मॉडल वास्तव में क्या करता है?

  • ए) दिए गए संदर्भ के आधार पर पैटर्न के अनुसार सबसे अधिक संभावित निरंतरता की भविष्यवाणी करता है
  • बी) वास्तव में कोड को संकलित और चलाकर सही परिणाम की गारंटी देता है
  • सी) यह पूरे इंटरनेट पर मौजूद कोड को लाइव स्कैन करता है और सबसे सटीक कोड को कॉपी करता है।
  • डी) एक मानव इंजीनियर की तरह कोड के तर्क को समझता है और इरादे को समझता है

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

2. जब एआई किसी गैर-मौजूद फ़ंक्शन या लाइब्रेरी को स्पष्ट रूप से गढ़ता है, तो आप इसे क्या कहते हैं, और एकमात्र वास्तविक मारक क्या है?

  • ए) इसे संकलन त्रुटि कहा जाता है; मारक औषधि अधिक मजबूत उपकरण है
  • बी) इसे मतिभ्रम कहा जाता है; एंटीडोट कोड और उपयोग किए गए प्रत्येक एपीआई को सत्यापित करना है ✔
  • सी) इसे प्रतिगमन कहा जाता है; मारक उपाय मॉडल को पुनः आरंभ करना है
  • डी) इसे संदर्भ अतिप्रवाह कहा जाता है; मारक उपाय संकेत को छोटा करना है

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

3. AI के साथ कोड जनरेट करते समय कौन सा दृष्टिकोण आउटपुट की गुणवत्ता और स्थिरता में सबसे अधिक सुधार करता है?

  • ए) बिना कोई संदर्भ दिए 'मुझे यह लिखो' कहकर मॉडल जारी करना
  • बी) संभव सबसे लंबा और फैंसी प्रॉम्प्ट लिखना
  • सी) इनपुट/आउटपुट अनुबंध, एज केस, संस्करण और शैली को निर्दिष्ट करें और उदाहरण दें ✔
  • डी) जेनरेट किए गए कोड को बिना पढ़े सीधे संयोजित करना

स्पष्टीकरण: फ़ंक्शन के इनपुट/आउटपुट प्रकार (अनुबंध), किनारे के मामले, भाषा/संस्करण और शैली की बाधा को निर्धारित करना और मॉडल को एक उदाहरण देना भविष्यवाणी से सटीकता तक संक्रमण को सक्षम बनाता है। संदर्भहीन 'मुझे यह लिखें' अनुरोध ऐसे कोड उत्पन्न करते हैं जो हर बार अलग होते हैं और अक्सर किनारे के मामलों को बायपास कर देते हैं।

4. एआई के साथ एक विदेशी कोडबेस की खोज करते समय, फ़ंक्शन का नाम 'validateAndSave' हो सकता है लेकिन एआई डाइजेस्ट गलत हो सकता है। सही दृष्टिकोण क्या है?

  • ए) एआई सारांश पर पूरा भरोसा है क्योंकि नाम स्वयं-व्याख्यात्मक है
  • बी) फ़ंक्शन को बिना पढ़े सीधे बदलना
  • सी) केवल फ़ंक्शन नाम देखकर निर्णय लेना
  • डी) एआई विवरण को एक परिकल्पना के रूप में मानें और कोड ✔ में महत्वपूर्ण दावों को पंक्ति दर पंक्ति सत्यापित करें

स्पष्टीकरण: एआई कोड में नाम देख सकता है और आपको बता सकता है कि 'ऐसा लग रहा है कि यह क्या कर रहा है', लेकिन वास्तव में तर्क भिन्न हो सकता है (या उलटा भी हो सकता है)। तो एआई स्पष्टीकरण एक परिकल्पना है; महत्वपूर्ण दावे, विशेष रूप से सुरक्षा, प्राधिकरण या धन प्रवाह से जुड़े दावों को प्रासंगिक आधार पर स्पष्ट रूप से सत्यापित किया जाना चाहिए।

5. एआई-सहायता प्राप्त कोड समीक्षा में 'एआई ने इसे देखा, यह स्पष्ट है' कहने में सबसे बड़ा खतरा क्या है?

  • ए) एआई गलत नकारात्मक परिणाम उत्पन्न कर सकता है; वास्तविक छूटी हुई गलतियाँ झूठा आत्मविश्वास पैदा करती हैं ✔
  • बी) एआई समीक्षा बहुत धीमी है इसलिए इसमें समय बर्बाद होता है
  • सी) टीम को समझ नहीं आता क्योंकि एआई केवल अंग्रेजी में टिप्पणी करता है
  • डी) पीआर अभिसरण नहीं करता है क्योंकि एआई हमेशा अति-व्याख्या करता है

स्पष्टीकरण: एआई गलत सकारात्मक (किसी समस्या को वहां चिह्नित करना जहां वह मौजूद नहीं है) और गलत नकारात्मक (असली बग गायब) दोनों उत्पन्न करता है। झूठी नकारात्मक बातें चुप हैं; सबसे खतरनाक गलतियाँ वे हैं जिनका समीक्षा में बिल्कुल भी उल्लेख नहीं किया गया है। इसलिए AI पहला फ़िल्टर है, अनुमोदन नहीं; विलय का निर्णय एक जवाबदेह व्यक्ति का है।

6. सबसे कपटपूर्ण जाल कौन सा है जो तब होता है जब आप एआई को केवल कोड और प्रिंट परीक्षण देते हैं?

  • ए) एआई हमेशा बहुत सारे परीक्षण लिखता है और कोडबेस को फुला देता है
  • बी) एआई कोड के वर्तमान (शायद गलत) व्यवहार को 'सही' के रूप में परीक्षण करता है और बग को ठीक करता है ✔
  • सी) परीक्षण लिखते समय एआई स्वचालित रूप से कोड हटा देता है
  • डी) एआई न केवल खुश पथ के लिए बल्कि हमेशा किनारे के मामले के लिए परीक्षण लिखता है

स्पष्टीकरण: एआई कोड को देखता है और ऐसे दावे लिखता है जो वर्तमान व्यवहार का परीक्षण करते हैं। यदि कोड शुरू से ही गलत है, तो AI इस गलत व्यवहार को 'सही' के रूप में ठीक कर देता है। इसलिए, परीक्षण की अपेक्षाओं को आवश्यक नियम (विनिर्देश) के अनुसार लिखा जाना चाहिए, न कि कोड के वर्तमान आउटपुट के अनुसार।

7. एआई के साथ बग को डीबग करते समय परिकल्पना की सटीकता सबसे अधिक क्या निर्धारित करती है?

  • ए) संकेत कितनी विनम्रता से लिखा गया है।
  • बी) प्रश्न कितनी बार दोबारा पूछा गया
  • सी) मॉडल को प्रदान किए गए साक्ष्य की गुणवत्ता: पूर्ण त्रुटि संदेश, स्टैक ट्रेस, इनपुट और अपेक्षित व्यवहार ✔
  • डी) कोड किस रंग थीम में लिखा गया है?

स्पष्टीकरण: AI आपकी तरह त्रुटि नहीं देखता है; वह केवल वही जानता है जो आप उसे देते हैं। पूर्ण त्रुटि संदेश, स्टैक ट्रेस, ट्रिगरिंग इनपुट और अपेक्षित व्यवहार को देखते हुए, मॉडल वास्तविक संभावनाओं की गणना करता है; यदि कोई सबूत नहीं है, तो यह एक अनुमान (मतिभ्रम) बनाता है और आपको गलत रास्ते पर ले जाता है।

8. विश्लेषण के लिए एआई को उत्पादन लॉग देने से पहले सबसे महत्वपूर्ण कदम क्या है?

  • ए) लॉग को वैसे ही चिपकाना, पूरे दिन को कवर करना
  • बी) पहले लॉग को अपरकेस में बदलें
  • सी) लॉग लाइनों को वर्णानुक्रम में व्यवस्थित करना
  • डी) व्यक्तिगत डेटा और रहस्यों को छिपाना और केवल प्रासंगिक विंडो देना ✔

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

9. यदि एआई कहता है कि लॉग विश्लेषण में दो घटनाएं 'एक साथ' हुई हैं और एक को मूल कारण घोषित करता है तो क्या किया जाना चाहिए?

  • ए) सहसंबंध को कार्य-कारण के रूप में नज़रअंदाज करना और मेट्रिक्स और कोड के साथ दावे की पुष्टि करना ✔
  • बी) कारण को निश्चित मानना क्योंकि एआई एक समय संबंध स्थापित करता है
  • सी) पहले आरोपी घटक को तुरंत पुनः आरंभ करना
  • डी) लॉग को पूरी तरह से हटाना और उन्हें फिर से एकत्र करना

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

10. एआई के साथ रीफैक्टरिंग करते समय गैर-परक्राम्य सुनहरा नियम क्या है और इसे क्या सुरक्षित करता है?

  • ए) कोड छोटा होना चाहिए; पंक्तियों की संख्या इसकी गारंटी देती है
  • बी) व्यवहार में कोई परिवर्तन नहीं; वर्तमान व्यवहार को पकड़ने वाले परीक्षण यह सुनिश्चित करते हैं ✔
  • सी) कोड में अधिक टिप्पणियाँ हैं; एआई इसकी गारंटी देता है
  • डी) पूरी फ़ाइल को एक ही बार में दोबारा लिखना; एजेंट इसकी गारंटी देता है

स्पष्टीकरण: रीफैक्टरिंग कोड के बाहरी व्यवहार को बदले बिना उसकी आंतरिक संरचना में सुधार कर रही है; सुनहरा नियम यह है कि व्यवहार स्थिर रहता है। यह सुनिश्चित करना परीक्षण है: एक टेस्टनेट जो वर्तमान व्यवहार को बदलने से पहले कैप्चर करता है और प्रत्येक चरण के बाद स्थापित और चलाया जाता है। टेस्टनेट के बिना रिफैक्टरिंग एक जुआ है।

11. दस्तावेज़ीकरण उत्पादन में वह कौन सी परत है जिसे AI नहीं जान सकता और जिसे बनाना खतरनाक है?

  • ए) इंस्टॉलेशन चरणों को कैसे चलाएं
  • बी) किसी फ़ंक्शन की पैरामीटर सूची
  • सी) 'क्यों' का औचित्य एक डिजाइन निर्णय इस तरह से किया गया था ✔
  • डी) कोड किस भाषा में लिखा गया है?

विवरण: एआई कोड से 'क्या/कैसे' परत (फ़ंक्शन क्या करता है, इसे कैसे सेटअप किया जाता है) निकाल सकता है; लेकिन यह 'क्यों' परत (किसी निर्णय के लिए डिज़ाइन तर्क, सीमा मूल्य का कारण) नहीं जान सकता। एक बना-बनाया 'कारण' बिना किसी औचित्य के अधिक खतरनाक है; कोड स्वामी को यह परत अवश्य जोड़नी होगी.

12. यदि किसी डेवलपर को तत्काल बग का समाधान करते समय लाइव एपीआई कुंजी वाली कॉन्फ़िगरेशन फ़ाइल को गैर-अनुमोदित एआई टूल में पेस्ट करना हो तो उसे क्या करना चाहिए?

  • ए) गति के लिए, फ़ाइल को वैसे ही पेस्ट करें और फिर चैट को हटा दें
  • बी) फ़ाइल के अंत में एक 'गोपनीय' नोट जोड़ें और भेजें
  • सी) कुंजी छोड़ें और केवल फ़ाइल नाम बदलें
  • डी) रहस्य हटाएं/छिपाएं और केवल आवश्यक गैर-संवेदनशील संदर्भ दें ✔

प्रकटीकरण: रहस्य, व्यक्तिगत डेटा और गोपनीय संपत्तियों को कभी भी अस्वीकृत माध्यमों में दर्ज नहीं किया जाना चाहिए; तात्कालिकता इस लाल रेखा को निलंबित नहीं करती है। सही तरीका यह है कि पहले रहस्यों को उजागर किया जाए/पर्दा डाला जाए और केवल आवश्यक, गैर-संवेदनशील संदर्भ दिया जाए। यदि कोई रहस्य अभी भी लीक हो जाता है, तो सबसे पहली बात यह है कि उस कुंजी को तुरंत चालू करें।

13. एआई-जनरेटेड कोड परीक्षण से गुजरता है और उत्पादन में चलता है। क्या इससे साबित होता है कि कोड सुरक्षित है?

  • ए) नहीं; 'कार्य' का मतलब सुरक्षित नहीं है, सुरक्षा के लिए प्रमाणीकरण की एक अलग परत की आवश्यकता होती है ✔
  • बी) हाँ; परीक्षण में उत्तीर्ण होने वाला कोड परिभाषा के अनुसार सुरक्षित है
  • ग) हाँ; इसे उत्पादन में चलाने से सभी कमजोरियाँ दूर हो जाती हैं
  • डी) नहीं; लेकिन सुरक्षा तभी मायने रखती है जब कोड धीमा हो

स्पष्टीकरण: 'कार्य करना' 'सुरक्षित' के समान नहीं है। भले ही कोड में SQL इंजेक्शन जैसी भेद्यता हो, यह परीक्षण पास कर सकता है और सुचारू रूप से चल सकता है; भेद्यता तभी प्रकट होती है जब कोई हमलावर इसे ढूंढ लेता है। इसलिए, सटीकता के अलावा, सुरक्षा-उन्मुख समीक्षा और SAST जैसे स्कैन को एक अलग परत के रूप में किया जाना चाहिए।

14. सीएलआई एजेंट (स्वायत्त उपकरण जो फाइलों को संशोधित कर सकता है और कमांड चला सकता है) को मल्टी-फ़ाइल कार्य देते समय सबसे सुरक्षित अनुशासन क्या है?

  • ए) एजेंट से कहना 'इस मॉड्यूल को सुधारें' और पूरी आजादी देना
  • बी) संकीर्ण दायरा और स्वीकृति मानदंड देना, पहले एक योजना मांगना, उसे मंजूरी देना, उसे चरण दर चरण लागू करना और परीक्षण चलाना ✔
  • सी) एजेंट के सभी परिवर्तनों की समीक्षा किए बिना उन्हें सीधे मर्ज कर दें
  • डी) एजेंट को उत्पादन वातावरण और गोपनीय डेटा तक अप्रतिबंधित पहुंच प्रदान करना

व्याख्या: जैसे-जैसे स्वायत्तता बढ़ती है, नियंत्रण भी बढ़ना चाहिए. एजेंट को एक संकीर्ण दायरा और स्पष्ट स्वीकृति मानदंड देना, पहले बिना बदलाव के एक योजना मांगना, योजना को मंजूरी देना, फिर इसे चरण दर चरण लागू करना और प्रत्येक चरण पर परीक्षण चलाना; यह उन परिवर्तनों को रोकता है जो व्यापक, समीक्षा योग्य नहीं हैं और जिन्हें वापस लेने की आवश्यकता है।

15. सुरक्षा-महत्वपूर्ण सॉफ़्टवेयर (जैसे भुगतान या प्रमाणीकरण) में एआई-जनरेटेड कोड से उत्पन्न होने वाली देनदारी किसकी है?

  • ए) चूंकि कोड एआई से आता है, यह वाहन प्रदाता के पास है
  • बी) यदि एआई पर्याप्त रूप से विकसित है, तो किसी के पास नहीं है; सत्यापित करने की कोई आवश्यकता नहीं है
  • सी) टीम/इंजीनियर जो कोड की जांच, संयोजन और वितरण करता है; AI सहमति का स्थान नहीं लेता ✔
  • डी) केवल वह व्यक्ति जो प्रॉम्प्ट लिखता है, न कि वह जो इसकी समीक्षा करता है

विवरण: एआई एक गति गुणक और ब्लूप्रिंट जनरेटर है; जिम्मेदारी नहीं ले सकते. उत्पादन में कोड से उत्पन्न होने वाली किसी भी त्रुटि, कमजोरियों या उल्लंघन की जिम्मेदारी उस टीम की होती है जो उस कोड की समीक्षा, संयोजन और वितरण करती है। सुरक्षा-महत्वपूर्ण क्षेत्रों में, एआई आउटपुट किसी भी परिस्थिति में योग्य इंजीनियर द्वारा समीक्षा और अनुमोदन का विकल्प नहीं है।