কাজের অভিজ্ঞতা
AI-first ডেলিভারির গোটা ব্যবস্থা গড়া
কাজের চাহিদা আর ঠিক প্রেক্ষাপট থেকে সীমা মেনে এজেন্টের কাজ, ব্রাউজারে প্রমাণ আর পরের বদলে কাজে লাগবে এমন রিলিজের বিবরণ পর্যন্ত—ঝুঁকি বুঝে গোটা পথ তৈরি করার কাজ।
- আমার ভূমিকা
- Principal Engineer ও ডেলিভারি ব্যবস্থার নকশা
- কাজের প্রেক্ষাপট
- বহু ফিচারের SaaS ফ্রন্টএন্ডে কাজের ধরন থেকে সংবেদনশীল পরিচয় বাদ দিয়ে লেখা। প্রোডাক্টের চাহিদা, ডিজাইন, shared component, API-র চুক্তি, একাধিক রিপোজিটরি আর রিলিজ যাচাই এই কাজের মধ্যে।
- ব্যবহৃত প্রযুক্তি
- Angular, TypeScript, Agent Workflows, Figma, Atlassian, Browser Automation, Focused Testing
সমস্যাটা কী ছিল
দল যত দ্রুত দায়িত্বের ব্যবস্থা বাড়াতে পারে, AI তার চেয়েও দ্রুত কোড তৈরির পরিমাণ বাড়াতে পারে। জটিল প্রোডাক্ট রিপোজিটরিতে এক জায়গায় ঠিক ফল হলেই চলে না। চাহিদা বদলায়, প্রেক্ষাপটে বিরোধ থাকে, একাধিক surface একই আচরণ ভাগ করে। দেখতে ভালো diff-এও permission, responsive state বা রিলিজের শর্ত হারিয়ে যেতে পারে।
যে সীমাগুলো মাথায় ছিল
- কাজের চাহিদা বা চালু ব্যবহারকারীর আচরণ চুপচাপ নষ্ট হওয়া চলবে না
- প্রোডাক্ট, ডিজাইন, API আর রিপোজিটরির প্রেক্ষাপট আলাদা গতিতে বদলাচ্ছিল
- shared route, component আর schema-য় একসঙ্গে কাজের জন্য স্পষ্ট দায়িত্ব দরকার ছিল
- একটা build পাসের বদলে বদলের ঝুঁকির সঙ্গে মেলা প্রমাণ দরকার ছিল
- পাবলিক বিবরণে সংবেদনশীল পরিচয় আর বানানো performance-এর দাবি রাখা যাবে না
যেভাবে এগিয়েছি
- কে কাজ করবেন, কী আচরণ, কী সীমা, কী অক্ষুণ্ণ থাকবে, কী করব না আর গ্রহণের প্রমাণ কী—এসব দিয়ে উদ্দেশ্যকে ছোট requirement contract করেছি।
- প্রতিটা কাজে এখনকার সবচেয়ে ছোট দরকারি context packet পাঠিয়েছি। প্রোডাক্ট বা রিপোজিটরির জরুরি তথ্যের জন্য নির্দিষ্ট দায়িত্ব রেখেছি।
- রক্ষিত জায়গা, নির্ভরতা, handoff আর কখন থামবে বলে এজেন্টের কাজকে সীমানা দিয়েছি।
- নির্দিষ্ট test, build, ব্রাউজারের state, বিভিন্ন মাপের screenshot, console, রিভিউ আর রিলিজের প্রমাণ একসঙ্গে যাচাইয়ের সিঁড়িতে রেখেছি।
- মেনে নেওয়া সিদ্ধান্ত টেকসই নির্দেশে ফেরত দিয়েছি। সাময়িক debugging-এর প্রমাণ দীর্ঘমেয়াদি প্রেক্ষাপট থেকে আলাদা রেখেছি।
আর্কিটেকচারের সিদ্ধান্ত
- প্রোডাক্টের উদ্দেশ্য, ইমপ্লিমেন্টেশনের প্রমাণ আর টেকসই স্মৃতি আলাদা স্তরে, আলাদা দায়িত্ব আর আয়ু নিয়ে রেখেছি।
- চাহিদার পরিচয় দিয়ে context, কাজের সীমানা, ইমপ্লিমেন্টেশন, যাচাই আর রিলিজের প্রমাণ জুড়েছি।
- দায়িত্ব স্বাধীন হলেই parallel কাজ। একই নিয়ন্ত্রণের জায়গার বদল ইচ্ছে করে ক্রমে করেছি।
- সব বদলকে সমান ঝুঁকির না ধরে প্রভাব কতটা ছড়ায়, তা দিয়ে যাচাই বাড়িয়েছি।
যেখানে ছাড় দিতে হয়েছে
- কাজ শুরুর আগে কিছু কাঠামো লাগে। ছোট কাজে হালকা চুক্তি, বেশি ঝুঁকির কাজে গভীর যোগসূত্র রাখি।
- সব কাজে একাধিক এজেন্ট লাভ দেয় না। কিছু আর্কিটেকচার আর প্রোডাক্টের সিদ্ধান্তে আগে মূল তথ্য স্থির হলে কাজ দ্রুত হয়।
- অটোমেটেড প্রমাণ বারবার হাতে করা কাজ কমায়। কিন্তু দ্বিধা, প্রোডাক্টের বিচার, ছাড় দেওয়া আর রিলিজ মেনে নেওয়ার দায় মানুষেরই।
কী বদল এসেছে
- প্রতিটা জরুরি দাবি যে চাহিদার পক্ষে, তার সঙ্গে ধরে যাওয়া যায় এমন প্রমাণ থাকে।
- প্রেক্ষাপটের বিরোধ আর না-বলা state আত্মবিশ্বাসী অনুমানের বদলে স্পষ্ট প্রশ্ন হয়।
- নির্দিষ্ট ফিচার থেকে shared component, একাধিক রিপোজিটরি আর দলের নিয়ম পর্যন্ত একই চক্র বাড়ানো যায়।
- চাহিদা বদলালে আগের অক্ষুণ্ণ শর্ত না ফেলে দরকারি ইমপ্লিমেন্টেশন আর প্রমাণ নতুন করা যায়।
যা শিখেছি
- প্রথম ইমপ্লিমেন্টেশনে গতি দেখা যায়। পরের যুক্তিসঙ্গত বদলে ব্যবস্থার মান বোঝা যায়।
- বারবার করার কাজ অটোমেশন নিক, আর বিচারের জায়গায় মানুষ থাকুন—এভাবেই AI-first ইঞ্জিনিয়ারিং বেশি কাজে লাগে।
- diff একটা প্রস্তাব। প্রোডাক্টের শর্ত এখনও কেন ঠিক আছে, ব্যবস্থা সেটা বলতে পারলে তবেই শেষের দিকে যাওয়া যায়।