আমি একবার একটি AI-কে একটি ব্র্যান্ড ওয়েবসাইট তৈরি করতে বলেছিলাম। প্রথম দেখায় এটি বেশ বিশ্বাসযোগ্য মনে হলেও, আসলে এটি এমন কিছু জায়গায় ত্রুটিপূর্ণ ছিল যা অত্যন্ত গুরুত্বপূর্ণ। হেডারটিতে ঠিক দুটি লিঙ্ক দেখাচ্ছিল। কোথাও কোনো "About" পেজ ছিল না। ব্যাকএন্ডে একটি অ্যাডমিন প্যানেল ছিল, অথচ ফ্রন্টএন্ডে এমন কোনো বাটন বা রুট ছিল না যা দিয়ে সেখানে পৌঁছানো সম্ভব। সার্ভার সাইড ঠিকঠাক কাজ করছিল, কিন্তু ইউজার সাইড কাজ করছিল না।

যারা এই সমস্যার সম্মুখীন হন, তাদের বেশিরভাগই মনে করেন যে AI অলস হয়ে গেছে বা টোকেন লিমিটে পৌঁছে গেছে। আসলে বিষয়টি তেমন নয়। সমস্যাটি কাঠামোগত। AI কোডিং টুলগুলো মূলত অভ্যন্তরীণ সামঞ্জস্য (internal consistency) বজায় রাখার জন্য তৈরি করা হয়েছে। তারা প্রশ্ন করে: "আমি যা ঘোষণা করেছি তা কি নিজের সাথে মিলছে?" তারা প্রশ্ন করে না: "এই ধরণের একটি ডেলিভারেবল কি তার প্রয়োজনীয় সবকিছু ধারণ করছে?" আপনি যদি আপনার ব্র্যান্ড সাইটের জন্য দুটি পেজের কথা উল্লেখ করেন, তবে মডেলটি নিষ্ঠার সাথে পরীক্ষা করে দেখে যে সেই দুটি পেজ একে অপরের সাথে লিঙ্ক করা আছে কি না। লিঙ্কগুলো কাজ করলেই এটি কাজ সম্পন্ন হয়েছে বলে ধরে নেয়। একটি ব্র্যান্ড সাইটের জন্য একটি About পেজ, ট্রাস্ট সিগন্যাল বা একটি কন্টাক্ট পাথ প্রয়োজন—এই ধারণাটি এর মধ্যে সহজাত নয়। এর মাথায় কোনো মানদণ্ড নেই।

আমি এই সমাধানের নাম দিয়েছি Completeness Baseline।

একটি completeness baseline হলো মূলত একটি আদর্শ চেকলিস্ট যা একটি নির্দিষ্ট ডেলিভারেবলে কী কী থাকা আবশ্যক তা নির্ধারণ করে। আপনি আর্টিফ্যাক্টটি তৈরি করবেন, তারপর টুলের অভ্যন্তরীণ "সম্পন্ন" হওয়ার ধারণার ওপর নির্ভর না করে এই বাহ্যিক মানদণ্ডের বিপরীতে প্রকৃত আউটপুটটি যাচাই করবেন।

তিনটি স্তরে যাচাই করা

সব ধরণের অনুপস্থিত অংশ একইভাবে স্পষ্ট নয়। একটি কার্যকর বেসলাইন তিনটি ভিন্ন স্তর পরীক্ষা করে।

Existence (অস্তিত্ব)। অংশটি কি আসলেই বিদ্যমান? এটি শুনতে খুব সাধারণ মনে হতে পারে, কিন্তু একটি AI সানন্দে এমন একটি নেভিগেশন র‍্যাপার (navigation wrapper) তৈরি করতে পারে যা একটি ড্যাশবোর্ড পেজকে রেফারেন্স করে, অথচ ড্যাশবোর্ড পেজটি নিজে কখনো তৈরি করে না। রেফারেন্সটি বিদ্যমান, কিন্তু টার্গেটটি নেই।

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

Substantiation (প্রমাণ বা ভিত্তি)। উপরিভাগের নিচে কি প্রকৃত ডেটা বা কাঠামো রয়েছে? একটি পেজ যা লোড হয় কিন্তু সেখানে কেবল প্লেসহোল্ডার টেক্সট আছে এবং কোনো ইমেজ আপলোড স্লট নেই, তা হলো কেবল একটি সাজানো কঙ্কাল। একটি About পেজ যেখানে ইমেজ স্লট বা এডিটেবল টেক্সট ফিল্ড নেই, তা সম্পূর্ণ নয়, এমনকি যদি HTML সঠিকভাবে রেন্ডারও হয়।

এই তিনটি স্তর বিভিন্ন ধরণের ঘাটতি শনাক্ত করে। Existence খুঁজে পায় হারিয়ে যাওয়া জুতো। Reachability খুঁজে পায় আলমারিতে আটকে থাকা জুতো। Substantiation খুঁজে পায় তলাবিহীন জুতো।

ধরন অনুযায়ী বেসলাইন

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

Brand sites-এর জন্য নির্দিষ্ট বিভাগ এবং ব্যবহারযোগ্য পেজ প্রয়োজন। যেমন About, Contact, privacy লিঙ্ক এবং এমন নেভিগেশন যা প্রতিটি প্রধান ভিউ প্রকাশ করে।

