میں نے ایک بار ایک AI سے ایک برانڈ ویب سائٹ بنانے کو کہا۔ جو نتیجہ سامنے آیا وہ پہلی نظر میں تو قائل کرنے والا تھا، لیکن وہ ان طریقوں سے خراب تھا جو حقیقت میں اہمیت رکھتے ہیں۔ ہیڈر میں صرف دو لنکس نظر آ رہے تھے۔ کہیں بھی "About" پیج نہیں تھا۔ بیک اینڈ پر ایک ایڈمن پینل موجود تھا، لیکن فرنٹ اینڈ پر کوئی بٹن یا روٹ (route) نہیں تھا جو حقیقت میں وہاں تک پہنچ سکے۔ سرور سائیڈ کام کر رہی تھی۔ یوزر سائیڈ نہیں۔

زیادہ تر لوگ جو اس کا سامنا کرتے ہیں وہ یہ سمجھتے ہیں کہ AI سست ہو گیا ہے یا ٹوکن کی حد (token limit) ختم ہو گئی ہے۔ ایسا نہیں ہو رہا ہے۔ مسئلہ ساختی (structural) ہے۔ AI کوڈنگ ٹولز کو اندرونی ہم آہنگی (internal consistency) کی نگرانی کے لیے بنایا گیا ہے۔ وہ پوچھتے ہیں: "کیا جو کچھ میں نے بیان کیا ہے وہ ایک دوسرے کے مطابق ہے؟" وہ یہ نہیں پوچھتے کہ: "کیا اس قسم کے ڈیلیوریبل (deliverable) میں وہ سب کچھ شامل ہے جو اسے ہونا چاہیے؟" اگر آپ اپنی برانڈ سائٹ کے لیے دو صفحات کا ذکر کرتے ہیں، تو ماڈل فرض شناسی کے ساتھ یہ چیک کرتا ہے کہ آیا وہ دو صفحات ایک دوسرے سے جڑے ہوئے ہیں۔ ایک بار جب لنکس کام کرنے لگتے ہیں، تو وہ کام مکمل سمجھ لیتا ہے۔ اسے اس بات کا کوئی فطری تصور نہیں ہے کہ ایک برانڈ سائٹ کے لیے "About" پیج، اعتماد کے اشارے (trust signals)، یا رابطہ کرنے کا راستہ ہونا ضروری ہے۔ اس کے ذہن میں کوئی معیار (standard) نہیں ہوتا۔

میں اس حل کو Completeness Baseline کہتا ہوں۔

Completeness baseline محض ایک معیاری چیک لسٹ ہے کہ کسی بھی دیے گئے ڈیلیوریبل میں کیا کیا ہونا چاہیے۔ آپ آرٹفیکٹ (artifact) تیار کرتے ہیں، پھر ٹول کے "مکمل ہونے" کے اندرونی احساس پر بھروسہ کرنے کے بجائے، اس بیرونی معیار کے خلاف اصل آؤٹ پٹ کو چیک کرتے ہیں۔

تین تہوں (layers) پر چیک کرنا

تمام گمشدہ حصے یکساں طور پر واضح نہیں ہوتے۔ ایک مفید بیس لائن تین مختلف تہوں کو چیک کرتی ہے۔

وجود (Existence)۔ کیا وہ حصہ حقیقت میں موجود ہے؟ یہ سننے میں بنیادی لگتا ہے، لیکن ایک AI خوشی خوشی ایک نیویگیشن ریپر (navigation wrapper) بنا دے گا جو ڈیش بورڈ پیج کا حوالہ تو دے گا لیکن خود ڈیش بورڈ پیج کبھی تیار نہیں کرے گا۔ حوالہ موجود ہے۔ ہدف (target) موجود نہیں۔

رسائی (Reachability)۔ کیا ایک حقیقی صارف حقیقت میں وہاں تک پہنچ سکتا ہے؟ چھپے ہوئے ایڈمن پینلز اس کی کلاسیکی علامت ہیں۔ روٹ (route) اور کمپوننٹ (component) دونوں کوڈ بیس میں موجود ہو سکتے ہیں، پھر بھی کوئی مینو آئٹم، بٹن، یا ری ڈائریکٹ انہیں انٹرفیس پر ظاہر نہیں کرتا۔ اگر کوئی صارف عام استعمال کے دوران اس سے ٹکرا نہیں سکتا، تو وہ حقیقت میں وہاں موجود نہیں ہے۔

