এআই হল একটি অ্যাম্প্লিফায়ার, নয় দিক।

লেখক, উৎস: InfoQ

AI আপনাকে কোড লেখার গতি ১০ গুণ বাড়িয়ে দিল, তারপর? বেশি কোডের অর্থ বেশি কম্পাইল সময়, ভারী টেস্টিং, বন্ধ কোড রিভিউ, এবং কেউ বুঝতে পারবে না এমন একটি কোডবেস। সফটওয়্যার হল দায়, আপনি যত দ্রুত লিখবেন, তত বেশি ঋণ হবে।

গুগলের প্রধান সফটওয়্যার ইঞ্জিনিয়ার এডাম বেন্ডারের সতর্কবাণী খুব সরাসরি: আজ আপনি যেভাবে সফটওয়্যার তৈরি করেন, তা ১০ গুণ গতিতে কাজ করবে না। কিন্তু AI যুগের প্রকৃত বিজয়ীরা সবচেয়ে বেশি আউটপুট দেওয়া টিম নয়, বরং যাদের মৌলিক দক্ষতা সবচেয়ে শক্তিশালী। কারণ AI শুধুমাত্র বড় করে দেয়, দিকনির্দেশনা দেয় না।

গুগল I/O 2026-এর একটি প্রধান বক্তৃতায়, এডাম বেন্ডার একটি প্রশ্ন তুলে ধরেন যা অধিকাংশ মানুষ এখনও ভাবার সুযোগ পায়নি: যখন AI কোড উত্পাদনের গতি এমনভাবে বাড়িয়ে তোলে যে বর্তমান ইঞ্জিনিয়ারিং প্রক্রিয়াগুলি এটি বহন করতে অক্ষম হয়ে পড়ে, তখন আমাদের ডেভেলপার ইকোসিস্টেমের মধ্যে কীটি সবচেয়ে আগে ভেঙে পড়বে? তিনি একটি অপরিচিত ধারণা—সফটওয়্যার ইকোলজি—এর মাধ্যমে পুরো বক্তৃতাটি জড়িয়ে দেন, যা হলো সফটওয়্যার উৎপাদনের সামাজিক-প্রযুক্তিগত ইকোসিস্টেমের একটি সমগ্রতাবিশিষ্ট অধ্যয়ন। অর্থাৎ, আপনাকে শুধুমাত্র প্রযুক্তির দিকেই তাকাতে হবে না, আপনাকে মানুষ, সংস্কৃতি, এবং সংগঠনগতভাবে অলিখিত নিয়মগুলিরও দিকে তাকাতে হবে। এই বক্তৃতার ভিডিওর ভিত্তিতে, InfoQ-এর দ্বারা এই বিষয়বস্তুকে সংগঠিত করা হয়েছে।

নিম্নলিখিত মূল বিষয়গুলি:

• এআই ডিফল্টভাবে আপনার কোনো সমস্যা সমাধান করে না। যদি আপনার অনুশীলন ভালো হয়, তবে এটি সেগুলিকে বাড়িয়ে দেয়। কিন্তু যদি এটি ভালো না হয়, তবে এটি শুধু আরও বেশি সমস্যা তৈরি করবে।
• সবাই বিল্ডার হওয়া দারুণ, যতক্ষণ না আপনাকে সবার দ্বারা তৈরি সবকিছু বজায় রাখতে হয়।
• প্রকৌশল অনুশীলন পবিত্র বা অপরিবর্তনীয় নয়। অনুশীলন পরিবর্তিত হয়, কিন্তু নীতিগুলি গুরুত্বপূর্ণ।
• একজন সফটওয়্যার ইঞ্জিনিয়ার হিসাবে, এই সিদ্ধান্ত নেওয়ার মুহূর্তে, আপনি সফটওয়্যার ইঞ্জিনিয়ারিংয়ের ভবিষ্যৎ কোথায় যাবে তা নির্ধারণের কেন্দ্রে অবস্থান করছেন। টুল থেকে কাজের প্রবাহ, ইঞ্জিনিয়ারিং অনুশীলন থেকে ইঞ্জিনিয়ারিং সংস্কৃতি পর্যন্ত, যদি আপনি যে ব্যবস্থা চলছে তা বুঝতে পারেন, তবে আপনি লিভারেজ খুঁজে পাবেন।

“সিস্টেম” কী?

আপনার ২০২৬ সালের কাজ আপনার ২০২০ সালের কল্পনার সঙ্গে সম্পূর্ণ ভিন্ন। যদি আমি আজকের ঘটনাগুলি ব্যাখ্যা করার চেষ্টা করি ২০২০ সালের আমার কাছে, তবে আমি বিশ্বাস করতাম না। পরিবর্তনগুলি এতটাই বেশি যে এগুলি মোকাবিলা করা কিছুটা কঠিন। আমি ভবিষ্যতের পূর্বানুমান করতে পারি না, কিন্তু আমি বিশ্বাস করি যে যদি আমরা বর্তমান সফটওয়্যার ইকোসিস্টেমটি ভালভাবে অধ্যয়ন করি, তবে কিছু উত্তর আমাদের কল্পনার চেয়েও বেশি কাছাকাছি।

আজ আমি আপনার সাথে একটি শব্দ নিয়ে কথা বলতে চাই: সফটওয়্যার ইকোলজি (Software Ecology)। এটি শুনে মনে হতে পারে যে আমি শুধু প্রেজেন্টেশনের জন্য এটি গড়ে তুলেছি, কিন্তু না, এটি একটি বাস্তব পদ। সংজ্ঞা দেওয়ার আগে, আমি কিছুটা প্রস্তুতি দিতে চাই, আমরা সিস্টেম থিংকিং-এর দিকে একটু গভীরে যাই।

একটি সিস্টেম হল পরস্পর সংযুক্ত উপাদানগুলির একটি সেট, যা একটি নির্দিষ্ট নিয়মের ভিত্তিতে কাজ করে এবং একটি একক একক সমগ্রতা গঠন করে। এটি অত্যন্ত বিমূর্ত শোনাচ্ছে, কিন্তু আপনি সিস্টেমের সাথে পরিচিত নন এমন নয়। উদাহরণস্বরূপ, এসি: একটি তাপমাত্রা নির্ধারণকারী, যা লক্ষ্য তাপমাত্রা জানে, একটি HVAC যা গরম বা ঠাণ্ডা করে, একটি রুম, যখন তাপমাত্রা উপযুক্ত হয়, তখন সংকেতটি বন্ধ হয়ে যায়—এটি একটি সিস্টেম।

যদি আপনি একজন সফটওয়্যার ইঞ্জিনিয়ার হন, তাহলে আপনি প্রতিদিন সিস্টেমের সাথে কাজ করেন, আপনি সিস্টেম ডিজাইন করেন, সিস্টেম তৈরি করেন, সিস্টেম অপারেশন করেন, এই প্রক্রিয়ায় আপনি প্রায় একটি বিষয় শিখেছেন: সবকিছুই পরস্পর সংযুক্ত।

পরবর্তী হল ইকোসিস্টেম, যা একটি বিশেষ সিস্টেম। সংজ্ঞাটি কিছুটা দীর্ঘ, কিন্তু খুব গুরুত্বপূর্ণ: ইকোসিস্টেম হল পরস্পর নির্ভরশীল অংশগ্রহণকারীদের একটি গতিশীল নেটওয়ার্ক, যারা তাদের পরিবেশের সাথে একসাথে বিকাশ লাভ করে, যার বৈশিষ্ট্য হল উত্থাপিত আচরণ এবং কেন্দ্রীয়ভাবে বিচ্ছিন্ন স্বায়ত্তশাসন। সহজ ভাষায়, ইকোসিস্টেম খুব জটিল, এর উপাদানগুলি গভীরভাবে সংযুক্ত, প্রতিটি উপাদানের নিজস্ব স্বায়ত্তশাসন রয়েছে, যা সিদ্ধান্ত নিতে এবং কাজ করতে পারে। এবং সবচেয়ে গুরুত্বপূর্ণ বিষয়: পরিবেশটি সিস্টেমেরই অংশ, আপনি এগুলিকে আলাদা করতে পারবেন না।

ইকোসিস্টেম একটি জটিল অ্যাডাপ্টিভ সিস্টেম যা সময়ের সাথে বৃদ্ধি পায়, পরিবর্তিত হয় এবং বিকশিত হয়। এগুলির একটি বৈশিষ্ট্য রয়েছে যাকে উত্থাপন (Emergent Property) বলা হয়, যা হল আপনি যদি কোনও একক অংশকে পর্যবেক্ষণ করেন, তবে এটি দেখতে পাবেন না; শুধুমাত্র যখন সিস্টেমটি সম্পূর্ণভাবে একত্রিত হয়, তখনই এই আচরণগুলি উত্থিত হয়। এই নিরন্তর পরিবর্তন, নিরন্তর শেখা এবং উত্থাপনের কারণেই ইকোসিস্টেমের মধ্যে কী ঘটছে তা বুঝতে অত্যন্ত কঠিন।

