তিনটি কোডবেস পর্যালোচনায় দেখা গেছে যে শুধুমাত্র OpenTelemetry (OTel) ইনস্টল করলেই AI-assisted coding agents-এর জন্য ফিডব্যাক লুপ (feedback loop) সম্পন্ন হয় না। একটি কার্যকর লুপ ছাড়া, টেলিমেট্রি এজেন্টকে কী পরিবর্তন করতে হবে তা সিদ্ধান্ত নিতে সাহায্য করতে পারে না, এবং ডেভেলপাররা এমন একটি টুল যোগ করতে গিয়ে সময় নষ্ট করেন যা মডেলের সাথে কখনোই যোগাযোগ করতে পারে না।
কেন “observability-first” মানসিকতা যথেষ্ট নয়
অনেক টিম observability-কে কেবল একটি চেকবক্স হিসেবে বিবেচনা করে: একটি tracing library যোগ করা, একটি dashboard চালু করা এবং কাজ শেষ বলে ধরে নেওয়া। বাস্তবতা হলো এটি একটি তিন ধাপের সিঁড়ি:
- একটি observability mechanism বিদ্যমান।
- সিস্টেমটি প্রকৃতপক্ষে telemetry তৈরি করে।
- একটি AI agent সেই telemetry ব্যবহার করে সিদ্ধান্ত নিতে পারে।
বেশিরভাগ প্রজেক্ট প্রথম ধাপেই আটকে যায়। একটি নিখুঁতভাবে instrumented middleware যদি অ্যাপ্লিকেশনটি কখনোই কল না করে, তবে সেটি অলস বসে থাকে এবং কোনো ডেটা তৈরি করে না। একটি AI agent যখন সোর্স কোড স্ক্যান করে, তখন সে tracing code দেখে ধরে নেয় যে সিস্টেমটি observable, কিন্তু বাস্তবে রানটাইমে কোনো ডেটা পায় না। “একটি টুল থাকা” এবং “একটি লুপ থাকা”-র মধ্যকার এই ব্যবধানেই সমস্ত প্রচেষ্টা ব্যর্থ হয়।
ব্যবহারযোগ্য ডেটার জন্য ছয়টি শর্ত
র (raw) traces-কে একটি AI coding agent-এর জন্য কার্যকর ইনপুটে পরিণত করতে telemetry-কে ছয়টি ব্যবহারিক শর্ত পূরণ করতে হবে:
- Standardization. সামঞ্জস্যপূর্ণ attribute নাম এবং টাইপ ব্যবহার করুন যাতে এজেন্ট কোনো বিশেষ ম্যাপিং ছাড়াই ডেটা parse করতে পারে।
- Propagation. সমস্ত সার্ভিস এবং ল্যাঙ্গুয়েজ বাউন্ডারি জুড়ে একটি একক trace identifier বহন করুন, যাতে এজেন্ট একটি end-to-end execution পুনর্গঠন করতে পারে।
- Discoverability. কোড-লেভেল hooks বা সাধারণ CLI commands-এর মাধ্যমে ডেটা প্রকাশ করুন যাতে মডেলটি ম্যানুয়ালি খোঁজাখুঁজি না করেই এটি খুঁজে পায়।
- Controllability. এজেন্টকে সময়সীমা বা রেজাল্ট কাউন্ট অনুযায়ী কুয়েরি সীমিত করার অনুমতি দিন, যাতে অপ্রাসঙ্গিক span-এর চাপে এটি দিশেহারা না হয়ে পড়ে।
- Accessibility. এজেন্ট যে সেশনে কাজ করছে সেই সেশনেই ডেটা পড়ার উপযোগী রাখুন, আদর্শভাবে একটি লোকাল ফাইল বা stdout stream থেকে।
- Comparability. একই পরিস্থিতিতে “before” এবং “after” snapshot সংগ্রহের ব্যবস্থা রাখুন যাতে এজেন্ট একটি পরিবর্তনের প্রভাব পরিমাপ করতে পারে।
যখন এই স্তম্ভগুলোর কোনো একটি অনুপস্থিত থাকে, তখন ফিডব্যাক লুপ ভেঙে যায় এবং AI agent অনুমানের ওপর নির্ভর করতে শুরু করে।
ডেভেলপমেন্টের জন্য ক্লাউডের চেয়ে লোকাল পাইপলাইন বেশি কার্যকর
প্রোডাকশন এনভায়রনমেন্টগুলো ক্লাউড-ভিত্তিক telemetry collectors, aggregation services এবং dashboards-এর ওপর নির্ভর করে। বড় পরিসরে মনিটরিং করার জন্য এই পাইপলাইনগুলো অপরিহার্য, কিন্তু এগুলো কয়েক মিনিটের লেটেন্সি (latency) যোগ করে। একটি AI agent যদি ডেটার জন্য কয়েক মিনিট অপেক্ষা করে, তবে সে এমন একটি ডেভেলপমেন্ট লুপে অংশ নিতে পারবে না যেখানে কয়েক সেকেন্ডের মধ্যে সিদ্ধান্ত প্রয়োজন।
এর একটি ব্যবহারিক বিকল্প হলো একটি local telemetry pipeline:
- Telemetry লোকাল ফাইল বা stdout-এ লিখুন। OTel এমন exporter সমর্থন করে যা সরাসরি JSON বা plain-text spans ডেভেলপারদের ওয়ার্কস্পেসে পাঠিয়ে দেয়।
- সহজ টুলের মাধ্যমে ডেটা প্রকাশ করুন। একটি মিনিমাল HTTP server, command-line query interface, অথবা একটি লাইটওয়েট SQL wrapper চাহিদামত এজেন্টকে traces সরবরাহ করতে পারে।
- এজেন্টকে র (raw) আউটপুট পড়তে দিন। JSON বা Markdown ফরম্যাটে ডেটা থাকলে ল্যাঙ্গুয়েজ মডেলগুলোর জন্য একই এডিট সেশনের মধ্যে তা parse করা এবং তুলনা করা সহজ হয়।
শুরুতেই বিশাল পরিসরে auto-instrumentation করার চেষ্টা করলে কেবল অপ্রয়োজনীয় নয়েজ (noise) তৈরি হয়। পরিবর্তে একটি একক, গুরুত্বপূর্ণ execution path বেছে নিন—যেমন একটি request handling routine বা build step—এবং সেটিকে end-to-end instrument করুন। এই চেইনটি সম্পন্ন করুন: Generate → Propagate → Store → Query → Compare। একবার সেই লুপটি কাজ করা শুরু করলে, ধীরে ধীরে এর পরিধি বাড়ান।
টিমগুলোর পরবর্তী পদক্ষেপ কী হওয়া উচিত
- সবচেয়ে মূল্যবান ফ্লো (flow) শনাক্ত করুন। এমন একটি কোড অংশ বেছে নিন যেখানে পরিবর্তন করলে পারফরম্যান্স বা সঠিকতার (correctness) পরিমাপযোগ্য প্রভাব পড়বে।
- OTel দিয়ে সেই ফ্লো-টি instrument করুন। span তৈরি করতে, standardize attribute যুক্ত করতে এবং trace context প্রোপাগেট করতে ল্যাঙ্গুয়েজ-স্পেসিফিক API ব্যবহার করুন।
- লোকালভাবে এক্সপোর্ট করুন। এক্সপোর্টারটি এমনভাবে কনফিগার করুন যাতে এটি প্রজেক্ট ডিরেক্টরির একটি ফাইলে JSON lines লেখে অথবা কনসোলে প্রিন্ট করে।
- একটি কুয়েরি ইন্টারফেস প্রদান করুন। একটি ছোট স্ক্রিপ্ট যা trace ID এবং টাইম উইন্ডো অনুযায়ী ফাইলটি ফিল্টার করতে পারে, তা এজেন্টের জন্য সঠিক ডেটা অংশটি খুঁজে পেতে যথেষ্ট।
- ডেটা AI agent-কে দিন। মডেলটিকে “before” trace দিয়ে প্রম্পট করুন, পরিবর্তনের জন্য বলুন, তারপর আপডেট করা কোডটি চালান এবং তুলনার জন্য “after” trace সংগ্রহ করুন।
- পুনরাবৃত্তি (Iterate) করুন। প্রতিটি সফল লুপ ছয়টি শর্ত যাচাই করে এবং observable surface area বৃদ্ধি করে।
সারসংক্ষেপ
OpenTelemetry আপনার কোডকে ট্রেসিংয়ের জন্য একটি সাধারণ ভাষা প্রদান করে, কিন্তু এই ভাষাটি তখনই কার্যকর হয় যখন ডেটা ছয়টি সুনির্দিষ্ট শর্ত পূরণ করে এবং একটি দ্রুত ফিডব্যাক লুপের মাধ্যমে স্থানীয়ভাবে সহজলভ্য হয়। ছোট পরিসরে শুরু করুন, একটি মাত্র ফ্লো ইনস্ট্রুমেন্ট করুন, একটি ফাইলে এক্সপোর্ট করুন এবং AI এজেন্টকে ইন-প্লেস ট্রেসগুলো পড়তে ও তুলনা করতে দিন। এটিই হলো “আমার অবজারভেবিলিটি আছে” থেকে “আমার AI অ্যাসিস্ট্যান্ট প্রকৃতপক্ষে আমার কোড উন্নত করতে পারে” — এই অবস্থার মধ্যবর্তী একটি বাস্তবসম্মত পথ।