جامعیت (Substantiation)۔ کیا سطح کے پیچھے حقیقی ڈیٹا یا ڈھانچہ موجود ہے؟ ایک ایسا پیج جو لوڈ تو ہوتا ہے لیکن اس میں صرف پلیس ہولڈر ٹیکسٹ (placeholder text) ہو اور امیج اپ لوڈ کرنے کی جگہ نہ ہو، وہ ایک ایسا ڈھانچہ ہے جس نے صرف لباس پہن رکھا ہے۔ امیج سلاٹ یا قابل ترمیم ٹیکسٹ فیلڈ کے بغیر "About" پیج مکمل نہیں ہے، چاہے HTML صاف ستھرا رینڈر (render) ہی کیوں نہ ہو۔

یہ تین تہیں مختلف قسم کے خلاؤں کو پکڑتی ہیں۔ Existence گم شدہ جوتا ڈھونڈ لیتی ہے۔ Reachability الماری میں بند جوتا ڈھونڈ لیتی ہے۔ Substantiation بغیر تلے (sole) والا جوتا ڈھونڈ لیتی ہے۔

قسم کے لحاظ سے بیس لائنز

ایک بیس لائن ہر پروجیکٹ کے لیے کافی نہیں ہوگی۔ آپ کو یہ درجہ بندی کرنے کی ضرورت ہے کہ آپ کیا بنا رہے ہیں اور اس کیٹیگری کے لیے لازمی شرائط (non-negotiables) طے کرنے ہوں گی۔

Brand sites کو مخصوص سیکشنز اور قابل رسائی صفحات کی ضرورت ہوتی ہے۔ About، Contact، پرائیویسی لنکس، اور ایسی نیویگیشن کے بارے میں سوچیں جو حقیقت میں ہر اہم ویو (view) کو ظاہر کرے۔

APIs کو ڈاکومنٹیشن، جامع ایرر کوڈز (error codes)، اور ریٹ لمٹس (rate limits) کی ضرورت ہوتی ہے۔ ایک کام کرنے والا اینڈ پوائنٹ (endpoint) جو کامیابی کے لیے 200 OK اور باقی ہر چیز کے لیے عام 500 واپس کرتا ہے، وہ مکمل API نہیں ہے۔ یہ ایک خطرہ ہے۔

Automations کو لاگز (logs) اور ناکامی کے الرٹس (failure alerts) کی ضرورت ہوتی ہے۔ اگر کوئی ورک فلو رات 2 بجے ٹوٹ جائے اور جب تک کوئی انسان رن ہسٹری چیک نہ کرے کسی کو پتہ نہ چلے، تو وہ آٹومیشن نامکمل ہے۔ مشاہدہ (Observability) کوئی اضافی فیچر نہیں ہے۔ یہ ڈیلیوریبل کا حصہ ہے۔

ایک بار جب آپ کیٹیگری کا نام لے لیتے ہیں، تو بیس لائن خود بخود لکھ دی جاتی ہے۔ مشکل حصہ کوڈ تیار ہونے کے بعد اسے نافذ کرنا ہے۔

ڈیزائن کے اصول جو برقرار رہتے ہیں

میں نے اپنے ورک فلو کو اسی خیال کے گرد دوبارہ ترتیب دیا اور تین عملی اصولوں پر پہنچا جو پروجیکٹس کو آہستہ آہستہ بکھرنے سے بچاتے ہیں۔

Capability-gated design۔ کسی ٹول یا تیار کردہ ماڈیول پر بھروسہ کرنے سے پہلے، یہ معلوم کریں کہ وہ حقیقت میں کیا کر سکتا ہے۔ اگر کسی کمپوننٹ لائبریری میں نیٹو موبائل ڈرائر (native mobile drawer) سپورٹ نہیں ہے، تو AI کو ایسا مکمل نیویگیشن اسکیم بنانے کی اجازت نہ دیں جو یہ فرض کرے کہ وہ موجود ہے۔ سسٹم کو کسی صلاحیت کی کمی کی صورت میں ٹوٹنے کے بجائے بغیر کسی بڑی خرابی کے کام جاری رکھنا (degrade gracefully) چاہیے۔ پہلے حدود کو جانیں۔ ان کے اندر ڈیزائن کریں۔

Public engine, private values۔ بھاری کاموں کے لیے پبلک انجن استعمال کریں، لیکن اپنے نجی ڈیٹا، کنفیگریشنز اور

تجویز دیں، خودکار طریقے سے آگے نہ بڑھیں۔ AI کو اگلا قدم تجویز کرنے دیں، لیکن فیصلہ کرنے کے لیے انسان کو مجبور کریں۔ عمل کے بہاؤ (flow of execution) کو خودکار بنائیں، فیصلے (judgment) کو نہیں۔ جب کوئی ماڈل ایک ہی سانس میں ڈیٹا بیس مائیگریشن، آتھ اسکیم (auth scheme)، اور پیمنٹ ہک (payment hook) خودکار طریقے سے تیار کر دیتا ہے، تو آپ نگرانی کی قیمت پر سہولت حاصل کرتے ہیں۔ ٹول کو منصوبہ پیش کرنے دیں۔ ڈویلپر کو بٹن دبانے دیں۔

