---

اے آئی سے سافٹ ویئر کیسے بنائیں؟ فیچر پلاننگ اور نیگٹو پرومٹنگ کی اہمیت

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

اکثر لوگ اے آئی کو ایک مختصر سی ہدایت دیتے ہیں:

“یہ مینجمنٹ سسٹم بنا دیں اور تمام ضروری فیچرز شامل کر دیں۔”

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

اس مسئلے کی بنیادی وجہ اکثر کوڈنگ نہیں بلکہ منصوبہ بندی اور پرامپٹنگ ہوتی ہے۔

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

صرف “تمام فیچرز شامل کریں” کہنا کافی کیوں نہیں؟

انسان جب کہتا ہے:

“تمام ضروری فیچرز شامل کر دیں”

تو اس کے ذہن میں بہت سی چیزیں پہلے سے موجود ہوتی ہیں۔

لیکن اے آئی کو معلوم نہیں ہوتا کہ آپ کے نزدیک:

• کون سا فیچر لازمی ہے؟
• کون سا فیچر مستقبل کے لیے ہے؟
• کون سا فیچر ایڈمن کے لیے ہونا چاہیے؟
• کون سا فیچر صارف کے لیے ہونا چاہیے؟
• کن صفحات کو آپس میں مربوط ہونا چاہیے؟
• کون سا ڈیٹا محفوظ ہونا چاہیے؟
• کن اعمال کا ریکارڈ رکھنا ضروری ہے؟
• کن جگہوں پر اجازت یا پرمیشن درکار ہوگی؟
• کن حالات میں سسٹم کو عمل روک دینا چاہیے؟
• کس چیز کو ہرگز نہیں کرنا چاہیے؟

اسی لیے ایک مختصر جملہ اکثر مطلوبہ نتیجہ نہیں دیتا۔

اصل فرق پرامپٹ کی لمبائی سے زیادہ اس کی وضاحت، ساخت اور پابندیوں سے پڑتا ہے۔

پہلا مرحلہ: پہلے مکمل فیچرز لکھوائیں

جب آپ کسی نئے سافٹ ویئر پر کام شروع کریں تو فوراً اے آئی کو کوڈ لکھنے نہ دیں۔

سب سے پہلے اس سے کہیں کہ وہ اس سسٹم کے تمام فیچرز تفصیل سے لکھے۔

مثلاً اگر آپ:

اسکن اور لیزر کلینک مینجمنٹ سسٹم

بنانا چاہتے ہیں تو پہلے یہ معلوم ہونا چاہیے کہ اس میں صرف:

• مریض
• اپائنٹمنٹ
• ادائیگی

ہی نہیں بلکہ اس سے کہیں زیادہ چیزیں درکار ہوں گی۔

مثلاً:

• مریض کا مکمل پروفائل
• میڈیکل ہسٹری
• الرجی
• علاج کی سابقہ تفصیلات
• جلد کی تصاویر
• بیفور اینڈ آفٹر تصاویر
• اپائنٹمنٹس
• ڈاکٹر یا تھراپسٹ شیڈول
• ٹریٹمنٹ پلان
• لیزر سیشنز
• پیکیجز
• سیشن بیلنس
• کنسنٹ فارمز
• ادائیگیاں
• بقایا جات
• انوائس
• اخراجات
• اسٹاک
• استعمال ہونے والی اشیا
• آلات
• مشین مینٹیننس
• ملازمین
• کمیشن
• رپورٹس
• یاددہانیاں
• صارفین کی اجازتیں
• آڈٹ لاگ
• بیک اپ
• سیکیورٹی

وغیرہ۔

یہ فہرست صرف مثال ہے۔ اصل سسٹم میں اس سے کہیں زیادہ تفصیل ہو سکتی ہے۔

فیچرز براہِ راست لکھوائیں یا ایم ڈی فائل بنوائیں؟

یہاں ایک دلچسپ عملی فرق سامنے آتا ہے۔

اگر آپ اے آئی سے کہیں:

“مجھے تمام فیچرز تفصیل سے لکھ کر دیں”

تو وہ اکثر جواب چیٹ یا ورک اسپیس میں بہت تفصیل سے لکھ دیتا ہے۔

اس کا فائدہ یہ ہے کہ بعض اوقات اے آئی:

• زیادہ وضاحت کرتا ہے
• فیچرز کے اندر ذیلی فیچرز لکھتا ہے
• ورک فلو سمجھاتا ہے
• ڈیٹا فیلڈز تجویز کرتا ہے
• مختلف حالات بھی بیان کرتا ہے

لیکن مسئلہ یہ ہوتا ہے کہ بعد میں اس مکمل مواد کو الگ فائل میں منتقل کرنا پڑ سکتا ہے۔

