হারনেস ইঞ্জিনিয়ারিং: এজেন্ট-ফার্স্ট ওয়ার্ল্ডে Codex এর ব্যবহার

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

পণ্যটির অভ্যন্তরীণ দৈনিক ব্যবহারকারী এবং বাহ্যিক আলফা পরীক্ষক রয়েছে. এটি শিপ হয়, ডিপ্লয় হয়, ভেঙে যায় এবং ঠিক হয়. যা ভিন্ন তা হলো, কোডের প্রতিটি লাইন—অ্যাপ্লিকেশন লজিক, টেস্ট, CI কনফিগারেশন, ডকুমেন্টেশন, অবজারভেবিলিটি এবং অভ্যন্তরীণ টুলিং—Codex দ্বারা লেখা হয়েছে. আমরা অনুমান করি যে হাতে কোড লিখতে যত সময় লাগত, তার প্রায় এক দশমাংশ সময়ে আমরা এটি তৈরি করেছি.

মানুষ নিয়ন্ত্রণ করে. এজেন্টরা কার্য সম্পাদন করে.

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

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

একটি খালি রিপোজিটরিতে প্রথম কমিটটি 2025 সালের আগস্টের শেষের দিকে করা হয়েছিল.

প্রাথমিক স্ক্যাফোল্ড—রিপোজিটরি স্ট্রাকচার, CI কনফিগারেশন, ফরম্যাটিং নিয়ম, প্যাকেজ ম্যানেজার সেটআপ এবং অ্যাপ্লিকেশন ফ্রেমওয়ার্ক—GPT‑5 ব্যবহার করে Codex CLI দ্বারা বিদ্যমান টেমপ্লেটের একটি ছোট সেটের নির্দেশনায় তৈরি করা হয়েছিল. এমনকি এজেন্টদের রিপোজিটরিতে কাজ করার নির্দেশনা দেয়া প্রাথমিক AGENTS.md ফাইলটিও Codex দ্বারা লেখা হয়েছিল.

সিস্টেমের ভিত্তি স্থাপনের জন্য পূর্বে কোনো মানব-লিখিত কোড ছিল না. শুরু থেকেই এজেন্ট দ্বারা রিপোজিটরি গঠিত হয়েছিল.

পাঁচ মাস পরে, রিপোজিটরিতে অ্যাপ্লিকেশন লজিক, অবকাঠামো, সরঞ্জাম, ডকুমেন্টেশন এবং অভ্যন্তরীণ ডেভেলপার ইউটিলিটিজ জুড়ে প্রায় এক মিলিয়ন লাইনের কোড রয়েছে. ঐ সময়কালে, প্রায় 1,500-টি পুল রিকোয়েস্ট খোলা এবং মার্জ করা হয়েছে, যেখানে মাত্র তিনজন ইঞ্জিনিয়ারের একটি ছোট দল Codex-কে পরিচালনা করেছে. এটি প্রতিদিন প্রতি ইঞ্জিনিয়ার গড়ে 3.5 PRs-এর থ্রুপুটে অনুবাদ হয় এবং আশ্চর্যজনকভাবে টিমটি বেড়ে এখন সাতজন ইঞ্জিনিয়ার হওয়ার সাথে সাথে থ্রুপুট বেড়েছে . গুরুত্বপূর্ণভাবে, এটি শুধুমাত্র আউটপুটের জন্য আউটপুট ছিল না: পণ্যটি অভ্যন্তরীণভাবে শত শত ব্যবহারকারী দ্বারা ব্যবহৃত হয়েছে, যার মধ্যে দৈনিক অভ্যন্তরীণ পাওয়ার ব্যবহারকারীরাও রয়েছে.

উন্নয়ন প্রক্রিয়া জুড়ে, মানুষ কখনোই সরাসরি কোনো কোডে অবদান রাখেনি. এটি দলের জন্য একটি মূল দর্শন হয়ে উঠেছিল: কোনো হাতে লেখা কোড নয়.

হাতে-কলমে মানব কোডিংয়ের অভাব এক ভিন্ন ধরনের প্রকৌশল কাজের সূচনা করেছিল, যা সিস্টেম, কাঠামো এবং প্রভাবের উপর কেন্দ্রীভূত.

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