প্রকৃতির পরিবেশ বলতে আপনার মনে হয়তো পাহাড়, নদী, পাখির ডাক এবং ফুলের সুগন্ধ ভেসে আসে। কিন্তু অভ্যন্তরীণ ডেভেলপমেন্ট পরিবেশও একটি পরিবেশ: বিভিন্ন টুল এবং সার্ভিস, নিজস্ব ধারণা এবং দাবি নিয়ে আসা মানুষ, এবং ব্যবসায়িক সীমাবদ্ধতা। এটি একটি বিশেষ ধরনের সিস্টেম: সামাজিক-প্রযুক্তিগত সিস্টেম, যা মানুষ এবং প্রযুক্তির সমন্বয়ে গঠিত। সামাজিক-প্রযুক্তিগত সিস্টেম অত্যন্ত জটিল, কারণ আপনি সেই সমস্ত প্রযুক্তি দিয়ে শুরু করেন, তারপর মানুষকেও তাতে মিশিয়ে দেন।

আপনি সম্ভবত অজান্তেই সামাজিক-প্রযুক্তিগত সিস্টেমের বুদ্ধিমত্তার সাথে পরিচিত হয়েছেন। আপনি কনভে লজ জানেন? এটি বলে: একটি সংগঠন যে প্রযুক্তি তৈরি করে, তা তার অভ্যন্তরীণ যোগাযোগের কাঠামোকে প্রতিফলিত করে। সহজ ভাষায়, যদি একই কম্পাইলারের জন্য চারটি দল কাজ করে, তবে আপনি একটি চার-পর্যায়ের কম্পাইলার পাবেন—এটাই কথা। কনভে লজের মূল পর্যবেক্ষণটি হল, আমরা যেভাবে প্রযুক্তি তৈরি করি, তা এটি তৈরি করা সংগঠনের কাঠামোর সাথে অবিচ্ছেদ্যভাবে যুক্ত—সংগঠনটি চূড়ান্তভাবে তৈরি হওয়া জিনিসটিকে আকৃতি দেয়।

কিন্তু শুধু সংগঠনগত কাঠামোই ডেভেলপার ইকোসিস্টেমকে প্রভাবিত করে না, মূল্যবোধ এবং সংস্কৃতি একইভাবে গভীরভাবে প্রভাব ফেলে। আপনার ইকোসিস্টেম যা গড়ে তোলে, তা হল সংগঠন যা উৎসাহিত করে; আপনার ইঞ্জিনিয়ারিং সংস্কৃতি ডেভেলপার ইকোসিস্টেমের চারপাশে পরিবেশ তৈরি করে। একবার আপনি সামাজিক-প্রযুক্তিগত ব্যবস্থা বুঝতে পারলে, আপনি সফটওয়্যার ডেভেলপমেন্টের প্রতিটি কোণায় এগুলি দেখতে পাবেন: আর্কিটেকচার, ঘটনা বিশ্লেষণের সংস্কৃতি, কোড রিভিউ, নিরাপত্তা নীতি—এগুলি সর্বত্র। আমরা যা গড়ে তুলি, এবং আমরা যেভাবে তা গড়ে তোলার পছন্দ করি, তা আমাদের যা গুরুত্বপূর্ণ মনে করি, তারই প্রতিফলন। যদি আমরা যথেষ্ট সচেতন হই, তবে আমরা এই বোধকে ব্যবহার করে আমাদের মূল্যবোধগুলিকে বিস্তারিতভাবে প্রকাশ করতে পারি, এবং এগুলিকে আমরা যা গড়ে তুলি, তাতেই সংক্ষিপ্তভাবে সংযুক্ত করতে পারি।

এখন আমি আপনাকে একটি সঠিক সংজ্ঞা দিচ্ছি: সফটওয়্যার ইকোলজি হল সফটওয়্যার উৎপাদনের সামাজিক-প্রযুক্তিগত ইকোসিস্টেমের একটি সমগ্রতাবিষয়ক অধ্যয়ন। যদি আগের কিছুটা বিশুদ্ধ মনে হয়, তাহলে চিন্তা করবেন না, এখন একটি বাস্তব উদাহরণ দেখুন।

গুগলের ডেভেলপার ইকোসিস্টেম

আমি গুগল নিয়ে কথা বলছি কারণ আমি সেখানে কাজ করি বলে এটাকে প্রশংসা করছি, বরং কারণ এটি আমার সবচেয়ে ভালোভাবে বোঝা ডেভেলপার ইকোসিস্টেম। আমার উদ্দেশ্য হলো আপনাদের বলা যে আপনাদের গুগলের মতোই করতে হবে—এটি আপনাদের জন্য কোনো সুবিধা দেবে না। আপনারা ভিন্ন কোম্পানি, ভিন্ন পর্যায়ে আছেন, ভিন্ন সম্প্রসারণের সঙ্গে মোকাবিলা করছেন। গুগল যেসব সিদ্ধান্ত নিয়েছিল, সেগুলি ছিল তখনকার আমাদের ইকোসিস্টেম তৈরির জন্য নির্দিষ্ট প্রয়োজনীয়তা অনুযায়ী।

কয়েক বছর আগে আমরা একটি বই লিখেছিলাম, যার অভ্যন্তরীণ নাম ছিল "ফ্লেমিংগো বুক"। বইটির অর্ধেক ভাগ ভার্সন কন্ট্রোল এবং টেস্টিং নিয়ে, কিন্তু পুরো প্রথম অংশটি ইঞ্জিনিয়ারিং কালচার নিয়ে। অনেকেই জিজ্ঞাসা করেছেন কেন এত বেশি স্থান দেওয়া হয়েছে কালচারের কথা বলার জন্য, কারণ যদি আপনি Google-এর কালচারকে বুঝতে না পান, তাহলে আপনি বুঝতে পারবেন না যে আমরা কেন সেই টেকনোলজির পছন্দগুলো করেছি, এই বিষয়গুলো পরস্পরের সাথে যুক্ত।

গুগলের কিছু অনন্য সংস্কৃতিগত বৈশিষ্ট্য রয়েছে। আমরা গভীরভাবে ইঞ্জিনিয়ারিং-উন্মুখ, এবং গুরুত্বপূর্ণ সিদ্ধান্ত নেওয়ার সময় সবসময় ইঞ্জিনিয়ারদের উপস্থিতি থাকে; আমরা প্রায় সবকিছুর জন্য স্বচ্ছতাকে অত্যন্ত গুরুত্ব দি, সমস্ত ডকুমেন্ট এবং কোডকে সবার জন্য খোলা রাখার চেষ্টা করি; আমরা সহায়তাপূর্ণ আচরণকে উৎসাহিত করি, বাস্তবে, যেকোনো গুগল ছেড়ে যাওয়া ব্যক্তির সাথে কথা বললে, তাদের প্রথম উল্লেখিত বিষয় হবে সহকর্মীদের সহায়তাপূর্ণতা; আমরা কোড রিভিউকে একটি মূল্যায়নের অবসর হিসেবে নয়, বরং পরিচালনার সুযোগ হিসেবে দেখি; আমরা মানকীকরণকে অত্যন্ত গুরুত্ব দি; আমরা ধারাবাহিক উন্নতির বিশ্বাসী; আমরা দায়ভারবিহীন দুর্ঘটনা-বিশ্লেষণকে প্রশংসা করি; আমরা বিশ্বাস করি যে, পুরস্কার-প্রাপ্তির চেয়ে টেকসইতা, এবং হস্তচালিত কাজের চেয়ে স্বয়ংক্রিয়তা। অবশ্যই, আমরা সবসময়ই এইসব আদর্শগুলির অপেক্ষিত, কিন্তু এটিই আমাদের সংস্কৃতিগতভাবে অনুসরণের দিক।

টেকনিক্যাল দিকটা কেমন? একটি একক কোড রিপোজিটরি, প্রায় সমস্ত কোড একটি রিপোজিটরিতে; মেইনলাইন-ভিত্তিক ডেভেলপমেন্ট, প্রতিটি পরিবর্তন সরাসরি মেইনলাইনে মার্জ করা হয়; একটি বাইনারি ফাইল বিল্ড করার সময়, প্রায় প্রতিটি লাইন কোড সোর্স থেকে বিল্ড করা হয়; একটি একক বিল্ড টুলচেইন, যা সবাই ব্যবহার করে; গ্লোবাল টেস্ট অটোমেশন প্ল্যাটফর্ম, যেখানে সমস্ত টেস্ট একটি জায়গায় চলে, প্রতিদিন দশs of billions of test cases; একটি গ্লোবাল "লাস্ট গ্রিন" সিগন্যাল, যা আমি একটি সহজ অভ্যন্তরীণওয়েবসাইটের মাধ্যমে যেকোনো বিল্ডের অবস্থা বলতে পারি; একটি একক কম্পিউটিং পরিবেশ, তাই "আমার মেশিনে চলছে" ধরনের সমস্যা প্রায়ই ঘটে না; উচ্চ-নিয়ন্ত্রিত ডেভেলপার ফ্রেমওয়ার্ক এবং একটি ছোট কোর প্রোগ্রামিং ভাষা।

এই সংস্কৃতি এবং প্রযুক্তির মিশ্রণই গুগলকে আজকের মতো করে গড়ে তুলেছে, আপনি এর একটি অংশকে বুঝতে পারবেন না যদি অন্যটিকে উপেক্ষা করেন।

সংযুক্ত ভাগ্য

