AI কোডিং এজেন্টরা গবেষণা সফ্টওয়্যারকে দ্রুত আধুনিক করছে, কিন্তু যাচাইকরণই হয়ে উঠছে আসল বাধা

AI এজেন্টরা গবেষণা সফ্টওয়্যার রক্ষণাবেক্ষণে কার্যকর হয়ে উঠছে

OpenAI এবং একাডেমিক অংশীদারদের একটি নতুন ফিল্ড রিপোর্ট AI কোডিং সিস্টেমগুলোর একটি বাস্তব, কম ঝলমলে ব্যবহার দেখায়: বৈজ্ঞানিক গবেষণার বড় অংশকে ধরে রাখা অবহেলিত সফ্টওয়্যার মেরামত ও আধুনিকীকরণ করা। রিপোর্টটি এসব সিস্টেমকে স্বায়ত্তশাসিত বৈজ্ঞানিক চিন্তক হিসেবে উপস্থাপন করে না। বরং এগুলোকে দ্রুত সফ্টওয়্যার কর্মী হিসেবে দেখায়, যারা কোড refactor করতে পারে, পুরোনো টুলিং বদলাতে পারে, framework migration করতে পারে, এবং কিছু ক্ষেত্রে বড় performance gain দিতে পারে।

এই পার্থক্যটি গুরুত্বপূর্ণ। অনেক গবেষণা টুল শুরুতে এমন কোড ছিল যা একটি মাত্র paper বা সীমিত lab workflow সমর্থনের জন্য লেখা হয়েছিল। সময়ের সঙ্গে সেগুলো বৃহত্তর scientific pipeline-এ অন্তর্ভুক্ত হয়েছে, যদিও দীর্ঘমেয়াদি রক্ষণাবেক্ষণ, testing বা portability মাথায় রেখে সেগুলো তৈরি করা হয়নি। মূল লেখকেরা সরে গেলে এবং funding কম থাকলে, labs-গুলো নাজুক codebase-এর ওপর নির্ভর করে থাকে, যা তবু mission-critical।

রিপোর্টে বর্ণিত ঘটনাগুলো দেখায়, এই ধরনের backlog-এর জন্য coding agents খুবই উপযুক্ত হতে পারে। তারা বড় codebase পড়তে পারে, upgrade প্রস্তাব করতে পারে, এক framework বা language থেকে অন্যটিতে অনুবাদ করতে পারে, এবং build system, installation step, test-এর মতো সহায়ক infrastructure তৈরি করতে পারে। কিন্তু রিপোর্ট স্পষ্টভাবে দেখায়, এই সিস্টেমগুলো কী করতে পারে এবং কী করতে পারে না। তারা দ্রুত সফ্টওয়্যার আবার লিখতে পারে, কিন্তু পুনর্লিখিত সিস্টেমের বৈজ্ঞানিক আচরণ আসলে সঠিক কি না, তা নির্ভরযোগ্যভাবে বিচার করতে পারে না।

Build cleanup থেকে পূর্ণ পুনর্লিখন পর্যন্ত

রিপোর্টে আটটি case study রয়েছে, যার বেশিরভাগই জীববিজ্ঞানের। কাজটি তুলনামূলকভাবে সীমিত maintenance কাজ থেকে শুরু করে পুরোনো scientific software-এর বড় পুনর্লিখন পর্যন্ত বিস্তৃত।

একটি সহজ উদাহরণ ছিল cyvcf2, যা genetic data পড়ার জন্য ব্যবহৃত একটি Python library। ওই ক্ষেত্রে GPT-5.5 পুরোনো build এবং installation setup-কে আরও আধুনিক একটি ব্যবস্থায় প্রতিস্থাপন করে। এই ধরনের কাজ প্রায়ই একঘেয়ে কিন্তু গুরুত্বপূর্ণ: সফ্টওয়্যার ইনস্টল বা compile করা কঠিন হয়ে গেলে, তা বৈজ্ঞানিকভাবে প্রাসঙ্গিক থাকলেও পরিচালনাগতভাবে ভঙ্গুর হয়ে পড়তে পারে।

