ক্লড কোডের সাথে এআই-ফার্স্ট ইন্টিগ্রেশন ইঞ্জিনিয়ারিং: একটি বাস্তব ডিবাগ সেশন

বেশিরভাগ “এআই আমার কোড লিখেছে” ধরনের গল্পগুলো হলো ডেমো, যেখানে একটি পরিষ্কার প্রম্পট এবং একটি পরিষ্কার ফলাফল থাকে। এটি তেমন নয়। এটি একটি বাস্তব APIANT ইন্টিগ্রেশন প্রোডাক্টের উপর একটি আসল সেশন, যেখানে রয়েছে প্রকৃত প্রম্পট, ভুল পদক্ষেপ, সংশোধন, এবং সেই মুহূর্ত যখন মানুষের স্মৃতিশক্তি মেশিনকে হারিয়ে দেয়।

মূল বিষয় এটা নয় যে এআই চিত্তাকর্ষক। আসল কথা হলো, যখন আপনি বসে কাজটি করেন, তখন সেই সহযোগিতাটি আসলে কেমন হয়।

সেটআপ

পণ্যটি আমাদের CRMConnect ইন্টিগ্রেশনগুলোর মধ্যে একটি। মাইন্ডবডি থেকে হাবস্পটএকজন গ্রাহক অভিযোগ করেছেন যে একাধিক পেমেন্ট পদ্ধতির মাধ্যমে পরিশোধ করা বিক্রয়গুলো ভুলভাবে সিঙ্ক হচ্ছিল। তিনটি পেমেন্ট পদ্ধতিতে বিভক্ত $৮,৪০০-এর একটি বিক্রয় HubSpot-এ একটি একক $৪০০-এর ডিল হিসাবে দেখাচ্ছিল। বাকি $৮,০০০ পাইপলাইন থেকে উধাও হয়ে গিয়েছিল।

আমরা গিটহাব ইস্যু-তে ইঞ্জিনিয়ারিং কাজের হিসাব রাখি। গ্রাহকের সাথে কথোপকথনটি হাবস্পট সার্ভিস হাব-এ থাকে। বিল্ডার কর্তৃক এআই-কে কাজটি নির্দেশ করার মাধ্যমে সেশনটি শুরু হয়েছিল।

প্রম্পট: অর্থপ্রদানের বিষয়টি দেখুন

এআই-টি রিপোটির গিটহাব ইস্যুগুলো অনুসন্ধান করে খোলা ইনসিডেন্টটি খুঁজে বের করল, সেটির সম্পূর্ণ বিবরণ নিয়ে এসে পড়ে শোনালো: এটি ছিল একটি মাল্টি-পেমেন্ট সেলস বাগ, যার প্রমাণ হিসেবে দুটি প্রোডাকশন এক্সিকিউশন আইডি উল্লেখ করা ছিল। কোনো রকম সাহায্য বা নির্দেশনার প্রয়োজন হয়নি। এরপর এটি অনুমান না করে, সরাসরি ভাষায় পরবর্তী পদক্ষেপ জানতে চাইল।

প্রম্পট: লজিকটি কী করে এবং কোন অটোমেশন / অ্যাকশনগুলো?

এআই প্ল্যাটফর্ম থেকে প্রাসঙ্গিক অটোমেশনটি লোড করে, এর কাঠামোটি ধাপে ধাপে বিশ্লেষণ করে এবং ব্যর্থতাটি নির্ভুলভাবে ব্যাখ্যা করে। অটোমেশনটি প্রতিটি হাবস্পট ডিলের জন্য একটি ডিডুপ্লিকেশন কী তৈরি করে। একাধিক পেমেন্ট পদ্ধতির বিক্রয়ের ক্ষেত্রে, মাইন্ডবডি প্রতিটি পেমেন্ট পদ্ধতির জন্য একটি করে সারি ফেরত দেয়, যেগুলোর সবকটি একই কী ব্যবহার করে। ফলে, দ্বিতীয় ও তৃতীয় সারি প্রথম সারির তৈরি করা ডিলের সাথে মিলে যাওয়ায় তাদের পরিমাণগুলো নীরবে বাদ পড়ে যায়।

দরকারী। কিন্তু নির্মাতা ইতিমধ্যেই বেশ এগিয়ে ছিল।