যদি আমাকে এমন একটি নীতি বাছাই করতে হয় যা সবসময় আমাদের পথ দেখাচ্ছে, তাহলে আমি বেছে নেব “শেয়ার্ড ফেট (Shared Fate)”। এটি একটি ইকোসিস্টেম এবং এর উপাদানগুলির মধ্যে ঘনিষ্ঠ সম্পর্কের মাত্রা বর্ণনা করে, যেখানে একটি উপাদান অন্যান্য সমস্ত উপাদানকে প্রভাবিত করতে পারে। ডেভেলপার ইকোসিস্টেমে, শেয়ার্ড ফেট একটি প্রযুক্তিগত পছন্দ এবং একটি সামাজিক পছন্দ উভয়ই। আপনি শুধুমাত্র সবাইকে একই প্রযুক্তি ব্যবহার করতে বাধ্য করেই শেয়ার্ড ফেট অর্জন করতে পারবেন না, আপনাকে এই প্রযুক্তিগুলির ব্যবস্থাপনা করার বিষয়ে একটি সামাজিকচুক্তিও গড়ে তুলতে হবে।

গুগলে, সাধারণ ভাগ্য একক কোড রিপোজিটরি দিয়ে শুরু হয়। কোম্পানির প্রতিটি কোড লাইন, অল্প কয়েকটি ব্যতিক্রম যেমন Android এবং Chrome ছাড়া, একটি সাধারণ রিপোজিটরিতে থাকে। সমস্ত কোড মাস্টার শাখায় কমিট করা হয়, কোনো ব্রাঞ্চ নেই, কোনো ভার্সন নম্বর নেই, সবকিছু একই জায়গায়। এই সাধারণ ভাগ্যের কারণে আমরা একটি ফাইলে একটি সিকিউরিটি প্যাচ প্রয়োগ করতে পারি এবং জানি যে এক সপ্তাহের মধ্যে কোম্পানির প্রতিটি অ্যাপ্লিকেশনই ঠিক হয়ে যাবে। দশটি লাইনের কোড দিয়ে 100 বিলিয়ন লাইনের অ্যাপ্লিকেশন এবং সিস্টেম সফটওয়্যার ঠিক করা, এটা একটি সুপারপাওয়ারের মতো।

কিন্তু ভাগ করে নেওয়া ভাগ্য সবসময় ভালো কিছু নয়, এটি একটি পছন্দ। কিছু জায়গায় ভাগ করে নেওয়া ভাগ্য উপযুক্ত নয়, যেমন উৎপাদন পরিবেশে, আমরা কখনই চাই না যে একটি সার্ভিস অন্যান্য সবগুলোকে ধ্বংস করে দেবে, বা একটি ক্লাস্টার সম্পূর্ণ এলাকাকে আক্রান্ত করবে। তাই আমরা ক্ষতিকর ভাগ করে নেওয়া ভাগ্য—যা ক্রমবর্ধমান ব্যর্থতার দিকে নিয়ে যায়—এড়ানোর জন্য অনেক পরিশ্রম করেছি। ভাগ করে নেওয়া ভাগ্য একটি ট্রেড-অফ, আপনাকে সঠিক অবস্থানটি খুঁজে বের করতে হবে, এবং নিশ্চিত করতে হবে যে এটি আপনার জন্য কাজ করছে।

বড় পরিবর্তন

আমাদের পরিবেশে সবচেয়ে আকর্ষণীয় হঠাৎ বৈশিষ্ট্যগুলির মধ্যে একটি হল বৃহৎ পরিবর্তন। এটি মনে রাখবেন: AI আবির্ভাবের অনেক আগেই, Google-এর অভ্যন্তরীণ টুলগুলি একজন ডেভেলপারকে লক্ষ লক্ষ লাইন কোড পরিবর্তন করার সক্ষমতা দিয়েছিল—লক্ষ লক্ষ লাইন যা তারা কখনও পড়বেন না, আর কখনও দেখবেন না, এবং যার সম্পর্কে তারা সম্ভবত কিছুই জানেন না। আমরা এইসবকে স্বয়ংক্রিয়ভাবে সম্ভব করে তোলার জন্য টুলগুলি তৈরি করেছি, আজও এভাবেই, এবং আমরা অন্তত ১৫ বছর ধরে এটি করে আসছি।

এই ক্ষমতার কারণে আমরা একক কোড রিপোজিটরির অবিরাম বিকাশ ঘটাতে পারি, ভাষা এবং ফ্রেমওয়ার্ক আপডেট করি, এবং অভ্যন্তরীণ পরিবেশকে কঠিন হতে দেই না। এটা অতিরঞ্জন নয় যে, বড় পরিমাণের পরিবর্তন ছাড়া আমরা আজকের Google হতাম না। এই টুলগুলি তৈরি করা আমাদের সহকর্মীদের কাজটি একটি অদৃশ্য নায়কের মতো, যা কোম্পানিকে প্রয়োজনীয় গতিতে এগিয়ে যেতে সক্ষম করে।

কিন্তু মূল বিষয় হলো, আপনি যদি বৃহৎ পরিবর্তনকে সম্ভব করে তোলে এমন সংস্কৃতিগত এবং প্রযুক্তিগত উপাদানগুলি বুঝতে না পারেন, তাহলে আপনি এটিকে প্রকৃতপক্ষে বুঝতে পারবেন না। আপনার কী দরকার? সকলের জন্য টেস্টিংয়ের সাধারণীকৃত সংস্কৃতি, যাতে প্রত্যেকে টেস্ট লিখে। একটি একক টেস্টিং প্ল্যাটফর্ম, যাতে আপনি জানেন কোথায় ফলাফলগুলি পাবেন। একটি সাধারণ বিল্ডিং টুল, যাতে আপনি যা বিল্ড করেন, আমিও তা-ই বিল্ড করি। স্ট্যান্ডার্ডাইজড লাইব্রেরি, যাতে কম্পোনেন্টগুলি প্রতিস্থাপনের সময় আপনি কোনটির ভার্সনটি আপনার জন্য কাজ করবে, আমার জন্য কাজ করবে না—এমনভাবে লাফিয়ে-লাফিয়ে ঘুরতে না পড়েন। স্ট্যান্ডার্ডাইজড কোড রিভিউ, কোডবেসেরই স্বচ্ছতা, যাতে আপনি জানতে পারেন কোন্‌টির কোডটির পরিবর্তনের দরকার। বৃহৎ-পরিসরের পরিবর্তনগুলি Google-এর “অটোমেশন, হস্তচালিত কাজের চেয়েও ভালো”—এই ধারণারইচূড়ান্তপ্রকাশ,এবংএটিকেশুধুমাত্রসমগ্রপরিবেশসহযোগিতা—এইভাবেইসম্ভব।আপনিযদিওএকজনডেভেলপারএনভায়রনমেন্টেরএকটিমাত্রঅংশকেইইঙ্গিতকরেবলতেপারবেননা, “এটিইএটিরকারণ,”—সবগুলিরঅংশগুলিইযখনএকসঙ্গেযুক্তহয়,তখনইএটিরকারণ।

আপনার ইকোসিস্টেম, আপনার ভারসাম্য

প্রতিটি ডেভেলপার ইকোসিস্টেমের এই ধরনের উত্থানমূলক বৈশিষ্ট্য থাকে। এগুলি সাধারণত আপনাকে অনুভব করায় যে আপনি যে জায়গায় কাজ করছেন তা কিছুটা অনন্য, কারণ এগুলি আপনি যে সিরিজের পছন্দগুলি করেছেন তার ফলাফল।

গুগলের ডেভেলপার ইকোসিস্টেম আমাদের প্রযুক্তি এবং ব্যবসায়িক লক্ষ্যগুলির জন্য একটি অনন্য সমন্বয় তৈরি করেছে। কিন্তু প্রতিটি ইকোসিস্টেমের মতো, এটি সমস্ত কাজে উত্তম পারফরম্যান্স দেখাতে পারে না। আমরা চূড়ান্ট স্কেল, নিরাপত্তা এবং পারফরম্যান্সকে অপ্টিমাইজ করার পক্ষে সিদ্ধান্ত নিয়েছি, যদিও এর অর্থ হতে পারে ডেভেলপারদের উৎপাদনশীলতাকে কিছুটা বলি দেওয়া; আমরা এই সমন্বয়টি গ্রহণ করতে প্রস্তুত। পাঁচজনের একটি স্টার্টআপের ইকোসিস্টেম সম্পূর্ণভাবে ভিন্ন হবে, যেখানে গতি এবং সহজলভ্যতাই সবচেয়ে গুরুত্বপূর্ণ।

আপনাদের অধিকাংশের পরিবেশ পাঁচজন থেকে দুই লক্ষ মানুষের মধ্যে অবস্থিত। আপনাদের যে সমন্বয়গুলি করতে হবে, সেগুলি খুবই গুরুত্বপূর্ণ, কারণ আপনি যখন এই সমন্বয়গুলি পর্যালোচনা করেন, তখন আপনি সংগঠনটির মূল্যবোধ বুঝতে শুরু করতে পারেন: এটি আসলে কীতে আস্থা রাখে, শুধুমাত্র কী বলে, নয়—আপনি প্রকৃতপক্ষে যে বিকল্পগুলি লক্ষ্য করেন, সেগুলি কী প্রকাশ করে। আপনি যখন এই মূল্যবোধগুলি বুঝতে পারবেন, তখন আপনি যে পরিবর্তনটি ঘটছে, তাকে গড়ে তোলা শুরু করতে পারবেন।

10x মুহূর্ত: প্রতিটি নোড চাপের মধ্যে রয়েছে

এখন কক্ষের মধ্যে টোকেন খাওয়া হাতি নিয়ে কথা বলার সময়: একটি AI-প্রথম ডেভেলপার ইকোসিস্টেম কী দেখতে?

