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

লেখক: CyrilXBT

লেখার সংকলন, উৎস: ME News

২০২৬ সালের জুনে, এক সপ্তাহের মধ্যে, তিনজন ব্যক্তি স্বতন্ত্রভাবে একই সিদ্ধান্তে পৌঁছান।

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

প্রায় একই সময়ে, Anthropic Claude Code-এর প্রধান বোরিস চেরনি বলেছেন যে তিনি এখন সরাসরি Claude-এর কাছে প্রম্পট দেন না। বরং, তিনি একটি সারি চক্র চালান যেগুলো স্বয়ংক্রিয়ভাবে Claude-কে কল করে এবং পরবর্তী পদক্ষেপটি কী হওয়া উচিত তা নির্ধারণ করে, এবং তাঁর প্রকৃত কাজ হলো এই চক্রগুলো লিখা এবং ডিজাইন করা।

কয়েক দিন পর, গুগল ইঞ্জিনিয়ার অ্যাডি ওসম্যানি এই অনুশীলনের একটি ব্যবস্থিত সারাংশ প্রদান করেন এবং একটি নাম দেন:

লুপ ইঞ্জিনিয়ারিং, সাইক্লিক ইঞ্জিনিয়ারিং।

তারা এই কাজের পদ্ধতিটি কোনো কিছু থেকে সৃষ্টি করেননি, বরং একটি ইতিমধ্যেই ধীরে ধীরে ঘটছে এমন পরিবর্তনকে নাম দিয়েছে।

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

এটিই এই রোডম্যাপের অস্তিত্বের কারণ।

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

নিচে একজন প্রম্পট অপারেটর থেকে সিস্টেম ডিজাইনারে যাওয়ার একটি সম্পূর্ণ ২০ ধাপের পথ দেওয়া হল। এই পথে ধাপগুলির ক্রম অনুসরণ করা অপরিহার্য, কারণ এই পথে ধাপগুলির মধ্যের ক্রমিক সম্পর্ক প্রায়শই যেকোনো একক ধাপের চেয়ে বেশি গুরুত্বপূর্ণ।

সাইক্লিক ইঞ্জিনিয়ারিং হল একটি একক দক্ষতা যা "অধিগত" বা "অধিগত নয়" এমন দুটি বিকল্পের মধ্যে একটি, বরং এটি স্তরে স্তরে জমা হওয়া দক্ষতার স্তর। প্রতিটি স্তরই নীচের ভিত্তির দৃঢ়তার উপর নির্ভর করে।

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

একইভাবে, যদি আপনি ৬ এবং ৭ ধাপের বিশ্বস্ত যাচাইকরণ প্রক্রিয়া সম্পন্ন না করেই ১১ ধাপের স্থায়ী মেমোরি লেয়ার তৈরি করেন, তাহলে আপনি একটি অত্যন্ত ঢিলেঢালা, নিয়মিতভাবে ভুল ফলাফলগুলি অনুমোদন করে এমন “পর্যালোচক”-এর সংকলিত অভিজ্ঞতা গুরুত্বপূর্ণভাবে সংরক্ষণ করতে পারেন।

এটি শুধু সিস্টেমের উন্নতিতে সাহায্য করবে না, বরং ভুল অভিজ্ঞতা জমে যাবে এবং মেমোরি লেয়ারকে “অস্থায়ীভাবে অপ্রয়োজনীয়” থেকে “সক্রিয়ভাবে ক্ষতিকর” এ পরিণত করবে।

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

প্রকৃত প্রথম পদক্ষেপটি কোনও প্রযুক্তির সাথে সম্পর্কিত নয়।

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

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

মডেলটি প্রক্রিয়াকরণ, যাচাইকরণ এবং পুনরায় চেষ্টা করতে পারে, এবং এই অপারেশনগুলি মানুষের পদক্ষেপে এটি সম্পন্ন করার গতির চেয়ে অনেক দ্রুত।

এই ধাপটির জন্য কোনো প্রম্পট নেই, এটি একটি চিন্তাভাবনামূলক সিদ্ধান্ত।

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

যখন মডেলের আউটপুটে সমস্যা দেখা দেয়, তখন মানুষের সবচেয়ে প্রাকৃতিক প্রতিক্রিয়া হয় মূল প্রম্পটে আরও একটি নিয়ম যোগ করা।

কয়েক মাস পরে, এই পদ্ধতি নিয়মের একটি উচ্চ প্রাচীর তৈরি করবে: ঘন ঘন কন্টেন্ট, পরস্পরবিরোধী, এতটাই দীর্ঘ যে মডেল তার কার্যকারী স্মৃতিতে একসাথে সমস্ত প্রয়োজনীয়তা প্রক্রিয়াকরণ করতে পারবে না।

শেষ পর্যন্ত, মডেলগুলি প্রায়শই সর্বশেষ উপস্থিত বা সবচেয়ে উল্লেখযোগ্য বিষয়গুলির উপর ভিত্তি করে প্যাটার্ন মেলায় এবং অজান্তে অন্যান্য নিয়মগুলি উপেক্ষা করে।

সাইক্লিক ইঞ্জিনিয়ারিং এই চিন্তাধারাকে সম্পূর্ণরূপে পরিবর্তন করেছে।

যখন সমস্যা দেখা দেয়, তখন আপনি শুধুমাত্র প্রম্পটে একটি নতুন শর্ত যোগ করেন না, বরং সিস্টেমে একটি নতুন উপাদান যোগ করেন, যেমন:

• একটি স্বতন্ত্র যাচাইকরণ ধাপ যোগ করুন;
• একটি মেমোরি ফাইল যোগ করুন;
• একটি টাইমার ট্রিগার যোগ করুন;
• একটি স্ট্রাকচার্ড রিভিউ প্রক্রিয়া যোগ করুন।

বাহ্যিক সিস্টেমের ক্ষমতা বৃদ্ধির সাথে সাথে, প্রম্পট নিজেই দীর্ঘ হওয়ার পরিবর্তে ছোট হওয়া উচিত।

যেকোনো ক্ষেত্রের নির্দিষ্ট কাজ হোক না কেন, লুপের প্রতিটি রানকে পাঁচটি মৌলিক ক্রিয়ায় বিভক্ত করা যায়:

শনাক্তকরণ, হস্তান্তর, যাচাইকরণ, স্থায়ীকরণ, সময়সূচীকরণ।

শনাক্তকরণ

যা প্রকৃতপক্ষে সম্পন্ন করা দরকার তা বুঝে নিন।

হ্যান্ডঅফ

কাজটি বাস্তবায়নের জন্য দায়িত্বপ্রাপ্ত মডেল, এজেন্ট বা টুলের কাছে হস্তান্তর করুন।

যাচাইকরণ

প্রকৃত মানদণ্ড অনুযায়ী ফলাফলের সঠিকতা পরীক্ষা করুন।

পারসিস্টেন্স

এই রানের সময় কী ঘটেছিল এবং কী শিখলেন, তা রেকর্ড করুন যাতে পরবর্তী রানে এই অভিজ্ঞতা হারিয়ে না যায়।

শিডিউলিং

নির্ধারণ করুন এই প্রক্রিয়াটি আবার কখন চালু হবে।

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

অন্য তিনটি ক্রিয়া বা তো মূলত অস্তিত্বহীন, অথবা মানুষের নিজের মস্তিষ্কে লুকানো।

সাইক্লিক ইঞ্জিনিয়ারিংয়ের মূল হল এই পাঁচটি ক্রিয়াকলাপকে সম্পূর্ণরূপে প্রকাশ করা এবং সম্ভব হলে স্বয়ংক্রিয়ভাবে চালানো।

প্রথমে একটি কাজ বাছুন যা আপনি ইতিমধ্যে পুনরাবৃত্তি করছেন এবং যার গুণগত মানদণ্ড আপনি স্পষ্টভাবে বর্ণনা করতে পারেন।

সবচেয়ে কঠিন প্রশ্নগুলি বা কোনো পূর্বাবস্থা নেই এমন উদ্ভাবনী কাজগুলি বাছুন না।

প্রথম প্রার্থী কাজটি তিনটি শর্ত পূরণ করতে হবে:

1. আপনাকে এটি পুনরাবৃত্তি করতে হবে;
2. এটির লেখার জন্য স্পষ্ট মানদণ্ড রয়েছে;
3. এটির একটি সহজেই চিনতে পারা "সম্পন্ন অবস্থা" রয়েছে।

অন্যভাবে বললে, একজন সহকর্মী ফলাফল দেখে সহজেই বুঝতে পারবেন যে এই কাজটি সঠিকভাবে সম্পন্ন হয়েছে কিনা।

এই সীমাবদ্ধতাটি প্রতীয়মান চেহারার চেয়ে অনেক বেশি গুরুত্বপূর্ণ।

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

এটি সবচেয়ে বেশি মানুষ লাফিয়ে যায়, কিন্তু এটি পরবর্তী সিস্টেমটি সঠিকভাবে চলার জন্য সিদ্ধান্তগ্রহণকারী পদক্ষেপ।

যেকোনো এজেন্টের জন্য নির্দেশাবলী লেখার আগে, প্রথমে একটি সঠিক ফলাফল কী হওয়া উচিত তা পরিষ্কার এবং প্রাকৃতিক ভাষায় লিখুন।

আপনাকে প্রায়শই পরিমাপযোগ্য, যাচাইযোগ্য মানদণ্ড দরকার, যেমন “ভালো লাগছে” বা “পেশাদার দেখাচ্ছে” এর মতো অস্পষ্ট গুণমান নির্ধারণ নয়।

নিম্নলিখিত টেমপ্লেটটি ব্যবহার করা যেতে পারে:

কাজের নাম: [কাজের নাম]

ডিফিনিশন অফ ডন (DoD) সম্পন্ন হয়েছে:

• [নির্দিষ্ট, যাচাইযোগ্য মানদণ্ড 1]
• [নির্দিষ্ট, যাচাইযোগ্য মানদণ্ড 2]
• [নির্দিষ্ট, যাচাইযোগ্য মানদণ্ড 3]

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

যদি আপনি বর্তমান নির্বাচিত কাজটির জন্য এই টেমপ্লেটটি পূরণ করতে না পারেন, তাহলে ৪ম পদক্ষেপে ফিরে যান এবং চক্র তৈরির জন্য আরও উপযুক্ত কাজ নির্বাচন করুন।

এটি সমস্ত সাইক্লিক সিস্টেমের মধ্যে সবচেয়ে গুরুত্বপূর্ণ আর্কিটেকচারাল ডিসিশন।

ফলাফল তৈরি করার ভূমিকা এবং ফলাফল পরীক্ষা করার ভূমিকা পরস্পর থেকে পৃথক হতে হবে।

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

একটি যুক্তিসঙ্গত চক্রের মধ্যে, কমপক্ষে দুটি স্বাধীন ভূমিকা থাকা উচিত:

বিল্ডার

বিল্ডারদের কিছু সৃজনশীল স্থান রয়েছে এবং প্রথম সংস্করণের ফলাফল তৈরি করার দায়িত্ব তাদের।