আরও জটিল একটি প্রকল্প ছিল MHCflurry, একটি immunology model যা অনুমান করে immune cells কোন targets চিনতে পারবে। রিপোর্ট অনুযায়ী, Claude Code এবং Codex developer ও reviewer ভূমিকার মধ্যে পালা করে TensorFlow থেকে PyTorch-এ প্রায় 10,000 line of code port করেছে। এই ধরনের migration বহু দল বছরের পর বছর পিছিয়ে দেয়, কারণ এটি ব্যয়বহুল, ঝুঁকিপূর্ণ, এবং ভেঙে ফেলা সহজ।

source text-এ দেখানো সবচেয়ে উচ্চাকাঙ্ক্ষী উদাহরণ হলো rustar-aligner, STAR-এর একটি Rust rewrite। STAR একটি ব্যাপকভাবে ব্যবহৃত tool, যা sequencing read genome location-এ map করতে ব্যবহৃত হয়। STAR-এ 20,000-এর বেশি C এবং C++ line রয়েছে এবং এটি আর সক্রিয়ভাবে রক্ষণাবেক্ষিত নয়, যদিও এটি এখনো বহু গবেষণা pipeline-এর অংশ। এ ধরনের একটি tool পুনর্নির্মাণ করা শুধু software exercise নয়। ফলাফল ভিন্ন হলে downstream analysis-এ সূক্ষ্ম পরিবর্তন আসতে পারে।

Performance gain বাস্তব, কিন্তু বিশ্বাস অর্জন করতে হয়

রিপোর্ট করা gain এতটাই উল্লেখযোগ্য যে বোঝা যায় labs কেন আগ্রহী। source text অনুযায়ী, coding-agent-নেতৃত্বাধীন প্রচেষ্টায় কিছু ক্ষেত্রে 60 গুণেরও বেশি speedup এসেছে। সবচেয়ে পরিষ্কার উদাহরণ হলো RustQC, যা 15টি আলাদা quality-control tool একত্র করে একটি program বানিয়েছে। একটি বড় dataset-এ runtime 15 ঘণ্টা 34 মিনিট থেকে 14 মিনিট 54 সেকেন্ডে নেমে এসেছে। বড় biological dataset নিয়ে কাজ করা গবেষকদের জন্য, এই ধরনের হ্রাস বিশ্লেষণ কতবার চালানো হয় এবং experiment কত দ্রুত iterate করে তা উল্লেখযোগ্যভাবে বদলে দিতে পারে।

কিন্তু speed-ই মূল বিষয় নয়। আরও গুরুত্বপূর্ণ প্রশ্ন হলো, পুনর্লিখিত টুলগুলো বৈজ্ঞানিকভাবে অর্থবহ দিক থেকে আসলগুলোর মতো আচরণ করছে কি না। রিপোর্টটি এই validation কাজকে কেন্দ্রীয়, বিকল্প নয়, হিসেবে দেখে।

rustar-aligner-এর ক্ষেত্রে, দলটি yeast cell থেকে নেওয়া 10,000 short sequencing read ব্যবহার করে rewrite-টিকে STAR-এর সঙ্গে তুলনা করে। single-end read-এর জন্য নতুন tool 99.815 শতাংশ ক্ষেত্রে STAR-এর সঙ্গে মিলেছে। paired-end read-এর জন্য এই মিল 99.883 শতাংশে পৌঁছেছে। তুলনাটি genome-এ mapped location-এর মধ্যে সীমাবদ্ধ ছিল না। প্রতিটি read-এর জন্য তৈরি হওয়া কয়েকটি গুরুত্বপূর্ণ output field-ও এতে অন্তর্ভুক্ত ছিল। source text আরও বলে, একটি tool যে read map করতে পারেনি, অন্যটিও সেগুলো map করতে পারেনি।

এগুলো শক্তিশালী compatibility সংখ্যা, তবে AI-উৎপাদিত scientific software-এর মূল সীমাবদ্ধতাও দেখায়। একটি model বিশ্বাসযোগ্য code এমনকি plausible test-ও তৈরি করতে পারে, কিন্তু equivalence কী, সঠিক benchmark কোনটি, edge case কীভাবে দেখা হবে, এবং deviation বৈজ্ঞানিকভাবে গুরুত্বপূর্ণ কি না, তা নির্ধারণ করতে মানুষের প্রয়োজন থেকেই যায়।