শূন্য থেকে একটি সম্পূর্ণ নতুন ইকোসিস্টেম তৈরি করা অবশ্যই ভালো, কিন্তু আপনাদের মধ্যে কেউ এই সুযোগ পাচ্ছেন না। আপনাকে প্রায় প্রতিটি অংশকে প্রতিস্থাপন করতে থাকতে হবে, একইসাথে সফটওয়্যার চালিয়ে যেতে হবে। কোম্পানি আপনার কাছে মূল্য তৈরি করতে থাকার পাশাপাশি কোনো সমস্যা না ঘটানোর আশা রাখছে।

তাহলে নিজেকে একটি প্রশ্ন করুন: আপনি আজকের ডেভেলপার ইকোসিস্টেম সম্পর্কে কতটা জানেন? আপনি কি এটিকে সম্পূর্ণভাবে চিত্রিত করতে পারেন? আপনি কি সব অংশগুলির অবস্থান জানেন, শুধু প্রযুক্তিগত নয়, সামাজিকও? আপনি কি বলতে পারেন যে আপনার ইকোসিস্টেমটি কী দিয়ে গঠিত? আপনার সংগঠনের অন্যান্যরা কতটা জানে? এর সুবিধা ও অসুবিধা কী? বাধা কোথায়? কোথায় সীমাবদ্ধ, কোথায় স্বাধীন? আপনার কতটা বিকল্প রয়েছে? আপনি কী ধরনের উত্থানমূলক বৈশিষ্ট্য দেখেছেন? হয়তো সবচেয়ে গুরুত্বপূর্ণ: যদি আপনার ইকোসিস্টেমটি ভবিষ্যতের ১৮ মাসের মধ্যে ১০-১৫ গুণ বেশি কোডের মাধ্যমে চলতে বাধ্য হয়, তাহলে আপনি জানেন কি কীটি প্রথমেইভাঙবে?

পৃথিবীর প্রতিটি ডেভেলপার ইকোসিস্টেম একটি মৌলিক পরিবর্তনের মধ্যে দিয়ে যাচ্ছে, হয়তো এখনও আপনার প্রতিটি কোণায় পৌঁছায়নি, কিন্তু এটি আসছে, প্রতিটি ডেভেলপার ইকোসিস্টেমকে এই 10x মুহূর্তের সামনে দাঁড়াতে হবে। এটি অবিশ্বাস্য সময়, কিন্তু প্রচুর বিভ্রান্তিকর। গত পঞ্চাশ বছরে আমরা সচেতনভাবে বিকশিত করা সমস্ত ট্রেডঅফগুলি পুনরায় ভারসাম্যপূর্ণ হবে।

কোড তৈরি করা ১০ গুণ দ্রুত এবং ইঞ্জিনিয়ারিং ডেভেলপমেন্ট ১০ গুণ দ্রুত করা দুটি ভিন্ন বিষয়। গুগলে আমরা প্রায়শই বলি, ইঞ্জিনিয়ারিং হল সময়ের সাথে প্রোগ্রামিংয়ের সমষ্টি। কিন্তু সমস্যা হল, আমরা এখন প্রোগ্রামিংয়ের এই ধাপকে অনেক দ্রুত করছি, কোডের মেশিনটিকে দ্রুত চালাচ্ছি। তাই আমাদের এই কোডের মেশিনের চারপাশে ইঞ্জিনিয়ারিংয়ের ব্যবস্থা করার প্রয়োজন, যাতে আমরা প্রকৃতপক্ষে গ্রাহকদের ফলাফল পৌঁছে দিতে পারি। কেউই জানেন না এই উৎপাদনশীলতার বৃদ্ধি কতটা দূরে নিয়ে যাবে, কিন্তু একটা বিষয় নিশ্চিত: আমরা এখান থেকে উপরের দিকেই যাচ্ছি।

সমস্যা হলো, আজ আমরা যেভাবে সফটওয়্যার তৈরি করি এবং সরবরাহ করি, সেটি ১০ গুণ বা ১০০ গুণ গতিতে কাজ করবে না, কিছু পরিবর্তন হতে হবে।

একটি সরলীকৃত ডেভেলপার ইকোসিস্টেম চার্ট দিয়ে শুরু করা যাক। একটি ক্রিয়াকলাপ 10 গুণ বৃদ্ধি পাওয়া বিশ্বে, কী পরিবর্তন হতে হবে?

কোড ইন্ট্রি

কোড লিখুন। যদি প্রত্যেকে কোড লিখতে অনেক দ্রুত হয়ে যায়, তাহলে কোডের পরিমাণও অনেক বেড়ে যাবে, যা ভালো কিছু নয়। জেফ অ্যাটউড বলেছেন, সফটওয়্যার একটি দায়। তাই, ১০ গুণ কোড, ১০ গুণ দায়। আর আপনি প্রত্যেককে একসাথে টোকেন দিয়ে “ভাগ্যবান হোন” বলে পাঠাতে পারবেন না; আমি চাই আপনি প্রশিক্ষণের পরেই বিনিয়োগ করুন: আপনার ইঞ্জিনিয়ারিং অভ্যাসের ডকুমেন্টেশনটি কোথায়? এগুলির বিকাশ কীভাবে করবেন? তারপরেই ভাবুন।

সিস্টেম তৈরি করুন। বেশি কোড, বড় সিস্টেম অর্থাৎ বেশি কম্পাইল সময়। আমি নিশ্চিত যে আপনার কোম্পানিতে এখন কেউ কম্পাইলের ধীর গতির জন্য অভিযোগ করছেন না। কিন্তু অনুমান করুন, এগুলো আরও ধীর হয়ে যাবে। এবং যদি এজেন্ট বহু কাজ চালায়, তাহলে কম্পাইলের সংখ্যা বিস্ফোরিত হয়ে যায়। কম্পাইল মুক্ত নয়, সময় বা কম্পিউটেশনাল সম্পদের দিক থেকেই। আপনি হয়তো কখনও নিজেকে কম্পাইলের জন্য কতটা সময় ব্যয় করছেন তা মনে রাখেননি, কিন্তু ১০গুণ স্কেলে, আপনি অবশ্যই লক্ষ্য করবেন।

কোড ডিজাইন। আপনার কাছে ডিকাপ্লিংকে উৎসাহিত করার জন্য উপযুক্ত এজেন্ট-ভিত্তিক দক্ষতা আছে? বিভিন্ন ক্ষমতা দ্রুত এবং নিরাপদে সংযোগ করার জন্য কি উপযুক্ত সার্ভার-সাইড ফ্রেমওয়ার্ক আছে? আপনি জানেন আপনার কোম্পানিতে ওয়েব অ্যাপ্লিকেশনের কতগুলি ডিপ্লয়মেন্ট পদ্ধতি আছে? কতগুলি ভিন্ন সার্ভার-সাইড ফ্রেমওয়ার্ক চলছে? আপনি এজেন্ট দ্বারা লেখা কোডের কম্পোনেন্ট রিইউজ কিভাবে ম্যানেজ করেন? হয়তো আপনি ধরে নিচ্ছেন এটি গুরুত্বহীন। কিন্তু যদি এজেন্টগুলি সহজে লেখা কিন্তু কঠিনভাবে মেইনটেইন করা যায় এমন কোড তৈরি করে, তবে আশ্চর্য হবেন না—এটিই বর্তমান বেঞ্চমার্ক। এজেন্টগুলি কোড লিখতে দক্ষ, কিন্তু সবসময়ই দীর্ঘমেয়াদি দৃষ্টিভঙ্গি থেকে চিন্তা করে না। সেই কোডগুলি, আমি নিশ্চিত, ভালভাবে রিফ্যাকটর হবে না। ঠিকআছে, এইঅংশটি আমরা ভবিষ্যতে সমাধানকরব।কিন্তুতথ্যহলযে,এজেন্টগুলিআমাদেরজন্যঅনেককাজকরছে,আমাদেরপ্রতিদিনএইক্ষমতাগুলিকেসবচেয়েদক্ষভাবেব্যবহারকরারউপায়খুঁজতেহবে।

কিছু সময়ের মধ্যে, এই এজেন্ট-ভিত্তিক কাজগুলি আপনার বাইনারি ফাইলগুলিকে এতটাই বড় করে তুলতে পারে যে এগুলি কম্পাইল করা সম্ভব হবে না। অথবা এতটাই বড় হয়ে যাবে যে মোবাইলে আপলোড করা সম্ভব হবে না। আপনি কি কখনও প্রশ্ন করেছেন: আপনি কতটা বড় বাইনারি কম্পাইল করতে পারেন? আমি উত্তরটি জানি না, কিন্তু আমি জানি যে Google-এ, আমরা সীমানা ছুঁয়েছি, এবং কিছু জায়গায় বাইনারি এতটাই বড় হয়ে গেছে যে এগুলি কম্পাইল করা সম্ভব হচ্ছে না, আমি বিশ্বাস করি যে আমরা এটি সমাধান করব। কিন্তু বাস্তবতা হলো, বড়পনা অনেকগুলি প্রভাবকে সৃষ্টি করে, স্কেলের প্রভাব সর্বত্র।

আপনি হয়তো মাইক্রোসার্ভিস টেকস্ট্যাক ব্যবহার করছেন, এবং আপনি ভাবছেন: আমার সব সার্ভিসই ছোট, তাই আমাকে কী চিন্তা করতে হবে? কিন্তু আমার একটা প্রশ্ন: ১০ গুণ নেটওয়ার্ক ট্রাফিক, ১০ গুণ সার্ভিস সংখ্যা, ১০ গুণ যোগাযোগ, আপনি কি প্রস্তুত? কেউই এড়িয়ে যাবেন না, স্কেলের প্রভাব সর্বত্র।

