আপনার AI app builder কেন প্রথমে নকল ডেটা দেখায় (আর কেন সেটাই ঠিক পদক্ষেপ)

আপনি আপনার AI app builder-কে একটা app বর্ণনা করেন। এক মিনিট পরে আপনি একটা চলমান ইন্টারফেসের দিকে তাকিয়ে আছেন — পেজ, বোতাম, “Alex Rivera” আর “Priya Shah”-র মতো নামের ইউজারদের একটা টেবিল, এমন দাম যার কোনো মানে হয় না, একটা “Pro Plan” যা আপনি চাননি। কিছুই সেভ হয় না। আপনি refresh করলে ডেটা তখনো থাকে। আপনি একটা নতুন ইউজার যোগ করলে সেটা উধাও হয়ে যায়।

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

“প্রথমে নকল ডেটা” আসলে কী মানে

একটা AI app builder যখন আপনার brief নেয়, তখন সেটা সোজা ডেটাবেসে যায় না। একটা ভালো builder প্রথমে স্ক্রিনগুলো লেখে, সেগুলো বিশ্বাসযোগ্য প্লেসহোল্ডার ডেটা দিয়ে ভরায়, আর তারপর — আর কেবল তারপরই — সেটার সঙ্গে মিলিয়ে ডেটাবেস ডিজাইন করে।

প্লেসহোল্ডার ডেটা কোনো সাজসজ্জা নয়। এটা একটা চুক্তি। আপনার app যেই বলে “প্রতিটা order-এর একটা customer name, তিনটা line item, একটা total আর একটা status আছে,” অমনি পরে যে ডেটাবেস বানানো হবে, তাকে ঠিক ওই জিনিসগুলোই থাকতে হবে, ঠিক ওই আকারে। স্ক্রিনগুলো ঠিক করে দেয় ডেটা দেখতে কেমন হবে, উল্টোটা নয়।

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

AI-এর সঙ্গে এই ক্রমটা কেন বেশি ভালো কাজ করে

আমরা ডেটাবেস আর স্ক্রিন একসঙ্গে বানানোর চেষ্টা করেছিলাম। কাজ হয়নি। কেন হয়নি, তার সংক্ষিপ্ত রূপটা এই।

দুটো AI এজেন্ট যখন একে অন্যের আউটপুট না দেখে একটা app-এর ভিন্ন ভিন্ন অংশে কাজ করে, তখন তারা পরস্পরবিরোধী অনুমান করে। ইন্টারফেস এজেন্ট ঠিক করে ইউজারদের একটা “name” ফিল্ড আছে। ডেটাবেস এজেন্ট ঠিক করে ইউজারদের একটা “fullName” ফিল্ড আছে। দুটোই দেখতে ঠিকই লাগে। একসঙ্গে, কিছুই কাজ করে না। অমিলটা তালি দিতে একটা তৃতীয় এজেন্টকে আনা হয়। সেটাও অনুমান করে। এখন তিনটা অনুমান ছাড়া পেয়ে ঘুরছে, আর আপনি যে app প্রিভিউ করছেন সেটা ওদের সবগুলোর একটা ফ্রাঙ্কেনস্টাইন।

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

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

নকল ডেটা স্ক্রিনে থাকলে কী দেখবেন

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

কী খেয়াল রাখতে হবে, তার কয়েকটা উদাহরণ:

• ভুল শব্দভাণ্ডার। আপনি যে app চেয়েছিলেন সেটা “shipments” ট্র্যাক করে। প্লেসহোল্ডার ডেটা সেগুলোকে “orders” বলছে। builder-কে বলুন। এখন এটা ছেড়ে দিলে প্রতিটা স্ক্রিন, প্রতিটা ডেটাবেস ফিল্ড, প্রতিটা রিপোর্ট ভুল শব্দটা ব্যবহার করবে — আর পরে নাম বদলানো কোনো টুলেই এক-ক্লিকের অপারেশন নয়, মার্কেটিং যা-ই বলুক না কেন।
• গায়েব ফিল্ড। নকল invoice-এ একটা total আর একটা date আছে। আপনার একটা PO number-ও দরকার। স্ক্রিনে যখন পাঁচটা mock invoice আছে তখন এটা যোগ করা ভালো, ডেটাবেস বানানো আর আসল কাস্টমার ডেটা দিয়ে seed করার পরে নয়।
• ভুল আকার। mock ডেটা দেখাচ্ছে “১ customer, ১ address”। আপনার আসল কাস্টমারদের একাধিক address আছে। আপনার brief থেকে builder সেটা অনুমান করতে পারে না। এখনই বলুন, যখন আকার বদলাতে কোনো খরচ নেই।
• অপ্রত্যাশিত entity। builder একটা “team” ধারণা উদ্ভাবন করেছে যা আপনি চাননি, কারণ সে ধরে নিয়েছে এটা একটা মাল্টি-ইউজার app। হয়তো আপনি সেটা চেয়েছিলেন। হয়তো চাননি। যা-ই হোক, ডেটাবেস এটাকে ঘিরে বানানোর আগেই সিদ্ধান্ত নিন।

একটা কাজের নিয়ম: আপনার app-এ এমন কোনো বিশেষ্য থাকলে যা স্ক্রিনের প্লেসহোল্ডার ডেটায় নেই, তার মানে builder এখনো সেটা সম্পর্কে জানে না। প্রথম প্রিভিউতে “save”-এ ক্লিক করার আগে সেটার কথা উল্লেখ করুন।

পরে যা আসবে, তার জন্য ক্রমটা কেন গুরুত্বপূর্ণ

একবার প্লেসহোল্ডার ডেটা ঠিক হয়ে গেলে, ডেটাবেস বানানো যান্ত্রিক হয়ে যায়। builder আপনার নকল ডেটা পড়ে, তার সঙ্গে মেলে এমন একটা schema তৈরি করে, স্ক্রিনগুলো যেসব query কল করার চেষ্টা করছে সেগুলো লেখে, আর শেষে প্লেসহোল্ডার import-গুলো আসলগুলো দিয়ে বদলে দেয়। যে স্ক্রিনগুলো নকল ইউজার দেখাচ্ছিল, সেগুলোই এখন আপনি যা আসলে রাখবেন তা দেখায়।

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

এটা আদৌ কাজ করে কারণ নিচের দিকের সবকিছু — ডেটাবেস ডিজাইন, query, লোডিং স্টেট, খালি স্টেট — প্লেসহোল্ডার পর্যায়ে স্ক্রিনে আপনি যা দেখেছিলেন, তা দিয়েই ঠিক করা হয়েছিল। আপনি তিনটা কলামে সম্মতি দিলে, আপনি তিনটা কলাম পান। আপনি যদি “draft” আর “sent” মান নিয়ে একটা “status” ফিল্ডে সম্মতি দেন, ডেটাবেস ঠিক সেটাই গ্রহণ করে। দ্বিতীয় কোনো অনুবাদের ধাপ নেই, যেখানে একজন ডিজাইনার-ডেভেলপারের হস্তান্তরে জিনিসপত্র এলোমেলো হয়ে যায়।

একটা ছোট পরীক্ষা আপনি চালাতে পারেন

পরের বার যখন কিছু বানাবেন, এটা চেষ্টা করুন: প্লেসহোল্ডার ডেটা দেখা দিলে, অন্য কিছু চাওয়ার আগে সেটার একটা জিনিস বদলান। একটা ফিল্ডের নাম বদলান। একটা কলাম যোগ করুন। “users”-কে “members” দিয়ে বদলান। তারপর দেখুন ডেটাবেস বানানোর সময় কী হয়।

আপনি দেখবেন পরিবর্তনটা সর্বত্র ফুটে উঠছে — ডেটাবেস ডিজাইনে, query-তে, app শেষ হলে builder যে seed ডেটা বসায় তাতে। প্লেসহোল্ডার পর্যায়ের একটা শব্দ পুরো app জুড়ে ঢেউ তুলে দিল। এই পর্যায়ে এটাই আপনার হাতে থাকা লিভারেজ, আর এই কারণেই “প্রথমে নকল ডেটা” কোনো কোণা-কাটা কৌশল নয়। এখানেই app আসলে ঠিক হয়ে যায়।

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