دوسری طرف اگر شروع ہی میں کہیں:

“تمام فیچرز ایک ایم ڈی فائل میں بنائیں”

تو ایک منظم فائل حاصل کرنا زیادہ آسان ہو جاتا ہے۔

یعنی دونوں طریقوں کا اپنا فائدہ ہے۔

مختصر منصوبہ بندی

چیٹ میں فیچرز لکھوانا کافی ہو سکتا ہے۔

سنجیدہ پروجیکٹ

فیچرز کو ایک منظم Markdown یا .md فائل میں محفوظ کرنا زیادہ فائدہ مند ہے۔

صرف ایم ڈی فائل بنا لینا بھی کافی نہیں

یہاں ایک بہت اہم مسئلہ پیدا ہوتا ہے۔

فرض کریں آپ نے ایک انتہائی تفصیلی فیچر فائل تیار کر لی۔

پھر اسے کسی اے آئی کوڈنگ ایجنٹ کو دے کر صرف اتنا کہا:

“اس فائل پر مکمل عمل کریں۔”

یہ ضروری نہیں کہ وہ حقیقتاً پوری فائل پر عمل کرے۔

کوڈنگ ایجنٹ بعض اوقات:

• کچھ فیچرز چھوڑ دیتا ہے
• کچھ فیچرز کو صرف ظاہری شکل میں بنا دیتا ہے
• بیک اینڈ مکمل نہیں کرتا
• ڈیٹا بیس سے کنکشن نہیں بناتا
• بٹن بنا دیتا ہے مگر فنکشن نہیں
• صفحات بنا دیتا ہے لیکن ورک فلو نہیں جوڑتا
• خود یہ فرض کر لیتا ہے کہ کام مکمل ہو گیا ہے

یہی وہ مقام ہے جہاں Implementation Prompt ضروری ہو جاتا ہے۔

ایم ڈی فائل کے ساتھ سخت امپلیمنٹیشن پرامپٹ کیوں ضروری ہے؟

فیچر فائل صرف یہ بتاتی ہے کہ:

کیا بننا چاہیے۔

جبکہ Implementation Prompt اے آئی کو بتاتا ہے:

یہ سب کس اصول کے تحت بنانا ہے۔

اس پرامپٹ میں واضح طور پر یہ ہدایات ہونی چاہئیں کہ:

• فیچر فائل مکمل پڑھی جائے
• کوئی سیکشن نظر انداز نہ کیا جائے
• ہر فیچر کو الگ شناخت کیا جائے
• انحصار رکھنے والے فیچرز پہلے سمجھے جائیں
• فیچر بنانے سے پہلے موجودہ کوڈ دیکھا جائے
• ڈپلیکیٹ سسٹم نہ بنایا جائے
• UI اور بیک اینڈ دونوں مکمل ہوں
• ڈیٹا محفوظ ہو
• ہر متعلقہ بٹن حقیقتاً کام کرے
• فیچر بنانے کے بعد خود ٹیسٹ کیا جائے
• فیچر فائل کے خلاف دوبارہ تصدیق کی جائے
• کوئی فیچر رہ جائے تو کام مکمل تصور نہ کیا جائے

ایک مؤثر امپلیمنٹیشن پرامپٹ کی مثال

آپ اے آئی سے اس قسم کا پرامپٹ بھی بنوا سکتے ہیں:

“میرے لیے ایسا سخت Implementation Prompt تیار کریں جو کوڈنگ اے آئی کو پابند کرے کہ وہ دی گئی فیچر فائل مکمل پڑھے، تمام فیچرز ایک ایک کر کے بنائے، کوئی فیچر چھوڑے نہیں، ہر فیچر مکمل ہونے کے بعد اس کی فعالیت چیک کرے، آخر میں پوری فیچر فائل کے مقابلے میں implementation audit کرے اور جب تک تمام فیچرز مکمل نہ ہوں کام کو مکمل قرار نہ دے۔ کام کے دوران ایسی اجازتیں یا غیر ضروری سوالات نہ کرے جن کا جواب موجودہ پروجیکٹ، فیچر فائل یا کوڈ سے خود حاصل کیا جا سکتا ہو۔”

یہ ایک بنیادی خیال ہے۔

اصل پروفیشنل پرامپٹ اس سے کہیں زیادہ تفصیل میں لکھا جا سکتا ہے۔

فائل اپلوڈ کرنے کے بجائے پروجیکٹ میں فائل رکھنا

کوڈنگ ایجنٹس کے ساتھ کام کرتے وقت ایک مفید طریقہ یہ ہے کہ فیچر فائل کو بار بار چیٹ میں اپلوڈ کرنے کے بجائے اسے خود پروجیکٹ فولڈر کے اندر رکھا جائے۔