কোড রিভিউ। ধরে নিন আপনি এই সমস্ত কোড বিশ্বস্তভাবে কম্পাইল করতে পারবেন না, তাহলে আপনার কোড রিভিউ প্রক্রিয়াটি কীভাবে পরিবর্তিত হবে? সবাই কোড রিভিউকে নিয়ে চিন্তিত, যার কারণ আছে। আমরা এই অত্যন্ত মানবিক প্রক্রিয়ার উপর বিপুল চাপ চালাচ্ছি, অনেকক্ষেত্রে এটি বাধা হয়ে দাঁড়িয়েছে, এবং মানুষ বাধা হওয়ার পছন্দ করে না। যখন আপনি তাদের উপর চাপ দেন, তখন তাদের আচরণ অদ্ভুত হয়ে যায়। ১০ গুণ কোডের পরিমাণ, আপনি বা তো ১০ গুণ বড় পরিবর্তন পাবেন, অথবা ১০ গুণ বেশি পরিবর্তন। আপনার টেকনিক্যাল লিডারগুলি প্রয়োজনীয় রিভিউ গতি বজায় রাখতে পারবেন? অধিকাংশ টেকনিক্যাল লিডারদের ১০-গুণ ডেভেলপারদের ১দিনের ৫টি কোডের পরিমাণও রিভিউ করতে পারেন না।

তাই তারা বাধা হয়ে থাকার পরিবর্তে প্রক্রিয়াগুলি পুনর্বিন্যাস শুরু করে, সংক্ষিপ্ত পথ বেছে নেয়, যাতে কেউ বাধাগ্রস্ত না হয়, কারণ কেউই বাধা হতে চায় না। আপনি AI ব্যবহার করে কিছুটা সমাধান করতে পারেন—AI চালু করে কোড রিভিউ উন্নত করতে পারেন। কিন্তু এটি শুধুমাত্র অংশশঃ সমস্যার সমাধান, কারণ যদি আপনার টিমের সদস্যরা কোড লিখতে বন্ধ করে দেয়, তবে তাদের কোডের সাথে দেখা হয় শুধুমাত্র রিভিউয়ের সময়, আর রিভিউয়ের সময় মনোযোগও যথেষ্ট নয়, তাহলে কেউ কি কোডবেসের বিকাশকে মনোযোগ দিচ্ছে? কেউই না। খুব শীঘ্রই, আপনার কোডবেসটি এমন একটি অবস্থায় পৌঁছে যাবে যা কেউই বুঝতে পারবেন না।

টোকেন অর্থনীতি। টোকেন খুব মহঙ্গা, তোমাদের কিছুজন ইতিমধ্যেই জানো। বড় পরিসরে, টোকেন হল এমন একটি বাস্তব খরচ যা তোমাদের বিবেচনায় নিতে হবে। যদি কোম্পানির প্রতিটি ব্যক্তি 10 গুণ বা 100 গুণ টোকেন ব্যবহার শুরু করে তবে কী হবে? যদি তোমরা একদিনেই পুরো মাসের বাজেট ব্যয় করে ফেলো? যদি তোমাদের টোকেন কোথায় ব্যয় করতে হবে তা অগ্রাধিকার দিতে হয়, তবে তোমরা জানো কোথায় অগ্রাধিকার দিতে হবে? তোমাদের কি এমনকি টোকেনগুলি কোথায় যাচ্ছে তা দেখার দৃশ্যতা আছে?

এই সরল সিস্টেমের প্রথম � �ে নোডেই আমরা সমস্যা খুঁজে পেয়েছি। এবং খুব পরিষ্কারভাবে, কিছু চ্যালেঞ্জিং দ্বিতীয় পর্যায়ের প্রভাব থাকবে।

পরীক্ষা এবং সংস্করণ নিয়ন্ত্রণ

আপনি কি কখনও দেখেছেন যে আপনার টেস্ট ইনফ্রাস্ট্রাকচার কতটা কম্পিউটেশনাল রিসোর্স খরচ করছে? গুগলে, আমি কখনও আমার টেস্ট স্পিডের সাথে সন্তুষ্ট হইনি।

প্রতিটি ভার্সন কন্ট্রোলে যাওয়া পরিবর্তন পরীক্ষা করা হতে হবে। কিন্তু এর বাইরেও, এজেন্টগুলি পরীক্ষা চালানোর পছন্দ করে, কারণ পরীক্ষাগুলি তাদেরকে বলে যে তারা কতটা ভালো কাজ করছে। তাই এজেন্টগুলি অতিরিক্ত কাজ তৈরি করে, আমার কাজটা আরও বেড়ে যায়। তাহলে, 10 গুণ কমিটের পাশাপাশি এজেন্টগুলি যেসব কাজ করে, এখন এগুলি কতটা পরীক্ষা কম্পিউটিং সম্পদ খরচ করছে?

বাস্তবে পরিস্থিতি আরও খারাপ হতে পারে। আমরা গুগলে দেখেছি যে কোডবেস বাড়ার সাথে সাথে নির্ভরশীলতা গ্রাফ দ্বিঘাতভাবে বাড়ে, রৈখিকভাবে নয়। তাই যদি আপনার কোডবেস 10 গুণ বড় হয়, তাহলে আপনাকে চালানোর প্রয়োজন হতে পারে 10 গুণ নয়, বরং 100 বা 1000 গুণ পরীক্ষা। এটি একটি খুব আকর্ষণীয় চ্যালেঞ্জ হবে, এবং এটি কিছুদিনের মধ্যে আপনার বাজেটের একটি লাইনে পরিণত হবে। যদি আপনি এখনও পরীক্ষা কম্পিউটিং সম্পদের খরচের বিষয়ে চিন্তিত নন, তাহলে এটিই আমার জন্য আরও বেশি চিন্তার বিষয়, কারণ এর মানে হতে পারে আপনার পর্যাপ্ত পরীক্ষা নেই, এবং সেই agentগুলি আপনার কোডবেসে YOLO-এর মতো নিরাপত্তা-হীনভাবেই চলছে।

ধরুন কম্পাইল এবং টেস্টিং সমাধান হয়ে গেছে, এখন ভার্সন কন্ট্রোল সিস্টেমের দিকে তাকাই। সবচেয়ে জনপ্রিয় ভার্সন কন্ট্রোল সিস্টেমগুলি পারফরম্যান্সের জন্য অপ্টিমাইজড নয়; এগুলি সামঞ্জস্যতা এবং ক্রমবিন্যাসের জন্য অপ্টিমাইজড। এটি তাদের মূল কাজ, পূর্ণাঙ্গ রেকর্ড বজায় রাখা, দ্রুত দৌড়ানো নয়। আপনার ভার্সন কন্ট্রোল সিস্টেম এক মিনিটে কতবার কমিট গ্রহণ করতে পারে? আমি আপনাকে নিশ্চিত করি, এটি আপনি যা ভাবছেন তার চেয়ে অনেক কম। এটি আপনার প্রয়োজনীয় ১০ গুণ দ্রুততা পর্যন্ত স্কেল করতে পারে না। আপনি শেষবারের মতো ভার্সন কন্ট্রোল সিস্টেমের পারফরম্যান্সের কথা কখন ভাবেন? আপনি যদি Git-এর ডেভেলপমেন্টের সঙ্গে কাজ না করেন, তবে সম্ভবত কখনও ভাবেননি। সত্যি বলতে, ভার্সন কন্ট্রোলের পারফরম্যান্সের কথা আলোচনা করা পর্যন্ত—এটি বোঝায়, কিছুটা বিষয়টিরই গুরুতরভাবেই বিচ্যুতি ঘটেছে। আমরা ডেভেলপার এক্সপিরিয়েন্সের সবচেয়ে নিচুতলে, but this is the consequence of systemic change: it finds every corner of your system and says, “Hey, are you paying attention?” because something you didn’t expect is coming.

যারা বহু ছোট রিপোজিটরি ব্যবহার করে ভার্সন কন্ট্রোলের সমস্যা সমাধান করতে চায়, তাদের যারা শত শত বা হাজার হাজার ছোট রিপোজিটরি চালিয়েছেন, তাদের জিজ্ঞাসা করুন—আমি নিশ্চিত করে বলতে পারি, এটি শুধু একটি সম্পূর্ণ নতুন চ্যালেঞ্জের সেট, এবং AI অবশ্যই এই সমস্যাগুলিকে সহজ করে তোলেনি।

অপ্রত্যাশিত তালিকা

এখন পর্যন্ত আমরা শুধুমাত্র সেই সহজেই শনাক্তযোগ্য ক্ষমতা-ভিত্তিক নোডগুলি দেখেছি, যেগুলির জন্য একটি সংখ্যাকে 10 দিয়ে গুণ করে জিজ্ঞাসা করা হয় যে এটি ভালো হবে নাকি খারাপ হবে, এবং অনেক অপ্রত্যাশিত চ্যালেঞ্জও রয়েছে।