জজ

পর্যালোচক বিল্ডারের আউটপুট এবং ধাপ 5-এ নির্ধারিত সম্পন্ন পরিভাষা গ্রহণ করেন এবং এই মানদণ্ডের ভিত্তিতে ফলাফলটি যোগ্য কিনা তা নির্ণয় করেন।

আদর্শভাবে, পর্যালোচকদের এমন স্বতন্ত্র প্রমাণের প্রবেশাধিকার থাকা উচিত যা নির্মাতাদের প্রবেশাধিকার নেই, যেমন:

• টেস্ট স্যুট;
• মূল উৎস;
• রিয়েল-টাইম ডেটা;
• অথোরিটেটিভ ডাটাবেস;
• Original task brief.

এভাবেই পর্যালোচকদের সিদ্ধান্ত বাস্তব প্রমাণের উপর ভিত্তি করে গঠিত হবে, নাহলে তারা নির্মাতাদের একই চিন্তাভাবনা অনুসরণ করে আবার একটি ব্যক্তিগত মতামত তৈরি করবে।

যদি পর্যালোচক শুধুমাত্র বিল্ডারের আউটপুট দেখতে পায়, তবে এটি শুধুমাত্র ফলাফলের “সামঞ্জস্যপূর্ণ দেখানোর” কথা বলতে পারবে।

এটি ফলাফলটি প্রকৃতপক্ষে সঠিক কিনা তা বিচার করতে পারে না।

অতএব, পর্যালোচকদের কাছে যাচাইযোগ্য বস্তুগত ভিত্তি থাকা প্রয়োজন, যাকে বলা হয় গ্রাউন্ড ট্রুথ। প্রাসঙ্গিক প্রেক্ষাপটের ভিত্তিতে, এটিকে “বেঞ্চমার্ক তথ্য”, “বাস্তব ডেটা” বা “প্রাধিকারযুক্ত ভিত্তি” হিসাবে বুঝা যায়।

বিভিন্ন কাজের জন্য বস্তুনিষ্ঠ ভিত্তি আলাদা আলাদা।

প্রোগ্রামিং টাস্ক

পরীক্ষার সেট এবং কোডের বাস্তবিক রান করার ফলাফলই হল বস্তুনিষ্ঠ ভিত্তি।

কন্টেন্ট তৈরি কাজ

ঔপনিবেশিক ভিত্তি হল মূল উৎস এবং সারাংশ। পর্যালোচকদের মূল উৎস এবং তৈরি করা প্রতিবেদনটি পাশাপাশি তুলনা করতে হবে।

অনুসন্ধান কাজ

অবজেক্টিভ বেসিস হল কাজের স্পষ্ট প্রয়োজনীয়তা অনুযায়ী ব্যবহৃত মূল ফাইল, পেপার, ডেটাসেট বা বিশ্বস্ত উৎস।

যদি আপনি পর্যালোচকদের যাচাইয়ের জন্য কী ভিত্তিতে পরীক্ষা করতে হবে তা স্পষ্টভাবে বলতে না পারেন, তাহলে আপনার চক্রের কোনো প্রকৃত যাচাইকরণ ব্যবস্থা নেই, যদিও পর্যালোচকদের কথাবার্তা কতটা আত্মবিশ্বাসী শোনায়।

নির্মাতার আউটপুট এবং পর্যালোচকের সিদ্ধান্ত উভয়ই স্পষ্টভাবে সংজ্ঞায়িত কাঠামোতে হতে হবে, শুধুমাত্র মুক্ত প্রবাহিত প্রাকৃতিক ভাষা নয়।

অন্যথায়, পরবর্তী পরিচালকের জন্য স্থিতিশীল এবং নির্ভরযোগ্য তথ্য উপলব্ধ হবে না যা সিদ্ধান্ত গ্রহণ এবং রাউটিংয়ের জন্য প্রয়োজন।

নির্মাতারা নিম্নলিখিত আউটপুট ফরম্যাট ব্যবহার করতে পারেন:

বিল্ডার আউটপুট:

• চূড়ান্ত ডেলিভারি কন্টেন্ট;
• ফলাফলের প্রতি আত্মবিশ্বাসের মাত্রা;
• পরিচিত অনিশ্চয়তা।

পর্যালোচকগণ নিম্নলিখিত আউটপুট ফরম্যাট ব্যবহার করতে পারেন:

পর্যালোচনা সিদ্ধান্ত:

• পাস: সফল;
• FAIL: ব্যর্থ;
• প্রয়োজন সংশোধন: প্রয়োজন সংশোধন;
• প্রাপ্ত সমস্যাগুলি;
• এই পরীক্ষার জন্য ব্যবহৃত বস্তুগত মানদণ্ড বা মূল প্রমাণ।

অটোমেটিক স্কেডিউলিং এবং অটোমেটিক রিট্রাই এর আগে, একবার ম্যানুয়ালি পুরো “বিল্ডার—রিভিউয়ার” প্রক্রিয়া চালান।

পর্যালোচক দ্বারা প্রদানকৃত বিচারটি সাবধানে পড়ুন এবং নিজেকে জিজ্ঞাসা করুন:

• আপনি কি এর উপসংহারে সম্মত?
• এটি কি কখনও এমন ফলাফল ছেড়ে দিয়েছে যা আপনি জানেন ভুল?
• এটি কি একটি মূলত যোগ্য ফলাফলকে ভুলভাবে অস্বীকার করেছে?

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