বাস্তবে, এর মানে ছিল ডেপথ-ফার্স্ট পদ্ধতিতে কাজ করা: বড় লক্ষ্যগুলোকে ছোট ছোট নির্মাণ ব্লকে (ডিজাইন, কোড, রিভিউ, টেস্ট, ইত্যাদি) ভাগ করা, এজেন্টকে সেই ব্লকগুলো তৈরি করতে উৎসাহিত করা এবং সেগুলো ব্যবহার করে আরও জটিল কাজগুলো উন্মোচন করা. যখন কিছু ব্যর্থ হতো, সমাধান প্রায় কখনোই 'আরও বেশি চেষ্টা করুন' ছিল না. কারণ অগ্রগতি করার একমাত্র উপায় ছিল Codex-কে কাজ করতে দেওয়া, মানব প্রকৌশলীরা সবসময় কাজের মধ্যে প্রবেশ করে জিজ্ঞাসা করতেন: “কোন সক্ষমতাটি অনুপস্থিত, এবং আমরা কিভাবে এটিকে এজেন্টের জন্য একই সাথে বোধগম্য ও প্রয়োগযোগ্য করে তুলতে পারি?”

মানুষ প্রায় পুরোপুরিভাবে প্রম্পটের মাধ্যমেই সিস্টেমটির সাথে যোগাযোগ করে: একজন ইঞ্জিনিয়ার একটি কাজের বর্ণনা দেন, এজেন্টটি চালু করেন এবং এটিকে একটি পুল রিকোয়েস্ট ওপেন করার অনুমতি দেন. একটি PR সম্পন্ন করতে, আমরা Codex-কে নির্দেশ দিই যেন এটি লোকালি নিজের পরিবর্তনগুলো পর্যালোচনা করে, লোকালি এবং ক্লাউডে অতিরিক্ত নির্দিষ্ট এজেন্ট রিভিউ অনুরোধ করে, মানুষ বা এজেন্ট প্রদত্ত যেকোনো ফিডব্যাকে সাড়া দেয়, এবং সব এজেন্ট রিভিউয়ার সন্তুষ্ট না হওয়া পর্যন্ত একটি লুপে পুনরাবৃত্তি করে (এটি কার্যত একটি Ralph Wiggum Loop⁠(একটি নতুন উইন্ডোতে খোলে)). Codex আমাদের স্ট্যান্ডার্ড ডেভেলপমেন্ট টুলগুলো সরাসরি (gh, লোকাল স্ক্রিপ্ট এবং রিপোজিটরি-এম্বেডেড স্কিল) ব্যবহার করে কনটেক্সট সংগ্রহ করে, যাতে মানুষ CLI-তে কপি-পেস্ট না করেও কাজ করতে পারে.

মানুষ পুল রিকোয়েস্ট পর্যালোচনা করতে পারে, কিন্তু তা বাধ্যতামূলক নয়. সময়ের সাথে সাথে, আমরা প্রায় সব রিভিউ প্রচেষ্টা এজেন্ট-টু-এজেন্ট পরিচালিত হওয়ার দিকে নিয়ে গিয়েছি.

কোডের থ্রুপুট বাড়ার সাথে সাথে, আমাদের সীমাবদ্ধতা হয়ে দাঁড়াল মানব QA ক্ষমতা. কারণ স্থির সীমাবদ্ধতা ছিল মানুষের সময় এবং মনোযোগ, আমরা এজেন্টে আরও সক্ষমতা যোগ করার জন্য কাজ করেছি, যাতে অ্যাপ্লিকেশন UI, লগ এবং অ্যাপ মেট্রিক্সের মতো বিষয়গুলো Codex-এর কাছে সরাসরি পাঠযোগ্য হয়.

উদাহরণস্বরূপ, আমরা অ্যাপটিকে প্রতিটি গিট ওয়ার্কট্রি (git worktree) অনুযায়ী বুট করার যোগ্য করেছি, যাতে Codex প্রতিটি পরিবর্তনের জন্য একটি করে ইনস্ট্যান্স চালু এবং পরিচালনা করতে পারে. আমরা Chrome DevTools প্রোটোকলকে এজেন্ট রানটাইমে সংযুক্ত করেছি এবং DOM স্ন্যাপশট, স্ক্রিনশট এবং নেভিগেশনের জন্য কাজ করার দক্ষতা তৈরি করেছি. এটি Codex-কে বাগ পুনরায় তৈরি করতে, সংশোধন যাচাই করতে এবং সরাসরি UI আচরণ সম্পর্কে বিশ্লেষণ করতে সক্ষম করেছে.

