सॉफ्टवेयर इंजीनियरिंग के मूलभूत सिद्धांत अधिक मायने रखते हैं

एजेंटिक कोडिंग के अनुभव

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

टेस्टिंग, स्पेसिफिकेशन्स, और विश्वसनीयता

• मजबूत भावना यह है कि LLMs तब सबसे अच्छा प्रदर्शन करते हैं जब उन्हें मानव-लिखित टेस्ट और स्पष्ट लक्ष्यों से निर्देशित किया जाए (अक्सर TDD के साथ)।
• LLM को अपने खुद के टेस्ट लिखने देने से सतही या भ्रामक जांचें और “चीटिंग” होती है।
• कुछ अन्य लोग दावा करते हैं कि उनके पास बड़े, अधिकतर AI-रक्षित ऐप्स हैं जो व्यवहार में स्थिर हैं, लेकिन संशयवादी कम समय-सीमा और बाहरी उपयोगकर्ताओं की कमी की ओर इशारा करते हैं।

आर्किटेक्चर, मेंटेनबिलिटी, और कॉन्टेक्स्ट सीमाएँ

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

रीज़निंग बनाम प्रेडिक्शन

• इस पर बहस कि क्या “रीज़निंग” अगले टोकन की भविष्यवाणी का उभरता हुआ गुण है या सिर्फ़ पैटर्न मैचिंग का भ्रम।
• वास्तविक रीज़निंग के लिए कोई सहमत परीक्षण नहीं है; कई लोग तर्क देते हैं कि वर्तमान मॉडल केवल इसका अनुकरण करते हैं।

सुरक्षा और प्रॉम्प्ट इंजेक्शन

• एक पक्ष मूल्यांकन डेटा का हवाला देता है जिसमें कुछ नए मॉडलों में शून्य सफल इंडायरेक्ट प्रॉम्प्ट इंजेक्शन बताए गए हैं और सुझाव देता है कि समस्या “काफी हद तक हल” हो गई है।
• अन्य लोग हाल की वास्तविक घटनाओं की ओर इशारा करते हैं और नोट करते हैं कि अगर सिस्टम प्रॉम्प्ट को किसी भी तरह बायपास किया जा सकता है, तो इंजेक्शन अब भी अनसुलझा है। स्थिति स्पष्ट नहीं है।

उपमाएँ और AI-जनित कोड की भूमिका

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

सॉफ़्टवेयर इंजीनियरिंग और सीखने पर प्रभाव

• कुछ लोग औसत डेवलपर्स की मांग में नाटकीय कमी की भविष्यवाणी करते हैं, जहाँ AI सिस्टमों को निर्देशित करने वाला एक छोटा विशेषज्ञ कोर होगा।
• अन्य लोग समय-सीमाओं पर सवाल उठाते हैं और नोट करते हैं कि अब तक की भविष्यवाणियाँ अविश्वसनीय रही हैं।
• “मूलभूत सिद्धांतों” को सीखने के लिए सलाह इस पर केंद्रित है: बहुत सारे वास्तविक प्रोजेक्ट बनाइए, अंतर्निहित “क्यों” समझिए (भौतिक/लॉजिक सीमाओं तक), और एल्गोरिद्म, डेटा स्ट्रक्चर्स, तथा मुख्य डिज़ाइन प्रथाओं का अध्ययन कीजिए, न कि किसी एक सार्वभौमिक सिलेबस का।