একটি ভুল যাচাইকরণ পদ্ধতিকে স্বয়ংক্রিয় করলে শুধুমাত্র সিস্টেমটি দ্রুততর গতিতে ভুল ফলাফল উৎপাদন করবে।

উপরের পাঁচটি ধাপকে আরও বিশদভাবে বুঝতে, আমরা একটি সাধারণ কাজ পর্যবেক্ষণ করতে পারি: একটি মূল উৎসকে একটি সম্পূর্ণ নিবন্ধে রূপান্তরিত করা।

ধাপ ৫: সংজ্ঞাটি সম্পন্ন করুন

এই কাজের সম্পন্নের মানদণ্ড হতে পারে:

• প্রতিটি তথ্য খসড়ায় মূল উৎসের স্পষ্ট বিষয়বস্তুর সাথে অনুসরণ করা যায়;
• ড্রাফ্টটি ব্রিফে উল্লিখিত সমস্ত নির্দিষ্ট প্রয়োজনীয়তা, অন্তর্ভুক্ত দৈর্ঘ্য, টোন এবং কাঠামো পূরণ করে;
• মূল যুক্তি স্পষ্টভাবে রক্ষিত হয়েছে, অর্থহীন পূরণকারী বিষয়বস্তু দ্বারা দুর্বল হয়নি।

ধাপ ৬: বিল্ডার ড্রাফ্ট তৈরি করে

বিল্ডার মূল ডেটা এবং কন্টেন্ট ব্রিফ গ্রহণ করে একটি ড্রাফ্ট তৈরি করে।

এর সাথে সাথে, এটি লেখার প্রক্রিয়ায় বিদ্যমান অনিশ্চয়তাগুলিকে স্পষ্টভাবে তালিকাভুক্ত করতে হবে, যেমন:

• কোনো সংখ্যা কি আসল উৎসে প্রকৃতপক্ষে উপস্থিত ছিল;
• কোনো সিদ্ধান্ত মূল লেখায় স্পষ্টভাবে উল্লেখিত নাকি মডেল নিজে চিন্তা করে বের করেছে;
• কোনো তথ্যের পর্যাপ্ত উৎস কি অনুপস্থিত।

ধাপ ৭: সমালোচক মূল পাঠের সাথে তুলনা করুন

সমালোচকরা শুধুমাত্র খসড়া নয়, খসড়া এবং মূল উপাদান দুটি একসাথে পান।

এটি সংজ্ঞায়িত তিনটি মানদণ্ড পৃথকভাবে পরীক্ষা করবে এবং প্রতিটি মানদণ্ডের জন্য পৃথকভাবে পাস বা ফেলের সিদ্ধান্ত দেবে, সমস্ত মানদণ্ডকে একটি অস্পষ্ট সমন্বিত স্কোরে চাপিয়ে দেবে না।

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

ধাপ ৮: স্ট্রাকচার্ড হ্যান্ডওভার

রিভিউয়ারের সিদ্ধান্ত একটি স্ট্রাকচার্ড অবজেক্ট হওয়া উচিত, একটি সংরক্ষণমূলক ভাষায় ভরা প্রাকৃতিক ভাষা নয়।

এটি তিনটি স্পষ্ট পাস বা ফেল ফলাফল আউটপুট করতে হবে এবং প্রতিটি ফেলের জন্য বিশদ কারণ প্রদান করতে হবে।

ধাপ ৯: মন্তব্য প্রক্রিয়াটি হাতে যাচাই করুন

সিস্টেমটি স্বয়ংক্রিয়ভাবে চালু হওয়ার আগে, একবার ম্যানুয়ালি পুরো প্রক্রিয়াটি চালানো আপনাকে সমালোচকদের খুব ঢিলে বা খুব কঠোর কিনা তা বুঝতে সাহায্য করবে।

অত্যন্ত ঢিলেঢালা রিভিউয়াররা সম্ভবত নিবন্ধটি প্রবাহিতভাবে লেখা হয়েছে বলে এর মধ্যে কাল্পনিক ডেটা উপেক্ষা করবেন।

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

এই দুটি সমস্যা প্রথমবারের মতো সেটআপ করার সময় খুবই সাধারণ।

50 বার সিস্টেম অনুপস্থিতভাবে চলার পরে এগুলি আবিষ্কার করা প্রথমবারের ম্যানুয়াল টেস্টিংয়ের তুলনায় সমস্যা সমাধান করা অনেক বেশি খরচের।

ম্যানেজার পর্যালোচকদের বিচার পড়ে পরবর্তী পদক্ষেপ নির্ধারণ করেন।

প্রবন্ধের মধ্যে বন্ধ শর্তগুলি অবশ্যই থাকতে হবে, এবং এগুলি একটি স্পষ্ট কঠিন যুক্তি হিসাবে লেখা উচিত, যা মডেল নিজেকে ব্যাখ্যা করে এড়িয়ে যেতে পারে না।

উদাহরণস্বরূপ:

স্টপ শর্ত:

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

একটি বাস্তবিক বন্ধ শর্ত বিহীন লুপ একটি সিস্টেম নয়, বরং একটি ঝুঁকি প্রকাশের জন্য অপেক্ষা করছে এমন দায়।

কেন “ফলাফল যথেষ্ট ভাল হলে থামুন” এর মতো নরম নির্দেশ বিশ্বস্ত নয়?

কারণ এটি শুধু একটি পরামর্শ।

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

অন্যদিকে, কোড দ্বারা যান্ত্রিকভাবে পরীক্ষিত পুনরাবৃত্তির সংখ্যা বা ম্যানেজার যুক্তি দ্বারা এড়াতে পারে না এমন স্পষ্ট নিয়মগুলির ক্ষেত্রে এই সমস্যা দেখা দেয় না।

