এখনকার ভাবনা · ছয় পর্বে
6টির মধ্যে পর্ব 6 AI-কে নিয়ে ডেভেলপমেন্টের গোটা ব্যবস্থা গড়া
আসল পরীক্ষা পরের বদলটা সামলাতে পারা
প্রথম ইমপ্লিমেন্টেশন গতি দেখাতে পারে। চাহিদা আবার বদলালে বোঝা যায়, আগের কথা না ভুলে ব্যবস্থা মানিয়ে নিতে পারে কি না।
প্রথম ইমপ্লিমেন্টেশনে গতি দেখা যায়। দ্বিতীয় বদলে বোঝা যায় ব্যবস্থাটা কেমন।
প্রথম সংস্করণ ভুল ধারণা দিতে পারে
প্রথম ইমপ্লিমেন্টেশনের পরিবেশ অনেক সময় অস্বাভাবিক রকম সুবিধের। ডিজাইন নতুন, যে কথাবার্তা থেকে চাহিদা এসেছে তা কাছেই আছে, কোডে এখনও টানাটানির দায়িত্ব জমেনি। এজেন্ট দ্রুত চলে, কারণ ওই সময় কাজটার চারপাশের দুনিয়া ছোট।
তাই প্রথম সংস্করণের গতি দিয়ে AI-first ব্যবস্থা বিচার করা দুর্বল মাপ। প্রোডাক্ট মত বদলালে বেশি বোঝা যায়। নতুন role আসে। API একটা status-কে তিনটে করে। মোবাইলের workflow-তে অন্য interaction লাগে। shared component-এর দ্বিতীয় consumer-এর যুক্তিসঙ্গত ব্যতিক্রম লাগে।
প্রশ্ন তখন শুধু কোড তৈরি করতে পারে কি না নয়। কী বদলাল চিনতে পারে? যা বদলায়নি তা রাখতে পারে? দরকারি ইমপ্লিমেন্টেশন আর প্রমাণ নতুন করতে পারে? আর রিপোজিটরিটা আগের চেয়ে একটু বেশি বোঝার মতো রেখে যেতে পারে?
কয়েকটা boolean-এ আর ধরল না কাজটা
পরিচয় বাদ দেওয়া এক review workflow ধরা যাক। শুরুতে pending, approved আর rejected ছিল। প্রথম স্ক্রিনে দুটো button আর একটা status label লাগত বলে ইমপ্লিমেন্টেশন কয়েকটা boolean-এ আচরণটা নামিয়ে এনেছিল। সে রিলিজে কাজও হল।
দ্বিতীয় চাহিদায় partial approval, আরও তথ্য চাওয়ার state, মেয়াদ ফুরোনো আর role অনুযায়ী action এল। তৈরি বদলে component-এ আরও flag আর template-এ আরও condition যোগ হল। কিছু মিশ্রণে approved label-এর পাশেই আরও তথ্য জমা দিতে বলা সম্ভব হয়ে গেল। প্রথম কাজটা workflow-র বদলে screenshot-টাই ধরে বানানো হয়েছিল।
এ বদলে invariant আর change map কাজে লাগাই। পুরনো-নতুন চাহিদা, যোগ হওয়া state আর transition, কোন নিশ্চয়তা থাকতে হবে, কোন consumer-এ প্রভাব আর কোন প্রমাণ আবার চাই—লেখা থাকে। এই উদাহরণে মানচিত্রটা দেখাত, বদলের একক হওয়া উচিত state model, আগে লেখা boolean-গুলো নয়।
যা অটোমেট করি
চাহিদার সংস্করণের তুলনা আর কোথায় প্রভাব পড়তে পারে খোঁজা অটোমেট করি। বদলানো আচরণ চেনা, consumer খোঁজা, test আর নথি বার করা, কোন context packet, ইমপ্লিমেন্টেশনের অংশ আর যাচাইয়ের পথ বদলাবে তা সাজেস্ট করা যায়।
তারপর এজেন্ট স্পষ্ট state model নতুন করতে, consumer migrate করতে, transition-এর test বানাতে বা বদলাতে, আর পুরনো-নতুন আচরণ ব্রাউজারে চালাতে পারে। আগের রিলিজের প্রমাণও কাজে লাগে। কারণ দ্বিতীয় বদলে কোন নিশ্চয়তা রাখতে হবে বা ইচ্ছে করে বদলাতে হবে, সেটা তাতে আছে।
যাচাইয়ের পরে মেনে নেওয়া সিদ্ধান্ত দিয়ে টেকসই context নতুন করা যায়। সাময়িক debugging-এর প্রমাণ সাময়িকই থাকবে। নতুন প্রোডাক্টের সত্যি তথ্য তার দায়িত্ব নেওয়া উৎসে যাবে। পরের কাজকে যেন বিরোধী ইতিহাসের স্তূপ থেকে সব বোঝা আবার শুরু করতে না হয়।
যে সিদ্ধান্ত মানুষেরই থাকবে
কোন পুরনো আচরণ অক্ষুণ্ণ শর্ত আর কোনটা ইমপ্লিমেন্টেশনের ঘটনাচক্র, মানুষ ঠিক করবেন। পুরনো ব্যবহারের সঙ্গে মিল রাখতে হবে কি না, migration সঙ্গে সঙ্গে করা যায় কি না, সাময়িক দুটো আচরণ রাখার লাভ জটিলতার দাম পোষায় কি না—সেটাও।
পুরনো সীমানা কখন আর বদল সামলাতে পারছে না, মানুষকে বুঝতে হবে। এজেন্ট দেখাতে পারে কয়েকটা consumer-এ condition ছড়াচ্ছে। কিন্তু state machine আনব, দায়িত্ব ভাগ করব, API-র চুক্তি বদলাব, না ছোট একটা স্থানীয় আপস মেনে নেব—এটা আর্কিটেকচারের বিচার।
কঠিন সিদ্ধান্ত অনেক সময় নতুন চাহিদা কীভাবে বানাব সেটা নয়। ভবিষ্যতে কোন ধরনের কাজ সহজ করতে চাই, সেটা। প্রোডাক্টের দিক, দলের ক্ষমতা আর ভুল হলে খরচ—এসবের ওপর সিদ্ধান্ত দাঁড়ায়।
বদল বোঝা যাক, কল্পনার ভবিষ্যৎ বানাতে না যাই
এখানেও ছাড় দেওয়ার দিক আছে। পরের সব সম্ভাব্য বদলের জন্য আগে থেকে নকশা করলে প্রমাণ ছাড়া abstraction বাড়ে। তিন-state ফিচারের জন্য generic workflow engine পুরনো boolean-এর চেয়েও দামি আর দুর্বোধ্য হতে পারে। আন্দাজের নমনীয়তাকে আর্কিটেকচার সাজিয়ে চাই না।
চাই প্রথম সংস্করণে অনুমানগুলো দেখা যাক। state-এর নাম থাকুক। দায়িত্ব স্পষ্ট হোক। চাহিদা আর প্রমাণ ধরে যাওয়া যাক। পরের বদল এলে চাপটা কোথায় তা ব্যবস্থা দেখাক, অসংলগ্ন ফাইলে ছড়িয়ে না দিক।
আমি scale আর মানিয়ে নেওয়া এভাবেই মাপি। এজেন্ট এক বসায় কত কোড লিখল তা দিয়ে নয়। প্রোডাক্ট আগে কী প্রতিশ্রুতি দিয়েছিল না ভুলে, পরের যুক্তিসঙ্গত বদলটা গোটা ব্যবস্থা কতটা শান্তভাবে সামলাল, সেটা দিয়ে।