مثلاً:

project/
│
├── src/
├── public/
├── docs/
│   └── FEATURES.md
├── package.json
└── README.md

پھر اے آئی کو واضح طور پر بتایا جائے:

Read:
docs/FEATURES.md

اس طریقے کے کئی فائدے ہیں۔

1۔ فائل پروجیکٹ کا حصہ بن جاتی ہے

کوڈنگ ایجنٹ ضرورت پڑنے پر دوبارہ اسے پڑھ سکتا ہے۔

2۔ واضح حوالہ موجود رہتا ہے

بعد میں آپ کہہ سکتے ہیں:

“FEATURES.md کے Section 8 کی implementation دوبارہ چیک کریں۔”

3۔ ٹیم کے دوسرے لوگ بھی اسے دیکھ سکتے ہیں

اگر پروجیکٹ GitHub وغیرہ پر ہے تو یہی دستاویز پوری ٹیم کے لیے specification بن سکتی ہے۔

4۔ فیچر آڈٹ آسان ہو جاتا ہے

بعد میں مکمل سسٹم کو اسی فائل کے مقابلے میں چیک کیا جا سکتا ہے۔

پروجیکٹ کے فیچرز بنانے کے دو اہم طریقے

اس کام کو بنیادی طور پر دو سطحوں پر کیا جا سکتا ہے۔

طریقہ نمبر 1: اے آئی کی اپنی معلومات سے فیچر پلان بنوانا

اگر آپ:

• پریکٹس کر رہے ہیں
• چھوٹا ٹول بنا رہے ہیں
• پروٹو ٹائپ بنا رہے ہیں
• کلاس کا پراجیکٹ بنا رہے ہیں
• ابتدائی MVP بنا رہے ہیں

تو یہ طریقہ کافی ہو سکتا ہے۔

اے آئی کو اپنے سسٹم کی تفصیل دیں اور کہیں کہ اس کے مکمل فیچرز تیار کرے۔

مثلاً:

“میں ایک کلینک مینجمنٹ سسٹم بنا رہا ہوں۔ مجھے اس کے تمام بنیادی، ایڈوانس، ایڈمن، مالیاتی، مریض، اسٹاف، سیکیورٹی اور رپورٹنگ فیچرز مکمل تفصیل کے ساتھ دیں۔”

پھر حاصل ہونے والی فہرست کو review کر کے Implementation Prompt کے ساتھ استعمال کریں۔

طریقہ نمبر 2: ڈیپ ریسرچ کے بعد فیچرز بنوانا

اگر آپ ایسا سافٹ ویئر بنا رہے ہیں جسے:

• مستقل استعمال کرنا ہے
• کسی کاروبار میں چلانا ہے
• کلائنٹ کو دینا ہے
• مستقبل میں فروخت کرنا ہے
• SaaS بنانا ہے
• مارکیٹ میں مقابلہ کرنا ہے

تو صرف اے آئی کی عمومی معلومات پر انحصار نہیں کرنا چاہیے۔

یہاں Deep Research زیادہ مفید ہو سکتی ہے۔

ڈیپ ریسرچ کا مقصد کیا ہے؟

ڈیپ ریسرچ کا مقصد صرف یہ معلوم کرنا نہیں کہ:

“کلینک مینجمنٹ سسٹم میں کون سے فیچرز ہوتے ہیں؟”

بلکہ اصل مقصد یہ ہونا چاہیے:

“دنیا میں موجود کامیاب سسٹمز کیا کر رہے ہیں، صارفین کو کن مسائل کا سامنا ہے اور ہم ان دونوں سے کیا سیکھ سکتے ہیں؟”

موجودہ سافٹ ویئرز کا جائزہ لینا کیوں ضروری ہے؟

فرض کریں آپ ایک لیزر کلینک سسٹم بنانا چاہتے ہیں۔

ممکن ہے آپ کے ذہن میں پچاس فیچرز ہوں۔

لیکن دنیا میں موجود سافٹ ویئر بنانے والی کمپنیاں:

• کئی سال سے یہ سسٹم بنا رہی ہوں
• ہزاروں کلینکس سے feedback لے چکی ہوں
• سیکڑوں اپڈیٹس کر چکی ہوں
• مختلف ممالک کے قوانین دیکھ چکی ہوں
• صارفین کی شکایات سن چکی ہوں

لہٰذا ان کے تجربے سے فائدہ لینا زیادہ دانشمندانہ ہے۔

آپ کو ہر چیز صفر سے خود دریافت کرنے کی ضرورت نہیں۔

ڈیپ ریسرچ میں کن چیزوں کا جائزہ لینا چاہیے؟

ایک اچھا تحقیقی پرامپٹ صرف competitor features جمع نہ کرے۔