যদি একটি সাইকেল প্রতিবার শূন্য থেকে শুরু হয়, তবে এটি আগের রান থেকে কী শিখেছে তা মনে রাখতে পারবে না।

অতএব, একটি সাধারণ স্থায়ী স্তর যোগ করা প্রয়োজন।

প্রতিটি প্রকৃত নতুন অভিজ্ঞতার জন্য একটি ফাইল তৈরি করুন এবং ফাইলের শীর্ষে একটি বাক্যের মাধ্যমে সারসংক্ষেপ করুন:

• কী শিখলেন;
• কী সংশোধন করা হয়েছে;
• এই অভিজ্ঞতাটি কেন গুরুত্বপূর্ণ।

মূল নীতিটি হল: অন্য কোথাও সংরক্ষিত না হওয়া নতুন জ্ঞান মাত্র রেকর্ড করুন।

পুনরাবৃত্তি মনে রাখা জ্ঞান নয়, বরং শব্দ।

দীর্ঘস্থায়ী পদ্ধতিটি দীর্ঘকাল কার্যকর রাখতে, লেখার সময় সংযম অবলম্বন করা প্রয়োজন।

সমস্ত রান ডিটেইলস রেকর্ড করার প্রবণতা খুব সহজেই জাগ্রত হয়, কিন্তু এটি শুধুমাত্র ধাপ 2-এ উল্লিখিত “বৃহৎ প্রম্পট” সমস্যাটিকে পুনরায় তৈরি করে, শুধু এবার ফুলে উঠছে প্রম্পট নয়, বরং মেমোরি ফোল্ডার।

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

শুধু ধারাবাহিকতা মেকানিজম বাড়ানোর ফলে শেষ পর্যন্ত অত্যন্ত দীর্ঘ প্রম্পটের মতো সমস্যা তৈরি হবে।

সময়ের সাথে সাথে, সিস্টেম ডজন ব্যাপী ফাইল জমা করে, যার অনেকগুলি শুধু একই সমস্যার কিছুটা ভিন্ন বিবৃতি।

অতএব, মেমোরি ফাইলগুলি নির্দিষ্ট সময় ব্যবধানে সংগঠিত করা উচিত। সাধারণত প্রতি সপ্তাহে একবার করা উপযুক্ত ফ্রিকোয়েন্সি।

প্রক্রিয়াটি অন্তর্ভুক্ত করে:

• বর্তমান মেমোরি পরীক্ষা করুন;
• পুনরাবৃত্ত কনটেন্ট একীভূত করুন;
• একাধিক সদৃশ অভিজ্ঞতাকে একটি আরও স্পষ্ট নীতিতে সংকুচিত করুন;
• প্রমাণিতভাবে ভুল বা পুরনো কন্টেন্ট মুছে ফেলুন।

লক্ষ্য হল ক্রমাগত বেশি ফাইল সংগ্রহ করা নয়, বরং কম সংখ্যক, বেশি তথ্যঘনত্বযুক্ত জ্ঞান অর্জন করা।

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

কারণ এটি তাৎক্ষণিক ফিডব্যাক বিনা, এটিকে স্পষ্টভাবে সময়সূচীতে যোগ করা উচিত, যতক্ষণ না কেউ মনে করে যে মেমোরি ফোল্ডারটি পরিচালনা করা কঠিন হয়ে গেছে।

বাস্তবে, এই ধরনের “পরে সময় পেলে সাজানোর” কাজগুলি প্রায় কখনই ঘটে না, যতক্ষণ না বিপরীত, পুরনো এবং আংশিকভাবে সম্পর্কিত মেমোরির প্রচুর পরিমাণের কারণে সিস্টেমের পারফরম্যান্স কমে যায়।

প্রতিটি নতুন টাস্ক শুরু হওয়ার সময়, লুপটি প্রথমে মেমোরি ফাইলের একটি বাক্যের সারাংশ স্ক্যান করবে, যাতে বুঝতে পারে কোন অভিজ্ঞতাগুলি বর্তমান টাস্কের সাথে প্রকৃতপক্ষে সম্পর্কিত, এবং শুধুমাত্র সেই সংশ্লিষ্ট বিষয়বস্তুগুলি লোড করবে।

এছাড়াও, সিস্টেমকে স্পষ্টভাবে নির্দেশ দেওয়া উচিত: যদি বর্তমান কাজের জন্য কোনো বিদ্যমান মেমোরি প্রযোজ্য না হয়, তবে সরাসরি জানান যে কোনো প্রযোজ্য অভিজ্ঞতা নেই।

পুরনো অভিজ্ঞতা একটি সম্পূর্ণ ভিন্ন নতুন সমস্যার সাথে জোর করে মেলাবেন না, যদিও মেমোরি সিস্টেমটি ইতিমধ্যে বিদ্যমান।

পরবর্তীতে, এই চক্রটি কখন ম্যানুয়ালি শুরু না করেই স্বয়ংক্রিয়ভাবে চালু হবে তা নির্ধারণ করতে হবে।

ট্রিগার পদ্ধতির মধ্যে থাকতে পারে:

• ক্রন টাইমার টাস্ক;
• ফাইল পরিবর্তন শ্রোতা;
• ক্যালেন্ডার-ভিত্তিক সাইক্লিক ট্রিগার;
• যখন কোনো বাহ্যিক ঘটনা বা অবস্থা পরিবর্তিত হয়।

