क्लॉड कोड के साथ एआई-फर्स्ट इंटीग्रेशन इंजीनियरिंग: एक वास्तविक डिबग सत्र

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

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

जाल

यह उत्पाद हमारे CRMConnect एकीकरणों में से एक है। Mindbody से HubSpot तकएक ग्राहक ने शिकायत की कि एक से अधिक भुगतान विधियों से किए गए लेन-देन गलत तरीके से सिंक हो रहे थे। तीन भुगतान विधियों से किए गए $8,400 के लेन-देन को हबस्पॉट में एक ही $400 के सौदे के रूप में दिखाया गया। बाकी के $8,000 लेन-देन प्रक्रिया से गायब थे।

हम GitHub Issues में इंजीनियरिंग कार्य को ट्रैक करते हैं। ग्राहक से बातचीत HubSpot Service Hub में होती है। सत्र की शुरुआत में बिल्डर ने AI को कार्य की ओर निर्देशित किया।

तत्पर: "भुगतान संबंधी समस्या पर गौर करें"

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

तत्पर: "यह लॉजिक क्या करता है और कौन से ऑटोमेशन/एक्शन करता है?"

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

उपयोगी। लेकिन बिल्डर पहले से ही काफी आगे था।

वह संकेत जिसने सब कुछ बदल दिया

तत्पर: "इस डील के लिए इस्तेमाल किए गए इस विशिष्ट पहचानकर्ता की तुलना crmconnect-mindbody-zoho प्रोजेक्ट में हमारे द्वारा किए जा रहे काम से करें। मुझे लगा था कि हमने वहां समस्या का समाधान कर लिया है। कृपया बारीकी से तुलना करें।"

इस एक वाक्य ने पूरे काम का स्वरूप बदल दिया। निर्माता ने समाधान नहीं बताया। उन्होंने एक मिलते-जुलते उत्पाद की ओर इशारा करते हुए कहा, "जाओ और उसे पढ़ो।"

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

इसके जवाब में एक केंद्रित तुलना प्रस्तुत की गई। ज़ोहो के एकीकरण ने वास्तव में इस समस्या का समाधान कर दिया था, लेकिन एक अलग आर्किटेक्चर के साथ:

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

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

बिल्डर ने दायरे को सीमित कर दिया

यहीं पर मनुष्य ने चीजों को जमीन से जोड़े रखा।

तत्पर: “अभी V4.0 के लिए तैयार नहीं हैं। इसे बाद के लिए छोड़ दें, अभी हमें ग्राहकों द्वारा बताई गई डील गायब होने की समस्याओं को ठीक करने की आवश्यकता है।”

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

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

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

अनुमान

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

बिल्डर के पास तर्क देने के लिए कोई लिखित संहिता नहीं थी। उसके पास केवल याददाश्त थी।

तत्पर: "मुझे याद आ रहा है कि मैंने तारीख इसलिए जोड़ी थी क्योंकि इसकी जरूरत थी (एक ही लेनदेन पर 2 भुगतान, या कुछ इसी तरह की अजीब सी बात)?"

दोनों में से कोई भी मौजूदा स्वचालन से इसे साबित नहीं कर सका। इसलिए कृत्रिम बुद्धिमत्ता (एआई) स्वचालन के संस्करण इतिहास में गई। स्वचालन में 2021 से लेकर अब तक के तिरानवे सहेजे गए संस्करण थे। एआई ने प्रासंगिक विवरण मिलने तक परिवर्तन विवरणों को पढ़ा।

जनवरी 2022 से:

"एक ही आइटम पर कई भुगतान किए जाने पर डील आईडी को अद्वितीय बनाए रखने के लिए डेटाबेस में डील आईडी सेविंग में EPOCH MILLIS को जोड़ा गया है।"

फरवरी 2022 से:

"कस्टम प्रॉपर्टी के आधार पर डील खोजने के लिए बिक्री की तारीख जोड़ दी गई है ताकि यह पिछली बिक्री पर भुगतान संसाधित कर सके।"

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

एआई ने तुरंत अपनी सिफारिश को पलटते हुए स्पष्ट रूप से ऐसा कहा:

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

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

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

इसका गैर-आकर्षक हिस्सा: निर्माण करना, चलाना, ट्रेस पढ़ना, ठीक करना।

डिजाइन तय हो जाने के बाद, यह पुनरावर्ती इंजीनियरिंग बन गई। एक विकास वातावरण में बदलाव को बनाएं, उसे चलाएं, निष्पादन ट्रेस पढ़ें, अगली समस्या खोजें, उसे ठीक करें, फिर से चलाएं। असली बग तो सामान्य थे:

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

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

बिल्डरों के लिए इसका क्या मतलब है?

कहानी को हटा दें तो, यह है कार्यशील मॉडल:

• एआई की सबसे बड़ी ताकत पढ़ने की क्षमता है। इसने संपूर्ण सिबलिंग इंटीग्रेशन का अध्ययन किया, एक ऐसी समस्या का क्रॉस-रेफरेंस किया जिसे हम पहले ही हल कर चुके थे, दो अलग-अलग प्लेटफॉर्म पर आर्किटेक्चर को अनुकूलित किया, और एक डिज़ाइन निर्णय को सत्यापित करने के लिए इतिहास के नब्बे संस्करणों की छानबीन की। कोई भी इंसान यह सब एक दोपहर में नहीं कर सकता।
• मनुष्य की सबसे बड़ी ताकत उसकी स्मृति और विवेक क्षमता है। “मुझे लगता है मैंने इसे किसी कारण से जोड़ा था” किसी भी फाइल में नहीं है। “अभी V4.0 के लिए तैयार नहीं” किसी भी फाइल में नहीं है। ये दोनों बातें उत्पाद का उपयोग करने के अनुभव से निकली हैं। हर एक ने परिणाम को प्रभावित किया।
• गति लूप से आती है। ट्रेस पढ़ें, गलती सुधारें, फिर से चलाएँ। डिबगिंग में आने वाली वह अड़चन, जो आमतौर पर हुई घटना को समझने में बाधा डालती है, अब दूर हो गई है।

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

यही वह कार्यप्रणाली है जिसे विकसित करना सार्थक है।