اسے کئی زاویوں سے تحقیق کرنی چاہیے۔

1۔ موجودہ معروف سسٹمز

دیکھیں کہ مارکیٹ میں کون سے سافٹ ویئر پہلے سے موجود ہیں۔

ان کے:

• فیچرز
• ورک فلوز
• قیمتوں کے ماڈلز
• integrations
• موبائل سہولت
• رپورٹنگ
• automation

کا جائزہ لیا جا سکتا ہے۔

2۔ صارفین کے Reviews

کسی کمپنی کی اپنی ویب سائٹ ہمیشہ اس کی خوبیاں بتائے گی۔

اصل معلومات اکثر صارفین کے تجربات سے حاصل ہوتی ہیں۔

تحقیق میں دیکھیں:

• صارفین کس چیز کی تعریف کرتے ہیں؟
• وہ بار بار کس مسئلے کی شکایت کرتے ہیں؟
• کون سا کام بہت پیچیدہ ہے؟
• کس جگہ unnecessary clicks ہیں؟
• کس فیچر کی کمی بار بار بیان کی جاتی ہے؟
• کون سا فیچر نام تو موجود ہے لیکن استعمال میں ناقص ہے؟

3۔ فورمز اور کمیونٹیز

پروفیشنل کمیونٹیز اور فورمز میں لوگ اکثر حقیقی مسائل بیان کرتے ہیں۔

مثلاً:

“ہمیں ہر مریض کے پیکیج میں باقی سیشن دیکھنے میں مشکل ہوتی ہے۔”

یہ ایک انتہائی قیمتی product insight بن سکتی ہے۔

اس سے آپ اپنے سسٹم میں شروع ہی سے:

Remaining Sessions

کا واضح فیچر بنا سکتے ہیں۔

4۔ ویڈیوز اور ڈیموز

سافٹ ویئر کا feature page ایک چیز ہے۔

اصل workflow دیکھنا دوسری چیز ہے۔

ڈیمو سے معلوم ہو سکتا ہے کہ:

• اپائنٹمنٹ کیسے بنتی ہے؟
• مریض کیسے check-in کرتا ہے؟
• ٹریٹمنٹ نوٹس کہاں جاتے ہیں؟
• ادائیگی کیسے درج ہوتی ہے؟
• follow-up کیسے بنتا ہے؟
• رپورٹ کتنے steps میں نکلتی ہے؟

5۔ قانونی اور پرائیویسی کے تقاضے

خاص طور پر healthcare جیسے شعبوں میں صرف فیچرز کافی نہیں۔

آپ کو یہ بھی سوچنا ہوگا کہ:

• مریض کا ڈیٹا کس کو نظر آئے؟
• تصاویر کون دیکھ سکتا ہے؟
• معلومات کس طرح محفوظ ہوں؟
• audit trail موجود ہے یا نہیں؟
• ریکارڈ delete کرنے کی اجازت کس کو ہو؟
• consent کیسے محفوظ ہوگا؟

یہ requirements ملک اور استعمال کے ماحول کے لحاظ سے مختلف ہو سکتی ہیں، اس لیے حقیقی سسٹم کے لیے مقامی قانونی جائزہ الگ ضروری رہتا ہے۔

مثبت فیچرز کے ساتھ خامیاں بھی جمع کریں

یہ شاید پورے workflow کا سب سے زیادہ نظر انداز کیا جانے والا حصہ ہے۔

صرف یہ نہ پوچھیں:

“بہترین سافٹ ویئرز میں کیا اچھا ہے؟”

یہ بھی پوچھیں:

“لوگ ان سافٹ ویئرز سے کس وجہ سے پریشان ہیں؟”

کیونکہ competitor کی خرابی آپ کے لیے Negative Requirement بن سکتی ہے۔

نیگیٹو پرامپٹنگ کیا ہے؟

نیگیٹو پرامپٹنگ کا سادہ مطلب ہے:

اے آئی کو صرف یہ نہ بتانا کہ کیا کرنا ہے بلکہ یہ بھی بتانا کہ کیا نہیں کرنا۔

مثلاً:

مثبت ہدایت

“مریض کا پروفائل بنائیں۔”

بہتر ہدایت

“مریض کا مکمل پروفائل بنائیں جس میں رابطہ معلومات، تاریخ، ٹریٹمنٹ ہسٹری، تصاویر اور نوٹس شامل ہوں۔”

مثبت + نیگیٹو ہدایت

“مریض کا مکمل پروفائل بنائیں، لیکن حساس معلومات ہر ملازم کو نہ دکھائیں، permissions کو bypass نہ کریں، تصاویر public URLs کے ذریعے expose نہ کریں اور record deletion کو بغیر audit trail کے ممکن نہ بنائیں۔”