এই ধাপটি আপনার হাতে শুধুমাত্র ম্যানুয়ালি শুরু করা যায় এমন একটি সিস্টেমকে আপনি ঘুমানোর সময়ও চলতে থাকা একটি সিস্টেমে রূপান্তরিত করবে।

বিষয়টি হলো, এটি সাধারণত সম্পূর্ণ তালিকার মধ্যে সবচেয়ে সহজে বাস্তবায়নযোগ্য পদক্ষেপ, কিন্তু অনেকেই অন্যান্য উপাদানগুলি সম্পন্ন করেও এই পদক্ষেপটি করতে দেরি করে।

যেকোনো গুরুত্বপূর্ণ কাজের জন্য লুপ ব্যবহার করার আগে, চারটি ফেলিয়ার মোডের জন্য সক্রিয়ভাবে পরীক্ষা করা প্রয়োজন।

পরীক্ষা এক: অসম্পূর্ণ কাজ

একটি প্রকৃতপক্ষে অসমাধানযোগ্য কাজের সংস্করণ সিস্টেমকে দিন, যাতে পরিচালক অসীম লুপের পরিবর্তে বন্ধ হওয়ার শর্ত অনুযায়ী বন্ধ হয়ে যায়।

যদি একটি লুপ শুধুমাত্র সফলভাবে সম্পন্ন হওয়া কাজগুলিতে পরীক্ষিত হয়, তবে এটি কখনও নিজেকে সুন্দরভাবে ব্যর্থ হওয়ার ক্ষমতা প্রমাণ করেনি।

পরীক্ষা দুই: যে ফলাফলটি যুক্তিসঙ্গত মনে হচ্ছে কিন্তু বাস্তবে ভুল

একটি আউটপুট প্রদান করুন যাতে আপনি স্পষ্টভাবে জানেন যে সূক্ষ্ম ভুল রয়েছে।

এই ফলাফলটি খুব স্বাভাবিকভাবে পড়া উচিত, কিন্তু এতে একটি আপনি ইচ্ছাকৃতভাবে প্রবেশ করিয়েছেন তথ্য বা যুক্তির ভুল থাকবে।

শুধু কনটেন্টটি যুক্তিসঙ্গত শোনাচ্ছে বলে এটি অনুমোদন না করে, রিভিউয়ারদের দ্বারা সমস্যাগুলি শনাক্ত করা হচ্ছে কিনা তা পর্যবেক্ষণ করুন।

পরীক্ষা তিন: বিল্ডার এবং রিভিউয়ার মডেলের অন্ধকার অঞ্চল শেয়ার করে

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

যদি পর্যালোচক এবং নির্মাতা একই অন্ধবিন্দু বহন করে, তবে ৬ষ্ঠ ধাপে ডিজাইন করা ভূমিকা বিভাজনের কোনো অর্থ থাকে না।

পরীক্ষা চার: সর্বাধিক খারাপ পরিস্থিতিতে চলার খরচ গণনা করুন

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

তারপর নিজেকে সত্যিকারভাবে জিজ্ঞাসা করুন:

যদি এই ডিজিটাল সংখ্যাটি একটি বাস্তব বিলে দেখা যায়, তাহলে কি আপনি অস্বস্তিবোধ করবেন?

এই চারটি টেস্ট সম্পন্ন করে বিশ্বাস চক্র গুরুত্বপূর্ণ কাজগুলি পরিচালনা করার আগে বেশিরভাগ সম্ভাব্য সমস্যা আগে থেকেই শনাক্ত করা যায়।

অন্যথায়, এই সমস্যাগুলি সম্ভবত প্রথমবারের মতো গ্রাহক বা পরিচালকদের সামনে বা সরাসরি আপনার বিলে প্রকাশ পাবে, এবং আপনার নিয়ন্ত্রিত পরীক্ষায় প্রকাশ পাবে না।

যখন চক্রটি স্থিতিশীলভাবে চলমান থাকবে, তখন সমস্ত চরিত্রকে একই আপনার প্রিয় মডেল ব্যবহার করতে দিবেন না।

চক্রের বিভিন্ন ভূমিকাগুলির জন্য মডেলের ক্ষমতার প্রয়োজনীয়তা ভিন্ন ভিন্ন।

বিল্ডার

নির্মাতাদের সাধারণত সবচেয়ে শক্তিশালী মডেল ব্যবহার করা উচিত।

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

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

রিভিউয়ার

রিভিউয়ারদের পরিষ্কার মানদণ্ড অনুযায়ী পরীক্ষা করতে হয়, যেখানে বেশি সৃজনশীলতার প্রয়োজন হয় না।

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

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

প্রবেশাধিকারী

ম্যানেজার শুধু পূর্বনির্ধারিত নিয়মগুলি অনুসরণ করে রুটিং করে, এবং প্রায় কখনই সবচেয়ে ব্যয়বহুল মডেলটি ব্যবহার করতে হয় না।

এটি খোলা যুক্তিবিদ্যা করার জন্য নয়, বরং পূর্বনির্ধারিত যুক্তি বাস্তবায়নের জন্য।

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

উপযুক্ত স্তরীকৃত কনফিগারেশন সাধারণত:

• শক্তিশালী মডেল তৈরি করে;
• সাধারণ পর্যালোচনার জন্য সস্তা এবং স্থিতিশীল মডেল দায়ী;
• কম খরচের মডেল বা নিয়ম প্রোগ্রাম রাউটিং এবং পরিচালনা করে।

এই মডেল ভূমিকা মেলানো থেকেই সার্কুলেশন সিস্টেমে প্রকৃতপক্ষে উল্লেখযোগ্য খরচ কমানো হয়।