সেই ইঙ্গিত যা সবকিছুকে নতুন পথে চালিত করেছিল

প্রম্পট: এই ডিলের জন্য ব্যবহৃত অনন্য শনাক্তকারীটিকে crmconnect-mindbody-zoho প্রজেক্টে আমরা যেভাবে কাজ করি তার সাথে তুলনা করুন। আমি ভেবেছিলাম আমরা সেখানে এর সমাধান করে ফেলেছি। একটি অত্যন্ত সুনির্দিষ্ট তুলনা করুন।

এই একটি বাক্যই কাজটির গতিপথ বদলে দিল। নির্মাতা কোনো সমাধানের কথা বলেননি। তিনি একটি অনুরূপ পণ্যের দিকে ইঙ্গিত করে কার্যত বললেন, গিয়ে পড়ুন।

তাই এআই-টি তাই করল। এটি খুলে দিল মাইন্ডবডি থেকে জোহো ইন্টিগ্রেশন, যা একটি সম্পূর্ণ আলাদা প্রোডাক্ট, ঐতিহাসিক বিক্রয় পরিচালনা করে এমন অটোমেশনটি খুঁজে বের করে এবং সেটি পড়ে। তারপর এটি পেমেন্টের রেকর্ড লেখে এমন সাবরুটিনটি খুঁজে বের করে এবং পড়ে। কোনো সারাংশ নয়। বরং অটোমেশনের আসল লজিক, ধাপে ধাপে।

এটি একটি সুনির্দিষ্ট তুলনার সাথে ফিরে এসেছিল। জোহো ইন্টিগ্রেশন সত্যিই এর সমাধান করেছিল, কিন্তু একটি ভিন্ন আর্কিটেকচারের মাধ্যমে:

• HubSpot-এর প্রোডাক্টটি Mindbody-র পুরোনো সেলস এন্ডপয়েন্ট ব্যবহার করে প্রতিটি সেল লাইনের জন্য একটি করে ফ্ল্যাট ডিল তৈরি করে, যা প্রি-স্প্লিট পেমেন্ট রো রিটার্ন করে।
• জোহো প্রোডাক্টটি মাইন্ডবডির নতুন এন্ডপয়েন্ট ব্যবহার করে একটি প্যারেন্ট পারচেজ রেকর্ড এবং লাইন আইটেম ও পেমেন্টের জন্য আলাদা চাইল্ড রেকর্ড তৈরি করে, যেখানে প্রতিটি পেমেন্টের নিজস্ব আসল পেমেন্ট আইডি থাকে।

এআই-এর পর্যবেক্ষণ ছিল যে জোহো স্থাপত্যগতভাবে আরও পরিচ্ছন্ন, এবং এটি প্রাথমিকভাবে সম্পূর্ণ থ্রি-অবজেক্ট মডেলটি হাবস্পটে স্থানান্তর করার প্রস্তাব দিয়েছিল।

নির্মাতা কাজের পরিধি কমিয়ে আনে।

এইখানেই মানুষ সবকিছুকে বাস্তবতার মাটিতে ধরে রেখেছিল।

প্রম্পট: এখনও ভি৪.০ এর জন্য প্রস্তুত নই। এটা পরের জন্য রেখে দিন, এখন আমাদের গ্রাহকদের জানানো ডিল হারিয়ে যাওয়ার সমস্যাগুলো সমাধান করতে হবে।

এআই-টি একটি সন্তোষজনক আর্কিটেকচারাল রিরাইটের দিকে এগিয়ে গিয়েছিল। নির্মাতা বিষয়টিকে আসল সমস্যায় ফিরিয়ে আনেন: গ্রাহকের একটি নতুন ডেটা মডেল নয়, বরং সঠিক ডিল অ্যামাউন্ট প্রয়োজন। এআই এতে সম্মত হয়, রিরাইটের প্রস্তাবটিকে ভবিষ্যতের কাজ হিসেবে বন্ধ করে দেয় এবং বিদ্যমান ডিল অটোমেশনগুলোর একটি সুনির্দিষ্ট সমাধানের জন্য কাজের পরিধি নতুন করে নির্ধারণ করে।

