একটি ২০২৬ সালের Sonar সমীক্ষা দেখাচ্ছে যে ৮৮% ডেভেলপার মনে করেন AI-জেনারেটেড কোড টেকনিক্যাল ডেট (technical debt) বাড়িয়ে দিচ্ছে, এবং spec-driven development-এর প্রবক্তারা যুক্তি দিচ্ছেন যে একটি সুশৃঙ্খল স্পেসিফিকেশন ধাপ এই বিচ্যুতি রোধ করতে পারে।
কেন এই সমস্যাটি গুরুত্বপূর্ণ
যখন একজন মানুষ একটি অস্পষ্ট টিকিট পান, তখন তারা বিষয়টি পরিষ্কার করার জন্য প্রশ্ন করেন। এর বিপরীতে, একটি AI এজেন্ট তার সম্ভাব্য অনুমানের মাধ্যমে শূন্যস্থানগুলো পূরণ করে এবং এমন কোড প্রদান করে যা দেখতে সঠিক মনে হয়। এই সঠিকতার বিভ্রম অত্যন্ত ব্যয়বহুল: একই Sonar পোল রিপোর্ট করেছে যে অর্ধেকেরও বেশি উত্তরদাতা এমন কোড দেখেছেন যা প্রাথমিক পরীক্ষাগুলো (basic checks) পাস করলেও ভেতরে সূক্ষ্ম ত্রুটি লুকিয়ে রাখে। এই ত্রুটিগুলো টেকনিক্যাল ডেট হিসেবে জমা হতে থাকে, যা পরবর্তীতে রিফ্যাক্টরিং (refactor) করতে বাধ্য করে, ফিচার ডেলিভারি ধীর করে দেয় এবং রক্ষণাবেক্ষণ বাজেট বাড়িয়ে দেয়।
spec-driven development দেখতে কেমন
Spec-driven development (SDD) বর্তমান ধারাটিকে উল্টে দেয়। একটি সংক্ষিপ্ত ইউজার স্টোরি দিয়ে AI মডেলকে প্রম্পট দেওয়ার পরিবর্তে, টিম একটি বিস্তারিত এবং এজেন্ট-এক্সিকিউটেবল (agent-executable) স্পেসিফিকেশন লেখে যা কোডের মতোই একই ভার্সন-কন্ট্রোল সিস্টেমে থাকে। এই স্পেক (spec) হয়ে ওঠে তথ্যের একমাত্র উৎস (single source of truth)—এটি উদ্দেশ্য (intent), এজ কেস (edge cases), পারফরম্যান্সের প্রত্যাশা এবং AI মডেলকে অবশ্যই মেনে চলতে হবে এমন যেকোনো সীমাবদ্ধতা রেকর্ড করে।
এই প্রক্রিয়াটি মানুষের ডিজাইন করা কাজকে প্রতিস্থাপন করে না; বরং এটি সেটিকে কোড আকারে বা সুসংগঠিতভাবে উপস্থাপন করে। সিদ্ধান্তগুলোকে একজন ডেভেলপারের স্মৃতি থেকে একটি সুনির্দিষ্ট নথিতে নিয়ে আসার মাধ্যমে, মানুষ এবং ভবিষ্যৎ AI এজেন্ট উভয়ই ট্র্যাক করতে পারে কেন একটি কোড নির্দিষ্টভাবে কাজ করছে। একটি স্পেক তৈরি করতে শুরুতে কিছুটা শ্রম দিতে হয়, কিন্তু পরবর্তীতে অস্পষ্ট AI আউটপুট ডিবাগ করতে অনেক বেশি খরচ হয়।
কাজের ধারা (workflow) পরিবর্তন করা
Product backlog – আইটেমগুলো সংক্ষিপ্ত রাখুন, শুধুমাত্র উদ্দেশ্য এবং উচ্চ-স্তরের গ্রহণযোগ্যতার মানদণ্ড (acceptance criteria) অন্তর্ভুক্ত করুন। এই তালিকাটি প্রায়োরিটি নির্ধারণে সহায়তা করবে।
Sprint planning – টিমগুলো সামগ্রিক লক্ষ্য নিয়ে আলোচনা করে এবং একটি Sprint Goal-এর ওপর একমত হয়, তবে স্পেক প্রস্তুত না হওয়া পর্যন্ত তারা বিস্তারিত ইমপ্লিমেন্টেশন স্থগিত রাখে।
During the sprint – যে ব্যক্তি কাজটি নিচ্ছেন তিনি একটি সুনির্দিষ্ট এবং মেশিন-রিডেবল স্পেক লেখেন। স্পেকটিতে ইনপুট ফরম্যাট, প্রত্যাশিত আউটপুট, এরর হ্যান্ডলিং এবং যেকোনো নন-ফাংশনাল রিকোয়ারমেন্ট তালিকাভুক্ত থাকে। যেহেতু স্পেকটি ভার্সন-কন্ট্রোল করা হয়, তাই রিভিউয়াররা কোডের মতোই এতে মন্তব্য করতে পারেন, পরিবর্তনের পরামর্শ দিতে পারেন এবং পরিবর্তন অনুমোদন করতে পারেন।
Definition of Done – কোয়ালিটি গেটে “Spec reviewed and approved” যোগ করুন। স্পেকটি ইমপ্লিমেন্টেশনের মতো একই রিভিউ স্ট্যান্ডার্ড পাস না করা পর্যন্ত কোনো কোডই সম্পন্ন বলে গণ্য হবে না।
Kanban adaptation – দুটি নতুন কলাম যোগ করুন: “Spec Drafted” এবং “Spec Approved।” এখন কাজের ধাপগুলো হবে: backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done। এই ভিজ্যুয়াল পরিবর্তনটি আগে অদৃশ্য থাকা সমন্বয় ধাপটিকে স্পষ্ট করে তোলে।
যেসব টুল ইতিমধ্যে স্পেক প্রয়োগ করছে
GitHub Spec Kit এবং AWS Kiro-এর মতো প্ল্যাটফর্মগুলো এমন গেট যুক্ত করেছে যা AI কোড জেনারেশন শুরু করার আগে একটি রিকোয়ারমেন্ট ডকুমেন্ট দাবি করে। এগুলো AI মডেলকে প্রতিস্থাপন করে না; বরং এগুলো আক্ষরিক অর্থে কাজ করা এজেন্টদের মানুষের উদ্দেশ্যের সাথে সামঞ্জস্যপূর্ণ করে তোলে। স্পেককে একটি পূর্বশর্ত হিসেবে তৈরি করার মাধ্যমে, এই টুলগুলো বিদ্যমান CI/CD পাইপলাইন নষ্ট না করেই এই পরিবর্তনটি স্বয়ংক্রিয়ভাবে সম্পন্ন করে।
সম্ভাব্য আপত্তি
সমালোচকরা বলেন যে একটি স্পেক লেখা ইতিমধ্যে দ্রুতগতির অ্যাজাইল (agile) কাজের ছন্দে বাধা সৃষ্টি করে। এর বিপরীতে যুক্তি হলো: একটি স্পেক তৈরি করতে যে সময় ব্যয় হয়, তা সাধারণত একটি অস্পষ্ট প্রম্পট থেকে তৈরি হওয়া AI-জেনারেটেড কোড ডিবাগ করতে ব্যয় হওয়া সময়ের তুলনায় অনেক কম।
আরেকটি উদ্বেগ হলো রিকোয়ারমেন্ট পরিবর্তনের সাথে সাথে স্পেসিফিকেশনগুলো পুরনো হয়ে যেতে পারে। ভার্সন-কন্ট্রোল ইন্টিগ্রেশন এই সমস্যার সমাধান করে: স্পেকে যেকোনো পরিবর্তন একটি নতুন কমিট তৈরি করে, একটি রিভিউ ট্রিগার করে এবং টিমকে সংশ্লিষ্ট কোডটি পুনরায় মূল্যায়ন করতে বাধ্য করে। বাস্তবে, স্পেককে কোডের মতো বিবেচনা করলে ডকুমেন্টেশন সবসময় আপ-টু-ডেট থাকে।
পরবর্তী দিকে যা লক্ষ্য রাখতে হবে
এর ব্যবহার এখনও প্রাথমিক পর্যায়ে রয়েছে, তবে এর গতি দৃশ্যমান। AI কোড জেনারেটরগুলো যত বেশি সক্ষম হবে, সুনির্দিষ্ট এবং মেশিন-রিডেবল উদ্দেশ্যের প্রয়োজনীয়তা তত বাড়বে।
সারকথা: অস্পষ্ট প্রম্পটগুলোকে সুনির্দিষ্ট এবং রিভিউ করা স্পেসিফিকেশনে রূপান্তর করা একটি অতিরিক্ত ধাপ বলে মনে হতে পারে, কিন্তু এটি অনুমানের পরিবর্তে দায়বদ্ধ সিদ্ধান্ত গ্রহণে সহায়তা করে।