আমরা পর্যবেক্ষণযোগ্যতা টুলিং-এর জন্যও একই কাজ করেছি. লগ, মেট্রিক্স এবং ট্রেস Codex-এর কাছে একটি স্থানীয় পর্যবেক্ষণ স্ট্যাকের মাধ্যমে প্রকাশ করা হয়, যা যেকোনো নির্দিষ্ট কাজের গাছের জন্য ক্ষণস্থায়ী. Codex সেই অ্যাপটির একটি সম্পূর্ণ আইসোলেটেড ভার্সনে কাজ করে—এর লগ এবং মেট্রিক্সসহ, যা টাস্কটি সম্পূর্ণ হলে মুছে ফেলা হয়. এজেন্টরা LogQL দিয়ে লগ এবং PromQL দিয়ে মেট্রিক্স কুয়েরি করতে পারে. এই প্রেক্ষাপট উপলব্ধ থাকলে, “ensure service startup completes in under 800ms” বা “no span in these four critical user journeys exceeds two seconds”-এর মতো প্রম্পটগুলি বাস্তবায়নযোগ্য হয়ে ওঠে.

আমরা নিয়মিত দেখি যে একক Codex রান একটি একক টাস্কে ছয় ঘণ্টারও বেশি সময় ধরে কাজ করে (প্রায়ই যখন মানুষ ঘুমিয়ে থাকে).

বৃহৎ এবং জটিল কাজগুলোতে এজেন্টদের কার্যকর করে তোলার ক্ষেত্রে 'কনটেক্সট ম্যানেজমেন্ট' বা প্রেক্ষাপট ব্যবস্থাপনা অন্যতম বড় একটি চ্যালেঞ্জ. আমরা যে প্রাথমিক শিক্ষাগুলোর একটি শিখেছিলাম তা ছিল সহজ: Codex-কে 1,000 পৃষ্ঠার নির্দেশিকা ম্যানুয়াল নয়, একটি মানচিত্র দিন.

আমরা “একটি বড় AGENTS.md⁠(একটি নতুন উইন্ডোতে খোলে)” (ফাইল) ব্যবহারের পদ্ধতিটি চেষ্টা করেছিলাম. এটি অনুমানযোগ্য উপায়ে ব্যর্থ হয়েছে:

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

তাই AGENTS.md -কে বিশ্বকোষ হিসেবে বিবেচনা না করে, আমরা এটিকে সূচিপত্র হিসেবে বিবেচনা করি.

রিপোজিটরির জ্ঞানভাণ্ডার একটি কাঠামোবদ্ধ docs/ ডিরেক্টরিতে থাকে, যা সিস্টেম অব রেকর্ড হিসেবে বিবেচিত হয়. একটি সংক্ষিপ্ত AGENTS.md ফাইল (প্রায় 100 লাইন) কনটেক্সটে অন্তর্ভুক্ত করা হয় এবং মূলত একটি মানচিত্র হিসেবে কাজ করে, যা অন্যত্র থাকা আরও গভীর তথ্যের উৎসগুলোর দিকে নির্দেশ করে.

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

পরিকল্পনাগুলিকে প্রথম-শ্রেণির নিদর্শন হিসেবে বিবেচনা করা হয়. ছোটখাটো পরিবর্তনের জন্য স্বল্পস্থায়ী ও হালকা পরিকল্পনা ব্যবহার করা হয়, যেখানে জটিল কাজগুলোকে 'একজিকিউশন প্ল্যান'⁠(একটি নতুন উইন্ডোতে খোলে) -এর মাধ্যমে লিপিবদ্ধ করা হয়—যাতে অগ্রগতি এবং সিদ্ধান্ত গ্রহণের লগ বা রেকর্ড থাকে এবং সেগুলো রিপোজিটরিতে জমা (check-in) করা হয়. সক্রিয় পরিকল্পনা, সম্পন্ন হওয়া পরিকল্পনা এবং পরিচিত প্রযুক্তিগত ঋণ—সবই সংস্করণভিত্তিক এবং একই স্থানে সহাবস্থান করে, ফলে এজেন্টরা বাহ্যিক কন্টেক্সটের উপর নির্ভর না করেই কাজ করতে পারে.