تیسری ہدایت زیادہ محفوظ اور زیادہ واضح ہے۔

نیگیٹو پرامپٹ کیوں اہم ہے؟

بعض اوقات کسی کام کو صحیح کروانے کے لیے صرف یہ کہنا کافی نہیں ہوتا کہ:

“یہ کام کریں۔”

یہ بھی بتانا پڑتا ہے:

“یہ کام اس غلط طریقے سے نہ کریں۔”

سافٹ ویئر ڈیولپمنٹ میں یہ خاص طور پر اہم ہے کیونکہ اے آئی اکثر مقصد حاصل کرنے کے لیے آسان ترین راستہ اختیار کر سکتا ہے۔

مثلاً اگر کہا جائے:

“Login feature بنائیں”

تو ممکن ہے وہ ایک ظاہری login page بنا دے۔

لیکن اگر ساتھ کہیں:

• hardcoded users استعمال نہ کریں
• password plain text میں محفوظ نہ کریں
• frontend-only authentication نہ بنائیں
• permissions صرف UI hide کر کے implement نہ کریں

تو implementation کافی بہتر ہو سکتی ہے۔

منفی نتائج بھی تحقیق کا نتیجہ ہوتے ہیں

تحقیق میں ایسا نتیجہ بھی قیمتی ہوتا ہے جو یہ بتائے کہ:

“یہ طریقہ استعمال نہیں کرنا چاہیے۔”

اگر کسی موجودہ سسٹم کے صارفین مسلسل یہ شکایت کر رہے ہیں کہ:

• interface بہت پیچیدہ ہے
• رپورٹ سمجھ نہیں آتی
• appointment reschedule کرنا مشکل ہے
• duplicate patient records بن جاتے ہیں
• inventory خود update نہیں ہوتی
• mobile interface ناقص ہے

تو یہ complaints آپ کے لیے خامیاں نہیں بلکہ design requirements ہیں۔

آپ اپنے اے آئی کو واضح طور پر کہہ سکتے ہیں:

“ہمارے سسٹم میں یہ مسائل نہیں آنے چاہئیں۔”

Positive Requirements اور Negative Requirements

ایک مضبوط سافٹ ویئر specification میں دونوں ہونے چاہئیں۔

Positive Requirements

یہ وہ چیزیں ہیں جو لازماً بننی چاہئیں۔

مثلاً:

• مکمل appointment system
• patient history
• treatment plans
• inventory tracking
• invoices
• role-based permissions
• reports

Negative Requirements

یہ وہ چیزیں ہیں جو نہیں ہونی چاہئیں۔

مثلاً:

• duplicate patient profiles نہ بنیں
• unauthorized staff clinical data نہ دیکھ سکے
• booking accidentally double نہ ہو
• deleted financial transaction خاموشی سے غائب نہ ہو
• dummy buttons باقی نہ رہیں
• fake statistics نہ دکھائے جائیں
• hardcoded dashboard figures استعمال نہ ہوں
• save button صرف ظاہری نہ ہو
• frontend میں کامیابی دکھا کر backend failure چھپایا نہ جائے

یہ Negative Requirements اے آئی کو غلط shortcuts لینے سے روکتی ہیں۔

ڈیپ ریسرچ کے لیے بہتر پرامپٹ کیسے لکھیں؟

ایک بنیادی تحقیقی پرامپٹ اس طرح بنایا جا سکتا ہے:

“میں ایک جدید اسکن، لیزر اور ایستھیٹک کلینک مینجمنٹ سسٹم بنانا چاہتا ہوں۔ دنیا بھر میں موجود معروف کلینک، میڈیکل اسپاز، اسکن کلینکس اور لیزر کلینک مینجمنٹ سسٹمز کا گہرائی سے جائزہ لیں۔ ان کے فیچرز، ورک فلوز، رپورٹس، اپائنٹمنٹ سسٹمز، مریض مینجمنٹ، ٹریٹمنٹ پلاننگ، پیکیجز، سیشن ٹریکنگ، تصاویر، کنسنٹ، ادائیگی، انوینٹری، اسٹاف، کمیشن، مارکیٹنگ، کمیونیکیشن، automation، security اور integrations کا تقابلی جائزہ لیں۔ اس کے ساتھ صارفین کے reviews، complaints، forums اور دستیاب demonstrations سے بار بار سامنے آنے والی خامیاں بھی الگ نوٹ کریں۔ تحقیق کے نتیجے میں مجھے صرف عام رپورٹ نہ دیں بلکہ ایسی structured product requirements بنائیں جنہیں بعد میں coding AI کے لیے مکمل feature specification میں تبدیل کیا جا سکے۔”

