অডিট ট্রেইলে কোডিং: এজেন্ট-সহায়ক সফটওয়্যারের নতুন নিয়ম

Kwame Boateng-এর লেখা

AI-সহায়িত কোডিংকে প্রায়ই পেয়ার প্রোগ্রামিংয়ের দ্রুততর সংস্করণ হিসেবে বর্ণনা করা হয়। এখন এই তুলনাটি অতিরিক্ত সীমিত। যখন কোনো এজেন্ট একটি রিপোজিটরি পরিদর্শন করতে, একাধিক ফাইল পরিবর্তন করতে, টুল চালাতে, একটি প্রিভিউ তৈরি করতে এবং একটি pull request খুলতে পারে, তখন সহযোগিতার কেন্দ্রীয় সমস্যা আর শুধু “এটি কি কোড লিখতে পারে?” নয়। বরং প্রশ্ন হলো, “মানুষ কি দেখতে, পর্যালোচনা করতে, অনুমোদন করতে এবং পরে কী ঘটেছিল তা পুনর্গঠন করতে পারে?”

এই কারণেই এজেন্ট-সহায়িত সফটওয়্যার দলের সবচেয়ে গুরুত্বপূর্ণ নকশাগত পরিবর্তন হতে পারে ব্যক্তিগত প্রম্পট থেকে দৃশ্যমান ওয়ার্কস্পেসে সরে যাওয়া। উদাহরণস্বরূপ, Slack Code-কে এমন একটি ব্যবস্থা হিসেবে বর্ণনা করা হয় যা প্রকল্প চ্যানেলের সঙ্গে কোডিং এজেন্ট, কোড-ডিফ অডিটিং, লাইভ HTML প্রিভিউ, ফিডব্যাক ও অনুমোদন ওয়ার্কফ্লো, স্বয়ংক্রিয় আর্কাইভিং এবং অডিট লগ একত্র করে। GitHub-এর Copilot অ্যাপও প্রকল্পজুড়ে issue ও pull request সংগঠিত করার জন্য “My work” প্যান যুক্ত করেছে। এই বৈশিষ্ট্যগুলো একটি ব্যবহারিক নীতির দিকে ইঙ্গিত করে: এজেন্টের কাজকে যেন অস্বচ্ছ উত্তরের মতো না দেখায়, বরং নিয়ন্ত্রিত উৎপাদন প্রক্রিয়ার মধ্য দিয়ে এগিয়ে চলা একটি change set-এর মতো দেখায়।

চ্যাট কাজের রেকর্ড নয়

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

একটি স্থায়ী ওয়ার্কস্পেস এসব বিবরণ পরিদর্শনযোগ্য করে তোলে। এতে অনুরোধটিকে একটি নির্দিষ্ট রিপোজিটরি বা প্রকল্পের সঙ্গে যুক্ত করা, এজেন্টের পরিকল্পনা সংরক্ষণ করা, টুলের কার্যক্রম ও ফাইলের পরিবর্তন দেখানো, টেস্ট ও প্রিভিউয়ের লিংক দেওয়া এবং ফলাফলটি কে অনুমোদন করেছে তা নথিবদ্ধ করা উচিত। সঠিক ইন্টারফেস ভিন্ন হতে পারে—issue tracker, pull request, collaboration channel অথবা agent console—কিন্তু সেশন শেষ হওয়ার পরও তথ্যটি টিকে থাকা উচিত।

এটি শুধু কমপ্লায়েন্সের জন্য নয়, সাধারণ প্রকৌশলগত কারণেও গুরুত্বপূর্ণ। দুই সপ্তাহ পরে কোনো বাগ দেখা দিলে একটি দলের চূড়ান্ত diff-এর চেয়েও বেশি কিছু প্রয়োজন হয়। তাদের মূল প্রয়োজনীয়তা, তৈরি করা পরিকল্পনা, টেস্টের প্রমাণ, পর্যালোচকের মন্তব্য এবং কোনো ঝুঁকিপূর্ণ সমঝোতা মানুষ স্পষ্টভাবে গ্রহণ করেছিল কি না—এসব জানতে হতে পারে। একটি স্থায়ী রেকর্ড সেই তদন্তকে সংক্ষিপ্ত করে।