এটি 'প্রগ্রেসিভ ডিসক্লোজার' বা পর্যায়ক্রমিক প্রকাশকে সম্ভব করে তোলে: এজেন্টরা একটি ছোট ও স্থিতিশীল এন্ট্রি পয়েন্ট থেকে কাজ শুরু করে এবং তাদের শেখানো হয় এরপর কোথায় খুঁজতে হবে, যাতে শুরুতেই তারা তথ্যের চাপে দিশেহারা হয়ে না পড়ে.

আমরা এটি যান্ত্রিকভাবে প্রয়োগ করি. নির্দিষ্ট লিন্টার এবং CI কাজগুলি যাচাই করে যে জ্ঞানভাণ্ডারটি আপডেটেড, ক্রস-লিঙ্কড এবং সঠিকভাবে গঠিত. একটি পুনরাবৃত্তিমূলক “ডক-গার্ডেনিং” এজেন্ট নিয়মিতভাবে সেকেলে বা অপ্রাসঙ্গিক নথিপত্র খুঁজে বের করে যা কোডের প্রকৃত আচরণের সাথে মেলে না এবং সেগুলো সংশোধনের জন্য পুল রিকোয়েস্ট ওপেন করে.

কোডবেস বিকশিত হওয়ার সঙ্গে সঙ্গে, Codex-এর ডিজাইন সিদ্ধান্তের কাঠামোও বিকশিত হওয়া প্রয়োজন ছিল.

কারণ রিপোজিটরি সম্পূর্ণভাবে এজেন্ট দ্বারা তৈরি, এটি প্রথমে Codex এর পাঠযোগ্যতার জন্য অপ্টিমাইজ করা হয়েছে. একইভাবে দলগুলো যেমন নতুন ইঞ্জিনিয়ারিং নিয়োগপ্রাপ্তদের জন্য তাদের কোডের নেভিগেশন উন্নত করতে চায়, তেমনি আমাদের মানব প্রকৌশলীদের লক্ষ্য ছিল একটি এজেন্টকে সম্পূর্ণ ব্যবসায়িক ডোমেইন সম্পর্কে যুক্তি করতে সক্ষম করা সরাসরি রিপোজিটরি থেকেই.

এজেন্টের দৃষ্টিকোণ থেকে, চলার সময় কন্টেক্সটের মধ্যে যা কিছু সে কার্যকরভাবে অ্যাক্সেস করতে পারে না, তা কার্যত অস্তিত্বহীন. Google Docs, চ্যাট থ্রেড বা মানুষের মাথায় থাকা জ্ঞান সিস্টেমের জন্য অ্যাক্সেসযোগ্য নয়. রিপোজিটরি-লোকাল, ভার্সনকৃত আর্টিফ্যাক্ট (যেমন কোড, মার্কডাউন, স্কিমা, এক্সিকিউটেবল প্ল্যান) এগুলোই কেবল দেখা যায়.

আমরা শিখেছি যে সময়ের সাথে সাথে আমাদের রেপোতে আরও বেশি কনটেক্সট যোগ করতে হবে. Slack-এর সেই আলোচনাটি, যা একটি আর্কিটেকচারাল প্যাটার্নের বিষয়ে পুরো টিমকে একমত করেছিল? যদি এজেন্ট এটি খুঁজে না পায়, তবে এটি একইভাবে অপাঠ্য, যেমনটি তিন মাস পরে যোগদানকারী নতুন কর্মীর কাছে অজানা থাকবে.