یہ عام سوال:

“Clinic software میں کیا features ہوتے ہیں؟”

سے کہیں زیادہ طاقتور ہے۔

ایک اے آئی کی تحقیق دوسرے اے آئی کو دینا

اگر آپ زیادہ مضبوط نتیجہ چاہتے ہیں تو ایک ہی اے آئی کی تحقیق پر مکمل انحصار کرنا ضروری نہیں۔

مثلاً:

مرحلہ 1

ایک research tool سے competitor research کروائیں۔

مرحلہ 2

حاصل ہونے والی research محفوظ کریں۔

مرحلہ 3

دوسرے advanced AI کو کہیں کہ:

• اس تحقیق کا جائزہ لے
• اپنی الگ تحقیق کرے
• دونوں کو compare کرے
• missing areas تلاش کرے
• contradictions identify کرے
• final feature specification بنائے

اس طریقے سے دوسری اے آئی صرف پہلی رپورٹ نقل نہیں کرتی بلکہ اسے research input کے طور پر استعمال کرتی ہے۔

تحقیق کی رپورٹ نہیں، قابلِ عمل فیچر Specification مانگیں

یہ ایک اہم فرق ہے۔

اگر مقصد سافٹ ویئر بنانا ہے تو آخر میں صرف ایک academic رپورٹ کی ضرورت نہیں۔

آپ کو ایسی چیز چاہیے جس پر coding AI عمل کر سکے۔

اسی لیے final instruction یہ ہونی چاہیے کہ تحقیق مکمل ہونے کے بعد نتیجہ:

AI-ready Feature Specification

میں تبدیل کیا جائے۔

ایک اچھی Feature Specification میں کیا ہونا چاہیے؟

ہر بڑے فیچر کے اندر کم از کم یہ چیزیں شامل کی جا سکتی ہیں:

فیچر کا نام

مثلاً:

Patient Management

مقصد

یہ فیچر کیوں بنایا جا رہا ہے؟

صارفین

کون اسے استعمال کرے گا؟

مثلاً:

• Admin
• Doctor
• Therapist
• Receptionist

اہم Actions

صارف کیا کر سکے گا؟

Required Fields

کون سا ڈیٹا محفوظ ہوگا؟

Business Rules

کن شرائط کے تحت کام ہوگا؟

Permissions

کس کو کیا کرنے کی اجازت ہوگی؟

Validation

غلط ڈیٹا کیسے روکا جائے گا؟

Edge Cases

غیر معمولی حالات میں کیا ہوگا؟

Integrations

یہ کن دوسرے modules سے جڑا ہوگا؟

Negative Requirements

اس فیچر میں کن غلطیوں کی اجازت نہیں ہونی چاہیے؟

Acceptance Criteria

ہم کیسے تصدیق کریں گے کہ فیچر حقیقتاً مکمل ہے؟

یہ structure coding agent کے لیے بہت زیادہ واضح ہوتا ہے۔

صرف UI بنا دینا فیچر مکمل ہونا نہیں

اے آئی ڈیولپمنٹ میں یہ مسئلہ بہت عام ہے۔

مثلاً آپ کہیں:

“Inventory Management بنائیں۔”

اے آئی:

• Inventory page بنا دیتا ہے
• table بنا دیتا ہے
• Add Item بٹن لگا دیتا ہے
• چند dummy products دکھا دیتا ہے

اور سمجھتا ہے کہ فیچر مکمل ہے۔

لیکن حقیقی Inventory Management میں ممکن ہے یہ سب بھی درکار ہو:

• item creation
• categories
• units
• suppliers
• purchase entries
• stock-in
• stock-out
• treatment consumption
• damaged stock
• stock adjustment
• minimum stock
• expiry dates
• batch tracking
• low-stock alerts
• usage history
• inventory valuation
• audit log
• reports

اسی لیے specification جتنی واضح ہوگی، implementation اتنی مضبوط ہوگی۔

ہر فیچر کے بعد خود تصدیق کروانا ضروری ہے

اے آئی کو یہ ہدایت دینی چاہیے کہ:

“Feature created”

لکھ دینا کافی نہیں۔

اسے خود verify بھی کرنا ہوگا کہ:

• متعلقہ page موجود ہے
• route چل رہا ہے
• form submit ہوتا ہے
• data database میں جاتا ہے
• edit کام کرتا ہے
• delete policy کے مطابق چلتا ہے
• permissions صحیح ہیں
• validation کام کرتی ہے
• دوسرے modules سے integration صحیح ہے
• refresh کے بعد data برقرار رہتا ہے

فیچر چیک لسٹ بنوائیں

ایک مفید طریقہ یہ ہے کہ پوری فیچر فائل کو checklist میں تبدیل کروایا جائے۔