দৃশ্যমান কাজের পাঁচটি স্তর

কোডিং এজেন্ট গ্রহণকারী দলগুলো প্রতিটি পরিবর্তনকে একটি ছোট, পরিদর্শনযোগ্য কেস ফাইল হিসেবে বিবেচনা করতে পারে। পাঁচটি স্তর বিশেষভাবে কার্যকর:

1. উদ্দেশ্য: issue, গ্রহণযোগ্যতার মানদণ্ড, সীমাবদ্ধতা এবং অনুরোধকৃত পরিসর।
2. পরিকল্পনা: ফাইল সম্পাদনার আগে এজেন্টের প্রস্তাবিত পদ্ধতি। জটিল কাজের ক্ষেত্রে এটি একটি অনুমোদন-পর্যায়, অলংকার নয়।
3. Diff: সুনির্দিষ্ট সংযোজন, অপসারণ, dependency পরিবর্তন, configuration সম্পাদনা এবং তৈরি করা asset।
4. প্রমাণ: টেস্টের ফলাফল, lint output, নিরাপত্তা পরীক্ষা, স্ক্রিনশট এবং প্রাসঙ্গিক ক্ষেত্রে একটি লাইভ বা deploy করা যায় এমন প্রিভিউ।
5. সিদ্ধান্তের রেকর্ড: পর্যালোচকের মন্তব্য, অনুরোধকৃত পরিবর্তন, অনুমোদন, প্রত্যাখ্যান, rollback অথবা পরবর্তী কাজ।

উদ্দেশ্য প্রতিটি পরিবর্তনকে ভারী কমিটির মধ্য দিয়ে যেতে বাধ্য করা নয়। একটি টাইপো এবং একটি payment-flow পরিবর্তনের ক্ষেত্রে একই নিয়ন্ত্রণ থাকা উচিত নয়। উদ্দেশ্য হলো সম্ভাব্য প্রভাবের অনুপাতে পর্যালোচনার মাত্রা নির্ধারণ করা।

অনুমোদন কর্মের সঙ্গে যুক্ত হওয়া উচিত

“Human in the loop” একটি কার্যকর নিয়ন্ত্রণ হিসেবে ব্যবহারের জন্য অতিরিক্ত অস্পষ্ট। কেউ ফলস্বরূপ diff না দেখে একটি পরিকল্পনা অনুমোদন করতে পারেন, অথবা এজেন্ট একটি deployment ফাইলও পরিবর্তন করেছে তা খেয়াল না করেই কোড পরিবর্তন অনুমোদন করতে পারেন। আরও ভালো ওয়ার্কফ্লো স্পষ্ট করে যে কোনো অনুমোদন কী করার অনুমতি দেয়।

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

অনুমোদনের পরিসর ও মেয়াদও থাকা দরকার। “landing-page-এর লেখা আপডেট করো”র অনুমোদন যেন নীরবে একটি নতুন analytics package অনুমোদন না করে। গতকাল অনুমোদিত একটি পরিকল্পনা যেন আজ বস্তুগতভাবে পরিবর্তিত diff-এর ক্ষেত্রে স্বয়ংক্রিয়ভাবে প্রযোজ্য না হয়। ইন্টারফেসে এসব সীমা দৃশ্যমান করা উচিত।

প্রিভিউ পর্যালোচনাকে পরিদর্শনে রূপ দেয়

মানুষ যখন source file দেখে ফলাফল অনুমান করার বদলে ফলাফলটি সরাসরি পরিদর্শন করতে পারে, তখন code review প্রায়ই সহজ হয়। একটি লাইভ HTML প্রিভিউ ভাঙা spacing, অনুপস্থিত state, accessibility-বঞ্চিত control অথবা navigation-এ অনিচ্ছাকৃত পরিবর্তন প্রকাশ করতে পারে—যা কোনো পর্যালোচক textual diff-এ উপেক্ষা করতে পারেন।