APIs-এর জন্য ডকুমেন্টেশন, বিস্তারিত এরর কোড (error codes) এবং রেট লিমিট (rate limits) প্রয়োজন। একটি কার্যকরী এন্ডপয়েন্ট যা সফলতার জন্য 200 OK এবং অন্য সবকিছুর জন্য একটি সাধারণ 500 রিটার্ন করে, তা একটি সমাপ্ত API নয়। এটি একটি ঝুঁকি।

Automations-এর জন্য লগ (logs) এবং ফেইলর অ্যালার্ট (failure alerts) প্রয়োজন। যদি কোনো ওয়ার্কফ্লো রাত ২টায় ভেঙে যায় এবং কোনো মানুষ রান হিস্ট্রি চেক না করা পর্যন্ত কেউ তা জানতে না পারে, তবে সেই অটোমেশনটি অসম্পূর্ণ। Observability কোনো বোনাস ফিচার নয়; এটি ডেলিভারেবলের একটি অংশ।

একবার আপনি ক্যাটাগরি নির্ধারণ করে ফেললে, বেসলাইনটি নিজেই তৈরি হয়ে যায়। আসল কঠিন কাজ হলো কোড জেনারেট হওয়ার পর এটি কার্যকর করা।

কার্যকর ডিজাইন নিয়মাবলী

আমি আমার নিজস্ব ওয়ার্কফ্লো এই ধারণার ওপর ভিত্তি করে পুনর্গঠন করেছি এবং তিনটি ব্যবহারিক নিয়মে পৌঁছেছি যা প্রজেক্টকে ধাপে ধাপে অগোছালো হওয়া থেকে রক্ষা করে।

Capability-gated design। কোনো টুল বা জেনারেট করা মডিউলের ওপর নির্ভর করার আগে, এটি আসলে কী করতে পারে তা শনাক্ত করুন। যদি কোনো কম্পোনেন্ট লাইব্রেরিতে নেটিভ মোবাইল ড্রয়ার (mobile drawer) সাপোর্ট না থাকে, তবে AI-কে এমন একটি পূর্ণাঙ্গ নেভিগেশন স্কিম তৈরি করতে দেবেন না যা ধরে নেয় যে এটি বিদ্যমান। কোনো সক্ষমতা না থাকলে সিস্টেমটি ভেঙে না গিয়ে বরং সুন্দরভাবে কাজ চালিয়ে যাওয়া উচিত (degrade gracefully)। আগে সীমানাগুলো জানুন। সীমানার ভেতরে ডিজাইন করুন।

Public engine, private values। ভারী কাজের জন্য একটি পাবলিক ইঞ্জিন ব্যবহার করুন, তবে রানটাইমে (runtime) আপনার ব্যক্তিগত ডেটা, কনফিগ এবং নিয়মগুলো যুক্ত করুন। এটি আপনার ব্যক্তিগত বা কোম্পানির পদ্ধতিগুলোকে জেনারেট করা স্কাফোল্ড (scaffold) থেকে নিরাপদ এবং আলাদা রাখে। AI কাঠামোটি তৈরি করে। আপনি তাতে কাঁচ বসিয়ে দেন। এটি মডেলটিকে এমন কোনো ধারণা হার্ড-কোড করতে বাধা দেয় যা আপনার প্রকৃত মানদণ্ড লঙ্ঘন করে বা পাবলিক ট্রেনিং কনটেক্সটে সংবেদনশীল প্যাটার্ন ফাঁস করে দেয়।

Propose, do not auto-advance. Let the AI suggest the next step, but force a human to make the choice. Automate the flow of execution, never the judgment. When a model auto-generates a database migration, an auth scheme, and a payment hook in one breath, you get convenience at the cost of oversight. Make the tool present the plan. Let the developer press the button.

Picking the Right Model for the Job

I tested this across different models and found a clear split in value. Cheaper models handle mechanical bulk shockingly well. They churn out boilerplate, repetitive components, and structural stubs faster than you can type. The expensive models earn their price only when they demonstrate restraint. You want the premium option when it refuses to invent fake fixes and instead flags a genuine gap. A model that hallucinates a workaround for a missing API endpoint is dangerous. A model that stops and says, "This workflow requires a webhook target that is not defined," is worth the cost. Pay for discernment, not volume.

Build Systems, Don't Chase Magic

Do not try to fix AI gaps by throwing bigger models or more prompting tricks at the problem. Fix them with a baseline. The gap is not a capacity problem. It is an expectations problem.

To stop the missing blocks, do three things.

Give the system a completeness baseline before any code is written. Make it a physical checklist that lives next to the task.

Bake your conventions into reusable parts. If you enforce your baseline through templates, lint rules, or pre-built scaffolds, the AI starts from a position of correctness rather than hoping it guesses your standards.

Automate the flow while keeping a human in control of judgment. Let the machines handle repetition. Reserve the decisions for people who understand the context.

Here is one last habit that changed how I work. If you make the same design decision seven times, stop treating it as a one-off choice. That is not repetition. That is a law. Name it. Turn it into a rule. Document it. When you codify the pattern, you remove the chance that an AI will drift away from it the eighth time.

The source for this framework and the original exploration can be found here.

If you want to trade notes with others working through the same problems, you can join the GyaanSetu learning community.