Codex-কে আরও বেশি কনটেক্সট দেওয়ার অর্থ হলো সঠিক তথ্যগুলোকে এমনভাবে গুছিয়ে রাখা এবং তুলে ধরা যাতে এজেন্ট সেটি নিয়ে যৌক্তিকভাবে বিশ্লেষণ করতে পারে; অপ্রাসঙ্গিক বা তাৎক্ষণিক নির্দেশনার (ad-hoc instructions) চাপে তাকে দিশেহারা করা নয়. যেভাবে আপনি পণ্য নীতিমালা, ইঞ্জিনিয়ারিং নিয়মাবলী এবং টিম সংস্কৃতি (ইমোজি পছন্দসহ) নিয়ে নতুন টিমমেটকে পরিচিত করান, ঠিক সেভাবেই এজেন্টকে এই তথ্য দিলে আরও ভালোভাবে সামঞ্জস্যপূর্ণ আউটপুট পাওয়া যায়.

এই কাঠামো অনেক সমঝোতা স্পষ্ট করেছে. আমরা এমন নির্ভরশীলতা এবং বিমূর্ততাকে অগ্রাধিকার দিয়েছি, যেগুলোকে রিপোর ভেতরেই সম্পূর্ণভাবে আত্মস্থ করা এবং যুক্তিসঙ্গতভাবে বিশ্লেষণ করা সম্ভব. প্রযুক্তিগুলি যেগুলি প্রায়ই “বিরক্তিকর” হিসেবে বর্ণিত হয়, সেগুলি কম্পোজেবিলিটি, API স্থিতিশীলতা এবং প্রশিক্ষণ সেটে উপস্থাপনার কারণে এজেন্টদের জন্য মডেল করা সহজ হয়. কিছু ক্ষেত্রে, পাবলিক লাইব্রেরির অস্বচ্ছ আপস্ট্রিম আচরণকে এড়িয়ে চলার চেয়ে এজেন্টকে কার্যকারিতার কিছু অংশ পুনরায় বাস্তবায়ন করানোই সস্তা ছিল. উদাহরণস্বরূপ, একটি সাধারণ p-limit-স্টাইল প্যাকেজ ব্যবহার করার পরিবর্তে, আমরা কনকারেন্সি সহ ম্যাপ করার জন্য আমাদের নিজস্ব একটি হেল্পার তৈরি করেছি: এটি আমাদের OpenTelemetry ইনস্ট্রুমেন্টেশনের সাথে সম্পূর্ণভাবে সংযুক্ত, 100% টেস্ট কভারেজ রয়েছে এবং আমাদের রানটাইম যেভাবে প্রত্যাশা করে ঠিক সেভাবেই কাজ করে.

সিস্টেমের আরও অংশকে এমন একটি ফর্মে আনা যা এজেন্ট সরাসরি পরিদর্শন, যাচাই এবং পরিবর্তন করতে পারে, লিভারেজ বাড়ায়—শুধু Codex এর জন্য নয়, অন্যান্য এজেন্টদের জন্যও (যেমন, Aardvark) যারা কোডবেসেও কাজ করছে.

শুধু ডকুমেন্টেশনই একটি সম্পূর্ণ এজেন্ট-উৎপাদিত কোডবেসকে সুসংগত রাখতে পারে না. ইনভেরিয়ান্টগুলো প্রয়োগ করে, ইমপ্লিমেন্টেশনগুলো খুঁটিয়ে নিয়ন্ত্রণ না করে, আমরা এজেন্টদের ভিত্তি দুর্বল না করেই দ্রুত কাজ করতে দিই. উদাহরণস্বরূপ, আমরা Codex-কে সীমানায় ডেটা শেপ বিশ্লেষণ করতে⁠(একটি নতুন উইন্ডোতে খোলে) বলি, কিন্তু কিভাবে তা করা হবে সে বিষয়ে আমরা নির্দিষ্ট নির্দেশনা দিই না (মডেলটি Zod পছন্দ করে বলে মনে হয়, তবে আমরা সেই নির্দিষ্ট লাইব্রেরি উল্লেখ করিনি).

এজেন্টরা কঠোর সীমারেখা এবং পূর্বানুমেয় কাঠামোযুক্ত⁠(একটি নতুন উইন্ডোতে খোলে) পরিবেশে সবচেয়ে কার্যকর, তাই আমরা অ্যাপ্লিকেশনটি একটি কঠোর স্থাপত্য মডেলের উপর ভিত্তি করে তৈরি করেছি. প্রতিটি ব্যবসায়িক ডোমেইন একটি নির্দিষ্ট স্তরের সেটে বিভক্ত, যেখানে নির্ভরতার দিকনির্দেশনা কঠোরভাবে যাচাই করা হয় এবং অনুমোদিত প্রান্তের সংখ্যা সীমিত. এই সীমাবদ্ধতাগুলি যান্ত্রিকভাবে কাস্টম লিন্টার (অবশ্যই Codex-জেনারেটেড!) এবং স্ট্রাকচারাল টেস্টের মাধ্যমে প্রয়োগ করা হয়.