کام کے لیے صحیح ماڈل کا انتخاب کرنا

میں نے مختلف ماڈلز پر اس کا تجربہ کیا اور قیمت و معیار کے حوالے سے ایک واضح فرق پایا۔ سستے ماڈلز میکانکی کاموں (mechanical bulk) کو حیرت انگیز طور پر بہتر طریقے سے سنبھالتے ہیں۔ وہ آپ کے ٹائپ کرنے کی رفتار سے بھی زیادہ تیزی سے بوائلر پلیٹ (boilerplate)، بار بار آنے والے اجزاء (repetitive components)، اور اسٹرکچرل اسٹبز (structural stubs) تیار کر دیتے ہیں۔ مہنگے ماڈلز اپنی قیمت صرف اس وقت ثابت کرتے ہیں جب وہ ضبط کا مظاہرہ کریں۔ آپ کو پریمیم آپشن کی ضرورت تب ہوتی ہے جب وہ فرضی حل ایجاد کرنے سے انکار کر دے اور اس کے بجائے کسی حقیقی کمی کی نشاندہی کرے۔ ایسا ماڈل جو کسی غائب API اینڈ پوائنٹ کے لیے کوئی فرضی حل (workaround) گھڑ لے، وہ خطرناک ہے۔ ایک ایسا ماڈل جو رک جائے اور کہے، "اس ورک فلو کے لیے ایک ویب ہک ٹارگٹ (webhook target) کی ضرورت ہے جو کہ تعریف شدہ نہیں ہے،" وہ اپنی قیمت کے قابل ہے۔ بصیرت (discernment) کے لیے ادائیگی کریں، مقدار (volume) کے لیے نہیں۔

سسٹم بنائیں، جادو کے پیچھے نہ بھاگیں

AI کی خامیوں کو بڑے ماڈلز یا پرومپٹنگ کی مزید چالاکیوں سے ٹھیک کرنے کی کوشش نہ کریں۔ انہیں ایک بیس لائن (baseline) کے ذریعے ٹھیک کریں۔ یہ کمی صلاحیت (capacity) کا مسئلہ نہیں ہے۔ یہ توقعات (expectations) کا مسئلہ ہے۔

حصوں کے غائب ہونے کو روکنے کے لیے، تین کام کریں۔

کوئی بھی کوڈ لکھنے سے پہلے سسٹم کو مکمل ہونے کی ایک بیس لائن (completeness baseline) دیں۔ اسے ایک جسمانی چیک لسٹ (physical checklist) بنائیں جو کام کے ساتھ موجود ہو۔

اپنے اصولوں (conventions) کو دوبارہ استعمال ہونے والے حصوں (reusable parts) میں شامل کریں۔ اگر آپ ٹیمپلیٹس، لنٹ رولز (lint rules)، یا پہلے سے بنے ہوئے اسکیفولڈز (scaffolds) کے ذریعے اپنی بیس لائن کو نافذ کرتے ہیں، تو AI آپ کے معیار کا اندازہ لگانے کی امید کرنے کے بجائے درستگی کی پوزیشن سے آغاز کرے گا۔

فیصلہ سازی کا کنٹرول انسان کے پاس رکھتے ہوئے عمل کے بہاؤ کو خودکار بنائیں۔ مشینوں کو تکرار (repetition) سنبھالنے دیں۔ فیصلے ان لوگوں کے لیے رکھیں جو سیاق و سباق (context) کو سمجھتے ہوں۔

یہاں ایک آخری عادت ہے جس نے میرے کام کرنے کا طریقہ بدل دیا۔ اگر آپ سات بار ایک ہی ڈیزائن کا فیصلہ کرتے ہیں، تو اسے محض ایک وقتی انتخاب سمجھنا چھوڑ دیں۔ یہ تکرار نہیں ہے۔ یہ ایک قانون ہے۔ اسے نام دیں۔ اسے ایک اصول میں بدل دیں۔ اسے دستاویز (document) کریں۔ جب آپ اس پیٹرن کو کوڈ کی شکل دے دیتے ہیں، تو آپ اس امکان کو ختم کر دیتے ہیں کہ آٹھویں بار AI اس سے ہٹ جائے۔

اس فریم ورک کا ذریعہ اور اصل تحقیق یہاں مل سکتی ہے۔

اگر آپ ان لوگوں کے ساتھ اپنے تجربات بانٹنا چاہتے ہیں جو انہی مسائل پر کام کر رہے ہیں، تو آپ GyaanSetu learning community میں شامل ہو سکتے ہیں۔