مثلاً:

[ ] Patient Registration
[ ] Patient Medical History
[ ] Patient Photos
[ ] Consent Forms
[ ] Appointment Booking
[ ] Appointment Rescheduling
[ ] Appointment Cancellation
[ ] Treatment Plans
[ ] Package Management
[ ] Session Tracking
[ ] Payments
[ ] Receivables
[ ] Inventory
[ ] Staff
[ ] Reports

کام مکمل ہوتے ہوئے:

[x] Patient Registration
[x] Patient Medical History
[x] Patient Photos

اس طرح agent کے لیے بھی track کرنا آسان ہوتا ہے کہ کتنا کام باقی ہے۔

Final Feature Audit لازمی رکھیں

جب coding agent کہے:

“تمام فیچرز مکمل ہو گئے ہیں”

تو فوراً یہ نہ مانیں کہ واقعی مکمل ہو گئے ہیں۔

ایک الگ audit کروائیں۔

اس audit کا مقصد نئی coding نہیں بلکہ verification ہونا چاہیے۔

اے آئی کو کہیں:

1. اصل Feature Specification دوبارہ پڑھیں۔
2. موجودہ codebase کا جائزہ لیں۔
3. ہر requirement کا corresponding implementation تلاش کریں۔
4. missing feature الگ لکھیں۔
5. partially implemented feature الگ لکھیں۔
6. broken integration الگ لکھیں۔
7. dummy data یا placeholder implementation الگ لکھیں۔
8. security gaps الگ لکھیں۔
9. تمام gaps مکمل کریں۔
10. دوبارہ audit کریں۔

یہ عمل سافٹ ویئر کی quality میں بہت بڑا فرق پیدا کر سکتا ہے۔

اے آئی کو اپنے تصور کو حقیقت ماننے سے روکیں

Coding AI کی ایک اہم کمزوری یہ ہے کہ بعض اوقات وہ:

جو بنانے کا ارادہ کرتا ہے اسے بنا ہوا سمجھ لیتا ہے۔

اسی لیے صرف اس کے statement پر اعتبار نہ کریں۔

مثلاً:

“Authentication implemented successfully.”

یہ حقیقی ثبوت نہیں۔

ثبوت یہ ہے کہ:

• user register ہو
• login ہو
• incorrect password reject ہو
• protected page unauthorized user نہ کھول سکے
• token/session درست چلے
• logout کے بعد access ختم ہو
• role permissions enforce ہوں

اسی لیے اپنے prompts میں verification based on actual code and behavior کی شرط رکھیں۔

بار بار اجازت لینے کا مسئلہ

بڑے پروجیکٹ میں ایک اور مسئلہ پیدا ہوتا ہے۔

اے آئی ہر چھوٹے مرحلے پر پوچھتا رہتا ہے:

“کیا میں اگلا فیچر شروع کروں؟”

اگر Feature Specification پہلے سے مکمل ہے تو ایسی permission اکثر غیر ضروری ہوتی ہے۔

اس لیے Implementation Prompt میں یہ واضح کیا جا سکتا ہے کہ:

“Specification میں پہلے سے منظور شدہ فیچرز مکمل کرنے کے لیے ہر مرحلے پر دوبارہ اجازت طلب نہ کریں۔ جہاں requirements واضح ہیں وہاں مسلسل کام کریں۔ صرف ایسی صورت میں سوال کریں جہاں کوئی اہم فیصلہ موجودہ specification، codebase یا project conventions سے حل نہ کیا جا سکے۔”

اس سے workflow زیادہ مؤثر ہو جاتا ہے۔

تحقیق میں وقت لگانا وقت ضائع کرنا نہیں

لوگ اکثر محسوس کرتے ہیں کہ:

“اتنی تحقیق میں وقت کیوں لگائیں؟ اتنی دیر میں اے آئی آدھا سافٹ ویئر بنا دے گا۔”

لیکن بڑے پروجیکٹ میں یہی ابتدائی تحقیق بعد کا بہت سا وقت بچاتی ہے۔

بغیر تحقیق کے ممکن ہے:

• architecture دوبارہ بنانا پڑے
• database schema تبدیل کرنا پڑے
• کئی صفحات دوبارہ بنانے پڑیں
• missing features بعد میں شامل کرنے پڑیں
• پہلے سے بنے modules توڑنے پڑیں
• data migrations کرنی پڑیں

یعنی ایک گھنٹہ صحیح planning میں لگانا بعض اوقات کئی دن کی rework سے بچا سکتا ہے۔

ہر پروجیکٹ کے لیے Deep Research ضروری نہیں

یہ بھی سمجھنا ضروری ہے کہ ہر چھوٹے پراجیکٹ کو enterprise research project بنانے کی ضرورت نہیں۔