নিচের ডায়াগ্রামটি নিয়মটি দেখায়: প্রতিটি ব্যবসায়িক ডোমেইনের মধ্যে (যেমন অ্যাপ সেটিংস), কোড কেবল একটি নির্দিষ্ট স্তরের সেটের মাধ্যমে “ফরওয়ার্ড” দিকে নির্ভর করতে পারে (Types → Config → Repo → Service → Runtime → UI). ক্রস-কাটিং বিষয়সমূহ (auth, কানেক্টর, টেলিমেট্রি, ফিচার ফ্ল্যাগ) একটি একক স্পষ্ট ইন্টারফেসের মাধ্যমে প্রবেশ করে: প্রোভাইডারস. অন্য কিছু অনুমোদিত নয় এবং যান্ত্রিকভাবে প্রয়োগ করা হয়.

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

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

মানুষ-কেন্দ্রিক ওয়ার্কফ্লোতে, এই নিয়মগুলো খুঁতখুঁতে বা সীমাবদ্ধতামূলক মনে হতে পারে. এজেন্টদের সাথে, তারা গুণক হয়ে ওঠে: একবার এনকোড করা হলে, তারা একসাথে সর্বত্র প্রয়োগ করা যায়.

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

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

মানব রুচি ক্রমাগত সিস্টেমে প্রতিফলিত হয়. রিভিউ মন্তব্য, রিফ্যাক্টরিং পুল রিকোয়েস্ট এবং ব্যবহারকারী-মুখী বাগগুলি ডকুমেন্টেশন আপডেট হিসেবে ধরা হয় বা সরাসরি টুলিং-এ এনকোড করা হয়. যখন ডকুমেন্টেশন যথেষ্ট নয়, আমরা নিয়মটিকে কোডে উন্নীত করি.

Codex-এর থ্রুপুট বাড়ার সাথে সাথে, অনেক প্রচলিত ইঞ্জিনিয়ারিং নর্ম প্রতিকূল হয়ে উঠেছিল.

রিপোজিটরি ন্যূনতম ব্লকিং মার্জ গেট দিয়ে পরিচালিত হয়. পুল রিকোয়েস্টগুলি স্বল্পস্থায়ী. টেস্ট ফ্লেকগুলোকে প্রায়ই অগ্রগতি অনির্দিষ্টকালের জন্য আটকে না রেখে ফলো-আপ রান দিয়ে সমাধান করা হয়. একটি সিস্টেমে যেখানে এজেন্টের থ্রুপুট মানব মনোযোগের চেয়ে অনেক বেশি, সেখানে সংশোধন সস্তা এবং অপেক্ষা ব্যয়বহুল.

কম থ্রুপুট পরিবেশে এটি দায়িত্বজ্ঞানহীন হবে. এখানে, এটি প্রায়ই সঠিক সমঝোতা.

যখন আমরা বলি কোডবেসটি Codex এজেন্টদের দ্বারা তৈরি, তখন আমরা কোডবেসের প্রতিটি অংশকেই বোঝাই.

এজেন্টরা উৎপাদন করে:

• পণ্যের কোড এবং পরীক্ষা
• CI কনফিগারেশন এবং রিলিজ টুলিং
• অভ্যন্তরীণ ডেভেলপার টুলস
• ডকুমেন্টেশন এবং ডিজাইনের ইতিহাস
• মূল্যায়ন হারনেসগুলি
• মন্তব্য এবং প্রতিক্রিয়া পর্যালোচনা করুন
• রিপোজিটরি পরিচালনার জন্য ব্যবহৃত স্ক্রিপ্টসমূহ
• প্রোডাকশন ড্যাশবোর্ডের সংজ্ঞা ফাইলগুলি

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