বাধা coding থেকে review-এর দিকে সরে যাচ্ছে

এটাই সম্ভবত রিপোর্টের সবচেয়ে গুরুত্বপূর্ণ ইঙ্গিত। coding agent উন্নত হতে থাকলে, গবেষণা সফ্টওয়্যারে সবচেয়ে দুর্লভ সম্পদ raw implementation time আর নাও থাকতে পারে। আসল bottleneck হতে পারে expert verification।

সেই জগতে, labs কেবল সফ্টওয়্যার agent-এর হাতে তুলে দিয়ে ফল মেনে নেয় না। বরং তারা এমন একটি workflow তদারকি করে, যেখানে model দ্রুত candidate implementation তৈরি করে, আর domain expert-রা output যাচাই, আগের আচরণ পুনরুত্পাদন, এবং পুনর্লিখনে কোনো scientific assumption লুকিয়ে ঢুকে যায়নি কি না তা নিশ্চিত করতে সময় দেন। workflow বদলায়, কিন্তু expert oversight-এর প্রয়োজন কমে না।

এটি গবেষণা পরিবেশে বিশেষভাবে প্রাসঙ্গিক, কারণ code correctness সমস্যার মাত্র এক স্তর। একটি refactor syntactically পরিষ্কার, computationally দ্রুত, এবং তবু scientificভাবে ভুল হতে পারে যদি এটি numerical behavior, default parameter, বা hidden assumption বদলে দেয়। তাই রিপোর্টের সতর্কবাণী যে এই সিস্টেমগুলো বিজ্ঞান সঠিক কি না তা বিচার করতে পারে না, সেটি কেবল একটি caveat নয়। এটি তাদের দায়িত্বশীল ব্যবহারের শর্ত।

এটি বিজ্ঞান অবকাঠামোর জন্য কী অর্থ বহন করতে পারে

যদি এই ফলাফলগুলো সাধারণভাবে প্রযোজ্য হয়, তবে coding agent-রা একাডেমিয়ার জন্য মূল্যবান infrastructure tool হয়ে উঠতে পারে। বৈজ্ঞানিক ক্ষেত্রগুলো প্রায়ই এমন সফ্টওয়্যারের ওপর নির্ভর করে, যা উপেক্ষা করা যায় না কিন্তু হাতে ধরে আধুনিকীকরণ করার মতো যথেষ্ট funding নেই। AI সিস্টেমগুলো বিশেষভাবে কার্যকর হতে পারে সেই maintenance gap-এ, যেখানে সমস্যা নতুন বিজ্ঞান উদ্ভাবন নয়, বরং পুরোনো, নাজুক code-কে এমন রূপে অনুবাদ করা, যা চালানো, review করা, এবং বিস্তৃত করা সহজ।

প্রতিশ্রুতি যথেষ্ট বড়: দ্রুত migration, উন্নত performance, পুনরুজ্জীবিত toolchain, এবং কম abandoned codebase। কিন্তু এর বিনিময়ে trust এখনও ধীর উপায়েই তৈরি করতে হবে। বৈজ্ঞানিক সফ্টওয়্যারকে শুধু ভালো পড়ে বা পরিষ্কারভাবে compile হয় বলে গ্রহণ করা যায় না। এটিকে বাস্তব workload-এর বিরুদ্ধে পরীক্ষা করতে হবে এবং বিজ্ঞান ও code দুটোই বোঝেন এমন মানুষের দ্বারা বিচার করতে হবে।

ফলে এই ফিল্ড রিপোর্ট automated discovery-এর গল্পের চেয়ে বেশি শ্রমবণ্টনের গল্প হয়ে ওঠে। AI সফ্টওয়্যার আধুনিকীকরণের আরও কাজ সামলাতে পারে। কিন্তু resulting systems বৈজ্ঞানিক নথির অংশ হওয়ার যোগ্য কি না, তা নির্ধারণের দায় গবেষকদেরই থাকে।

এই নিবন্ধটি The Decoder-এর প্রতিবেদনের ভিত্তিতে। মূল নিবন্ধটি পড়ুন.