বছরের পর বছর ধরে, কৃত্রিম বুদ্ধিমত্তা (AI) এডিটরে আপনার পাশে বসে পরবর্তী অংশটি কী হতে পারে তা অনুমান করত। আপনি একটি লাইন লিখতেন; এটি তার পরের লাইনটি সাজেস্ট করত। আর্কিটেকচার, ডিবাগিং এবং সিনট্যাক্সের নিয়ন্ত্রণ তখনও আপনার হাতেই ছিল। সেই ব্যবস্থা এখন শেষ।
আমরা এখন Intent-Driven Development-এর দিকে এগিয়ে যাচ্ছি। আপনি লুপ (loops) এবং কন্ডিশনাল (conditionals) টাইপ করা বন্ধ করে দেবেন। পরিবর্তে, আপনি আপনার প্রয়োজনীয় ফলাফলটি বর্ণনা করবেন। একটি এজেন্ট সেই লক্ষ্যটি গ্রহণ করবে, ধাপগুলো পরিকল্পনা করবে, কোড লিখবে, টেস্ট চালাবে এবং আপনি ফলাফল দেখার আগেই নিজের ভুলগুলো সংশোধন করে নেবে। কিবোর্ড আর প্রাথমিক হাতিয়ার থাকবে না। স্পষ্ট চিন্তাভাবনাই হবে মূল হাতিয়ার।
লাইন-বাই-লাইন কোডিংয়ের অবসান
পুরনো কাজের পদ্ধতিতে আপনাকে প্রতিটি উদ্দেশ্যকে একটি নির্দিষ্ট ভাষায় রূপান্তর করতে হতো যা একটি কম্পাইলার বুঝতে পারে। আপনি ব্যবসার প্রয়োজনীয়তাগুলো মাথায় রাখতেন, তারপর সেগুলোকে ম্যানুয়ালি ফাংশন, ইমপোর্ট, এরর হ্যান্ডলিং এবং টেস্ট কেসে ভাগ করতেন। Intent-Driven Development সেই ট্রান্সলেশন লেয়ার বা রূপান্তরের স্তরটিকে বিলুপ্ত করে দেয়।
ধরুন, আপনাকে একটি পেমেন্ট webhook ইন্টিগ্রেট করতে হবে। আগে আপনাকে রুট হ্যান্ডলার লিখতে হতো, পেলোড পার্স (parse) করতে হতো, সিগনেচার ভ্যালিডেট করতে হতো, একটি ট্রানজ্যাকশনের মধ্যে ডাটাবেস আপডেট করতে হতো এবং একটি রিসিট ইমেইল কিউ (queue) করতে হতো। এখন আপনি শুধু প্রয়োজনীয়তাটি বর্ণনা করবেন: “ইনকামিং Stripe webhook ভ্যালিডেট করো, ইভেন্টটি idempotently রেকর্ড করো এবং রিসিট ফ্লো ট্রিগার করো। যদি ডাটাবেস রাইট ব্যর্থ হয়, তবে রোলব্যাক করো।” এজেন্ট হ্যান্ডলারটি লিখবে, পার্সিং স্ট্র্যাটেজি নির্বাচন করবে, রিট্রাই লজিক তৈরি করবে এবং টেস্ট জেনারেট করবে। আপনার ভূমিকা এখন লেখক থেকে পরিচালকের (director) হয়ে যাবে।
এটি কেবল তখনই কাজ করে কারণ এজেন্ট শুধু কোড জেনারেশনের মধ্যেই থেমে থাকে না। এটি একটি লুপে প্রবেশ করে।
এজেন্টের লুপের ভেতরে
মূল কাজ এখন আর মানুষের টাইপিং বা ম্যানুয়াল ডিবাগিং নয়। এটি জেনারেশন এবং ভ্যালিডেশনের মধ্যে একটি নিবিড় চক্র। এজেন্ট কোড তৈরি করে, আপনার টেস্ট সুইটের বিপরীতে তা এক্সিকিউট করে, আউটপুট পড়ে এবং নিজেই ব্যর্থতাগুলো সংশোধন করে। একটি মিসিং ইমপোর্ট, টাইপ মিসম্যাচ বা ফেইলিং অ্যাসারশন — এজেন্ট স্ট্যাক ট্রেস দেখে ফাইলটি এডিট করে এবং পুনরায় টেস্ট রান করে। আপনি সেই লুপের ভেতরে থাকেন না। এই চক্রটি মেশিনের গতিতে চলে।
আপনি তখনই হস্তক্ষেপ করেন যখন লুপটি নিজেই ভেঙে পড়ে। হতে পারে এজেন্ট দুটি ডিপেন্ডেন্সির মধ্যে দ্বন্দ্ব মেটাতে পারছে না, অথবা এটি এমন কোড তৈরি করছে যা ইউনিট টেস্ট পাস করলেও উচ্চ-স্তরের কোনো বিজনেস রুল লঙ্ঘন করছে। সেই সীমানাগুলোতেই মানুষের বিচারবুদ্ধির প্রয়োজন হয়।
আপনার আসল কাজ: কনস্ট্রেইন্ট ডিজাইনার এবং এজ-কেস হান্টার
মেশিন যদি ফাংশনগুলো লিখে ফেলে, তবে আপনার জন্য কী বাকি থাকে? দুটি জিনিস, এবং সেগুলো সিনট্যাক্স টাইপ করার চেয়েও কঠিন।
প্রথমত, আপনি সেই কনস্ট্রেইন্ট বা সীমাবদ্ধতাগুলো লিখবেন যা এজেন্টকে সঠিক পথে রাখে। এজেন্টের ব্যাপক জ্ঞান থাকলেও আপনার নির্দিষ্ট এনভায়রনমেন্ট সম্পর্কে তার কোনো ধারণা নেই। আপনাকে তাকে বলতে হবে: “শুধুমাত্র ইন্টারনাল বিলিং API ব্যবহার করো, কখনোই র (raw) কার্ড টোকেন লগ করো না এবং রেসপন্স ল্যাটেন্সি ২০০ মিলিসেকেন্ডের নিচে রাখো।” এই সীমানাগুলো কেবল সাধারণ প্রম্পট নয়; এগুলো হলো স্পেসিফিকেশন যা সাফল্য বা ব্যর্থতা নির্ধারণ করে।
দ্বিতীয়ত, আপনি সেই ১০ শতাংশ কেসগুলো ধরবেন যেখানে এজেন্ট ব্যর্থ হয়। এজেন্ট সাধারণ পথগুলো খুব ভালোভাবে সামলাতে পারে। কিন্তু সূক্ষ্ম রেস কন্ডিশন (race conditions), অস্পষ্ট বিজনেস লজিকের এজ-কেস এবং তাদের ট্রেনিং ডেটাতে থাকা সিকিউরিটি অ্যাজাম্পশনগুলোর ক্ষেত্রে তারা হোঁচট খায়। আপনার দক্ষতা প্রকাশ পায় যখন আপনি ওয়েবহুক হ্যান্ডলার এবং রিফান্ড ক্রন জবের (cron job) মধ্যে রেস স্পট করতে পারেন, অথবা বুঝতে পারেন যে জেনারেট করা রিট্রাই লজিকটি চার্জ ডুপ্লিকেট করতে পারে। মেশিন সাধারণ সমস্যা সমাধান করে, আর আপনি ধরেন বিপজ্জনক ব্যতিক্রমগুলো (exceptions)।
কোড রিভিউয়ের পরিবর্তে ভেরিফিকেশন হারনেস ব্যবহার করুন
যখন একটি এজেন্ট রাতারাতি ৫০টি ফাইল তৈরি করতে পারে, তখন আপনি কেবল ডিফ (diff) দেখে সেগুলো "ঠিক আছে কি না" তা যাচাই করতে পারবেন না। কাজের বিশাল পরিমাণের কারণে মানুষের পক্ষে তা দেখা অসম্ভব হয়ে পড়ে। আপনার এমন একটি হারনেস প্রয়োজন যা কোড আপনার কাছে পৌঁছানোর আগেই ভুলগুলো ধরে ফেলবে।
এই হারনেসটি তিনটি স্তম্ভের ওপর দাঁড়িয়ে।
Durable execution. এজেন্ট টাস্কগুলো প্রায়শই একটি সিঙ্গেল রিকোয়েস্ট টাইমআউটের চেয়ে বেশি সময় ধরে চলে। যদি সাময়িক নেটওয়ার্ক সমস্যার কারণে কোনো ধাপ ব্যর্থ হয়, তবে হারনেসটি স্টেট নষ্ট না করেই কাজ থামিয়ে দেয়, পুনরায় চেষ্টা করে এবং আবার শুরু করে। এতে কাজের ধারাবাহিকতা বজায় থাকে।
Structured outputs. এজেন্ট একটি সঠিক কনফিগারেশন ফাইল দেবে—এমনটি আশা না করে, আপনি আগে থেকেই কন্ট্রাক্ট বা নিয়মটি নির্ধারণ করে দেবেন। JSON Schema-এর মতো টুলগুলো তাৎক্ষণিকভাবে আউটপুট ভ্যালিডেট করে। যদি এজেন্ট কোনো প্রয়োজনীয় ফিল্ড বাদ দেয় বা ভুল ডেটা টাইপ ব্যবহার করে, তবে কোডটি আপনার রিপোজিটরিতে পৌঁছানোর আগেই হারনেস সেটি প্রত্যাখ্যান করবে।
Dynamic guardrails. এজেন্টের সিক্রেট পড়ার বা প্রোডাকশন ডাটাবেসে লেখার অবাধ স্বাধীনতা থাকা উচিত নয়। হারনেসটি ডায়নামিকভাবে পারমিশন নিয়ন্ত্রণ করে এবং এজেন্টকে স্যান্ডবক্স (sandboxing) করে রাখে, যাতে এটি কেবল নির্দিষ্ট টেস্ট ডাটাবেস এবং ইন্টারনাল এন্ডপয়েন্টগুলো ব্যবহার করতে পারে। আপনি প্রতিটি লাইন রিভিউ করছেন না; আপনি এজেন্টের চারপাশের সুরক্ষা বেষ্টনীটি অডিট করছেন।
যখন কোড কাজ করে কিন্তু প্রোডাক্ট ব্যর্থ হয়
এখানেই হলো প্যারাডক্স। টেস্ট হারনেস খারাপ কোড ধরতে পারে, কিন্তু এটি খারাপ উদ্দেশ্য (intent) ধরতে পারে না।
আপনার স্পেসিফিকেশন যদি বলে, “প্রতিটি নতুন ব্যবহারকারীকে একটি ওয়েলকাম ইমেল পাঠান,” তবে এজেন্ট একটি পরিচ্ছন্ন এবং পরীক্ষিত কোড লিখবে যা সেই ইমেলটি পাঠাবে। কিন্তু এটি জানবে না যে আপনি আসলে বোঝাতে চেয়েছিলেন, “শুধুমাত্র তখনই ওয়েলকাম ইমেল পাঠান যদি ব্যবহারকারী তার ঠিকানা ভেরিফাই করেন, মার্কেটিংয়ের জন্য সম্মতি দেন এবং তাদের স্থানীয় টাইমজোনে ব্যবসায়িক সময়ের মধ্যে সাইন আপ করেন।” কোডটি প্রযুক্তিগতভাবে ত্রুটিহীন কিন্তু বাণিজ্যিকভাবে বিপজ্জনক।
Intent-Driven Development-এর আসল ঝুঁকি হলো অস্পষ্ট স্পেসিফিকেশন। অস্পষ্ট উদ্দেশ্য এমন সফটওয়্যার তৈরি করে যা ভুল সমস্যাকে অত্যন্ত নিখুঁতভাবে সমাধান করে। এই কারণেই আপনাকে আপনার স্পেসিফিকেশনগুলোকে প্রকৃত সম্পদ হিসেবে বিবেচনা করতে হবে। এগুলোর ভার্সন (version) তৈরি করুন। স্টেকহোল্ডারদের সাথে এগুলো রিভিউ করুন। এজেন্ট কাজ শুরু করার আগেই প্রকৃত ওয়ার্কফ্লোর সাথে এগুলো যাচাই করে নিন। চ্যাট বক্সে লিখে দেওয়া একটি প্রম্পট কোনো স্পেসিফিকেশন নয়; এটি একটি ঝুঁকি।
ইঞ্জিনিয়ারিং বিচারবুদ্ধি এখন উচ্চতর স্তরে স্থানান্তরিত হচ্ছে
ইঞ্জিনিয়ারিং বিচারবুদ্ধি হারিয়ে যাচ্ছে না; এটি উচ্চতর স্তরে স্থানান্তরিত হচ্ছে।
আপনি এখন আর একটি ম্যাপ কীভাবে ইটারেট করতে হবে বা একটি ক্লাস হায়ারার্কি কীভাবে গঠন করতে হবে, তা নিয়ে মানসিক শক্তি ব্যয় করেন না। বরং আপনি এখন ব্যয় করেন সিস্টেমটি ব্যর্থতার সময় কী করবে, কোন ডেটা কখনোই প্রকাশ করা উচিত নয় এবং ডিস্ট্রিবিউটেড সার্ভিসেসের ক্ষেত্রে কোন ইনভ্যারিয়েন্টস (invariants) বজায় রাখতে হবে, তা নিয়ে। কোডিংয়ের কারুকার্য এখন রিকোয়ারমেন্টস বা প্রয়োজনীয়তা নির্ধারণের কারুকার্যে পরিণত হচ্ছে।
এর মানে হলো, আপনার স্পেসিফিকেশনে এখন সেই একই নির্ভুলতা প্রয়োজন যা আপনি একসময় আপনার কোডের ক্ষেত্রে প্রয়োগ করতেন। আপনার কনস্ট্রেইন্টসগুলো (constraints) সুনির্দিষ্টভাবে উল্লেখ করুন। ফেইলর মোডগুলো (failure modes) স্পষ্টভাবে সংজ্ঞায়িত করুন। বিজনেস রুলসগুলো ততটাই স্পষ্টভাবে বলুন যতটা স্পষ্টভাবে আপনি একসময় আপনার টাইপস (types) ঘোষণা করতেন। এজেন্ট ইমপ্লিমেন্টেশনের কাজ সামলাবে। আপনাকে নিশ্চিত করতে হবে যে সেই ইমপ্লিমেন্টেশনটি তৈরির যোগ্য।
আপনার কোয়ালিটি বার (quality bar) পুল রিকোয়েস্ট থেকে সরিয়ে প্রম্পটে নিয়ে আসুন। প্রথমে হারনেস তৈরি করুন। দ্বিতীয়ত, স্পেসিফিকেশন লিখুন। তারপর মেশিনকে সিনট্যাক্স সামলাতে দিন, আর আপনি মনোযোগ দিন সমস্যাটি সঠিকভাবে সংজ্ঞায়িত করা হয়েছে কিনা এবং সীমানাগুলো নিরাপদে নির্ধারণ করা হয়েছে কিনা তার ওপর।
আপনি যদি এই পরিবর্তনের পেছনের ধারণাগুলো আরও গভীরভাবে অন্বেষণ করতে চান, তবে Intent-Driven Development সংক্রান্ত মূল আলোচনাটি এখানে পাওয়া যাচ্ছে। AI-native ইঞ্জিনিয়ারিং সংক্রান্ত চলমান আলোচনার জন্য আপনি GyaanSetu কমিউনিটিতে যোগ দিতে পারেন।