এজেন্টরা সরাসরি আমাদের স্ট্যান্ডার্ড ডেভেলপমেন্ট টুলস ব্যবহার করে. তারা রিভিউ ফিডব্যাক সংগ্রহ করে, ইনলাইনে উত্তর দেয়, আপডেট পুশ করে এবং প্রায়ই নিজেদের পুল রিকোয়েস্ট স্কোয়াশ করে মার্জ করে.

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

একটি প্রম্পট দিলে, এজেন্ট এখন করতে পারে:

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

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

পূর্ণ এজেন্ট স্বায়ত্তশাসন নতুন সমস্যার সূচনা করে. Codex রিপোজিটরিতে ইতিমধ্যেই বিদ্যমান প্যাটার্নগুলো—এমনকি অসম বা অপ্টিমাল নয় এমনগুলোও—অনুকরণ করে. সময়ের সাথে সাথে, এটি অনিবার্যভাবে বিচ্যুতির দিকে নিয়ে যায়.

শুরুতে, মানুষ এটি হাত দিয়ে সমাধান করত. আমাদের দল আগে প্রতি শুক্রবার (সপ্তাহের 20%) “AI slop” পরিষ্কার করতে সময় ব্যয় করত. অবাক করার মতো কিছু নয়, সেটি প্রসারিত হয়নি.

পরিবর্তে, আমরা যাকে 'গোল্ডেন প্রিন্সিপলস' বলি তা সরাসরি রিপোজিটরিতে এনকোড করা শুরু করেছি এবং একটি পুনরাবৃত্তিমূলক পরিস্কার প্রক্রিয়া তৈরি করেছি. এই নীতিগুলি মতামতনির্ভর, যান্ত্রিক নিয়ম যা ভবিষ্যতের এজেন্ট রানগুলোর জন্য কোডবেসকে পাঠযোগ্য এবং সামঞ্জস্যপূর্ণ রাখে. উদাহরণস্বরূপ: (1) আমরা ইনভেরিয়ান্টগুলোকে কেন্দ্রীভূত রাখতে নিজে তৈরি করা হেল্পারের চেয়ে শেয়ার্ড ইউটিলিটি প্যাকেজকে বেশি পছন্দ করি, এবং (2) আমরা 'YOLO-স্টাইলে' ডেটা প্রোব করি না—আমরা বাউন্ডারি যাচাই করি বা টাইপড SDK-এর উপর নির্ভর করি যাতে এজেন্ট ভুল করে অনুমানভিত্তিক শেপের উপর নির্মাণ না করে. নিয়মিত বিরতিতে, আমাদের কিছু ব্যাকগ্রাউন্ড Codex টাস্ক চালু থাকে যা বিচ্যুতিগুলো খুঁজে বের করে, কোয়ালিটি গ্রেড আপডেট করে এবং সুনির্দিষ্ট রিফ্যাক্টরিং pull requests ওপেন করে. এগুলোর বেশিরভাগই এক মিনিটের কম সময়ে পর্যালোচনা করা যায় এবং স্বয়ংক্রিয়ভাবে একীভূত করা যায়.

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

এই কৌশলটি এখন পর্যন্ত OpenAI-এ অভ্যন্তরীণভাবে চালু এবং গ্রহণের ক্ষেত্রে ভালোভাবে কাজ করেছে. বাস্তব ব্যবহারকারীদের জন্য একটি প্রকৃত পণ্য তৈরি করা আমাদের বিনিয়োগকে বাস্তবতার সাথে সংযুক্ত রাখতে সহায়তা করেছে এবং আমাদের দীর্ঘমেয়াদি রক্ষণাবেক্ষণের দিকে পরিচালিত করেছে.

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

যা স্পষ্ট হয়েছে: সফটওয়্যার তৈরি করতে এখনও শৃঙ্খলা প্রয়োজন, তবে শৃঙ্খলাটি কোডের চেয়ে স্ক্যাফোল্ডিং-এ বেশি দেখা যায়. কোডবেসকে সুসংগত রাখতে যে টুলিং, অ্যাবস্ট্র্যাকশন এবং ফিডব্যাক লুপগুলি কাজ করে, সেগুলি ক্রমবর্ধমানভাবে গুরুত্বপূর্ণ হয়ে উঠছে.

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

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