এই সংশোধনটি গুরুত্বপূর্ণ। কৃত্রিম বুদ্ধিমত্তা মার্জিত সাধারণ সমাধান খুঁজে বের করতে পারদর্শী। কিন্তু কখন সেই মার্জিত সমাধানটি প্রয়োজনের চেয়ে বেশি কিছু হয়ে দাঁড়ায়, তা বুঝতে এটি সবসময় পারদর্শী নয়। নির্মাতা এক বাক্যেই সেই বিচারটি করে দিয়েছিলেন।

এরপর এআইটি জোহো ডিজাইনের পেছনের মূলনীতিটি গ্রহণ করে, তবে এর কাঠামোটি হুবহু নকল করেনি: প্রতিটি সেল লাইন আইটেমের জন্য একটি করে ডিল মেলানো, মাইন্ডবডির আরও সমৃদ্ধ এন্ডপয়েন্ট থেকে ডেটা সংগ্রহ করা, এবং প্রথম পেমেন্টটি যেন বাকিগুলোকে ওভাররাইট না করে, সেজন্য বিভিন্ন পেমেন্ট পদ্ধতি জুড়ে টাকার পরিমাণ সঠিকভাবে একত্রিত করা। প্ল্যাটফর্ম ভিন্ন, কাজ ভিন্ন, কিন্তু মূল ধারণা একই।

অনুমান

ডিডুপ্লিকেশন কী-টি পুনর্গঠন করার সময়, এআই এর একটি উপাদান—একটি তারিখ—এর দিকে নজর দেয়। এর যুক্তি ছিল সুস্পষ্ট। সেল আইডি এবং সেল ডিটেইল আইডি ইতিমধ্যেই কী-টিকে অনন্য করে তুলেছে। তারিখটি অপ্রয়োজনীয়। কী-টিকে সরল করতে এবং দুটি অটোমেশনের মধ্যেকার দুর্বলতার উৎস দূর করতে এটি তারিখটি বাদ দেওয়ার সুপারিশ করে।

নির্মাতার কাছে তর্ক করার মতো কোনো সাংকেতিক নির্দেশিকা ছিল না। তার ছিল স্মৃতিশক্তি।

প্রম্পট: আমার যতদূর মনে পড়ে, আমি তারিখটা যোগ করেছিলাম কারণ সেটার প্রয়োজন ছিল (একই লেনদেনে দুটো পেমেন্ট, বা ওইরকমই কোনো অদ্ভুত ব্যাপার)?

তাদের কেউই বর্তমান অটোমেশন থেকে এটি প্রমাণ করতে পারেনি। তাই এআই অটোমেশনটির ভার্সন হিস্ট্রিতে প্রবেশ করল। অটোমেশনটিতে ২০২১ সাল পর্যন্ত ৯৩টি সংরক্ষিত ভার্সন ছিল। এআই পরিবর্তনের বিবরণগুলো পড়তে থাকল যতক্ষণ না প্রাসঙ্গিকগুলো খুঁজে পেল।

২০২২ সালের জানুয়ারি থেকে:

একই আইটেমের জন্য একাধিক পেমেন্ট করা হলেও ডিল আইডিকে অনন্য রাখতে ডেটাবেসে (DB) সেভ করার ক্ষেত্রে ইপক মিলিস (EPOCH MILLIS) যোগ করা হয়েছে।

২০২২ সালের ফেব্রুয়ারী থেকে:

কাস্টম প্রপার্টির মাধ্যমে ডিল খোঁজার জন্য বিক্রয়ের তারিখ যোগ করা হয়েছে, যাতে এটি পূর্ববর্তী বিক্রয়গুলোর পেমেন্ট প্রক্রিয়া করতে পারে।

নির্মাতার নিজের কথা অনুযায়ী, এটি চার বছর আগেই ছিল। যখন কোনো গ্রাহক আগের কোনো বিক্রয়ের বিপরীতে পরে অর্থ পরিশোধ করেন, তখন মাইন্ডবডি নতুন তারিখে সেই বিক্রয়টি পুনরায় নথিভুক্ত করে। কী-তে তারিখটি না থাকলে, পরবর্তী পেমেন্টটি মূল চুক্তির সাথে মিলে যায় এবং নিজের কোনো রেকর্ড তৈরি করতে পারে না। তারিখটি অপ্রয়োজনীয় ছিল না। এটি ছিল একটি ভারবাহী অংশ, যা কিস্তি এবং স্বয়ংক্রিয় পরিশোধের বিষয়টি সামলানোর জন্য ইচ্ছাকৃতভাবে যোগ করা হয়েছিল।