অনেকে মনে করেন খরচ নিয়ন্ত্রণ করার অর্থ হলো চক্রের সংখ্যা বা পুনরায় সংশোধনের সংখ্যা কমানো। বাস্তবে, আরও কার্যকরী পদ্ধতি হলো মডেলের খরচকে চক্রের প্রতিটি ভূমিকার প্রকৃত কঠিনতার সাথে মেলানো।

প্রথম চক্রটি সফল হওয়ার পর, মানুষ সহজেই একসাথে একাধিক চক্র তৈরি করার চেষ্টা করে, পাঁচটি ভিন্ন কাজ একসাথে প্রক্রিয়াকরণ করে।

যদিও বর্তমান আর্কিটেকচার এই বিস্তারকে সমর্থন করতে পারে, তবুও এই প্রবণতাকে সংযমী হওয়া উচিত।

প্রথম লুপটি যতক্ষণ না আপনি আসলে এর প্রতিটি আউটপুটের উপর কঠোরভাবে নজর রাখার প্রয়োজন বোধ করবেন না, ততক্ষণ এটি স্থিতিশীলভাবে চালানো উচিত।

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

এই অবস্থাটি অর্জন করার পরেই দ্বিতীয় চক্র তৈরি শুরু করা উচিত।

দ্বিতীয় লুপটি প্রথম লুপ থেকে স্পষ্টভাবে ভিন্ন একটি কাজ পরিচালনা করা উচিত।

এটি নিশ্চিত করে যে নীচের স্তরের কাঠামোটি সত্যিকারের সার্বজনীনতা রাখে, শুধুমাত্র একই কাজের জন্য ক্রমাগত পরিষ্কার অপ্টিমাইজেশন নয়।

একাধিক লুপ একসাথে চালানোর পর, প্রতিটি লুপ আলাদাভাবে দেখার পরিবর্তে, সমস্ত লুপের খরচ এবং বন্ধ শর্ত ট্রিগারের একটি একীকৃত মনিটরিং দৃশ্য তৈরি করা প্রয়োজন।

একা একা দেখলে, একটি চক্রাকার কাজের বাজেট সম্পূর্ণরূপে যুক্তিসঙ্গত হতে পারে।

কিন্তু যদি দশটি সাইকেল প্রতিটি বাজেটের মধ্যে চলে, তবুও তাদের মোট খরচ একটি অপ্রত্যাশিত স্তরে পৌঁছতে পারে।

প্রতিটি চক্রের স্বতন্ত্র ডেটা সাধারণত স্বাভাবিক দেখায়, তাই এই ঝুঁকি প্রায়শই সম্মিলিত বিল আসা পর্যন্ত ধরা পড়ে না।

সফলভাবে সম্পন্ন কাজের পাশাপাশি, প্রতিটি বন্ধ শর্তের ট্রিগার বিশেষভাবে রেকর্ড করা প্রয়োজন।

যদি কোনো চক্র প্রায়শই সর্বাধিক পরিবর্তনের সীমার সংস্পর্শে আসে এবং অন্যান্য চক্রগুলি এই অবস্থা খুব কমই দেখায়, তবে এটি যে সংকেত প্রেরণ করে তা হতে পারে “এই কাজটি বিশেষভাবে কঠিন” নয়, বরং:

• মূল্যায়ন মানদণ্ড অযৌক্তিকভাবে সেট করা হয়েছে;
• পর্যালোচকদের অত্যন্ত কঠোর হওয়ায় কোনো ফলাফলই পাস করতে পারছে না;
• সিস্টেম ভুল বস্তুগত ভিত্তি পরীক্ষা করেছে;
• সংজ্ঞাটি সম্পূর্ণ করা নিজেই সমস্যাজনক।

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

আপনার দৈনিক মনোযোগ দেওয়া মাপকাঠি যদি পরিবর্তিত হয়, তবেই চিন্তার পরিবর্তনটি প্রকৃতপক্ষে সম্পন্ন হয়েছে তা সবচেয়ে স্পষ্ট মাপকাঠি।

প্রম্পট অপারেটরদের চিন্তা হল:

• আজ কতগুলি কার্যকরী প্রম্পট লেখা হয়েছে;
• কোন প্রম্পটটি সবচেয়ে ভালো ফলাফল দেয়;
• কিভাবে প্রম্পট লেখা যায় আরও পরিষ্কার ও কার্যকরভাবে।

সিস্টেম ডিজাইনারদের চিন্তা হল:

• বর্তমানে কতগুলি সাইকেল চলছে;
• প্রতিটি সাইকেলের বিশ্বস্ততা কেমন;
• সিস্টেম নিজের জন্য কতক্ষণ মুক্ত করেছে;
• কোন কাজগুলি এখন মানব পর্যবেক্ষণের প্রয়োজন হয় না।

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

শেষ ধাপটি এখন আর শুধুমাত্র আপনার নিজস্ব সিস্টেম সম্পর্কে নয়।

এটি আপনার এই পদ্ধতিটি সত্যিই বুঝেছেন কিনা তা যাচাই করতে ব্যবহৃত হয়।

আপনাকে জটিল শব্দের উপর নির্ভর না করে অন্য একজনকে পাঁচটি মৌলিক ক্রিয়া ব্যাখ্যা করার চেষ্টা করতে হবে:

শনাক্তকরণ, হস্তান্তর, যাচাইকরণ, স্থায়ীকরণ, সময়সূচীকরণ।

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

তুমি এখন সেই চক্রের ভিতরে থাকা এবং পরবর্তী নির্দেশ প্রবেশ করানোর মানুষ নও।

