यदि एआई शुरू से ही मौजूद था: सस्ता कोड ने निर्णय लेने को आसान नहीं बनाया

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

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

यह अब सच नहीं है, और परिवर्तन इतनी तेजी से हुआ है कि अधिकांश इंजीनियरिंग नेताओं को इसे पचाने का समय नहीं मिला है।

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

हालांकि, जो वास्तव में हुआ है वह जटिल है: टीमें अब इतना सॉफ्टवेयर उत्पादित कर सकती हैं जितना वे जानते हैं कि इसके साथ क्या करना है, और जो उन्हें धीमा कर रहा है वह चुपचाप कहीं और चला गया है।

“आप एक तोड़ी हुई प्रक्रिया पर एआई लागू नहीं कर सकते,” कहा पाब्लो गाम्बा, इंटिवे में प्रौद्योगिकी अमेरिका के प्रमुख। “यह एक कार्यकर्ता को तेज़ शोवेल देने जैसा है। वह तेजी से काम करेगा, लेकिन केवल गलत दिशा में।”

तेजी से निष्पादन, पुरानी पुरानी सीमा

प्रत्येक प्रमुख तकनीकी परिवर्तन – इंटरनेट, क्लाउड और आउटसोर्सिंग – एक ही आकार का अनुसरण किया है। कुछ ऐसा जो पहले महंगा था लगभग रातोंरात सस्ता हो गया, और जो कुछ भी एक फर्म ने उस लागत के आधार पर बनाया था उसे तोड़ दिया गया और पुनः निर्मित किया गया।

इस समय, सस्ता हो रही चीज़ स्वयं लागू तकनीकी बुद्धिमत्ता है, जो कि सेवा फर्मों और इंजीनियरिंग टीमों द्वारा दशकों से जो शुल्क लिया जाता है, गाम्बा दावा करते हैं।

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

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

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

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

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

संख्याएं उन्हें वापस करती हैं, भी। फॉर्च्यून 50 उद्यम एआई-सहायता प्राप्त विकास का उपयोग कर रहे हैं जो अपने समकक्षों की तुलना में 3x-4x तेजी से प्रतिबद्धता जारी कर रहे हैं, क्लाउड सुरक्षा गठबंधन से अनुसंधान के अनुसार, लेकिन लगभग दस गुना दर से नए सुरक्षा निष्कर्ष पेश कर रहे हैं।

इस अर्थ में, गति बिना स्पष्ट गंतव्य के नहीं जाती; यह प्रयास को बर्बाद नहीं करती है, बल्कि जोखिम को तेजी से बढ़ाती है जितना कि अधिकांश सुरक्षा टीमें तालमेल बिठा सकती हैं।

एआई का लाभ उठा सकता है जो भाषा में आवश्यकताओं को प्राप्त करना

यदि परिभाषा वह जगह है जहां वास्तविक सीमा अब बैठती है, तो समाधान अधिक प्रलेखन नहीं है। यह अलग प्रलेखन है, जो एक एआई प्रणाली द्वारा बिना किसी अंतराल को भरने के लिए कार्रवाई की जा सकती है।

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

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

एक एजेंट का अनुमान ऐसा नहीं दिखता। यह साफ, फ्लूएंट, पूरी तरह से बना हुआ कोड के रूप में दिखाई देता है, और इसमें कोई हेज नहीं है, यहां तक कि जब यह गलत होता है।

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

जो टीमें इसे एक प्रलेखन कोर के रूप में मानती हैं वे सीखती हैं कि अस्पष्ट इरादा केवल अस्पष्ट सॉफ्टवेयर का उत्पादन करता है मशीन की गति से।

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

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

बैकलॉग प्रबंधक, इरादे के क्यूरेटर

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

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

यह डिज़ाइन धीरे-धीरे यह आकार दे रहा है कि परिभाषा क्या है और नौकरी अब और क्या है।

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

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

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

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

गार्डरेल के बिना तेजी से निष्पादन जीत नहीं है

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

संख्याएं यहां भी करीब नहीं हैं। वेराकोड के स्प्रिंग 2026 परीक्षण में पाया गया कि केवल 55% कोड जनरेशन कार्यों ने सुरक्षित आउटपुट उत्पादित किया जब कोई स्पष्ट सुरक्षा मार्गदर्शन प्रदान नहीं किया गया था, एक आंकड़ा जो दो साल में भी बहुत कम नहीं बदला है, भले ही कार्यात्मक सटीकता में काफी छलांग लगाई गई हो।

स्पष्ट है कि सही वाक्य रचना को प्राप्त करना मुश्किल हिस्सा बंद हो गया है। मानव इंजीनियर द्वारा लिखते समय सुरक्षा, अनुपालन और जो डेटा को छूना चाहिए और किस प्रणाली को नहीं छूना चाहिए, के बारे में निर्णय लेना है – वे हिस्से हैं जो प्रतिस्थापित करने में कठिन हैं।

यही कारण है कि सुरक्षा, अनुपालन और जो डेटा को छूना चाहिए और किस प्रणाली को नहीं छूना चाहिए, जैसे कि कार्यात्मक आवश्यकताओं के साथ समान देखभाल के साथ परिभाषित क्या है और क्या नहीं है, को परिभाषित करने के लिए उसी कठोरता की आवश्यकता है।

उन्हें स्पष्ट रूप से परिभाषित किए बिना छोड़ना और आशा करना कि एक एजेंट उन्हें सही ढंग से अनुमान लगा लेगा, उत्पाद आवश्यकताओं को अस्पष्ट छोड़ने और उम्मीद करने जैसा है कि निर्माण किसी तरह से ठीक हो जाएगा।

नेतृत्व क्या दिखता है

यह एआई-त्वरित विकास के खिलाफ नहीं है; निर्माण कभी भी इतनी तेजी से या सस्ता नहीं रहा है, और वह बोतल में वापस नहीं जा रहा है।

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

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