স্ট্র্যাটেজি যাচাই করুন। আজকের জন্য আপনার যাচাই হল অনেকগুলি ইউনিট টেস্ট এবং কিছু ইন্টিগ্রেশন টেস্ট। কিন্তু ১০ গুণ কোড এবং ১০ গুণ সার্ভিসের বিশ্বে, ইন্টিগ্রেশন টেস্টিং গুণগত স্ট্র্যাটেজির সবচেয়ে গুরুত্বপূর্ণ অংশ হয়ে উঠবে। আপনাদের মধ্যে কতজন আজকের ইন্টিগ্রেশন টেস্টিং পদ্ধতির সাথে সন্তুষ্ট? আমিও সন্তুষ্ট নই। ইন্টিগ্রেশন টেস্টিং সত্যিই কঠিন, এখনও আমার কাছে আমি যা চাইছি তা অনুযায়ী ইন্টিগ্রেশন টেস্টিং করার জন্য কোনও টুল নেই।

বুলিয়ান কনজাকশন সমস্যা। আজ আপনি সফটওয়্যার রিলিজ করতে চান, আপনি প্রতিটি টেস্ট পাস করতে চান, সমস্ত বুলিয়ান গ্রিন হতে হবে, সবকিছু ঠিকঠাক হলেই আপনি রিলিজ করবেন—এটি যুক্তিসঙ্গত। কিন্তু যখন আপনার এক মিলিয়নটি টেস্ট থাকে, এবং নীচের টেস্ট ইনফ্রাস্ট্রাকচারের নিজেই এক মিলিয়নটি টেস্ট চালানোর বিশ্বস্ততা সমস্যাজনক হয়ে যায়, তখন কী হয়? সফটওয়্যার রিলিজের জন্য সমস্ত বুলিয়ানকে সত্য হতে হবে—এই ধারণাটি অসম্ভব হয়ে যায়। আপনার একটি নতুন কৌশলের প্রয়োজন, সম্ভবত পরিসংখ্যানভিত্তিক, যা বুঝতে সাহায্য করবে কোনটির টেস্টগুলি চালানোর উপযুক্ত—কারণ আপনি সমস্ত টেস্টই চালাতে পারবেন না।

অত্যন্ত বড় পরিবর্তন। সবকিছু পুনর্গঠন করা, ভাষা এবং ফ্রেমওয়ার্ক পরিবর্তন করা সত্যিই উত্তেজনাপূর্ণ। কিন্তু আপনার কি এমন কাজের প্রবাহ এবং সামাজিক চুক্তি আছে যা লক্ষ লক্ষ, দশ লক্ষ, এমনকি কোটি লাইনের মার্জ কনফ্লিক্টগুলি পরিচালনা করতে পারে? সম্ভবত না। যদি কোম্পানির প্রতিটি ব্যক্তি অত্যন্ত বড় পরিবর্তনগুলি করতে পারে, তাহলে আমাদের নতুন কাজের প্রবাহ কৌশলের প্রয়োজন হবে।

এজেন্ট সংশোধন যুদ্ধ। একজন এজেন্ট একটি পরিবর্তন করে, আরেকজন এজেন্ট দৌড়ে আসে বলে, "না, আমি এটা পছন্দ করি না, আমি একটা ভিন্ন পরিবর্তন করব।" এটা মজার মনে হয়, যতক্ষণ না আপনি বুঝতে পারেন যে আপনি দুইপক্ষের জন্যই টোকেন ফি দিচ্ছেন।

প্রকাশের গতি। আপনি আজকে কতবার ক্লায়েন্টদের কাছে প্রকাশ করেন? প্রতিদিন? এটা খুব ভালো। যদি না হয়, তাহলে একটা সমস্যা আছে: আপনি ১০ গুণ বেশি সফটওয়্যার পাবেন, যা কিন্তু কোথাও না কোথাও রাখা দরকার। যদি আপনি প্রতিদিন প্রকাশ না করেন, তাহলে প্রতিবার পরিবর্তনগুলো অনেক বড় হয়ে যায়। আর আমার SRE বন্ধুরা আপনাকে বলবে, খুব বড় পরিবর্তনগুলো খুবই ভয়ঙ্কর। এটা করবেন না। কিন্তু কোডকে মূল্যবান করতে হলে এটিকে ডিপ্লয় করতেই হবে, তাই আপনি হয়তো আরও বেশি ফ্রিকোয়েন্সিতে প্রকাশের চেষ্টা করবেন, যা ভালো, DORA-এর বন্ধুরা খুশি হবেন। কিন্তু একটা বিন্দুতেই লাভের হ্রাস শুরু হয়, প্রতি সেকেন্ডে প্রকাশ করলেও আপনার বহুতর মূল্যবানতা পাওয়ার সম্ভাবনা কম। কোডটা বাড়তেই থাকবে, এবং আপনাকে বুঝতেই হবে, এটিকে কোথায় place-এর (স্থান)দিলেই ।

অভ্যন্তরীণ API। আমি সবসময় আমার সহকর্মীদের বলে আসছি, তোমার সব API হঠাৎ করেই পাবলিক হয়ে গেছে। এজেন্ট তোমার সাথে পরামর্শ করবে না, এটি API খুঁজে বের করে সরাসরি কল করবে। এটি যা অ্যাক্সেস করতে পারবে, তাই ব্যবহার করবে, আমি নিশ্চিত করে বলছি। যদি তুমি কখনও অভ্যন্তরীণ ইন্টারফেস এবং অভ্যন্তরীণ ডেটাসেটকে পাবলিক API-এর মতো সুরক্ষিত করে না থাকো, তাহলে এজেন্ট সেইসব জিনিসগুলো খুঁজে বের করবে যা তুমি চাওনি যেন এটি খুঁজে না পায়।

জেভন্স প্যারাডক্স। জেভন্স বলেছিলেন, একটি সম্পদ যত বেশি সস্তা এবং দক্ষ হবে, আমরা তত বেশি ব্যবহার করব। টোকেনের বিস্ফোরণ হল একটি জীবন্ত উদাহরণ। আমরা এগুলিকে সব জায়গায় রাখছি, যা আমাদের কাজ করার এবং কাজ সম্পর্কে চিন্তা করার পদ্ধতিকে পরিবর্তন করছে। আমরা যেসব অদৃশ্য উৎপাদনশীলতা শ্রমকে আগে মূল্যায়ন করিনি, এখন তাদের মূল্য দিচ্ছি, এটি আমাদের আচরণের উপর কী প্রভাব ফেলবে? আমি এখনও জানি না।

রোলব্যাক করুন। আপনি জানেন কেন আজকের জন্য রোলব্যাক প্রায় সম্ভব? কারণ আপনি সফটওয়্যার প্রকাশের গতি প্রোডাকশন পরিবেশে সমস্যা শনাক্ত করার গতির চেয়ে কিছুটা ধীর। যদি আপনি খুব খুব দ্রুত প্রকাশ করতে পারেন, এমনভাবে যে আপনি কোনো সমস্যা শনাক্ত করার আগেই প্রকাশ শেষ হয়ে যায়, তাহলে আপনার রোলব্যাক কৌশলটি কেমন হবে? প্রতিটি রোলব্যাককে একসাথে জমা হওয়া এবং পরস্পরবিরোধী অনেকগুলি পরিবর্তনের সাথে মোকাবিলা করতে হবে। তাই শুধুমাত্র দ্রুততরভাবে প্রকাশ করা যথেষ্ট নয়, আপনাকে সম্পূর্ণ সিস্টেমটি—যার মধ্যে রোলব্যাকও একটি গুরুত্বপূর্ণ সিকিউরিটি ভালভ—বিবেচনা করতে হবে। একটা কথা, আপনাকে token ইঞ্জিনটি কোথায় রাখতে হবে, সেটা নিয়ে সতর্কতা অবলম্বন করতে হবে। যদি আপনার রোলব্যাক প্রক্রিয়াটির উপর একটি agent-এর যথেষ্ট capacity-এর নির্ভরশীলতা থাকে, আর আগেরকারা সেই agent-এর token budget-টি শেষ করেছে,ফলে এখন আপনি রোলব্যাকই করতে পারছেননা,তাহলে—এটা ।।।

প্রত্যেকেই একজন নির্মাতা। আপনি হয়তো কখনও ভাবেন যে কোম্পানিতে আপনি যে টুলটি পছন্দ করেন না, তার জন্য একটি বিকল্প তৈরি করুন। এখন, এটিকে কোম্পানিতে প্রতিটি ব্যক্তি এবং প্রতিটি টুলের সংখ্যা দিয়ে গুণ করুন। যখন প্রত্যেকে সম্পূর্ণভাবে ভিন্ন ভিন্ন টুল ব্যবহার করে, তখন কোম্পানির সামাজিক গঠনের কী হয়? আপনি যদি ভাগ্যবান হন এবং একটি এককীকৃত ডেটা বেসমেন্ট থাকে, যেখানে সমস্ত ডেটা একই জায়গায় আসে, তাহলে ঠিক আছে। কিন্তু যদি না থাকে? প্রত্যেকেই নির্মাতা হওয়াটা দারুণ, যতক্ষণ না আপনাকে সবার দ্বারা তৈরি সবকিছুরই রক্ষণাবেক্ষণ করতে হয়।

টেকনিক্যাল লিডারশিপ ইনটেনসিভ। একজন টেকনিক্যাল লিডার হওয়ার জন্য এত সময় লাগে কারণ আপনাকে সিদ্ধান্ত নেওয়ার জন্য ইনটুইশন, বিচারক্ষমতা এবং পেশাদারিত্ব অর্জন করতে হয়, কারণ আপনি যখন একটি টিমের নেতৃত্ব দেন, তখন আপনার ভুলগুলির প্রভাব আপনি একা কাজ করার চেয়ে অনেক বেশি। যখন একজন নতুন প্রজন্মের প্রতিষ্ঠানে ৫০টি agent-এর পরিবেশে প্রবেশ করে, কিন্তু কোনও ইনটুইশন বা বিচারক্ষমতা ছাড়াই, তখন কীভাবে কিছু ভুল হবে? আমি কীভাবে ৬ মাসে ১০ বছরের অভিজ্ঞতা শেখাব? আমি জানি না।