এআই-এর প্রতিক্রিয়া ছিল অবিলম্বে তার সুপারিশ প্রত্যাহার করা এবং তা স্পষ্টভাবে জানিয়ে দেওয়া:

আপনার স্মৃতিশক্তির উপর বিশ্বাস রাখুন। আপনি যদি ইচ্ছাকৃতভাবে তারিখটি যোগ করে থাকেন, তবে এটি একটি লোড-বেয়ারিং ফাইল, এবং এটি বাদ দেওয়ার কোনো প্রশ্নই ওঠে না। ভার্সন হিস্ট্রিতে এটি খুঁজে পেয়েছি।

এরপর বিষয়টি আরও এক ধাপ এগিয়ে গেল। যেহেতু তারিখটি অপরিবর্তিত রাখতে হতো, তাই দুটি অটোমেশনকেই হুবহু একই তারিখের মান তৈরি করতে হতো, নইলে কী-গুলো মিলতো না এবং ডুপ্লিকেট ডিল দেখা যেত। মূল অটোমেশনটি একটি নির্দিষ্ট মাইন্ডবডি ফিল্ড থেকে তারিখটি তৈরি করে। এআই নতুন অটোমেশনটিকে একই এপিআই কল থেকে, একই টাইমজোন কনভার্সন সহ, সেই একই ফিল্ডটি পড়ার জন্য পুনরায় নির্দেশ দেয়। একই ইনপুট, একই আউটপুট, এবং কী-গুলো যে মিলবে তার নিশ্চয়তা।

এমন একটি রিগ্রেশন যা নীরবে কিস্তিতে অর্থ পরিশোধের ব্যবস্থাটি ভেঙে দিত, তা কখনোই ঘটেনি। এর কারণ এই নয় যে এআই সতর্ক ছিল, বরং কারণ হলো একজন মানুষের একটি অনুমান মনে পড়েছিল এবং এআই কয়েক সেকেন্ডের মধ্যে চার বছরের ইতিহাসের সাথে তা যাচাই করে নিতে পেরেছিল।

অনাড়ম্বর অংশ: বিল্ড করা, চালানো, ট্রেস পড়া, ঠিক করা।

ডিজাইনটি চূড়ান্ত হয়ে যাওয়ার পর, এটি পুনরাবৃত্তিমূলক ইঞ্জিনিয়ারিং-এ পরিণত হলো। ডেভেলপমেন্ট এনভায়রনমেন্টে পরিবর্তনটি তৈরি করা, সেটি চালানো, এক্সিকিউশন ট্রেস পড়া, পরবর্তী সমস্যাটি খুঁজে বের করা, সমাধান করা, এবং পুনরায় চালানো। আসল বাগগুলো ছিল সাধারণ:

• ষোলটি ক্ষেত্রে একটি চুক্তি তৈরির পদক্ষেপ ব্যর্থ হয়েছে। PROPERTY_DOESNT_EXIST ত্রুটি দেখা দিয়েছিল কারণ ফিল্ড বাইন্ডিংগুলোতে HubSpot-এর অভ্যন্তরীণ প্রপার্টির নামগুলো ছিল না। এআই ট্রেসটি পড়ে, কানেক্টরের ফিল্ড স্কিমা সংগ্রহ করে এবং প্রতিটি ফিল্ডকে তার সঠিক আইডি দিয়ে পুনরায় বাইন্ড করে।
• একটি লুপ একবার চলার কথা থাকলেও তা দুইবার চলেছিল, কারণ প্ল্যাটফর্মটি সোর্স ডেটার দীর্ঘতম অ্যারের উপর ভিত্তি করে পুনরাবৃত্তি গণনা করছিল এবং পেমেন্টস অ্যারেটি লাইন-আইটেম অ্যারের চেয়ে দীর্ঘ ছিল। এআই একটি সুস্পষ্ট পুনরাবৃত্তি নিয়ন্ত্রণ যুক্ত করেছে, ফলে লুপটি শুধুমাত্র লাইন আইটেমগুলোই গণনা করে।
• যখন কোনো ডিল তৈরি হয়নি, তখন একটি “ফাইন্ড ডিল” ধাপ পুরো প্রক্রিয়াটিকে থামিয়ে দিয়েছিল, কারণ এর ডিফল্ট এরর মোড “খুঁজে পাওয়া যায়নি” পরিস্থিতিটিকে মারাত্মক হিসেবে গণ্য করছিল। এআই এটিকে “কন্টিনিউ-অন-এরর” মোডে পরিবর্তন করে দেয়, যাতে ক্রিয়েট ব্রাঞ্চটি চলতে পারে; এটি পূর্ববর্তী অটোমেশনের কার্যপ্রণালীর সাথে সামঞ্জস্যপূর্ণ ছিল।