اگر آپ:

• مشق کر رہے ہیں
• کلاس assignment بنا رہے ہیں
• چھوٹا calculator بنا رہے ہیں
• prototype بنا رہے ہیں
• idea test کر رہے ہیں

تو مختصر feature planning کافی ہو سکتی ہے۔

لیکن اگر آپ:

• کاروباری سسٹم
• SaaS
• کلائنٹ سافٹ ویئر
• clinic system
• school system
• accounting system
• hotel system
• ERP
• CRM
• marketplace

جیسی سنجیدہ چیز بنا رہے ہیں تو تحقیق پر وقت خرچ کرنا فائدہ مند ہے۔

مکمل پروفیشنل ورک فلو

پورا طریقہ ایک ترتیب میں اس طرح رکھا جا سکتا ہے۔

مرحلہ 1: Idea Define کریں

واضح کریں کہ سافٹ ویئر کس مسئلے کو حل کرے گا۔

مرحلہ 2: ابتدائی فیچر پلان بنائیں

اے آئی سے تمام ممکنہ فیچرز تفصیل سے لکھوائیں۔

مرحلہ 3: Competitive Deep Research کریں

موجودہ معروف سسٹمز کا جائزہ لیں۔

مرحلہ 4: User Complaints جمع کریں

Reviews، forums اور حقیقی user feedback سے common problems نکالیں۔

مرحلہ 5: Positive Requirements بنائیں

وہ تمام چیزیں لکھیں جو سسٹم میں لازماً ہونی چاہئیں۔

مرحلہ 6: Negative Requirements بنائیں

وہ غلطیاں اور limitations لکھیں جو سسٹم میں نہیں آنی چاہئیں۔

مرحلہ 7: Final Feature Specification تیار کریں

تمام تحقیق کو coding-ready format میں تبدیل کریں۔

مرحلہ 8: Specification پروجیکٹ میں محفوظ کریں

مثلاً:

docs/FEATURES.md

مرحلہ 9: Implementation Prompt دیں

Coding AI کو واضح، سخت اور قابلِ تصدیق instructions دیں۔

مرحلہ 10: مرحلہ وار implementation کروائیں

تمام modules dependency order میں مکمل کروائیں۔

مرحلہ 11: ہر فیچر verify کروائیں

صرف files بننا completion نہیں۔

Functional testing بھی ضروری ہے۔

مرحلہ 12: Final Feature Audit کروائیں

اصل specification اور موجودہ codebase کا تقابلی جائزہ لیا جائے۔

مرحلہ 13: Missing Features مکمل کروائیں

جب تک checklist مکمل نہ ہو، feature phase کو complete نہ سمجھیں۔

ایک طاقتور بنیادی اصول

اے آئی سے اچھا سافٹ ویئر بنوانے کا اصول صرف یہ نہیں:

اے آئی کو زیادہ کام دیں۔

اصل اصول ہے:

اے آئی کے لیے کام کو زیادہ واضح بنائیں۔

آپ جتنا واضح بتائیں گے:

• کیا بنانا ہے
• کیوں بنانا ہے
• کیسے کام کرنا ہے
• کس سے جڑنا ہے
• کس کو اجازت ہے
• کس چیز کی اجازت نہیں
• مکمل ہونے کا معیار کیا ہے
• تصدیق کس طرح ہونی ہے

اتنا ہی بہتر نتیجہ ملنے کا امکان بڑھ جاتا ہے۔

نتیجہ

اے آئی کوڈنگ کے دور میں coding speed بہت بڑھ گئی ہے، لیکن specification کی اہمیت کم نہیں ہوئی بلکہ مزید بڑھ گئی ہے۔

ایک مختصر سا جملہ:

“تمام فیچرز شامل کر دیں”

بظاہر آسان ہے، لیکن بڑے سسٹم کے لیے کافی نہیں۔

زیادہ مضبوط طریقہ یہ ہے کہ:

Research → Feature Specification → Negative Requirements → Implementation Instructions → Verification → Final Audit

کا مکمل workflow اختیار کیا جائے۔

اس طریقے میں شروع میں زیادہ محنت محسوس ہوتی ہے، لیکن یہی محنت بعد میں:

• missing features
• repeated corrections
• incomplete modules
• broken workflows
• unnecessary redesign

سے بچاتی ہے۔

اے آئی خود سے بہت کچھ کر سکتا ہے، لیکن اسے واضح specification، مناسب context، حدود اور verification criteria دینا اب بھی انسان کی ذمہ داری ہے۔

اور یہی چیز ایک عام AI-generated application اور ایک واقعی استعمال کے قابل professional software system کے درمیان بڑا فرق پیدا کرتی ہے۔