মানুষের মনোযোগ হল আমাদের কাছে সবচেয়ে মূল্যবান সম্পদ। এখন অসংখ্য শব্দ রয়েছে, অসংখ্য এজেন্ট এবং অসংখ্য জিনিস আমাদের মনোযোগ নিয়ে প্রতিদ্বন্দ্বিতা করছে, আমাদের অবশ্যই এটি পরিচালনা করার উপায় খুঁজে বার করতে হবে। আমরা আগে একটি বিষয়ের উপর লাভবান হয়েছিলাম: আমরা যতটা মনোযোগ দিতে পারি, ততটাই সমস্যা তৈরি করতে পারতাম, কিন্তু এখন এই অবস্থা আর নেই।

এটি অনেক মনে হচ্ছে, কারণ একটি সিস্টেমে সবকিছু পরস্পর সংযুক্ত। আমি যা বলেছি তার মধ্যে যেকোনো চ্যালেঞ্জকে শুধুমাত্র সিস্টেমের একটি নোড দেখে সমাধান করা সম্ভব নয়, আপনাকে সম্পূর্ণ সিস্টেমটি দেখতে হবে।

এজেন্ট-ভিত্তিক ডেভেলপমেন্টের জন্য, আমাদের সবাইকে সিস্টেমের মাধ্যমে ধারাবাহিকভাবে চিন্তা করা শিখতে হবে। যখন আপনি সিস্টেম নিয়ে চিন্তা করছেন, তখন এই বিষয়গুলি আপনার মনোযোগ আকর্ষণ করবে: বস্তুগুলি কীভাবে বড় হচ্ছে, সময়ের সাথে প্রভাবগুলি কীভাবে পরিবর্তিত হচ্ছে, কারণ-প্রভাবের দিকটি কোথায় প্রবাহিত হচ্ছে, কোন নোডগুলি সব প্রতিবেশীর সাথে কথা বলছে, উদ্ভূত প্রক্রিয়াগুলি কীভাবে দেখায়, এবং যেসব জিনিস কোথা থেকে আসছে তা কী। উদ্দীপনা কী? সামাজিক এবং প্রযুক্তিগত, ক্ষমতা, ফিডব্যাক লুপ এবং বটলনেক, এগুলি হল সিস্টেম বিশ্লেষণের টুলস।

এটি জটিল মনে হচ্ছে, কিন্তু আসলে শুধু দুটি প্রশ্ন দরকার: কেন (Why?), আর যদি (What if?)। আমাদের ইন্টিগ্রেশন টেস্ট এত কম কেন? যদি আমাদের ইউনিট টেস্টের চেয়ে বেশি ইন্টিগ্রেশন টেস্ট থাকত? আমরা এই নির্দিষ্ট ভাষাগুলি কেন ব্যবহার করি? যদি AI সব কোড লিখে ফেলে?

“কেন” হল আপনার সিস্টেমের মূলে প্রবেশ করে এটি কীভাবে কাজ করে তা বুঝতে ব্যবহৃত ড্রিল। আপনারা সবাই “কেন” জিজ্ঞাসা করতে খুব দক্ষ, কিন্তু “যদি” হল আরও কঠিন অংশ। “যদি” প্রশ্নটি ভয়ঙ্কর হতে পারে, যদি এটি আপনাকে এমন অভ্যাসগুলি ত্যাগ করতে বাধ্য করে যা আপনি আগে খুব ভালভাবে ডিজাইন করেছিলেন। যদি আপনি এটি পরীক্ষা না করেন? যদি আপনি সম্পূর্ণরূপে টেস্ট না লিখেন? অতিরিক্ত দূরে যাবেন না। কিন্তু যদি আপনি এটিকে ঘটতে দেন, “যদি”ও খুবই উত্তেজনাপূর্ণ হতে পারে।

এআই হল অ্যাম্প্লিফায়ার, নয় দিক

এআই একটি অ্যাম্প্লিফায়ার। এই ধারণাটি আমার ডোরার বন্ধুদের কাছ থেকে এসেছে, যারা গত বছরের এআই ডেভেলপমেন্ট রিপোর্টে দেখেছিলেন যে যারা সত্যিকার অর্থে বিষয়গুলি বুঝেছিল, তাদের মধ্যে একটি সম্পর্ক ছিল: তারা বুঝেছিল কীভাবে এআইকে একটি অ্যাম্প্লিফায়ার হিসাবে ব্যবহার করতে হয়।

এআই আপনাকে আরও বেশি দেবে। আরও টেস্ট, আরও ডকুমেন্টেশন, আরও কোড, কিন্তু আরও বেশি বিশৃঙ্খলা। বড় করা হল পরিমাণ, নয় দিক। এআই এই জিনিসগুলো কোথায় যাচ্ছে তা নিয়ে চিন্তা করে না, এটি শুধু আপনাকে আরও বেশি দেয়। ডোরা আসলে যা খুঁজে পেল, তা হল—যারা মৌলিক দক্ষতায় দক্ষ, তারাই এই বড় করার প্রভাবকে উপযোগী দিকে পরিচালিত করতে পারে।

এটি প্রশ্ন তুলে ধরে: আপনি আপনার মৌলিক দক্ষতার প্রতি কেমন অনুভব করছেন? আপনার কোম্পানির সিদ্ধান্ত গ্রহণের সংস্কৃতি কেমন? এটিকে উন্নত করতে আপনি কী করতে পারেন? প্রযুক্তিগত কৌশল কেমন? কি কেউ ডেভেলপার উৎপাদনশীলতার দিকে মনোযোগ দিচ্ছেন? আজকের দিনে সংগঠনের মানুষগুলি কতটা ভালোভাবে সহযোগিতা করছে? নিরাপত্তা অবস্থা কেমন? কোডের স্বাস্থ্য, প্রকাশের পরিষ্কারপনা, বিশ্বস্ততা কেমন? AI ডিফল্টভাবে আপনার কোনো সমস্যাই সমাধান করবে না। যদি আপনার অনুশীলনগুলি ভালো হয়, তবে এটি সেগুলিকে বাড়িয়ে দেবে। কিন্তু যদি এগুলি ভালো না হয়, তবে এটি শুধুমাত্র আরও বেশি সমস্যা তৈরি করবে।

কিন্তু যদিও মৌলিক দক্ষতা শক্তিশালী, আমরা একটি প্রকৃত যাত্রার শুরুতে রয়েছি। আমি অনুমান করি, 2030 সালের মধ্যে, আজকের আমাদের ডেভেলপার ইকোসিস্টেম ঠিক 2001 সালের মতোই দূরে চলে যাবে, যেমনটা আজকের আমাদের কাছে 2001 সাল মনে হয়। 2001 সালে আমরা CD-ROM এর মাধ্যমে সফটওয়্যার প্রকাশ করতাম, 2030 সালে আমরা হয়তো এতটাই দূরে চলে যাব।

আপনি যখন আপনার মৌলিক দক্ষতা শক্তিশালী করছেন, তখন আপনি যে চারটি বিষয় নিয়ে চিন্তা করতে পারেন, তা আমি আপনাকে বলছি।

প্রথমত, অবকাঠামোর ক্ষমতা। যদি আপনি না জানেন আপনার কাছে কতটা সম্পদ রয়েছে, তাহলে আপনি এআই বা কম্পিউটিং সম্পদ বাস্তবায়ন করতে পারবেন না; এগুলি ট্র্যাক করার জন্য আপনার একটি ভালো পদ্ধতি দরকার।

দ্বিতীয়ত, প্রমাণীকরণ কৌশল। আপনি যে কোনও সফটওয়্যার প্রমাণীকরণ ছাড়াই প্রকাশ করতে পারবেন না এবং করা উচিত নয়। কিন্তু প্রমাণীকরণ কৌশলগুলি পরিবর্তিত হচ্ছে, এখনই এটি পরিষ্কারভাবে ভাবার সময়। ইন্টিগ্রেশন টেস্টিং আপনার সবচেয়ে গুরুত্বপূর্ণ অস্ত্র হয়ে উঠবে, এবং আপনি সম্ভবত এখনও উপযুক্ত টুলস পাচ্ছেন না।

তৃতীয়ত, বিচ্ছিন্নতা। আপনি বিভিন্ন উদ্দেশ্যের জন্য অনেক কোড পাবেন, যেমন কিছু উদ্দেশ্য আগে কখনও কোড দিয়ে পূরণ করা হয়নি। এটা ঠিক, কিন্তু আপনি চান না যে একটি মজার প্রোটোটাইপ কোড প্রোডাকশন পরিবেশে ঢুকে যায়। মজার জিনিসগুলোকে আয়ের জিনিসগুলোকে প্রভাবিত করতে দিবেন না।

