इस सप्ताह Meta का AI कोडिंग बाज़ार में प्रवेश एक ऐसे विशिष्ट दावे के साथ हुआ, जिस पर ठहरकर विचार करना चाहिए। कंपनी का नया टर्मिनल-आधारित कोडिंग एजेंट Muse Code सिर्फ़ एक बार में एक फ़ाइल का कोड नहीं लिखता—Mark Zuckerberg की लॉन्च पोस्ट के अनुसार, जब कोई काम काफ़ी बड़ा होता है तो यह "अलग-अलग वर्कट्री में समानांतर रूप से काम कर रहे अलग सब-एजेंटों में फैल जाता है," और Meta की अपनी जाँच में इसने कथित तौर पर एक गेम के लिए छह फ़ीचर बिना किसी टकराव के एक साथ बनाए। यह लॉन्च के दिन अपने ही उत्पाद के बारे में विक्रेता का दावा है, स्वतंत्र रूप से सत्यापित परिणाम नहीं, इसलिए इस विशिष्ट संख्या को संदेह की दृष्टि से देखें। लेकिन इसके द्वारा बताए गए वर्कफ़्लो का स्वरूप केवल Meta का विचार नहीं है—समानांतर, पृथक एजेंट निष्पादन कोडिंग-एजेंट क्षेत्र में एक डिफ़ॉल्ट पैटर्न बनता जा रहा है, और इससे वास्तव में "इस काम में अच्छा होना" का अर्थ बदल जाता है।

पिछले दो वर्षों से AI कोडिंग टूल्स का मुख्य वादा एक ही थ्रेड पर गति को लेकर था: एक एजेंट, एक काम, समीक्षा के लिए एक डिफ़। यह ऐसा कौशल है जिसे अधिकांश इंजीनियर पहले ही कुछ हद तक आत्मसात कर चुके हैं—डिफ़ पढ़ो, टेस्ट चलाओ, उसे रिलीज़ कर दो। अलग-अलग वर्कट्री में काम कर रहे कई एजेंटों में काम बाँटना इस मॉडल को तोड़ देता है। अब आप एक विचार-प्रवाह से आए एक सुसंगत बदलाव की समीक्षा नहीं कर रहे हैं। आप कई एक-साथ किए गए, स्वतंत्र रूप से तर्क किए गए बदलावों की समीक्षा कर रहे हैं, जिन्हें एक-दूसरे का विरोध किए बिना, लॉजिक को दोहराए बिना, या साझा कोडबेस के किसी हिस्से के व्यवहार को लेकर चुपचाप असहमत हुए बिना, एक काम करने वाली प्रणाली में मिलना होगा।

यह पुराने कौशल का तेज़ संस्करण नहीं, बल्कि वास्तव में एक अलग कौशल क्यों है

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

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

विशेष रूप से कोडिंग टूल्स से आगे का व्यापक पैटर्न

यह ध्यान देने योग्य है कि यह केवल डेवलपर टूल्स तक सीमित नहीं है। उसी सप्ताह सामने आया Google के सर्च बॉक्स का नया डिज़ाइन AI Overviews और AI Mode को एक ही प्रवाह में समाहित करता है, जो इनपुट के रूप में टेक्स्ट, इमेज, PDF, वीडियो और खुले हुए Chrome टैब ले सकता है, और काम को क्वेरी पार्सर के बजाय एक एजेंट को सौंपता है। दोनों रिलीज़ के बीच साझा सूत्र एक ही है: इंटरफ़ेस "AI को एक स्पष्ट निर्देश दो और एक स्पष्ट आउटपुट जाँचो" से हटकर "AI को ढीले तौर पर परिभाषित लक्ष्य और इनपुट्स का एक ढेर सौंपो, और उसे चरणों का पता लगाने दो" की ओर बढ़ रहा है। यह पैटर्न हर उस जगह दिखाई देता है जहाँ एजेंटिक टूल्स तैनात किए जाते हैं, केवल कोड एडिटर में नहीं—और इसका अर्थ है कि समीक्षा और ऑर्केस्ट्रेशन का कौशल इंजीनियरिंग भूमिकाओं से काफ़ी बाहर भी प्रासंगिक होने वाला है, उन सभी लोगों के लिए जिनके काम में एकल प्रॉम्प्ट के बजाय किसी बहु-चरणीय कार्य के दौरान AI प्रणाली को निर्देशित करना शामिल है।

वास्तव में किसका अभ्यास करें, ठोस रूप से

यदि आप कोड लिखते या उसका प्रबंधन करते हैं, तो कुछ विशिष्ट, जाँची जा सकने वाली आदतें इसके बारे में पढ़ने की तुलना में इस क्षमता को तेज़ी से विकसित करती हैं:

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

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