एआई कोड लिख रहा है, लेकिन क्या आपकी इन्फ्रास्ट्रक्चर इसके साथ तालमेल बिठा सकती है?

हम सॉफ्टवेयर इंजीनियरिंग इतिहास में सबसे अजीब उलटफेर के माध्यम से जी रहे हैं। दशकों से, लक्ष्य निर्धारितता था; ऐसे सिस्टम बनाना जो हर बार एक ही तरह से व्यवहार करते हैं। अब हम उस आधार पर संभाव्य एआई एजेंटों को परत दे रहे हैं, जो अलार्मिंग स्केल और गति से कोड उत्पन्न कर रहे हैं। और ईमानदारी से? हमारी अधिकांश इन्फ्रास्ट्रक्चर इस तरह के लिए नहीं बनाई गई थी।

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

स समस्या पहले से ही यहाँ है

एक 2025 गिटक्लियर अध्ययन में पाया गया कि लगभग 7% कमिट अब एआई-जनित कोड हैं। उनके पिछले विश्लेषण में 153 मिलियन लाइनों के परिवर्तित कोड का विश्लेषण किया गया, जिसमें यह खुलासा हुआ: “कोड चर्न”—कोड जो दो सप्ताह के भीतर पुनः लिखा या हटा दिया गया—2024 में एआई से पहले के आधारभूत स्तर की तुलना में दोगुना हो गया।

सुरक्षा निहितार्थ समान रूप से तीव्र हैं। हाल के विश्लेषण में 80 करीबी कोडिंग कार्यों के साथ 100 से अधिक बड़े भाषा मॉडलों का विश्लेषण किया गया, जिसमें पाया गया कि एआई-जनित कोड 45% मामलों में सुरक्षा कमजोरियों को पेश करता है। वास्तविक दुनिया का प्रभाव? एक में से पांच सीआईएसओ अब एआई-जनित कोड से सीधे प्रभावित प्रमुख घटनाओं की रिपोर्ट करते हैं।

गति लाभ वास्तविक हैं, लेकिन स्थिरता लागतें भी वास्तविक हैं।

प्रवर्धन प्रभाव

एक बात जो मैंने सीखी है कि एआई सब कुछ बढ़ाता है। यदि आपके पास अच्छी प्रथाएं हैं, तो एआई उन्हें बेहतर और तेज बनाता है। यदि आपकी प्रक्रियाएं गंदी हैं, तो एआई उस गंदगी को भी बढ़ाता है। यह एक पैटर्न को दर्शाता है जो हर साल डोरा की वार्षिक डेवओप्स रिपोर्ट में दिखाई देता है: कम चर dẫn बेहतर परिणामों में। सफल टीमें कम ऑपरेटिंग सिस्टम, कम प्रोग्रामिंग भाषाओं, कम तरीकों से चीजें करने के लिए मानकीकृत करती हैं। वे जानबूझकर जटिलता को कम करते हैं।

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

निर्धारितता विरोधाभास

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

मेरा उत्तर? स्टैक के जितना संभव हो उतना निर्धारित रखें। यदि आप 80% अपनी इन्फ्रास्ट्रक्चर को निर्धारित स्तर पर रख सकते हैं, तो आपके एआई एजेंटों के पास कम चर होते हैं। वे “यह निर्भरता क्यों नहीं स्थापित हुई?” या “मैं इस बिल्ड कमांड को फिर से आजमाऊंगा” जैसी चीजों पर संदर्भ विंडो खर्च नहीं कर रहे हैं। वे वास्तविक काम पर ध्यान केंद्रित कर रहे हैं जो आप उनसे करने के लिए कह रहे हैं।

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

विनिर्देशन और सत्यापन कुंजी हैं

जो बात स्पष्ट हो रही है कि एआई-चालित विकास हमें दो ऐतिहासिक रूप से कम मूल्य वाले कौशलों के बारे में सोचने के लिए मजबूर करता है: विनिर्देशन और सत्यापन। आपको यह बताने की आवश्यकता है कि आप वास्तव में क्या बना रहे हैं, और आपके पास यह सत्यापित करने के लिए मजबूत तरीके होने चाहिए कि आपने इसे प्राप्त किया है।

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

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

विश्वास करें, लेकिन सत्यापित करें (और नियंत्रित करें)

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

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

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

क्या आगे आता है

हम एक बदलाव बिंदु पर हैं। जिन टीमों ने पहले से ही अच्छी प्रथाएं थीं, वे एआई के साथ बड़े उत्पादकता लाभ देख रहे हैं। जो टीमें संघर्ष कर रही थीं, वे अब तेजी से संघर्ष कर रही हैं।

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

मेरी सबसे बड़ी सलाह एआई के युग में सफल होने की कोशिश कर रही टीमों के लिए यह है:

• क्रूर रूप से मानकीकृत करें। कम चर उच्च प्रदर्शन से संबंधित हैं। अपनी तकनीकी स्टैक को लॉक करें, सभी प्लेटफ़ॉर्म पर सुसंगत वातावरण लागू करें, और एआई इसे बढ़ाने से पहले कॉन्फ़िगरेशन ड्रिफ्ट को समाप्त करें। यदि पाइथन संस्करण मेल नहीं खाते हैं तो अब समस्याएं पैदा करते हैं, तो वे एआई द्वारा कोड के पैमाने पर 10 गुना अधिक समस्याएं पैदा करेंगे।

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

• पुनरुत्पादन में निवेश करें जैसे कि यह इन्फ्रास्ट्रक्चर है। वातावरण की सुसंगतता को पहले स्तर की इन्फ्रास्ट्रक्चर चिंता के रूप में व्यवहार करें। जब आप यह सिद्ध कर सकते हैं कि आपका स्थानीय वातावरण, सीआई वातावरण और उत्पादन वातावरण समान हैं, तो आप एक पूरे वर्ग के “मेरी मशीन पर काम करता है” समस्याओं को समाप्त कर देते हैं। यह निर्धारित आधार है जो आपको संभाव्य एआई कार्यभार को सुरक्षित रूप से ऊपर परत देने की अनुमति देता है।

यह सवाल नहीं है कि क्या एआई हमारे अधिकांश कोड लिखेगा। यह पहले से ही कई टीमों के लिए ऐसा करता है। सवाल यह है कि क्या हमारी इन्फ्रास्ट्रक्चर इसके साथ तालमेल बिठा सकती है।