প্রিভিউ সঠিকতার প্রমাণ নয়। এগুলো টেস্ট ও source review-এর পাশে থাকা উচিত, সেগুলোর পরিবর্তে নয়। তবে এগুলো আলোচনার জন্য একটি অভিন্ন বস্তু তৈরি করে: কোনো পর্যালোচক নির্দিষ্ট screen, state অথবা interaction-এর দিকে ইঙ্গিত করতে পারেন এবং প্রস্তাবিত পরিবর্তনের সঙ্গে যুক্ত করে feedback দিতে পারেন।

পর্যালোচনায় অ-বিশেষজ্ঞরা যুক্ত থাকলে এটি বিশেষভাবে মূল্যবান। কোনো product manager framework পরিবর্তন মূল্যায়ন করতে না পারলেও workflow-টি প্রয়োজনীয়তার সঙ্গে সামঞ্জস্যপূর্ণ কি না নিশ্চিত করার জন্য তিনিই সঠিক ব্যক্তি হতে পারেন। একজন designer visual regression যাচাই করতে পারেন। একজন security specialist permissions ও data handling-এর দিকে নজর দিতে পারেন। এজেন্ট-সহায়িত ওয়ার্কস্পেস প্রতিটি প্রশ্নের উত্তর দেওয়ার জন্য সবচেয়ে উপযুক্ত ব্যক্তির কাছে তা পাঠাতে পারে।

Diff-এর শুধু রং নয়, প্রেক্ষাপটও দরকার

পরিচিত লাল-সবুজ diff এখনও অপরিহার্য, কিন্তু এজেন্ট-তৈরি পরিবর্তন এত বিস্তৃত হতে পারে যে তা পর্যালোচককে বিভ্রান্ত করে ফেলতে পারে। দলগুলোর উচিত এজেন্টকে commit বা change group সংকীর্ণ রাখতে বলা, প্রতিটি গুরুত্বপূর্ণ ফাইল কেন পরিবর্তিত হয়েছে তা ব্যাখ্যা করতে বলা এবং generated বা vendor file আলাদাভাবে চিহ্নিত করা।

উপযোগী পর্যালোচনার প্রশ্নগুলোর মধ্যে রয়েছে:

• ব্যবহারকারীর দৃশ্যমান আচরণে কী পরিবর্তন এসেছে?
• বাস্তবায়নকে সমর্থন করার জন্যই কেবল কোন ফাইলগুলো পরিবর্তন করা হয়েছে?
• বিদ্যমান আচরণ সম্পর্কে এজেন্ট কী কী অনুমান করেছে?
• কোন পরীক্ষাগুলো যোগ, পরিবর্তন বা চালানো হয়নি?
• এই পরিবর্তন কি অনুমতি, ডেটা সংরক্ষণ, বিলিং বা বাহ্যিক API-কে প্রভাবিত করতে পারে?

এই প্রশ্নগুলো “এটা একবার দেখে নিন” ধরনের অস্পষ্ট অনুরোধকে একটি পুনরাবৃত্তিযোগ্য পর্যালোচনায় রূপ দেয়। এগুলো একটি সাধারণ ব্যর্থতার ধরনও প্রকাশ করতে সাহায্য করে: আপাতদৃষ্টিতে গ্রহণযোগ্য একটি ফিচারের সঙ্গে অসম্পূর্ণ টেস্ট আপডেট বা অনিচ্ছাকৃত কনফিগারেশন পরিবর্তন।

গুরুত্বপূর্ণ যুক্তিগুলো সংরক্ষণ করুন

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

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

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

সফটওয়্যার ক্যারিয়ারের জন্য এর পরিবর্তন কী

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

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

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

একটি সহজ পরিচালন নীতি

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

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