তুমি চক্রের বাইরে দাঁড়িয়ে সিস্টেম ডিজাইন করেছ এবং এটি নিজে নিজে চলছে তা পর্যবেক্ষণ করছ।

ধাপগুলি এড়িয়ে যাওয়ার ফলে নিঃশব্দে জমা হওয়া চারটি খরচ

লেখার শেষে একটি সতর্কবার্তা দেওয়া প্রয়োজন।

এই রোডম্যাপের ধাপগুলি এড়িয়ে যাওয়া সাধারণত সিস্টেমের ক্র্যাশের কারণ হয় না।

এর ব্যর্থতা সাধারণত নীরবভাবে ঘটে, এমনকি দীর্ঘ সময় ধরে অনুভূত হয় না, যতক্ষণ না সমস্যাটি পর্যাপ্ত গুরুতর হয়ে যায়।

যখন আপনি ৬ষ্ঠ এবং ৭ম ধাপ উপেক্ষা করেন, বাস্তবিক স্বাধীন পর্যালোচক তৈরি করেন না এবং বিশ্বস্ত বস্তুনিষ্ঠ ভিত্তি প্রদান করেন না, তখন ঋণের যাচাইয়ের পরিমাণ বৃদ্ধি পেতে থাকে।

চক্রটি প্রতীয়মান হচ্ছে যে এটি স্বাভাবিকভাবে কাজ করছে, কারণ উত্পাদিত ফলাফলগুলি "ভালো দেখাচ্ছে"।

একটি ভুল কয়েক দশক ধরে জমা হয়ে চূড়ান্তভাবে কেউ আবিষ্কার করা পর্যন্ত, আপনি বুঝতে পারবেন না যে সিস্টেমটি শুরু থেকেই ফলাফলগুলির সঠিকতা বিচার করেনি।

২০ তম পদক্ষেপ লাফিয়ে যাওয়ার সময় বুঝতে অসুবিধা হতে পারে।

আপনি এখনও আপনার নিজের তৈরি চক্রটি চালিয়ে যাচ্ছেন, কিন্তু প্রতিটি উপাদান কেন অস্তিত্ব রাখে তা আপনি স্পষ্টভাবে ব্যাখ্যা করতে পারছেন না, এবং সিস্টেমের ব্যর্থতার সময় কার্যকরভাবে ডিবাগ করতেও পারছেন না।

কারণ হলো, আপনি কখনও এই আর্কিটেকচারের পিছনের যুক্তি বাস্তবিকভাবে অন্তর্ভুক্ত করেননি।

যদি পদক্ষেপ 1 কখনও সম্পূর্ণ না হয়, তবে জ্ঞানগত আত্মসমর্পণ ঘটে।

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

এই আচরণটি সাবধান মনে হলেও, প্রকৃতপক্ষে সিস্টেম গঠনের পুরো অর্থকে বাতিল করে দেয়।

যদি ১০ম পদক্ষেপ বাদ দেওয়া হয় এবং লুপের জন্য কোনো প্রকৃত বন্ধ শর্ত না নির্ধারিত হয়, তবে টোকেন খরচ এবং কল খরচ নিয়ন্ত্রণহীন হয়ে যাওয়ার সম্ভাবনা রয়েছে।

আপনি সাধারণত সিস্টেম নিয়ন্ত্রণ হারানোর প্রথম মুহূর্তে সমস্যাটি বুঝতে পারেন না, বরং চূড়ান্ত বিল আসা পর্যন্ত অপ্রয়োজনীয় কলগুলির একটি চক্র চলছে তা বুঝতে পারেন।

উপরের সমস্ত খরচ এড়ানো যায়।

এগুলি এড়ানোর উপায় সর্বদা একই নিয়মিততা:

প্রতিটি ধাপ ক্রমানুসারে তৈরি করুন, যে ধাপগুলি যেমন কম আকর্ষণীয় মনে হয় তাদের বাদ দেবেন না।

সবচেয়ে ক্লান্তিকর অংশগুলিই প্রায়শই সত্যিকার অর্থে কাজ করে:

• স্পষ্ট সম্পন্ন সংজ্ঞা;
• নির্ভরযোগ্য বন্ধ শর্ত;
• যাচাইযোগ্য বস্তুগত ভিত্তি;
• Independent review mechanism.

অপেক্ষাকৃত, যে অংশগুলি আকর্ষণীয় শোনায়—দক্ষ প্রম্পট, জটিল সিস্টেম আর্কিটেকচার ডায়াগ্রাম—তারা মানুষের কল্পনায় যতটা গুরুত্বপূর্ণ ততটা নয়।

সিস্টেমের গুণগত মান নির্ধারণ করে এটি যে সিস্টেমটি জানে:

• কখন আপনি সঠিক হন;
• কখন নিজেকে ভুল বলে মনে করা হয়;
• কখন বন্ধ করতে হবে।

এটাই প্রম্পট অপারেটর এবং সিস্টেম ডিজাইনারের মধ্যে একমাত্র পার্থক্য।

এটি কার বেশি বুদ্ধিমান বা কে আরও সুন্দর প্রম্পট লিখতে পারে তার পার্থক্য নয়।

সত্যিকারের পার্থক্য হলো, আপনার কাছে যথেষ্ট অনুশাসন আছে কিনা, যাতে আপনি সেই ক্লান্তিকর, উপেক্ষিত হওয়ার ঝুঁকি থাকা কিন্তু ব্যবস্থার নির্ভরযোগ্যতা নির্ধারণকারী অংশগুলি গুরুত্বপূর্ণভাবে তৈরি করতে পারেন।