এর কোনো কিছুই আকর্ষণীয় নয়। এটাই ইন্টিগ্রেশন কাজের আসল চিত্র। যা বদলে গেছে তা হলো কাজের গতি। এআই একটি সম্পূর্ণ ধাপে ধাপে এক্সিকিউশন ট্রেস পড়তে পারত এবং সঙ্গে সঙ্গে ব্যর্থ হওয়া ধাপটি চিহ্নিত করে দিতে পারত, ফলে প্রতিটি ফিক্স সাইকেলে কয়েক মিনিট সময় লাগত। ডেভ টেস্ট পাস না করা পর্যন্ত গ্রাহকের কাছে কিছুই পাঠানো হতো না।

নির্মাতাদের জন্য এর অর্থ কী

আখ্যানটি সরিয়ে ফেললে কার্যকরী মডেলটি হলো:

• এআই-এর শক্তি হলো পড়া। এটি একটি সম্পূর্ণ সিibling ইন্টিগ্রেশন অধ্যয়ন করেছে, আমাদের ইতিমধ্যে সমাধান করা একটি সমস্যার সাথে ক্রস-রেফারেন্স করেছে, দুটি ভিন্ন প্ল্যাটফর্মে একটি আর্কিটেকচার অভিযোজিত করেছে এবং একটি ডিজাইন সিদ্ধান্ত যাচাই করার জন্য ইতিহাসের নব্বইটি সংস্করণ ঘেঁটে দেখেছে। কোনো মানুষ এক বিকেলে এই কাজগুলো করতে পারে না।
• মানুষের শক্তি হলো স্মৃতিশক্তি ও বিচারবুদ্ধি। “আমার মনে হয় আমি কোনো কারণে ওটা যোগ করেছি”—এই কথাটি কোনো ফাইলে নেই। “এখনও ভি৪.০-এর জন্য প্রস্তুত নই”—এই কথাটিও কোনো ফাইলে নেই। দুটোই এসেছে পণ্যটি ব্যবহারের অভিজ্ঞতা থেকে। প্রতিটিই ফলাফল বদলে দিয়েছে।
• গতিটি লুপ থেকে আসে। ট্রেসটি পড়ুন, ধাপটি ঠিক করুন, আবার চালান। যে বাধাটি সাধারণত ডিবাগিং এবং কী ঘটেছিল তা পুনর্গঠনের গতি কমিয়ে দেয়, তা দূর হয়ে গেছে।

এআই-ফার্স্ট ইন্টিগ্রেশন ইঞ্জিনিয়ারিং মানে এই নয় যে এআই একা কাজ করছে, বা মানুষ আরও দ্রুত কাজ করছে। এর মানে হলো, এআই এমন সব তথ্য পড়ে যা পড়ার সময় কোনো মানুষের নেই, এবং মানুষ এমন সব প্রাসঙ্গিক তথ্য সরবরাহ করে যা কোনো কোডবেসে রেকর্ড করা থাকে না। এই দুটিকে একত্রিত করলে, চার বছর ধরে চলতে থাকা একটি পুনরাবৃত্তিমূলক বাগ একটিমাত্র ওয়ার্কিং সেশনেই বোঝা, সমাধান করা এবং যাচাই করা সম্ভব হয়।

এটাই সেই কর্মপ্রবাহ যার দিকে এগিয়ে যাওয়া উচিত।