চতুর্থ, বিমূর্তীকরণ। আমরা বিমূর্তীকরণ তৈরি করি যাতে ডেভেলপাররা খারাপ সিদ্ধান্ত না নেয়, এটাই আমাদের লাইব্রেরি এবং ফ্রেমওয়ার্ক থাকার কারণ। কেউ শূন্য থেকে ওয়েব সার্ভার লেখে না। এজেন্টকে অসংখ্য সিদ্ধান্ত নিতে দিলে একই ফলাফল আসবে, তাই আপনার এজেন্টগুলিকে অনুসরণ করার জন্য ভালো বিমূর্তীকরণ প্রয়োজন। তাদের খারাপ বিকল্প দিবেন না।

আপনাকে একটি বিষয় মেনে নিতে হবে: ইঞ্জিনিয়ারিং প্র্যাকটিসগুলি পবিত্র নয়। প্র্যাকটিসগুলি পরিবর্তন হয়, কিন্তু নীতিগুলিই গুরুত্বপূর্ণ। এটি বলা সহজ, কিন্তু করা কঠিন—যদি আপনি কখনও ভাবেননি যে আপনার টিম কেন এভাবে সফটওয়্যার টেস্ট করে, বা কেন রিলিজ প্রক্রিয়াটি এভাবে কাজ করে, তাহলে আপনি এটিকে উন্নত করতে পারবেন না। নীতিগুলি বুঝতে পারলেই আপনাকে ১০ গুণের মুহূর্তের মধ্যে দিয়ে যাওয়ার শক্তি ও আত্মবিশ্বাস দেবে।

এখন সফটওয়্যার ইঞ্জিনিয়ারদের জন্য একটি আকর্ষণীয় যুগ। আমাদের কাজের প্রতিটি দিক পুনর্গঠন হচ্ছে; আমাদের আগের যেকোনো সময়ের চেয়ে বেশি সৃজনশীলতা প্রয়োজন; আমাদের কনটেক্সট ম্যানেজমেন্ট, টোকেন অর্থনীতি, মডেল ড্রিফটের মতো সমস্যাগুলির সাথে মোকাবিলা করার দক্ষতা প্রয়োজন; আমাদের সৃজনশীলতা প্রয়োজন; সবকিছুকে অপ্টিমাইজ করার আকর্ষণে খুব বেশি আটকে যাওয়া উচিত নয়, অন্বেষণকে উৎসাহিত করা প্রয়োজন।

একটি প্রশ্ন আমাকে ঘুম থেকে জাগিয়ে দেয়, এটি শুধুমাত্র অপ্টিমাইজেশন দিয়ে সমাধান করা যায় না: কোডবেস বৃদ্ধি পেলে আমরা কীভাবে এর উপর বুদ্ধিগত নিয়ন্ত্রণ বজায় রাখব? বুদ্ধিগত নিয়ন্ত্রণ মানে হলো, মানুষ কি সামনের জিনিসটির যুক্তি দিতে পারে? আমরা এই যুদ্ধে কমপক্ষে পনেরো বছর ধরে হারছি, আমাদের সবচেয়ে বড় সিস্টেমগুলি এখন যেকোনো একজন মানুষের চিন্তা করার সীমা ছাড়িয়েছে। আপনি যদি বিশ্বাস না করেন, তবে একটি পরীক্ষা করুন: আপনার টিমের প্রতিটি সদস্যকে একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম আঁকতে বলুন, এবং দেখুন আপনি কতগুলি ভিন্ন সংস্করণ পাচ্ছেন।

আমাদের অনেক সফটওয়্যার সিস্টেম খুবই ভঙ্গুর, একটি খারাপ কোড লাইন বা একটি ভুল কনফিগারেশন ফ্ল্যাগ একটি মিলিয়ন লাইনের সিস্টেমকে ধ্বংস করে দিতে পারে, এই ভঙ্গুরতা আপনাকে পরিবর্তন করার আগে তিনবার ভাবতে বাধ্য করে। কিন্তু AI-এর বিষয়ে আমার একটি খুবই উত্তেজনাপূর্ণ ধারণা আছে: একটি নিরন্তর আপডেটযুক্ত, প্রায় ইন্টারঅ্যাকটিভ আর্কিটেকচার স্পেস, যার সাথে আমি প্রশ্ন করতে পারি। যদি আমরা এখানকার ক্ষমতা পূর্ব উপকূলে সরিয়ে নিই? যদি ব্যবহারকারীর বৃদ্ধি 40% হঠাৎ বেড়ে যায়? আজকের একটি মধ্যম আকারের সিস্টেমের জন্যও, এটি ফাংশনালি প্রায় অসম্ভব, কারণ ভেরিয়েবলগুলির সংখ্যা অত্যন্ত বেশি। কিন্তু AI-এর কাছে খুবই বড় ডেটা সেটগুলি বুঝতে পারা যায়, তাই আমি মনে করি, এখানে খননযোগ্য কিছুটা আছে।

এই প্রশ্নটি পছন্দের কারণ হলো, আমরা শুধু কোডের মেশিনকে আরও দ্রুত ঘুরানোর জন্য নয়, আমরা জিজ্ঞাসা করছি: আমরা যা তৈরি করেছি, তার প্রতি আমাদের বোঝার গভীরতা কীভাবে বাড়ানো যায়?

পরিবর্তনগুলি খুব দ্রুত ঘটছে, যা তোমাদের অধিকাংশের অভিজ্ঞতার চেয়ে দ্রুত। এখন তোমাদের করার সবচেয়ে গুরুত্বপূর্ণ কাজগুলির মধ্যে একটি হল যারা সংগ্রাম করছে, তাদের সাহায্য করা এবং যারা এখনও বুঝতে পারছে না, তাদের হাত বাড়ানো। আমরা সবাই ভিন্ন গতিতে এগিয়ে যাচ্ছি, এবং এই পরিবর্তনের সাথে ভিন্নভাবে মোকাবিলা করছি। নিজেকে পিছনে পড়ে যাচ্ছি বলে মনে করা খুবই সহজ।

অভিজ্ঞ ইঞ্জিনিয়ারদের, মেন্টর হয়ে যান। যারা আটকে গেছে, তাদের খুঁজে বার করুন এবং তাদের সাহায্য করুন। যদি আপনি AI ডেভেলপমেন্ট ওয়ার্কফ্লোটি বুঝে ফেলেছেন, তবে অন্যদের সাথে শেয়ার করুন, এটি কোনও মূল্যবান গোপনীয়তা নয়। টেকনিক্যাল লিড, আপনাকে অবশ্যই জড়িয়ে পড়তে হবে এবং আপনার কোম্পানিতে সফটওয়্যার ইঞ্জিনিয়ারিংয়ের দিকনির্দেশনা দিতে সাহায্য করুন। যদি আপনি সফটওয়্যার কোয়ালিটি বা সফটওয়্যার ডিজাইনকে গুরুত্ব দেন, তবে এর জন্য আপনার কণ্ঠস্বর ব্যবহার করুন। এখানে উপস্থিত সবাইকেই এইগুলো করতে হবে, আপনার বসগুলো সম্ভবত করবেন না।

যদি আমরা ডেভেলপার ইকোসিস্টেমকে একটি জীবিত ইকোসিস্টেম হিসাবে কল্পনা করি, তাহলে আমরা সবাই প্রতিটি গাছের প্রতিটি ডালের প্রতিটি পাতা দেখে চলি, যেন এটি কোনও বিশেষ জীবনের রূপ। কিন্তু খুব তাড়াতাড়িই, আমাদের কাজ হবে শুধু একটি গাছ নয়, পুরো বনের। এবং আপনি একটি গাছের দিকে চেয়ে পুরো বনকে পরিচালনা করতে পারবেন না, আপনাকে বনটিকে একটি ইকোসিস্টেম হিসাবে দেখতে হবে।

প্রণালীগত পরিবর্তনের একটি বৈশিষ্ট্য হল: এটি একসাথে সব জায়গায়, সব কিছুতে ঘটে, এতটাই বড় যে মনে হয় কিছুই ধরা যাচ্ছে না। এখনই, আপনি হয়তো মনে করছেন যে প্রতি সপ্তাহে আসা পরিবর্তনের ঢলের মধ্যে আপনাকে কিছুই স্থির রাখতে পারছে না। কিন্তু যেমনটি আমরা এখনই দেখেছি, একটি প্রণালীতে, সবকিছুই পরস্পরের সাথে সংযুক্ত, ছোট কাজগুলি বড় প্রভাব ফেলতে পারে।

যেমন পৃষ্ঠে দেখাচ্ছে তেমন নয়, AI রূপান্তর শুধুমাত্র কোম্পানির নেতৃত্বের ক্ষেত্র নয়। এই সীমান্ত মুহূর্তে, একজন লাইন-লেভেল সফটওয়্যার ইঞ্জিনিয়ার হিসাবে, আপনি সফটওয়্যার ইঞ্জিনিয়ারিংয়ের ভবিষ্যৎ কোথায় যাবে তা নির্ধারণের কেন্দ্রে অবস্থান করছেন। টুলস থেকে ওয়ার্কফ্লো, ইঞ্জিনিয়ারিং প্রথা থেকে ইঞ্জিনিয়ারিং সংস্কৃতি পর্যন্ত, যদি আপনি যে সিস্টেমটি চলছে তা বুঝতে পারেন, তবে আপনি লিভারেজ খুঁজে পাবেন। আপনার যে স্বাধীনতা আছে, তা আপনি যতটা ভাবছেন ততটা কম নয়—এই স্বাধীনতা ব্যবহার করুন, আপনার সংগঠন, আপনার দল এবং আপনার নিজের জন্য ভবিষ্যৎ তৈরি করুন।