ইঞ্জিনিয়ারিং ম্যানেজার
AI টুলগুলি দ্রুত আধুনিক সফ্টওয়্যার ইঞ্জিনিয়ারিংকে নতুন আকার দিচ্ছে, এই প্যানেলটি অন্বেষণ করবে যে কীভাবে ডেভেলপাররা তাদের দৈনন্দিন ওয়ার্কফ্লোতে AI-সহায়তা কোডিং, অটোমেটেড এজেন্ট এবং বিশেষ ডেভেলপার টুলিং ব্যবহার করছে। আমাদের লক্ষ্য হল ব্যবহারিক অ্যাপ্লিকেশন হাইলাইট করা, পরিমাপযোগ্য প্রোডাক্টিভিটি উন্নতি নিয়ে আলোচনা করা এবং স্কেলে AI ইন্টিগ্রেট করার সময় ইঞ্জিনিয়ারিং টিম যে চ্যালেঞ্জগুলির মুখোমুখি হয় তা স্পষ্টভাবে সমাধান করা।
সঞ্চালনায়: বেন ট্রেনগ্রোভ, Google Developer Relations Engineer
ট্রান্সস্ক্রিপ্ট করা
হ্যালো, সবাইকে।
আপনি এই সপ্তাহে বা গত দুই দিনে অনেক Android Googler-এর থেকে শুনেছেন।
তাই, আমরা ভেবেছিলাম যে বাইরে থেকে, কমিউনিটি থেকে, Android Dev কমিউনিটি থেকে কিছু লোকের কথা শুনে কনফারেন্স শেষ করা সত্যিই ভালো হবে।
আমরা এজেন্টিক কোডিং এবং বাস্তব জগতে এর প্রভাব সম্পর্কে কথা বলতে যাচ্ছি।
তাই আমরা নিজেদের পরিচয় দিয়ে শুরু করব।
আমার নাম বেন, Android DevRel.
এই কনফারেন্সে আপনি আমার কথা একবার শুনেছেন, তবে প্যানেলের বাকিদের কথা শোনা যাক।
হ্যালো বন্ধুরা।
আমার নাম বিনয় এবং আমি Databricks-এ AI টুলিং সংক্রান্ত প্রচেষ্টায় সহায়তা করি।
এখানে আসতে পেরে আনন্দিত।
হ্যালো, আমি লুইস আর্টোলা।
আমি Google Maps-এর জন্য কাজ করি।
আমি এমন টিমকে নেতৃত্ব দিই যারা এজেন্টিক অভিজ্ঞতা তৈরি করতে এবং সফ্টওয়্যার ডেভেলপমেন্ট সাইকেল উন্নত করতে AI ব্যবহার করছে।
হ্যালো, আমি অ্যানিস ডেভিস।
আমি Ford-এ কাজ করি।
আমি কিছু ইঞ্জিনিয়ারিং টিমের নেতৃত্ব দিই যারা আমাদের সাবস্ক্রিপশন এবং লয়ালটি প্রোডাক্ট ডেভেলপ করে।
হ্যালো, বন্ধুরা।
আমি টাই স্মিথ।
আমি Uber-এ ডেভেলপারদের সাহায্য করি।
এটি অনেক দিন ধরে মোবাইল হিসেবে ব্যবহার করা হচ্ছে।
গত কয়েক বছর ধরে, AI টুলিংয়ের মাধ্যমে আমরা যে নতুন ও আকর্ষণীয় যুগে প্রবেশ করেছি, তার উপর অনেক বেশি ফোকাস করা হয়েছে।
হ্যালো বন্ধুরা।
আমি কৌশিক গোপাল।
আমি Instacart-এ প্রিন্সিপাল ইঞ্জিনিয়ার হিসেবে কাজ করি এবং আমি Android ডেভেলপমেন্টের উপর Fragmented নামে এই পডকাস্ট শুরু করেছি।
আজকাল, Ty যেমন বলেছেন, আমরা স্ট্র্যাটেজি একটু পরিবর্তন করেছি এবং, আপনি জানেন, আমরা AI ডেভেলপমেন্ট সম্পর্কে কথা বলি।
ঠিক আছে।
তাহলে, আমাদের হাতে ৩০ মিনিট সময় আছে।
আমার মনে হয়, সময় খুব দ্রুত চলে যাবে, তাই আমরা সরাসরি কঠিন প্রশ্নগুলি নিয়ে আলোচনা শুরু করব।
আমরা সবসময়, আপনি জানেন, Android DevRel-এ, বলেছি যে আমরা অ্যাপ তৈরি করার প্রসেস আরও দ্রুত এবং সহজ করতে চাই।
এখন AI এসে গেছে এবং আপনি জানেন যে আমরা এখানে বলেছি, "এটি সত্যিই তাই।
আমরা মনে করি, অ্যাপ তৈরি করা আরও দ্রুত ও সহজ হবে।"
তবে আমি জানতে চাই, আমরা কি সত্যিই আরও দ্রুত অ্যাপ শিপ করছি, নাকি আমরা শুধু এমন একগুচ্ছ কোড তৈরি করছি যা কোনও কাজে লাগে না?
চলো, বিনয়।
ঠিক আছে।
হ্যাঁ, আমরা সবাই একে অপরের দিকে তাকিয়ে আছি।
অসাধারণ।
তাই, আপনি যদি শুধু সংখ্যার দিকে তাকান, তাহলে আমরা অবশ্যই দেখতে পাব যে PR-এর ক্ষেত্রে, কোডের লাইনের ক্ষেত্রে, আমরা একটি বিশাল ত্বরণ দেখেছি এবং ফলস্বরূপ, আমরা স্কেলিং চ্যালেঞ্জের সম্মুখীন হচ্ছি, এমনকি আমরা কোথায় আমাদের কোড স্টোর করছি, ঠিক?
তাই এই ত্বরণ খুবই বাস্তব।
তবে, এটি কীভাবে ফলাফলকে প্রভাবিত করে তা স্পষ্ট নয় এবং আমি মনে করি যে পুরো ইন্ডাস্ট্রি ফলাফলের ক্ষেত্রে সঠিক মেট্রিক কী তা বোঝার চেষ্টা করছে, কীভাবে এটি বটম লাইনকে প্রভাবিত করে তা জানার চেষ্টা করছে।
তবে আমি অবশ্যই এটি কাজ করতে দেখছি।
আমার মনে হয়, গত ছয় মাসে আমরা আগের থেকে অনেক বেশি কোড শিপ করেছি এবং আমি এটি অস্পষ্ট রাখব, তবে এটি অনেক দীর্ঘ সময় ধরে করা হয়েছে।
এবং এর ফলস্বরূপ, আমি মনে করি যে প্রোডাক্টিভিটি কীভাবে পরিমাপ করা যায় তার আশেপাশে আমাদের স্ট্র্যাটেজি পরিবর্তিত হয়েছে, তাই না?
কারণ এই বিষয়ে বিভিন্নভাবে ভাবা যেতে পারে।
আমরা মধ্যক কীভাবে বাড়ানো যায় তা বোঝার চেষ্টা করছি, তাই তো?
কারণ আপনি যখন আউটলায়ার এবং মধ্যক দেখেন, তখন এই দুই ধরনের মানুষের মধ্যে ৫ থেকে ১০ গুণ ডেল্টা থাকে এবং আমাদের ফোকাস হল ফ্লোর বাড়ানো, মধ্যক বাড়ানো এবং সেইসব মানুষকে তাদের আশেপাশের সমকক্ষদের মতো উৎপাদনশীল করে তোলা যাদের আমরা উৎপাদনশীল হিসেবে দেখি।
আমরা বিভিন্ন প্রকারের ভূমিকা দেখতে পাচ্ছি।
কিছু লোক অনেক অনেক দ্রুত চলছে।
এমন কিছু লোক আছেন যারা দিনে একশোটি PR করেন এবং তারা অবিশ্বাস্য কাজ করছেন।
তবে, এই ধরনের স্পেসে তারা কাজ করে।
সেটি হয়ত আরও বেশি গ্রিনফিল্ড অথবা তারা টুল ব্যবহারের ক্ষেত্রে আরও বেশি সাবলীল।
এছাড়াও, আমরা এমন লোকজনকে দেখি যারা, আপনি জানেন, ব্রাউনফিল্ড বা প্ল্যাটফর্মের কাজে বেশি যুক্ত এবং তারা এমন এক ধরনের কাজকে সমর্থন করছেন যা হয়ত ততটা দ্রুত নয় কারণ তাদের মানুষের বিচারবুদ্ধি প্রয়োগ করে এবং জিনিসগুলি যাতে ভেঙে না যায় তা নিশ্চিত করতে বেশি সময় ব্যয় করতে হচ্ছে।
আর এই দুটির কম্বিনেশন, আপনি জানেন, এটি আগের থেকে অনেক বেশি দ্রুত, তবে আমার মনে হয় আমাদের জন্য আসল আকর্ষণীয় বিষয় হল, আমরা আরও বেশি শিপিং করলেও, ব্যবসা কি আসলে এন্ড ইউজারদের আরও বেশি শিপিং করছে?
এই ক্ষেত্রে আমরা গত বছর থেকে বিনিয়োগ করছি যাতে আমরা বুঝতে পারি যে আমরা শুধু কোড নয়, ফিচারও দ্রুত শিপ করছি কিনা?
প্রাথমিক ইঙ্গিত বলছে যে আমরা তা করছি, তবে এটি শুধু PR-এর থেকে অনেক আলাদা।
আমার মনে হয়, যা ঘটেছে তা হল, খুব স্পষ্টভাবেই, লোকজন অনেক বেশি শিপিং করছেন, যেমন, আপনি জানেন, PR-এর সংখ্যা, গণনা, আপনি জানেন, বেড়েছে।
তবে আমার মনে হয়, এখনও অনেক চিন্তাভাবনা এইরকম, "আমরা কীভাবে AI এবং আমাদের কাছে থাকা এই ধরনের টুল ব্যবহার করে বর্তমান প্রসেসকে আরও উন্নত করতে পারি?"
ঠিক?
যেমন, আগে আমরা যেভাবে কোড শিপ করতাম তার বেশিরভাগই মনে হয় যে আমরা সবসময় একজন মানুষের মতো চিন্তা করতাম, যিনি প্রোডাকশন পর্যন্ত পুরো পথটি পরিচালনা করবেন।
কিন্তু আমার মনে হয়, এখন আমরা যা দেখছি তা হল, হ্যাঁ, এটি কাজ করে।
আমরা আরও শিপিং করছি।
কিন্তু আমরা এমন সব বাধার সম্মুখীন হচ্ছি যা আগে কখনও দেখা যায়নি, তাই না?
কারণ, অতীতে আমরা কখনও এই ধরনের সমস্যার সম্মুখীন হইনি, কিন্তু এখন, যেমন, আমরা একটি অংশের টার্বোচার্জিং করছি, যেমন, আপনি জানেন, একটি মাল্টিপল-স্টেপ সাইকেল এবং আমি মনে করি যে এখানেই এটি আকর্ষণীয় হয়ে উঠছে, যা হল, "ঠিক আছে।
আমরা আরও বেশি ডেলিভার করছি, তবে এখন এটি এফেক্টের ফায়ার হোসের মতো।"
তাই, আমরা অন্যান্য চ্যালেঞ্জের সম্মুখীন হচ্ছি।
এটি একটি খুব আকর্ষণীয় পয়েন্ট, তাই না, কারণ আপনি যখন এটি সম্পর্কে চিন্তা করেন, তখন অনেকগুলি বিভিন্ন ধাপ থাকে, তবে একটি উচ্চ-স্তরের দৃষ্টিকোণ থেকে, আপনি সেগুলিকে তিনটি পর্যায়ে ভাগ করতে পারেন, তাই না?
কোডিংয়ের ক্ষেত্রেও এটি ব্যবহার করা হচ্ছে এবং এর ব্যবহার দ্রুত বাড়ছে।
প্রোডাকশন রেডিনেসের মধ্যে আইনি, গোপনীয়তা এবং এমন কিছু বিষয় অন্তর্ভুক্ত থাকে যা আপনাকে কোনও কিছু প্রকাশ করতে দেয় এবং তারপরে লঞ্চ করার বিষয়টি আসে, তাই তো?
আর, আপনি কোথায় আছেন তার উপর নির্ভর করে শিপিংয়ের অর্থ আলাদা হয়, তাই না?
আপনি যদি সম্পূর্ণ সার্ভার সাইড প্রোডাক্টের মতো হন, তাহলে সম্ভবত শিপিং মানে আরও স্ট্রিমলাইনড প্রসেস, যেখানে আপনি এমন কিছু শিপিং করছেন যা গ্রাহকের কাছে যায়, ঠিক, যেমন এক্সপেরিমেন্টেশনে এটি পাওয়া ঠিক একটি জার্নির মাঝখানে থাকার মতো, তাই না?
আপনাকে এখনও অনেক পরীক্ষা-নিরীক্ষা ও পরিমাপ করতে হবে এবং আপনি যা বলছিলেন তার সাথে এটি সম্পর্কিত, অর্থাৎ আপনার মনে হবে যে আপনি একটি মেট্রোপলিটন এলাকায়, একটি ফ্রিওয়েতে আছেন এবং আপনার একটি চোক পয়েন্ট আছে এবং তারপরে আপনি গতি বাড়াতে শুরু করেন এবং আপনি বলেন, "হ্যাঁ, দারুণ।
আমি খুব দ্রুত এগোচ্ছি," কিন্তু এখন আপনি পরবর্তী চোক পয়েন্টে পৌঁছে গেছেন।
আর AI-এর মতো এটি যা তৈরি করছে তা থেকে খুব স্পষ্ট যে আপনি ঘর্ষণ বিন্দুগুলি আরও স্পষ্টভাবে দেখতে পাচ্ছেন এবং তাদের মধ্যে কিছু কোডিং বা প্রযুক্তির সাথে সম্পর্কিত নয়।
এটি প্রসেস ও মানুষের সাথে সম্পর্কিত এবং AI-এর মাধ্যমে আপনি কীভাবে এটি অপ্টিমাইজ করবেন।
শুরু থেকে শেষ পর্যন্ত কীভাবে স্ট্রিমলাইন করা যায় সেই বিষয়ে এটি সত্যিই একটি আকর্ষণীয় চ্যালেঞ্জ।
আমরা এই স্পেসের ব্যাপারে একটি আকর্ষণীয় উপায়ের কথা ভাবছি, সেটি হল, কোনও ব্যক্তি বা টিমের কাছে এটি সম্পূর্ণভাবে শিপ করার জন্য কতটা এজেন্সি আছে?
তাই, আমরা যদি ইন্টার্নালি দেখি, আপনি জানেন, অনেক টিম আছে যারা হয়ত ইন্টার্নাল টুল তৈরি করছে বা এমন কিছু যা গ্রাহকের কাছে পাঠানো হচ্ছে না।
তারা অনেক দ্রুত শিপিং করছে, তাই না?
গ্রাহকদের কাছে অবিলম্বে তা পৌঁছে দেওয়ার জন্য তাদের কাছে সম্পূর্ণ এজেন্সি আছে।
আপনার কাছে যদি কোনও এক্সটার্নাল প্রোডাক্ট থাকে যা এখনও ব্যবহারকারীর সাথে পরীক্ষা-নিরীক্ষার মাধ্যমে যেতে হবে, বা, আপনি জানেন, অ্যাপ স্টোর রোলআউট করার সময়, বা, আপনি জানেন, ডিজাইন এবং প্রোডাক্টের সাথে কাজ করা, এই সমস্ত অন্যান্য বাধাগুলি যোগ হচ্ছে এবং যারা কোড লিখছেন তাদের কাছে এটি দ্রুত এগিয়ে যাওয়ার জন্য অনেক কম এজেন্সি রয়েছে।
তাই, তারা সিস্টেমের বাকি বাধাগুলি অতিক্রম করার চেষ্টা করছে।
তাই, আমি মনে করি যে সেগুলিকে দুটি ভিন্ন ক্ষেত্রে ভাগ করলে আপনার ব্যবসার প্রসেস কোথায় উন্নত করা যেতে পারে তা সত্যিই হাইলাইট করে।
হ্যাঁ, আমি একমত, এবং আমি সততার সাথে অনুভব করি, ইঞ্জিনিয়ারিং কখনই বাধা ছিল না।
আমি অনেক বছর ধরে এই কথা বলছি।
ইঞ্জিনিয়ারিংয়ের ক্ষেত্রে কাজ করার পদ্ধতি খুবই সুনির্দিষ্ট এবং ব্যবসার দিক থেকে সবসময় প্রশ্ন করা হয়, "সমস্যাটা কী?"
আপনি সেটির ১০টি আলাদা উত্তর পাবেন।
এবং তারপর, "ঠিক আছে।
এখন, প্রোডাক্টের সাথে কিছু সমাধানের জন্য সেই ধরনের অনুবাদ করা যাক।
এখন, আসুন কিছুক্ষণ এই বিষয়ে চিন্তা করি।
ওহ, তাহলে ডিজাইন নিয়ে একটু কথা বলা যাক।
ওখানে কিক করো।"
ইঞ্জিনিয়ারিং টিমের কাছে পৌঁছানোর আগেই আমরা কম-বেশি জেনে যাই যে আমাদের কী করতে হবে।
তারপর, আমরা Stack Overflow-তে গিয়ে কিছু জিনিস কপি-পেস্ট করে কাজ চালিয়ে নিই।
তাই, AI-এর মাধ্যমে, আমি যেখানে সবচেয়ে বেশি গতি দেখতে পাচ্ছি তা হল কমপ্লায়েন্স সংক্রান্ত কাজ।
সেইসব জিনিস যেখানে আমরা সবসময় XYZ আধুনিকীকরণ করতে চেয়েছি অথবা আমরা সবসময় Spring Boot ভার্সন দ্রুত আপগ্রেড করতে চেয়েছি।
আমরা খুব দ্রুত তা করছি।
তবে, ফিচার ডেলিভারির ক্ষেত্রে আমি উল্লেখযোগ্য কোনও উন্নতি দেখতে পাইনি।
সুতরাং, আপনারা সবাই একরকমভাবে এই বিষয়ে বলেছেন যে, হয়ত বাধাটি সরে গেছে এবং আপনি এমন প্রসেস চালাচ্ছেন যা আগে বাধা ছিল না, কিন্তু এখন বাধা হয়ে দাঁড়িয়েছে।
তবে, সেইসব প্রসেস সম্ভবত অতীতে কঠিন অভিজ্ঞতার মাধ্যমে শেখা হয়েছে, তাই তো?
তাই, আপনি কি সেগুলি পরিবর্তন করার জন্য কোনও চাপ অনুভব করছেন এবং আমি মনে করি সবচেয়ে স্পষ্ট হল কোড রিভিউ।
কোড রিভিউয়ের ভবিষ্যৎ কী হতে পারে বলে আমরা মনে করি?
বর্তমানে আমরা কী করছি?
তাই হ্যাঁ, আমি শুনতে চাই।
আপনি জানেন, এটি আমার তৈরি করা এই পয়েন্টে ফিরে যায়।
আমার মনে হয়, এই ধরনের অনেক বাধা-বিপত্তি আসে কারণ আমরা ভাবি যে, ধরুন আপনার কাছে যদি কোনও ম্যাজিক ওয়ান্ড থাকে এবং আপনি যদি সফ্টওয়্যার ইঞ্জিনিয়ারিংকে নতুন করে আবিষ্কার করতে পারেন এবং আপনার কাছে যদি আজ AI থাকে, তাহলে কি আমরা একই ধরনের অনেক কিছু ব্যবহার করব? আমরা কি একই জিনিস করব?
যেমন, কোড রিভিউ করার জন্য আমাদের একজন মানুষের প্রয়োজন ছিল, যিনি সবকিছু পাস করবেন, যেমন, আপনি জানেন, সেই ফাইনাল ক্রস-চেক করা।
আমার মনে হয়, এটিও পরিবর্তন হচ্ছে, যেমন, আপনি জানেন, আমরা এখন কোড রিভিউ সম্পর্কে যেভাবে ভাবছি, তা হল, আমাদের হয়ত এই ধারণার ব্যাপারে খোলা মনে চিন্তা করা উচিত যে, আপনি যদি নামের রিফ্যাক্টর করেন বা কোড রিফ্যাক্টর করার চেষ্টা করেন এবং আপনি জানেন যে আপনার কাছে দুর্দান্ত টেস্ট আছে, যা স্পষ্টতই সবার কাছে আছে।
আমরা AI-কে দিয়ে লিখিয়েছি, ঠিক আছে।
না, মানে, আপনি কি ওই এজেন্টের থেকে অনেক ভালো কাজ করতে পারবেন?
আমি জানি না, যেমন, হয়ত এটি পর্যালোচনা করার জন্য সময় ব্যয় করবেন না।
আবার, আপনি যদি কোনও বাগ শিপ করেন এবং আপনার সিইও আপনাকে ফোন করে বলেন, "এই বাগটির জন্য আমাদের X ডলার খরচ হচ্ছে," তাহলে আপনাকে সেইসব ক্ষেত্র এবং সিস্টেম শনাক্ত করতে হবে, যেমন, "এটি একটি গুরুত্বপূর্ণ ক্ষেত্র।
এটি কোনও গুরুত্বপূর্ণ ক্ষেত্র নয়," এবং তারপর আবার কল্পনা করার চেষ্টা করুন।
যেমন, আমার মনে হয় না যে আমরা আজ এইভাবে কাজ করি, তাই না?
আজকে, এটা অনেকটা এরকম, "আরে, একটা PR আছে।
আমিই ইঞ্জিনিয়ার।
আমি এই বিষয়ে ফোকাস করছি।
এটি আরও বাড়বে।
আমি মাঝরাতে বিনয়কে কোড রিভিউ করার জন্য বিরক্ত করি, কারণ আমি চাই এই জিনিসটা মার্জ হয়ে যাক।"
তবে, আমাদের হয়ত এগুলির মধ্যে অনেক কিছু নিয়ে আবার ভাবতে হবে।
আমি সম্পূর্ণ একমত এবং আমি কোড রিভিউকে যাচাইকরণ সংক্রান্ত সমস্যা হিসেবে দেখি। এর অর্থ হল, এমন একটি দুনিয়া যেখানে কোনও কিছু যাচাই করার ব্যাপারে আমার ক্ষমতার উপর আমার সম্পূর্ণ আস্থা আছে, সেখানেও কি আমি আমার PR-এর ১০০% কোড রিভিউ করব?
সম্ভবত নয়, তাই তো?
সুতরাং, কোড রিভিউ দুটি উদ্দেশ্যে করা হয়।
প্রথমত, আমরা সঠিক কাজ করছি কিনা তা যাচাই করা এবং দ্বিতীয়ত, শিক্ষা, তাই তো?
যেমন, আপনার আশেপাশের লোকজন আপনার সিদ্ধান্ত সম্পর্কে জানতে পারবেন এবং তারা সেই সিদ্ধান্তের সাথে একমত কিনা তাও জানাতে পারবেন।
তাই, এমন কিছু কাজ অবশ্যই আছে যা আমরা আরও দ্রুত করতে পারি এবং কোড ও রিলিজের ক্ষেত্রেও তা প্রয়োগ করতে পারি।
এখন, এটি ১০০% ক্ষেত্রে প্রযোজ্য নাও হতে পারে, তবে আমি মনে করি এটি একটি খুব বেশি, ডবল-ডিজিট নম্বর যার ক্ষেত্রে এটি প্রযোজ্য হওয়া উচিত।
And I think we are getting ready to make those changes and we all as a community need to make sure that our systems are ready for that, because it's coming.
এটিকে এড়িয়ে যাওয়ার কোনও উপায় নেই।
ফানেলের উপরের অংশটি বিভিন্ন সারফেস সহ অনেক বড়, যা আপনাকে আরও PR তৈরি করার সুযোগ দেয়।
এবং আপনি প্রসেসের সবচেয়ে ধীর গতির ধাপের মতোই দ্রুত।
এবং অনেক টিমের জন্য সেটি হল কোড রিভিউ এবং যেসব টিম দ্রুত কাজ করছে তারা সততার সাথে এই বাস্তবতাকে বুঝেছে এবং মেনে নিয়েছে।
হ্যাঁ, এবং আমরা যদি নিজেদের সাথে সৎ থাকি, তাহলে আমি বলতে চাই যে আমি যত PR দেখেছি তার ৭০% আমার কাছে ভালো লেগেছে।
যেমন, আমরা যদি বিশ্বের সমস্ত কোড বেস সার্চ করি, তাহলে PR কমেন্টগুলি হবে, "আমার কাছে ভাল লাগছে", LGTM, বোর্ড জুড়ে।
তাই, এর কিছুটা হল ইঞ্জিনিয়ারিং পেশাদার হিসেবে, কখনও কখনও আমরা নিজেদের যতটা প্রাপ্য তার চেয়ে বেশি কৃতিত্ব দিই।
আমরা সত্যিই মনে করি যে আমরা সেখানে আছি।
"তারা কি কমান্ড প্যাটার্ন ব্যবহার করেছে?"
না, আমরা শুধু বলি, "ঠিক আছে।
হ্যাঁ, আমার তো ঠিকই লাগছে।"
তাহলে, আমি কেন কোনও এজেন্টকে দিয়ে তা করাতে পারব না?
আমি সত্যিই মনে করি যে এটিই হল ভবিষ্যৎ, যেখানে আমরা দেখতে পাব যে আমার কাছে কোনটি ভালো লাগছে, যেমন কোন ধরনের বৈশিষ্ট্য, কোন ধরনের আচরণ আপনাকে এমন অনুভব করিয়েছে?
এবং তারপরে, এজেন্ট যাতে একই জিনিস খোঁজে তা নিশ্চিত করুন।
অথবা, অন্যভাবে বলতে গেলে, রিভিউ করার বিভিন্ন উপায় সম্পর্কেও চিন্তা করার চেষ্টা করুন, তাই না?
যেমন আমি জানি যে আজকাল যারা Twitter-এ আছেন, তারা এই কথা বলেন, তাই না?
যেমন, আপনি এখন কোনও PR যাচাই করার সময়, আপনার এজেন্টদের এটি অন্যভাবে ভিজ্যুয়ালাইজ করতে বলেন, তাই না?
আগের ছবিটা দেখাও।
আমাকে পরেরটা দেখাও।
প্রতিটি লাইন ধরে-ধরে কোড পর্যালোচনা করার পরিবর্তে আপনি যে টেস্ট লিখেছেন তা আমাকে দেখান।
কিন্তু এটা চ্যালেঞ্জ করে তুমি কিছু বলতে যাচ্ছিলে, লুইস?
না, আমার মনে হয় এটি একটি চিন্তা-উদ্দীপক বিষয়, তাই না?
Like that we're going to get to a place where you feel really comfortable letting CLs, like or PRs, going through without human intervention.
তাই, আমি একটু অন্যভাবে ভাবছি এবং আমি বলতে চাই যে আমরা যখন ঘর্ষণ সম্পর্কে কথা বলি, তখন আমার মনে হয় যে ঘর্ষণ খারাপ বলে মনে করার প্রবণতা রয়েছে, তবে ভাল এবং খারাপ ঘর্ষণ রয়েছে।
এবং আমি মনে করি যে রিভিউ এখনও ভাল ঘর্ষণের বিভাগে রয়েছে।
ডেভেলপারদের জন্য আমরা কীভাবে এটি আরও সহজ করে তুলতে পারি, তাই তো?
এবং কখনও কখনও এটি সেই সময়ে আমরা কীভাবে সেই পর্যালোচনাটিকে আরও ভাল বা আরও দক্ষ করে তুলব তা নিয়ে নয়?
AI-এর সাহায্যে আপনি কীভাবে ডেভেলপমেন্টের আপস্ট্রিম আরও নিখুঁত করতে পারেন, তাই তো?
কারণ আপনি যদি শুধু AI কীভাবে ব্যবহার করেন তার উপর নির্ভর করেন, যেমন ভালো ইনপুট দিলে ভালো আউটপুট পাওয়া যায়, কিন্তু খারাপ ইনপুট দিলে সত্যিই খারাপ আউটপুট পাওয়া যায়, তাই না?
তাই, আমি মনে করি যে, সেই আকর্ষণীয়, আপনি জানেন, শেষ অবস্থায় পৌঁছাতে, শুরু থেকে শেষ পর্যন্ত AI-এর মাধ্যমে প্রসেসের সামগ্রিক উন্নতি করতে হবে, আর্কিটেকচার আরও ভালোভাবে বোঝার জন্য AI ব্যবহার করতে হবে, যাতে, আপনি জানেন, ডেভেলপারদের কম পরিশ্রমেই সত্যিই সলিড স্পেসিফিকেশন পাওয়া যায়, যাতে এটি আরও ভালো কোয়ালিটির কোড তৈরি করে।
তাই, রিভিউয়ের ক্ষেত্রে ডেভেলপারদের কম সমস্যার সম্মুখীন হতে হয়।
আমার মনে হয়, এই বিষয়ের শেষ অবস্থা যা নিয়ে কোনও বিতর্ক থাকবে না তা হল, বেশিরভাগ লোকই বুঝতে পারবেন যে এই সব কোড শেষ পর্যন্ত হিউম্যান রিভিউ ছাড়াই ল্যান্ড করবে।
আমার মনে হয়, ইতিমধ্যে আমরা এমন এক পরিবর্তনশীল পরিস্থিতির মধ্যে রয়েছি যেখানে মডেলগুলি আরও উন্নত হচ্ছে এবং আমরা তাদের প্রযুক্তিগত ভুল করার বিষয়ে কম চিন্তিত এবং তারা ব্যবসায়িক ভুল বা বিচার বা ধারণার মতো ভুল করার বিষয়ে বেশি চিন্তিত।
এবং তাই, এটিও সিগন্যালে যায় যেখানে আপনি পর্যালোচনার পর্যায়ে এটিকে আলাদা করতে চান।
যেমন, আমাদের কি PR-এ লাইন-বাই-লাইন রিভিউ করা উচিত নাকি তারা যে উদ্দেশ্যটি পরে পুশ করার চেষ্টা করছে সেটি রিভিউ করা উচিত?
আমরা এই বিষয়ে হয়ত আলাদা আলাদা উপায়ে ভাবছি।
প্রথমত, আমরা কীভাবে ব্যবহারকারীকে আরও প্রাসঙ্গিক তথ্য দিতে পারি যাতে তারা সেটিকে অগ্রাধিকার দিতে শুরু করতে পারেন?
অন্যটি হল, সেইসব নিরাপদ এলাকা কোনগুলি যেখানে আমরা পরীক্ষা করতে পারি এবং এই ধরনের প্রোগ্রামে আরও দ্রুত এগিয়ে যেতে পারি?
কৌশিক যেমন বলছিলেন, সব ক্ষেত্রে একই পরিমাণ কঠোরতার প্রয়োজন নেই।
আমরা এটি শনাক্ত করতে পারি এবং কিছু কন্টেন্ট দ্রুত প্রকাশ করার অনুমতি দিতে পারি, ঝুঁকি কমাতে পারি, তবে আপনি জানেন যে, যেসব ক্ষেত্রে আরও বেশি করে নিয়ম মেনে চলতে হয় বা, আপনি জানেন যে, খুব মৌলিক বিষয়গুলি নিয়ে আরও বেশি ঘর্ষণ হয়, যতক্ষণ না আমরা শুধু মডেল নয়, তার মধ্যে যে ইনপুট যাচ্ছে, সেটিকেও বিশ্বাস করার মতো জায়গায় পৌঁছাতে পারি
সঠিক সিদ্ধান্ত ছিল।
যেমন, Uber অ্যাপে নতুন Android মডিউল রিফ্যাক্টর করা, ঠিক আছে।
সব Android ডেভেলপারকে ফ্রিতে রাইড দেওয়া হচ্ছে, সম্ভবত সেই কোড চেক করতে চান।
আমাদের সিইও-র সাথে কথা বলে আমাকে এটি চেক করতে হবে।
দুঃখিত, কৌশিক।
তবে আমার এও মনে হয় যে এই সমস্যার সমাধান হয়ে গেছে।
আমাদের কাছে আগে থেকেই ফিচার ফ্ল্যাগ আছে।
আমাদের কাছে আগে থেকেই ব্লু-গ্রিন ডেপ্লয়মেন্ট আছে।
আমাদের কাছে আগে থেকেই অনেক পিস আছে।
চ্যালেঞ্জটি এমন যে আমরা এটি করার জন্য খুব ব্যস্ত ছিলাম।
আমাদের কাছে আগে থেকেই আচরণগত ট্র্যাকিং আছে।
আমাদের কাছে এই ধরনের সব ডেটা আছে, কিন্তু সেগুলি এই সব আলাদা সিস্টেমে আছে।
আমরা আগে থেকেই ঘটনা ট্র্যাক করি।
আমাদের কাছে অনেক ডেটা আছে, কিন্তু সেইসব ডেটা একসাথে করে একটি বিস্তারিত ট্রেস তৈরি করা, এই কাজটিই করা হয়নি।
এইসব বিভিন্ন কোম্পানি জুড়ে এই ধরনের ইঞ্জিনিয়ারিং কনটেক্সট সার্ভিস কেমন দেখতে হয় তা আমরা একবার বুঝে গেলে, আমাদের আর চিন্তা করতে হবে না কারণ PR মার্জ হয়ে গেলেও তা নিরাপদ।
কারণ আমরা জানি, ঠিক আছে, আমরা ফিচার ফ্ল্যাগের পিছনে এটি পেয়েছি।
আমাদের কাছে ব্লু-গ্রিন ডিপ্লয়মেন্ট আছে।
আমাদের কাছে সব ধরনের পর্যবেক্ষণ করার সুবিধা আছে।
এবং তারপরে আপনি শুধু এই ধরনের কথা বলে অত্যন্ত আত্মবিশ্বাসী বোধ করতে পারেন, যেমন, "ওহ, এটি পাইপলাইনে রাখুন।"
খারাপ কিছু ঘটলে, আমাদের কাছে এই সমস্ত গার্ড এবং গেট রয়েছে।
আমার মনে হয়, কত দ্রুত উত্তর দেওয়া যাচ্ছে সেটাও খুব গুরুত্বপূর্ণ, তাই না?
যেমন ধরুন, Android-এ কোনও পরিবর্তন করা হলে, সেটি Play Store-এর মাধ্যমে শিপ করতে হয় এবং তারপর গ্রাহকদের কাছে রোল-আউট করা হয়। এই ক্ষেত্রে, কোনও সমস্যা হলে, সেটি অবিলম্বে হটফিক্স করার ক্ষমতা সীমিত থাকে। অন্যদিকে, ইন্টার্নাল ডিপ্লয়মেন্ট, ইন্টার্নাল অবজার্ভেবিলিটি এবং এজেন্টের মাধ্যমে কোনও পরিবর্তন করা হলে, সেটি অবিলম্বে করা যায় এবং দ্রুত কাজ করার অনেক বেশি সুযোগ থাকে।
তাই, আপনাদের জন্য আমার একটি প্রশ্ন হল, এই অ্যাপে কাজ করার ক্ষেত্রেও সমস্যা রয়েছে, তবে আপনার কাছে এই গ্রিনফিল্ড অ্যাপগুলি রয়েছে যা সহজ, তারপরে আপনার কাছে এই ব্রাউনফিল্ড অ্যাপগুলি রয়েছে এবং তারপরে এমন একটি মুহূর্ত আসে যেখানে আপনাকে এই চেকগুলির মধ্যে অনেকগুলি রাখার জন্য সময় প্রয়োজন, যাতে আপনি AI-এর ব্যবহার বাড়াতে পারেন।
আমি জানি যে আপনাদের মধ্যে অনেকেই বিশাল অ্যাপে কাজ করেন, তাই না?
তাই, আমি জানতে চাই যে আপনি এই বিষয়ে কী ভাবছেন?
এটা কি এমন যে, সিইও-কে বলা, আমাকে ৩ মাস সময় দিন, আমি এই অ্যাপকে AI-রেডি করে তুলি, নাকি প্রতিদিন একটু একটু করে যোগ করা?
হ্যাঁ।
তারা কখনও তা করে না।
আমার মনে হয় না।
মানে, বেশিরভাগ কোম্পানির কাছেই এই সুবিধা থাকে না।
আমার মনে হয়, টেক ডেটের মতো করেই আমাদের এই বিষয়ে সময় দিতে হবে, যেমন, আপনার সময়ের ২০% এই কাজে ব্যবহার করুন, তার ৫% প্রম্পট উন্নত করার কাজে ব্যবহার করুন।
এবং তারপরে প্রম্পটটি কী করে তা বুঝতে এবং প্রসঙ্গটিকে আরও ভালো করতে।
তাই, আমরা এই বিষয়ে অনেক কথা বলেছি, আমার মনে হয়, এর বেশিরভাগই হল যে ইঞ্জিনিয়াররা এখনও বুঝতে পারছেন না যে এটি কীভাবে কাজ করে।
এটি এখনও খুব জাদুকরী এবং রহস্যময় বলে মনে হয় এবং তাই তারা এটিকে এমনভাবে কনফিগার এবং টিউন করছে না যাতে তারা এটির থেকে আরও ভাল ভ্যালু, দক্ষতা পেতে পারে।
তাই, আমার মনে হয়, এমন একটা সময় আসে যখন লিডারদের বলতে হয়, "আমাদের টিমকে আরও উন্নত করতে কী করতে হবে যাতে তারা বুঝতে পারে যে এটি কীভাবে কাজ করে এবং আমরা আরও বেশি কিছু পেতে পারি?"
এটিও এর ধারাবাহিকতা।
কারণ এটি এত দ্রুত পরিবর্তিত হচ্ছে যে, আমি যদি কোনও টিমকে বলি যে, এক সপ্তাহ সময় নিয়ে লেটেস্ট ও সবচেয়ে ভালো প্রযুক্তি সম্পর্কে শিখে নাও এবং সেগুলি প্রয়োগ করো, কিন্তু তারপরে তারা যদি আর শেখা বা পরীক্ষা-নিরীক্ষা করার সময় না পায়, তাহলে পরের বছর আমরা যখন তাদের কাজ চেক করব, তখন দেখব যে তারা নতুন ক্ষমতার তুলনায় অনেক পিছিয়ে পড়েছে।
তাই, আমাদের এই সব কিছু করতে হবে, আপনি জানেন, আমরা যেন উড়তে উড়তে প্লেন তৈরি করছি, যেখানে আমরা গার্ডরেল বসাচ্ছি এবং আমরা শিখছি এবং পরিস্থিতি অনুযায়ী নিজেদের মানিয়ে নিচ্ছি এবং টিমকে এই বিষয়ে সবসময় আপ-টু-ডেট থাকতে হবে।
আর বড় বড় সংস্থায়, আমাদের মতো টিম থাকে যারা সেইসব তথ্যকে একটু সহজ করে, যাতে মানুষ বুঝতে পারে, রিলেট করতে পারে।
কিন্তু এই মুহূর্তে ইন্ডাস্ট্রির প্রত্যেকের কাছেই এটি একটি চ্যালেঞ্জ।
আমি একটু মিক্স করতে চাই।
আপনি আপনাদের মধ্যে অনেকেই ডেভেলপার ইনফ্রাস্ট্রাকচারের মতো কাজ করেন।
হাজার হাজার PR, আপনার টেস্টিং ইনফ্রাস্ট্রাকচার, আপনার সার্ভার, সব কি গলে যাচ্ছে?
আর আমি যুদ্ধের কিছু গল্প শুনতে চাই।
Ty?
হ্যাঁ।
তারা দারুণ খেলছে।
আমার CI আমাকে প্রতি রাতে ঘুমাতে সাহায্য করে।
আমাদের ডেভেলপার ইনফ্রাস্ট্রাকচার টিমের প্রায় সব সদস্যই এখন কম্পিউট স্কেলিং ও দক্ষতার সমস্যা নিয়ে কাজ করছেন।
মানে, কোড রেড চলছে।
তারা এই বিপুল পরিমাণ ভলিউম বৃদ্ধি দেখতে পান।
আমরা এজেন্টের সাথে আর্কিটেকচারাল পরিবর্তন করছি।
আমরা যত দ্রুত সম্ভব Bazel-এর মাধ্যমে রিমোট বিল্ড এক্সিকিউশন ও ক্যাশিংয়ের সুবিধা আরও বেশি করে প্রদান করার চেষ্টা করছি। আমরা দেখছি যে কীভাবে সব সময় মেইন গ্রিন রাখা যায় অথবা নির্দিষ্ট কিছু ক্ষেত্রে এজেন্টের মাধ্যমে ফরওয়ার্ড ফিক্স করা যায় কিনা। ইঞ্জিনিয়ারদের থেকে আসা ভলিউম দেখে আমরা সেল্ফ-হিলিং CI বা লোয়ার ফিডব্যাক লুপের মতো জিনিস করার চেষ্টা করছি। সব টিমই এই ধরনের বিষয়ে সক্রিয়ভাবে ইনভেস্ট করছে যাতে দক্ষতার লেভেল বজায় রেখে গ্রোথও বজায় রাখা যায়।
কিন্তু এটি অত্যন্ত চ্যালেঞ্জিং।
হ্যাঁ, টাই যা বলল, আমি তার সাথে সম্পূর্ণ একমত, তবে আমার মনে হয় যে এটি আমাদের নিজেদের দিকে ফিরে তাকাতে এবং সততার সাথে প্রশ্ন করতে বাধ্য করে যে, আমরা যদি এই পয়েন্ট থেকে ১০ গুণ বেশি করতে চাই, তাহলে কি আমরা প্রস্তুত?
এবং বেশিরভাগ মানুষের ক্ষেত্রে, উত্তরটি সম্ভবত না।
আর এর ফলে, ভবিষ্যতের কথা চিন্তা করে, আমরা ইচ্ছাকৃতভাবে আমাদের উচ্চাকাঙ্ক্ষাকে সেই স্কেলের সাথে মেলানোর চেষ্টা করছি যা ইনফ্রা সাপোর্ট করতে পারে।
আর কী-- AI-এর একটি অবদান হল, এটি আমাদের সবাইকে আরও উচ্চাকাঙ্ক্ষী করে তুলেছে কারণ আমরা ইতিমধ্যেই সেই অর্থপূর্ণ অগ্রগতি দেখেছি এবং তাই আমরা সততার সাথে আমাদের সিস্টেমগুলি পুনর্বিবেচনা করছি।
ঠিক, আমরা ভাবছি যে অন্য কোন সিস্টেম ভেঙে যেতে চলেছে, বা আমরা অনুমান করছি যে ভেঙে যেতে চলেছে এবং আমরা এটি থেকে এগিয়ে যাওয়ার জন্য কী করতে পারি যাতে এটি কোনও চমক না হয়?
আর বাস্তবে, আমরা অপ্রত্যাশিত কিছু এড়ানোর চেষ্টা করছি।
ঠিক, যতক্ষণ আমরা মনে করি যে আমরা নিয়ন্ত্রণে আছি, সবাই খুশি।
আমরা যখনই কোনও অপ্রত্যাশিত ঘটনার সম্মুখীন হই, আমি জানি যে এটি সবার জন্য খারাপ খবর।
ঠিক?
তাই, এই সময়টা হল, পিছনে ফিরে তাকানো, অডিট করা এবং এর পরে কী ভাঙতে চলেছে তা খুঁজে বের করার জন্য উপযুক্ত সময়, কারণ এটি ঘটবেই।
এটি অনিবার্য।
আমরা শুধু এর থেকে এগিয়ে থাকতে চাই।
Inflow-এর সিইও-র থেকে আমি একটি আকর্ষণীয় কোট শুনেছি।
তিনি বলছিলেন যে Google-এর এখন যত বিলিয়ন লাইন কোড আছে, সেখানে পৌঁছাতে এই টাইমলাইন লেগেছে এবং এতে, আপনি জানেন, ২০ বছরের মতো সময় লেগেছে এবং এর গতি বৃদ্ধির সাথে সাথে আমাদের অনেক কোম্পানিই AI-এর গতি বৃদ্ধির উপর ভিত্তি করে মাত্র কয়েক বছরের মধ্যে একই স্কেলে পৌঁছাতে চলেছে।
আর আমার মনে হয় না যে সব কোম্পানি ডেভেলপমেন্টের জন্য Google-এর মতো পরিকাঠামো তৈরি করতে পারবে।
তাহলে, সেই বিষয়ে, আপনার কোম্পানি কি কোনও ধরনের খরচের সীমা প্রয়োগ করে?
যেমন, আপনি কীভাবে এমন কিছু ডেভেলপারকে ম্যানেজ করেন যারা এখন সবকিছুর জন্য টোকেন খরচ করে, আপনি জানেন, সব সময় সম্ভাব্য সেরা মডেল ব্যবহার করেন।
যেমন, আপনি কি কোনও স্ট্র্যাটেজি খুঁজে পেয়েছেন নাকি তাদের ফ্রি ছেড়ে দেওয়াই ভাল, কারণ পরীক্ষা-নিরীক্ষা করলে মিষ্টি ফল পাওয়া যায়?
আমি বলব, গত বছরটা ছিল এক্সপেরিমেন্ট করার বছর।
সবকিছু করো।
এমনকি এই বছরের প্রথম অর্ধেকের ক্ষেত্রেও এটি যুক্তিসঙ্গতভাবে ব্যবহার করা হয়েছে।
আর এখন, সেপ্টেম্বর থেকে, আমাদের টোকেন সীমা আছে।
তাই, ডেভেলপারদের জন্য টোকেন ব্যবহারের ক্ষেত্রে আমাদের কাছে আসলে সীমা আছে।
আর তারপর আমাদের কাছে ইনস্ট্রুমেন্টেশন আছে, যাতে তারা বুঝতে পারে যে, আপনার সেশন ভালো ও স্বাস্থ্যকর হচ্ছে কিনা?
স্বাস্থ্যকর সেশন বলতে কী বোঝায়?
আপনি কি সেশন প্রতি এতগুলি টার্ন পাচ্ছেন?
টার্ন কী?
তাই, আমরা টুলিং ব্যবহার করে ডেভেলপারদেরও শিক্ষিত করার চেষ্টা করছি।
আমি মনে করি যে এটি শুধুমাত্র প্রথম ধাপ।
আপনি জানেন, কোনও সমস্যা সমাধান করার আগে আপনাকে জানতে হবে যে আপনার সমস্যা আছে।
তাই, তাদের মতো অন্তত এটি দেখা ফ্রি নয়।
আগে, সত্যিই মনে হত যে AI ফ্রি।
এবং লোকজন এটি ব্যবহার করছিলেন।
আমি চাই, "আমার ব্রাঞ্চ পরিবর্তন করুন," আপনি জানেন, যেমন, "ওহ, কোনও সমস্যা নেই অ্যানিস, আমি আপনার জন্য সেই ব্রাঞ্চ পরিবর্তন করব, $৫," তাই না?
এখন আমরা এমন একটা জায়গায় পৌঁছেছি যেখানে মনে হচ্ছে, "ঠিক আছে, আমি কমান্ড লাইনে গিয়ে নিজেই এটা করতে পারি, তাই না?"
তাই আমার মনে হয়, আমরা ইঞ্জিনিয়ারদের প্রকৃত খরচ সম্পর্কে শিক্ষিত করার মাধ্যমে শুরু করতে চলেছি।
More so like I wouldn't just spin up ECS instances and just like run away from them.
AWS যখন প্রথম আসে, তখন আমরা ভেবেছিলাম, "হ্যাঁ, আমি নিজের ইনস্ট্যান্স ব্যবহার করতে পারি।"
আর আমরা কোম্পানির অনেক টাকা খরচ করে ফেলছিলাম।
আমার মনে হয়, টোকেনের ক্ষেত্রেও এখন একই জিনিস ঘটছে।
আমার মনে হয়, বাস্তবসম্মত সীমাবদ্ধতাও সত্যিই আকর্ষণীয় সুযোগ প্রদান করে, তাই না?
কারণ, আপনি যদি ভাবেন যে, শুরুতে আমরা কীভাবে LLM ব্যবহার করা শুরু করেছিলাম, তাহলে আপনি সবকিছুই LLM-এর উপর ছেড়ে দিতেন, তাই না?
তারা কোডটি ইন্ট্রোস্পেক্ট করবে, জিনিসগুলি খুঁজে বের করবে এবং আপনার জন্য ম্যাজিক করবে, তাই না?
কিন্তু এর জন্য খরচ করতে হয়েছে।
এবং আমরা আসলে বাস্তব-- আপনি জানেন, ইন্ডাস্ট্রি তা বুঝতে পারছে।
এবং এটি আসলে ডেভেলপার এবং সংস্থাগুলিকে ভাবতে বাধ্য করছে যে, আপনি কীভাবে এটি অপ্টিমাইজ করতে পারেন, তাই না?
কেন, তার একটি বাস্তব উদাহরণ দিচ্ছি: আপনার কাছে যদি এমন একটি জেনারেটর থাকে যা ইউজার ইন্টারফেস কম্পোনেন্ট তৈরি করে এবং সেগুলিকে একটি নির্দিষ্ট স্ট্রাকচার, ইউনিট টেস্ট এবং এই ধরনের জিনিস মেনে চলতে হয়, তাহলে আপনি কেন মডেলগুলিকে ফ্লাইতে তৈরি করতে বলবেন, যদি আপনি আসলে এটি একটি নির্ধারক টুল তৈরি করতে পারেন যা তারা আপনার জন্য তৈরি করতে পারে, তাই না?
তাই, সেখানেই, টোকেন এবং ব্যবহারের সীমা আপনার সুবিধার্থে ব্যবহার করার এবং আসলে আরও কার্যকর হওয়ার অনেক সুযোগ রয়েছে।
হ্যাঁ, এবং সেই থিমগুলির সাথে, আমরা অবশ্যই সীমা চালু করেছি, অন্তত আপনি যেমন জানেন, Instacart-এ।
তবে আমার মনে হয়, AI-এর ব্যবহার সীমিত করাটা লক্ষ্য নয়, বরং AI-এর ব্যবহারকে আরও স্বাস্থ্যকর করে তোলা বা আপনি যেমন বললেন, আত্মদর্শন করা, তাই না?
যেমন, অন্যান্য মডেলের পরিবর্তে আপনার কখন নির্দিষ্ট মডেল ব্যবহার করা উচিত।
আপনি জানেন, সময় বলতে বা Git ব্রাঞ্চ পরিবর্তন করতে আপনার সম্ভবত Fable বা Astra-র মতো কিছুর প্রয়োজন নেই।
ঠিক?
আপনি সম্ভবত, আপনি জানেন, স্ক্রিপ্ট লেখার জন্য কিছু সময় ব্যয় করতে পারেন এবং এটি চিরকালের জন্য ফ্রি।
সেখানে কোনও টোকেন নষ্ট হয় না।
ঠিক?
তাই, আমার মনে হয়, আপনি যদি এমন কিছু যোগ করতে পারেন যাতে বোঝা যায় যে এই সীমাবদ্ধতা ব্যবহারের সীমা নির্ধারণ করার জন্য নয়, বরং আপনাকে আরও বেশি করে ভাবতে সাহায্য করার জন্য, যাতে আপনি সবকিছুই এর উপর ছেড়ে না দেন।
ঠিক?
আপনার কথা আমার ভালো লেগেছে, গত বছরটা যেন পরীক্ষা-নিরীক্ষার বছর ছিল।
এই বছর মনে হচ্ছে, ঠিক আছে, আমরা কীভাবে এই জিনিসটি কার্যকরভাবে ব্যবহার করব?
হ্যাঁ।
এখানে দেখানো গল্পগুলি আমাদেরও খুব ভালো লেগেছে।
বিশেষ করে আরও বেশি পরীক্ষা-নিরীক্ষা থেকে, আপনি জানেন, দক্ষতা এবং জবাবদিহিতার একটি ভারসাম্যপূর্ণ সেট।
এটি বিভিন্ন ধরনের বিনিয়োগ থেকে আসে।
ডেভেলপারদের জন্য শিক্ষা এবং দৃশ্যমানতার মতো বিষয় রয়েছে।
যেমন, অ্যানিস অ্যাক্টিভ সেশনের খরচ ও তথ্য সম্পর্কে বলছিলেন।
নিরাপদ ডিফল্টের মতো বিষয়ে বিনিয়োগ, যা আপনি জানেন, অপ্রয়োজনীয় ইন্টার্যাকশন এড়াতে সাহায্য করে, এটি নিশ্চিত করে যে তারা যে দক্ষতা ব্যবহার করছে তা রিগ্রেশন এবং সেইসব বিষয়ে দক্ষ।
এবং তারা যে খরচ করছে তার জবাবদিহিতা প্রদান করা।
তাই, আপনি জানেন যে আমাদের টোকেন সীমা আছে।
এবং যখন কোনও ডেভেলপার সেইসব থ্রেশহোল্ডে পৌঁছান, তখন তিনি একটি বোতামে ক্লিক করে এবং একটি যুক্তি প্রদান করে তার ম্যানেজারের কাছ থেকে অনুমোদন পেতে পারেন।
তাই, যদি কোনও ভালো কাজ হয়, আমরা চাই যে তারা যেন সেই কাজের সাথে যুক্ত থাকে।
কিন্তু, আপনি জানেন, তারা যদি আরও বেশি অপচয়মূলক বা পরীক্ষামূলক কিছু করে থাকেন, তাহলে তারা তাদের ম্যানেজারকে কেন, আপনি জানেন, কেন তাদের এতে অর্থ ব্যয় করা উচিত তা ব্যাখ্যা করতে পারবেন না, তাই এটি তাদের সেই ধরনের জিনিস নিয়ন্ত্রণে রাখতেও সাহায্য করে।
And that results not just in not doing work, but looking and saying, is this the right model choice?
এটির জন্য কি এই ওজন সঠিক?
আপনি জানেন যে, প্রতিযোগিতামূলক চাপের কারণে এই টোকেনগুলির দাম কমতে শুরু করেছে।
তবে, সাধারণভাবে আমাদের ইঞ্জিনিয়াররা এই বিষয়ে চিন্তা করছেন যে আমরা তাদের যে টাকা দিচ্ছি তা তারা সঠিকভাবে ব্যবহার করছেন কিনা, আমি মনে করি যে এটিই এখন সঠিক ও স্বাস্থ্যকর পদ্ধতি।
এবং তারপরে দীর্ঘমেয়াদী, তাদের থেকে সেই সিদ্ধান্ত সম্পূর্ণভাবে সরিয়ে দিতে সক্ষম হওয়া।
ঠিক?
আপনি অটোমেটিক মডেল রাউটিং এবং এই ধরনের জিনিস চান, যেখানে তাদের কখনই এই বিষয়ে ভাবতে হবে না।
তবে, ততক্ষণ, এটি একটি স্বাস্থ্যকর অবস্থা।
হ্যাঁ।
আমার মনে হয়, আমাদের ফোকাস মডেল রাউটারের মতো জিনিস তৈরি করার উপর ছিল, যাতে ডেভেলপারকে সেই সিদ্ধান্ত নিতে না হয় এবং আমরা টাস্ককে সঠিক মডেলের সাথে ম্যাপ করার চেষ্টা করতে পারি।
তবে, সঠিক ট্রিপওয়্যার থাকাটাও গুরুত্বপূর্ণ।
তাই, আমরা টোকেন সীমা সম্পর্কে কয়েকটি উপায়ে চিন্তা করি।
আমরা কখনই ডেভেলপারকে ব্লক করতে চাই না।
তবে আমরা নিশ্চিত করতে চাই যে এমন কিছু মুহূর্ত থাকবে যেখানে আমরা এক সেকেন্ডের জন্য বিরতি নিতে পারি এবং নিশ্চিত করতে পারি যে এটি সঠিক ক্ষেত্রে এবং সঠিক উপায়ে খরচ করা হচ্ছে।
তাই, উদাহরণ হিসেবে দৈনিক সীমা রয়েছে, যা ডেভেলপার নিজেই আনব্লক করতে পারবেন।
তাদের শুধু পোর্টালে যেতে হবে, একটি বোতামে ক্লিক করতে হবে এবং বলতে হবে, "আরে, আমি কিছুই আশ্চর্যজনক ঘটেনি।
আমি কন্ট্রোল করছি।"
ঠিক?
এবং এটি একটি সাধারণ লিভার কারণ প্রত্যেকেই লুপ করছে এবং এই লুপগুলি সারারাত চলতে পারে এবং আমরা চাই না যে এর জন্য খরচ বেড়ে যাক।
তাই, এটি খুবই যুক্তিযুক্ত।
অন্যদিকে, আমরা এটিও নিশ্চিত করতে চাই যে আমাদের ডেভেলপারদের কাছে যেন সেরা মডেল উপলভ্য থাকে।
তবে, এই ধরনের মডেলের জন্য আমরা ফ্রন্টিয়ার বাজেট তৈরি করেছি।
তাই, মাসিক বাজেট সেট করা আছে।
এটা যথেষ্ট উঁচু।
আপনাকে ব্লক করা হয়নি।
আপনাকে আনব্লক করতে হলে, একটি ব্যতিক্রমী প্রসেস আছে।
আপনার ম্যানেজারের কাছে যায়।
এটি এমন একটি মুহূর্ত যেখানে আপনি কী করছেন তা বর্ণনা করেন।
আর প্ল্যাটফর্ম টিম হিসেবে আমরা সিদ্ধান্ত গ্রহণকারী নই, কারণ যেখানে কাজ হচ্ছে তার কাছাকাছিই সেই সিদ্ধান্ত নেওয়া উচিত।
ফ্রন্টিয়ার মডেল ব্যবহারের ক্ষেত্রেও আমরা আপনাকে সর্বোচ্চ সীমা সহ সম্পূর্ণ ফ্লেক্সিবিলিটি দিই।
আর এটি কাজ করার কারণ হল, শেষ পর্যন্ত এটি প্রসেসে অনুমানযোগ্যতা নিয়ে আসছে।
ঠিক?
আমরা নিশ্চিত করতে চাই যে টোকেন খরচের বাজেট করার সময়, যা সকলের জন্যই একটি চ্যালেঞ্জ, আমরা যা পরিকল্পনা করেছি তা যেন হিসাবের মধ্যে থাকে এবং এই লিভারগুলি আমাদের তা করতে সাহায্য করে।
এইসব কথোপকথনে আমি কী আকর্ষণীয় খুঁজে পাই তা কি আপনি জানেন?
আমার মনে হয়, এর কারণ হল আমরা সবাই কোম্পানিতে কাজ করি।
আর তাই, এন্টারপ্রাইজ।
তাই, আমাদের প্রতিটি টোকেনের জন্য পেমেন্ট করতে হয়।
ঠিক?
কিন্তু ইন্টারনেটের এমন একটি দিকও আছে যেখানে লোকজন সাবস্ক্রিপশন প্রাইসিং ব্যবহার করেন।
তাই, তাদের জন্য এটি একটি সম্পূর্ণ ভিন্ন ক্যালকুলাস।
ঠিক?
তবে আমি মনে করি আপনি জানেন যে, এটি সময়ের ব্যাপার, আপনি জানার আগেই সবাই একই পুলে থাকবেন যেখানে আপনাকে প্রতিটি টোকেন সম্পর্কে চিন্তা করা শুরু করতে হবে।
এবং তখনই, আপনি জানেন, অন্য জুতোটি সম্ভবত একটু বেশি দায়িত্বশীল হওয়ার ক্ষেত্রে ড্রপ হতে চলেছে, যেমনটি আমাদের এখনই কোম্পানিগুলিতে করতে হবে।
অথবা আপনি এমন একটি ফ্রন্টিয়ার ল্যাবে কাজ করেন যেখানে আপনি আনলিমিটেড বাজেট পান।
এবং তারপরে আপনি শুধু কাজ চালিয়ে যান এবং আপনি জানেন যে এই ধরনের অনেক উত্তেজনাপূর্ণ AI নেটিভ উপায়ে কাজ করা যায় যা Twitter জুড়ে রয়েছে।
আমাদের সব কোম্পানিই সেটা করতে চায়, কিন্তু তারা মনে করে না যে তারা টোকেন খরচ করতে চায় যা…
Google-এ কাজ করেন এমন লোকজন এখানে আছেন।
আমি খুব কৌতূহলী।
এটি কীভাবে কাজ করে?
Google-এর বাজেট কত?
আপনি কি এটি নিতে চান, লুইস?
আমি মনে করি না যে এর অর্থনীতি সম্পর্কে কথা বলার জন্য আমি সঠিক ব্যক্তি।
Google একটি খুব বড় কোম্পানি যার অনেক বিভিন্ন সংস্থা আছে।
কিন্তু এটি আসলে আমাদের পুরোপুরি গুটিয়ে নেয়, কারণ আমরা ঠিক সময়ে আছি।