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

لکھنے والے: CyrilXBT

مضمون کا ترجمہ، ماخذ: ME News

جون 2026 میں، ایک ہفتے کے اندر، تین افراد نے الگ الگ ایک ہی نتیجہ پر پہنچا۔

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

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

کچھ دن بعد، گوگل انجینئر اڈی اوسمنی نے اس عمل کا نظام کی بنیاد پر جائزہ لیا اور اسے ایک نام دیا:

لوپ انجینئرنگ، سائکل انجینئرنگ۔

انہوں نے اس طرز کام کو ایسے ہی نہیں بنایا، بلکہ ایک ایسے تبدیلی کا نام دیا جو پہلے ہی خاموشی سے ہو رہی تھی۔

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

یہی وجہ ہے کہ یہ راستہ منصوبہ بنایا گیا ہے۔

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

یہ ایک مکمل 20 مرحلہ کا راستہ ہے جو پرومپٹ آپریٹر سے سسٹم ڈیزائنر تک جاتا ہے۔ اس راستے میں مراحل کا ترتیب ضروری ہے، کیونکہ اس میں مراحل کے درمیان ترتیب عام طور پر کسی ایک منفرد مرحلے سے زیادہ اہم ہوتی ہے۔

سائکل انجینئرنگ ایک ایسی واحد مہارت نہیں ہے جسے آپ "سیکھ لیتے ہیں" یا "نہیں سیکھ پاتے"، بلکہ یہ ایک لیئرڈ کیپیبلٹی اسٹیک ہے۔ ہر لیئر، نیچے کی بنیاد کے مضبوط ہونے پر منحصر ہے۔

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

اسی طرح، اگر آپ 11ویں مرحلے کی مستقل یادداشت لیyer کو بنانے سے پہلے 6ویں اور 7ویں مرحلے کے قابل اعتماد تصدیقی مکینزم کو مکمل نہیں کرتے، تو آپ ایک بہت زیادہ آزاد، مستقل غلط نتائج کو منظور کرنے والے "جائزہ لینے والے" کی طرف سے جمع کردہ تجربات کو سنجیدہ طور پر محفوظ کر سکتے ہیں۔

یہ صرف سسٹم کی ترقی میں مدد نہیں کرے گا، بلکہ غلط تجربات کو جمع کرے گا اور میموری لیئر کو “جب تک غیر مستعمل” سے “فعال طور پر نقصان دہ” بنائے گا۔

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

اصلی پہلا قدم کسی بھی ٹیکنالوجی کو متعلق نہیں ہوتا۔

آپ کو قبول کرنا ہوگا کہ موجودہ ورک فلو میں، کارکردگی کی پابندیاں اکثر مدل کی صلاحیتوں کی بجائے آپ کے خود کو چکر میں پھنسے رہنے کی وجہ سے ہوتی ہیں۔

جب بھی آپ کمپیوٹر کے سامنے بیٹھ کر ماڈل کے جواب کا انتظار کرتے ہیں، نتائج پڑھتے ہیں اور اگلی ہدایت درج کرتے ہیں، تو آپ پورے سسٹم کا سب سے سستا حصہ بن جاتے ہیں۔

ماڈل کو انجام دیا جا سکتا ہے، تصدیق کیا جا سکتا ہے، اور دوبارہ کوشش کی جا سکتی ہے، جبکہ یہ عمل انسان کی طرف سے مرحلہ وار نگرانی کے مقابلے میں بہت تیز ہوتا ہے۔

یہ مرحلہ کسی مخصوص ہدایت کے مطابق نہیں ہے، یہ ایک شناختی فیصلہ ہے۔

جب تک آپ اسے حقیقت کے طور پر قبول نہیں کرتے، تو اگلے تمام مراحل ناکافی اضافی کام کی طرح لگتے ہیں، نہ کہ ان کا اصل مقصد — سسٹم میں سب سے بڑا کارکردگی کا بندبند۔

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

کچھ ماہوں کے بعد، یہ طریقہ قواعد کی ایک بلند دیوار بنائے گا: معلومات سے بھرپور، باہمی تضاد رکھنے والی، اور اتنی لمبی کہ مدل اپنی کام کی یادداشت میں تمام تقاضوں کو ایک ساتھ نہیں سنبھال سکے گا۔

آخر کار، ماڈل اکثر صرف حالیہ ظاہر ہونے والے یا سب سے زیادہ نمایاں مواد کے مطابق پیٹرن میچ کرتا ہے اور دیگر قواعد کو بے خبری سے نظرانداز کر دیتا ہے۔

سائکل انجینئرنگ نے اس خیال کو بالکل تبدیل کر دیا۔

جب کوئی مسئلہ پیدا ہو تو آپ صرف پرومپٹ میں ایک نیا مطالبہ نہیں جوڑتے، بلکہ سسٹم میں ایک نیا کمپوننٹ شامل کرتے ہیں، جیسے:

• ایک الگ تھلگ تصدیق قدم شامل کریں؛
• ایک میموری فائل شامل کریں؛
• ایک ٹائمڈ ٹریگر شامل کریں؛
• ایک ساختی جائزہ کا مرحلہ شامل کریں۔

جیسے جیسے باہری نظام کی صلاحیتیں بڑھتی جا رہی ہیں، پرامپٹس خود کو مزید لمبے نہیں، بلکہ مزید مختصر بنانا چاہیے۔

چاہے کوئی مخصوص کام کسی بھی شعبے سے تعلق رکھتا ہو، لوپ کی ہر ایک رن کو پانچ بنیادی ایکشن میں تقسیم کیا جا سکتا ہے:

شناخت، ہاتھاپائی، تصدیق، مستقل کرنا، شیڈولنگ۔

تشخیص

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

ہینڈ آف

کام کو اسٹیک ہونے والے ماڈل، ایجینٹ یا ٹول کو سونپ دیں۔

تصدیق

نتیجہ کو حقیقی معیاروں کے مطابق چیک کریں۔

پائیداری

اس چلائی گئی کارروائی کے دوران کیا ہوا، کیا سیکھا، اسے رکھیں تاکہ اگلی کارروائی میں تجربہ ضائع نہ ہو۔

شیڈولنگ

یہ پروسیجر کب دوبارہ چلنا چاہیے، اس کا فیصلہ کریں۔

زیادہ تر لوگوں کے موجودہ کام کے عمل میں صرف دو پہلوؤں کو واضح طور پر شamil کیا گیا ہے: کام کی شناخت اور کام کا منتقل کرنا، اور عام طور پر یہ چیٹ ونڈو میں ہاتھ سے کیا جاتا ہے۔

دوسرے تین اقدامات یا تو بالکل موجود نہیں ہیں، یا انسانی دماغ میں چھپے ہوئے ہیں۔

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

سسٹم بنانے سے پہلے، ایک ایسا کام منتخب کریں جسے آپ پہلے سے دہرا رہے ہیں اور جس کی معیار کی واضح تعریف کی جا سکتی ہے۔

سب سے مشکل سوالوں کو نہ چنیں اور نہ ہی کوئی نئی اور مکمل طور پر غیر معمولی کام کریں۔

پہلا انتخابی کام تین شرائط کو پورا کرنا چاہیے:

1. آپ کو اسے دہرانا ہوگا؛
2. اس کے پاس لکھنے کے قابل واضح معیارات ہیں؛
3. اس کا ایک آسانی سے پہچانے جانے والا "مکمل حالت" ہے۔

دوسرا طریقہ یہ ہے کہ ایک ساتھی نتیجہ دیکھ کر فوراً اندازہ لگا سکے کہ کام درست طریقے سے مکمل ہو گیا ہے۔

یہ پابندی سطحی سے زیادہ اہم ہے۔

اگر کسی کام کے لیے واضح ختم ہونے کا معیار نہ ہو، تو اصلی تصدیق کا عمل نہیں بنایا جا سکتا۔ اور جس چکر میں قابل اعتماد تصدیق کا نظام نہ ہو، وہ اصلی چکر نہیں ہوتا، بلکہ صرف ایک بے نگرانہ اندازہ ہوتا ہے۔

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

کسی ایجنٹ کے لیے کوئی ہدایت لکھنے سے پہلے، ایک درست نتیجہ کیسے دکھائی دینا چاہیے، اسے واضح اور قدرتی زبان میں لکھیں۔

آپ کو مبہم معیار جیسے "اچھا لگ رہا ہے" یا "پیشہ ورانہ لگ رہا ہے" کی بجائے واضح اور جانچنے والے معیار چاہیے۔

آپ درج ذیل ٹیمپلیٹ کا استعمال کر سکتے ہیں:

ٹاسک نام: [ٹاسک نام]

مکمل تعریف (Definition of Done، DoD):

• [مخصوص، جانچنے کے قابل معیار 1]
• [مخصوص، جانچنے کے قابل معیار 2]
• [مخصوص، جانچنے کے قابل معیار 3]

اگر بالآخر آؤٹ پٹ مکمل اور اچھی طرح سے تحریری شکل دیا گیا ہو، لیکن اوپر کے کسی بھی نقطہ کی کمی ہو، تو اس کام کو مکمل نہیں سمجھا جائے گا۔

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

یہ تمام سائکلک سسٹمز میں سب سے اہم آرکیٹیکچرل فیصلہ ہے۔

نتائج کی تیاری کے ذمہ دار کو، نتائج کی جانچ کے ذمہ دار سے الگ رکھنا چاہیے۔

اس کا سبب یہ ہے کہ جب ماڈل اپنے پیدا کردہ مواد کے بعد فوراً اپنے آؤٹ پٹ کا جائزہ لیتا ہے، تو وہ اکثر اپنے تازہ ترین جواب کی حمایت کرنے کی倾向 رکھتا ہے، نہ کہ اس میں موجود مسائل کا حقیقی طور پر تنقیدی انداز میں جائزہ لینا۔

ایک مناسب سائکل میں، کم از کم دو الگ الگ کردار ہونے چاہئیں:

بیلڈر

بلڈرز کے پاس تخلیق کے لیے کچھ جگہ ہوتی ہے، جو پہلے ورژن کے نتائج تیار کرنے کی ذمہ داری ہوتی ہے۔

جج

ریویورز بیلڈر کے آؤٹ پٹ اور مرحلہ 5 میں تعریف کردہ مکمل ہونے کے معیارات کو حاصل کرتے ہیں اور ان معیارات کے بنیاد پر نتائج کو مناسب یا نامناسب قرار دیتے ہیں۔

ایڈیل طور پر، ریویور کو بھی وہ مستقل ثبوت دستیاب ہونا چاہیے جن تک تعمیر کرنے والے تک پہنچ نہیں سکتے، جیسے:

• ٹیسٹ سوٹ؛
• اصل مواد؛
• ریل ٹائم ڈیٹا؛
• اہم ڈیٹا بیس؛
• Original task brief.

اس طرح، جائزہ دینے والے کا فیصلہ حقیقی ثبوت پر مبنی ہو گا، نہ کہ ساز بنانے والے کے ایک جیسے خیالات سے دوبارہ ایک ذاتی رائے پیدا کر کے۔

اگر جائزہ دینے والا صرف تعمیر کنندہ کے نتائج دیکھ سکتا ہے، تو وہ صرف یہ فیصلہ کر سکتا ہے کہ نتیجہ "منسجم لگ رہا ہے" یا نہیں۔

یہ یہ نہیں کہ سکتا کہ نتیجہ حقیقت میں درست ہے۔

اس لیے، جائزہ دینے والے کے پاس ایک آبجیکٹیو بنیاد ہونی چاہیے، جسے Ground Truth کہا جاتا ہے۔ مخصوص سیاق و سباق کے مطابق، اسے "بنیادی حقیقت"، "حقیقی ڈیٹا" یا "اختیاری بنیاد" کے طور پر سمجھا جا سکتا ہے۔

مختلف کاموں کے لیے عینی بنیادیں بھی مختلف ہوتی ہیں۔

پروگرامنگ کا کام

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

مواد تیار کرنے کا کام

مرجع کے طور پر اصل مواد اور مختصر نوٹس استعمال کیے جاتے ہیں۔ جائزہ لینے والے کو اصل مواد اور تیار کیے گئے مسودے کو ایک ساتھ موازنہ کرنا ہوگا۔

تحقیقی کام

موضوعی بنیاد وہ اصل فائلیں، تحقیقی مقالے، ڈیٹا سیٹس یا معتمد ذرائع ہیں جن کا استعمال کام کی واضح درخواست کے مطابق کیا جانا ہے۔

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

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

ورنہ، اگلے مینیجر کے پاس فیصلہ لینے اور راؤٹ کرنے کے لیے مستحکم اور قابل اعتماد معلومات نہیں ہوں گی۔

بنیادی طور پر درج ذیل خروجی فارمیٹ استعمال کیا جا سکتا ہے:

بِلڈر آؤٹپٹ:

• آخری اشاعت کا مواد؛
• نتیجے پر اعتماد کی سطح؛
• معلوم عدم یقین۔

جائزہ کنندہ درج ذیل خروجی فارمیٹ استعمال کر سکتا ہے:

جائزہ کا نتیجہ:

• PASS: منظور؛
• FAIL：ناکامی؛
• درست کی جانے کی ضرورت ہے؛
• دریافت کیا گیا مسئلہ؛
• اس جانچ کے لیے استعمال کیے گئے عینی معیار یا اصل ثبوت۔

آٹومیٹڈ اسکیڈولنگ اور آٹومیٹڈ ریٹرائی سے پہلے، ایک مکمل "بِلڈر—ریویور" پروسیجر کو اپنے ہاتھوں سے ہاتھ سے چلائیں۔

评审者提供的判断 کو دھیان سے پڑھیں، اور خود سے پوچھیں:

• کیا آپ اس کے نتیجے سے متفق ہیں؟
• کیا اس نے کبھی ایک نتیجہ چھوڑا جس کا آپ کو پتہ تھا کہ غلط ہے؟
• کیا اس نے ایک اصل میں اہل نتیجہ کو غلطی سے مسترد کر دیا؟

اگر جانچنے والا ایک ایسا نتیجہ منظور کر لے جو آپ جانتے ہیں کہ غلط ہے، یا ایک ایسا نتیجہ مسترد کر دے جو دراصل مسئلہ نہیں رکھتا، تو پہلے عینی بنیادوں یا معیار کو درست کریں، اور پھر سسٹم کو تعمیر کرتے رہیں۔

ایک غلط تصدیق کا مرحلہ خودکار بنانا، صرف نظام کو تیزی سے غلط نتائج پیدا کرنے دے گا۔

اوپر دیے گئے پانچ مراحل کو مزید مخصوص بنانے کے لیے، ہم ایک عام کام کا مشاہدہ کر سکتے ہیں: ایک اصل مواد کو ایک مکمل آرٹیکل میں تبدیل کرنا۔

مرحلہ 5: تعریف مکمل کریں

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

• ہر تفصیل جو منصوبہ کے تحت ہے، اصل ذرائع میں واضح طور پر قابلِ ردیاب ہے؛
• مسودہ بریف میں تمام خاص درخواستوں، جیسے لمبائی، انداز اور ساخت، کو پورا کرتا ہے؛
• اصل دلیل واضح طور پر برقرار رکھی گئی ہے، اور اسے بے معنی بھرپور مواد سے کم نہیں کیا گیا۔

مرحلہ 6: ڈرافٹ بنانے والا

بیلڈر اصل مواد اور کنٹینٹ بریف کو حاصل کرتا ہے اور ایک مسودہ تیار کرتا ہے۔

اس کے علاوہ، اسے لکھائی کے عمل میں موجود عدم یقین کو واضح طور پر فہرست بند کرنا ہوگا، جیسے:

• کیا کوئی ڈیجیٹل نمبر اصل ماخذ میں حقیقت میں ظاہر ہوا ہے؛
• کیا یہ نتیجہ متن میں واضح طور پر بیان کیا گیا ہے، یا ماڈل نے اسے خود استنباط کیا ہے؛
• کیا کسی حقیقت کے لیے کافی ذرائع کی کمی ہے؟

مرحلہ 7: جائزہ لینے والے اصل متن کے ساتھ جانچ کریں

جائزہ کنندہ کو صرف draft نہیں، بلکہ draft اور اصل مواد دونوں مل جاتے ہیں۔

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

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

مرحلہ 8: ساختی ہاتھ بدلنا

评审者的 نتیجہ ایک ساختی شے ہونا چاہیے، نہ کہ ایک محفوظ الفاظ سے بھرپور قدرتی زبان کا متن۔

اسے تین واضح ہاں یا نہیں کے نتائج پیدا کرنے ہوں گے، اور ہر ناکامی کے لیے مخصوص وجوہات فراہم کریں۔

مرحلہ 9: جائزہ مکینزم کا دستی طور پر تصدیق کریں

سسٹم کو خودکار طور پر چلانے سے پہلے، ایک مکمل عمل کو دستی طور پر انجام دینا آپ کو یہ پتہ چل جائے گا کہ جائزہ دینے والے بہت آسان یا بہت سخت ہیں۔

بہت آزاد رائے دہندگان، اگر مضمون بہترین طریقے سے لکھا گیا ہو، تو اس میں موجود جعلی ڈیٹا کو چھوڑ سکتے ہیں۔

بہت سخت جانچنے والے، کسی ایسی ذاتی اسٹائل کی ترجیح کی وجہ سے جو کبھی بھی بریف میں درج نہیں ہوئی، ایک مناسب مضمون کو غلطی سے مسترد کر سکتے ہیں۔

یہ دونوں مسائل شروع میں سیٹ اپ کے دوران بہت عام ہیں۔

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

منیجر ریویور کے فیصلوں کو پڑھتا ہے اور اگلے اقدام کا فیصلہ کرتا ہے۔

روکنے کی شرائط بھی منیجر میں موجود ہونی چاہئیں، اور انہیں ایک واضح، سخت منطق کے طور پر لکھا جانا چاہئے، نہ کہ ایک نرم ہدایت جسے ماڈل اپنی خود تشریح کے ذریعے دور کر سکے۔

مثال کے طور پر：

روکنے کی شرط:

• زیادہ سے زیادہ تبدیلیوں کی تعداد: 3؛
• جب تیسری جائزہ کوشش بھی ناکام ہو جائے، تو مکمل تاریخ کو انسانی عمل کے لیے جمع کرائیں، اور چوتھی ترمیم شروع نہ کریں؛
• معیار کی معیاریت: تعریف میں ہر ایک آئٹم کو PASS ظاہر کرنا ضروری ہے؛
• بجٹ کی حد: اگر کام کی لاگت X سے زیادہ ہو جائے یا چلنا Y سے زیادہ وقت لے لے، تو فوری طور پر روک دیا جائے گا، چاہے موجودہ حالت کچھ بھی ہو۔

ایک ایسا حلقوں کا سلسلہ جس میں حقیقی روک کا شرط نہ ہو، نظام نہیں بلکہ خطرے کے اظہار کا انتظار کرنے والا بوجھ ہے۔

کیوں "جب نتائج کافی اچھے ہوں تو روک دیں" جیسے نرم ہدایات قابل اعتماد نہیں ہوتیں؟

کیونکہ یہ صرف ایک سفارش ہے۔

جب ماڈل کو بار بار ترمیم کرنے کے باوجود ابھی تک منظور نہیں کیا گیا ہو، تو اس کام کو ایک قابل قبول نتیجہ دینے کے لیے، یہ اپنے آپ کو یہ سمجھانے لگتا ہے کہ "یہ ورژن معیار کے بہت قریب ہے" اور اپنا جائزہ لینے کا معیار خود کم کر لیتا ہے۔

اس کے برعکس، کوڈ کے ذریعہ مکینیکل طور پر چیک کی جانے والی تکرار کی تعداد، یا جن قواعد کو مینیجر منطقی طور پر نہیں چھوڑ سکتا، اس مسئلے کا سامنا نہیں کرتے۔

اگر ایک سائکل ہر بار شروع ہونے پر صفر سے شروع ہو جائے، تو وہ پچھلی رن سے سیکھا ہوا کچھ نہیں یاد رکھے گا۔

اس لیے، ایک سادہ پائیدار لیئر کی ضرورت ہے۔

ہر اصل نئے تجربے کے لیے ایک فائل بنائیں اور فائل کے اوپر ایک جملے میں خلاصہ دیں:

• کیا سیکھا گیا؛
• کیا درست کیا گیا؛
• یہ تجربہ کیوں اہم ہے۔

اہم اصول یہ ہے کہ صرف اسی نئی معلومات کو ریکارڈ کیا جائے جو کہیں اور محفوظ نہ ہو۔

دہرائی گئی یادداشت علم نہیں، بلکہ شور ہے۔

مستقل مکانیت کو لمبے عرصے تک مؤثر بنانے کے لیے، لکھتے وقت پابندی برقرار رکھنا ضروری ہے۔

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

حقیقی طور پر قابلِ ریکارڈ تجربہ وہ ہے جسے اگر بھول جائیں تو دوبارہ دریافت کرنے میں بہت زیادہ وقت لگے، نہ کہ کسی معمولی کامیاب کارروائی کا ریکارڈ جو توقع کے مطابق ہو گیا۔

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

وقت کے ساتھ، سسٹم کئی دہائیوں کے فائلز جمع کر لیتا ہے، جن میں سے بہت سے صرف ایک ہی مسئلے کے مختلف تفصیلات ہوتے ہیں۔

اس لیے، میموری فائلز کو مقررہ دورانیے پر ترتیب دینا چاہیے۔ ہفتے میں ایک بار کرنا عام طور پر ایک مناسب اکھاڑ ہے۔

مرتب کرنے کا عمل درج ذیل ہے:

• موجودہ یادداشت کا جائزہ لیں؛
• دوہرائی گئی تفصیلات کو ضم کریں؛
• کئی مشابہ تجربات کو ایک زیادہ واضح اصول میں ملا دیں؛
• غلط یا قدیمی مواد کو حذف کریں۔

ہدف زیادہ سے زیادہ دستاویزات جمع کرنا نہیں، بلکہ کم تعداد میں، مزید معلوماتی طور پر بھرپور علم حاصل کرنا ہے۔

بہت سے لوگ اس مرحلے کو بالکل چھوڑ دیتے ہیں کیونکہ یہ فوری طور پر کوئی نظر آنے والی نئی صلاحیت نہیں لاتا، بلکہ مستقبل کے مسائل کو روکنے کے لیے ہے۔

لیکن اس کی عدم فوری فیڈ بیک کی وجہ سے، اسے اس وقت تک منتقل نہیں کیا جانا چاہئے جب تک کہ کوئی یادداشت کے فولڈر کو منظم کرنا مشکل پا لے۔

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

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

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

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

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

ٹرگر کے طریقے میں شامل ہو سکتے ہیں:

• کرون ٹائم اسکیولر؛
• فائل تبدیلیوں کا نگران
• کیلنڈر مبنی دورانیہ ٹریگر؛
• جب کوئی بیرونی واقعہ یا حالت تبدیل ہو تو فعال ہو جائے۔

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

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

کسی بھی اہم کام کے لیے لوپ کا استعمال کرنے سے پہلے، چار خرابی کے ماڈلز کے لیے فعال طور پر ٹیسٹ کیا جانا چاہیے۔

ٹیسٹ ایک: ناممکن کام

ایک ایسا اصلی طور پر حل نہ ہونے والا کام سسٹم کو دیں، تاکہ یہ تصدیق ہو سکے کہ مینیجر روکنے کے شرائط کے مطابق ختم ہو جائے گا، لیکن لا محدود لوپ میں نہیں پڑے گا۔

اگر ایک سائکل صرف کامیابی سے مکمل ہونے والے کاموں پر ہی ٹیسٹ کیا گیا ہے، تو اس نے کبھی اپنی خوبصورت شکست کی صلاحیت ثابت نہیں کی ہے۔

ٹیسٹ دو: منطقی لگتا ہے لیکن غلط نتیجہ

评审者 کو ایک ایسا آؤٹ پٹ فراہم کریں جس میں آپ کو معلوم ہے کہ باریکیوں کی خطا ہے۔

یہ نتیجہ بہت ہموار لگنا چاہیے، لیکن اس میں ایک ایسا ت fact یا منطقی غلطی ہونی چاہیے جو آپ نے جان بوجھ کر ڈالی ہے۔

صرف اس لیے کہ مواد منطقی لگ رہا ہے، اسے منظور کرنے کے بجائے، جائزہ دینے والے کو مسائل کی تلاش کرنے کی نگاہ رکھنی چاہیے۔

ٹیسٹ تین: بانی اور جائزہ دینے والے ماڈل کی کمیوں کو شیئر کرتے ہیں

اگر تعمیر کنندہ اور جائزہ دینے والا ایک ہی بنیادی ماڈل استعمال کریں، تو ان کے عام غلطیوں میں سے ایک کو عمدہ طور پر شامل کیا جا سکتا ہے تاکہ دیکھا جا سکے کہ جائزہ دینے والا اسے نظر انداز کر دے گا یا نہیں۔

اگر جائزہ دینے والا اور تعمیر کرنے والا ایک ہی اندھا بھٹکا رکھتے ہیں، تو چھٹے مرحلے میں ڈیزائن کیا گیا کرداروں کا الگ کرنا بے معنی ہو جاتا ہے۔

ٹیسٹ چار: بدترین صورت میں آپریشن کی لاگت کا حساب لگائیں

سب سے زیادہ ترمیم کی حد کے مطابق، سب سے مہنگے ماڈل کے استعمال اور مناسب حد تک لمبے آؤٹ پٹ کے ساتھ، اس لوپ کی بدترین صورت میں کتنی لاگت خرچ ہوگی۔

پھر خود سے ایمانداری سے پوچھیں:

اگر یہ ڈیجیٹل رقم اصل بل پر ظاہر ہو تو کیا آپ پریشان محسوس کریں گے؟

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

ورنہ، یہ مسائل عام طور پر صارفین یا مینیجرز کے سامنے پہلی بار ظاہر ہوں گے، یا براہ راست آپ کے بل پر ظاہر ہوں گے، نہ کہ آپ کے ذاتی کنٹرول میں ہونے والے ٹیسٹ میں۔

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

سرکل میں مختلف کردار، ماڈل کی صلاحیتوں کے لیے مختلف مانگ کرتے ہیں۔

بناونے والا

بنانے والے عام طور پر سب سے زیادہ طاقتور ماڈل کا استعمال کرنا چاہیں۔

کیونکہ یہ اہم پیچیدہ استدلال اور مواد کی تخلیق کا کام کرتا ہے۔ اگر یہاں کمزور ماڈل استعمال کیا جائے، تو پہلی نسخہ کی معیار کم ہو جائے گا اور بعد میں مزید ترمیم کے دور درکار ہو سکتے ہیں۔

آخر کار، کم معیار کے ابتدائی نسخے کو درست کرنے میں جو لاگت آتی ہے، وہ شروع سے ہی زیادہ طاقتور ماڈل کا استعمال کرنے کی لاگت سے زیادہ ہو سکتی ہے۔

ریویور

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

جب معیار کافی مخصوص ہو، تو ایک چھوٹا، سستا اور تیز مدل بھی جائزہ کا کام قابل اعتماد طریقے سے انجام دے سکتا ہے۔

اگر ایک چھوٹا ماڈل بہت واضح چیک لسٹ کے مطابق کام کرتا ہے، تو اس کی استحکام بڑے ماڈل کے قریب ہو سکتا ہے، لیکن اس کی لاگت اور تاخیر دونوں کافی کم ہوتی ہیں۔

منیجر

مینیجر صرف پہلے سے لکھے گئے قواعد کے مطابق رُوت کرتا ہے اور تقریباً کبھی سب سے مہنگا ماڈل استعمال نہیں کرتا۔

اس کا کام کھلی استدلال کرنے کے بجائے پہلے سے تعریف شدہ منطق کو انجام دینا ہے۔

اس کے علاوہ، چاہے بناونے والے اور جانچنے والے کیا کارکردگی دکھائی دیں، مینیجر ہر ایک تکرار میں کم از کم ایک بار چلتا ہے، اس لیے اس کی ایک بار کال کی لاگت خاص طور پر قابل توجہ ہے۔

مناسب طریقہ سے ترتیب دیا گیا لیوریج کنفیگریشن عام طور پر ہے:

• مضبوط ماڈل بنانے کی ذمہ داری؛
• سستے اور مستقل ماڈل عام جائزہ کے لیے ذمہ دار ہیں؛
• کم لاگت والے ماڈل یا قاعدہ پروگرام راؤٹنگ اور منیجمنٹ کے لیے ذمہ دار ہیں۔

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

بہت سے لوگ سمجھتے ہیں کہ لاگت کنٹرول کرنے کا مطلب ہے سائکل کی تعداد یا ایڈٹس کم کرنا۔ اصل میں، زیادہ موثر طریقہ یہ ہے کہ ماڈل کی لاگت کو سائکل میں ہر کردار کی حقیقی مشکل سے مطابق کیا جائے۔

پہلے سائکل کے کامیاب ختم ہونے کے بعد، لوگ فوراً متعدد سائکلز بنانے اور پانچ مختلف کاموں کو Parallel طور پر پروسیس کرنے کی کوشش کرنے لگتے ہیں۔

اگرچہ موجودہ آرکیٹیکچر اس توسیع کو سپورٹ کر سکتا ہے، لیکن اس جذبے پر قابو رکھنا چاہیے۔

آپ کو پہلے سائیکل کو کافی دیر تک مستقل طور پر چلنے دینا چاہیے، تاکہ آپ کو اس کی ہر چھپائی کی نگرانی کرنے کی ضرورت نہ پڑے۔

یہ صرف اس بات کا مطلب نہیں کہ کسی ایک مرتبہ سب نے سنجیدگی سے دیکھا اور وہ کامیاب ہو گئی، بلکہ یہ مطلب ہے کہ اس نے ایک حقیقی عمل کے بعد بھی انسانی نمونہ لینے کے ذریعے مستقل طور پر کام کرتی رہی۔

صرف اس حالت تک پہنچنے کے بعد ہی دوسرے سائکل کی تعمیر شروع کی جانی چاہیے۔

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

اس طرح یہ تصدیق ہو سکتی ہے کہ بنیادی ڈھانچہ حقیقی طور پر عام ہے، صرف ایک ہی کام کے لیے بار بار بہتر تہذیب کے نتیجے نہیں۔

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

اکیلے کے طور پر، ایک سائکلک کام کا بجٹ مکمل طور پر منطقی ہو سکتا ہے۔

لیکن اگر دس سیکنڈز کا ہر سیکنڈ اپنے بجٹ کے اندر کام کر رہا ہے، تو ان کی کل لاگت ابھی بھی ایک حیرت انگیز سطح تک پہنچ سکتی ہے۔

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

کامیابی کے ساتھ مکمل کیے گئے کاموں کے علاوہ، ہر روکنے کی شرط کے فعال ہونے کو الگ سے ریکارڈ کیا جانا چاہیے۔

اگر کوئی سائکل بار بار زیادہ ترین تبدیلیوں کی حد تک پہنچ جائے جبکہ دیگر سائکلز میں یہ صورت کم ہوتی ہے، تو یہ سگنل شاید یہ نہیں ہے کہ "یہ کام خاص طور پر مشکل ہے"، بلکہ یہ ہے:

• معیار جائزہ کرنا غلط طریقے سے ترتیب دیا گیا ہے؛
• جائزہ کنندگان بہت سخت ہیں، جس کی وجہ سے کوئی بھی نتیجہ قبول نہیں ہوتا؛
• سسٹم نے غلط مبنی کا جائزہ لیا؛
• تعریف کو مکمل کرنا خود میں مسئلہ ہے۔

اگر صرف کامیاب نتائج کو ہی ٹریک کیا جائے اور ہر انسانی اپ گریڈ کو ایک دوسرے سے متعلق نہ سمجھا جائے، تو یہ ڈیزائن لیول کا نمونہ نہیں پایا جائے گا۔

سوچ کے تبدیل ہونے کا سب سے واضح معیار یہ ہے کہ آپ کے روزمرہ کے اہم اشارے تبدیل ہو گئے ہیں۔

پرامپٹ آپریٹر کو یہ دلچسپی ہے:

• آج کتنے ایفیکٹو پرامپٹس لکھے گئے؛
• کون سا پرامپٹ بہترین نتیجہ دیتا ہے؛
• ہووے کہ پرامپٹس کو زیادہ ہنرمند انداز میں لکھا جائے۔

سسٹم ڈیزائنر کا خیال ہے:

• ابھی کتنے سائکل چل رہے ہیں؛
• ہر سائکل کی قابلیت کیا ہے؛
• سسٹم نے خود کے لیے کتنی وقت کی رہائی کی؛
• کون سے کامز اب انسانی نگرانی کی ضرورت نہیں رکھتے۔

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

آخری مرحلہ اب مکمل طور پر آپ کے اپنے سسٹم کے بارے میں نہیں ہے۔

یہ یہ جانچنے کے لیے استعمال ہوتا ہے کہ آپ اس طریقہ کو حقیقت میں سمجھ گئے ہیں۔

آپ کو پانچ بنیادی حرکات کو سمجھانے کی کوشش کرنی ہوگی جبکہ جटی الفاظ پر انحصار نہ کریں۔

شناخت، ہاتھاپائی، تصدیق، مستقل کرنا، شیڈولنگ۔

اگر آپ صرف ان پانچ حرکات اور پہلے مراحل کے ذریعے کسی اور کو اس کا پہلا سائکل تعمیر کرنے میں کامیاب ہو جائیں، تو یہ ثابت ہوتا ہے کہ آپ نے اس راستہ نامہ میں بیان کیے گئے اصل تبدیلی کو مکمل کر لیا ہے۔

آپ وہ شخص نہیں رہے جو سائکل کے اندر رہ کر لگاتار اگلے حکم کو درج کر رہے ہوں۔

آپ وہ شخص بن گئے جو چکر کے باہر کھڑا ہو کر نظام کا ڈیزائن کرتا ہے اور اسے خود چلتے ہوئے دیکھتا ہے۔

مرحلہ چھوڑنے کے بعد پیچھے چھپ کر جمع ہونے والی چار اخراجات

مضمون کے آخر میں ایک انتباہ دینا ضروری ہے۔

اس راستہ کے مراحل کو چھوڑنا عام طور پر فوری طور پر سسٹم کے کریش ہونے کا باعث نہیں بنتا۔

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

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

لیکن سائیکل ظاہری طور پر اب بھی درست طریقے سے کام کر رہا ہے، کیونکہ پیدا کردہ نتائج "اچھے لگ رہے ہیں"۔

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

جب آپ 20ویں قدم کو چھوڑ دیتے ہیں، تو سمجھ کا تلف ہو سکتا ہے۔

آپ اب بھی اپنے خود بنائے گئے سائکل کو چلا رہے ہیں، لیکن اب آپ کسی بھی کمپوننٹ کی موجودگی کی وضاحت نہیں کر سکتے اور سسٹم کی خرابی کے وقت اسے مؤثر طریقے سے ڈیبگ نہیں کر سکتے۔

اس کا سبب یہ ہے کہ آپ نے کبھی بھی اس ساخت کے پیچھے کے منطق کو اپنا نہیں لیا۔

اگر پہلا مرحلہ کبھی مکمل نہیں ہوا، تو شناختی تسلیم ہوتا ہے۔

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

یہ رویہ سامنے کا لگتا ہے، لیکن اصل میں نظام کے تعمیر کے پورے مقصد کو ختم کر دیتا ہے۔

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

آپ عام طور پر اس بات کا احساس نہیں کرتے کہ سسٹم کنٹرول سے باہر ہو رہا ہے، بلکہ جب آخری بل آ جائے تو ہی پتہ چلتا ہے کہ دوہرائی گئی کالوں کا دائرہ بہت زیادہ غیر ضروری ہو چکا ہے۔

اوپر کے تمام اخراجات سے بچا جا سکتا ہے۔

ان سے بچنے کا طریقہ، ہمیشہ ایک ہی انضباط ہے:

ترتیب سے بنائیں، اور وہ مراحل نہ چھوڑیں جو کم دلچسپ لگ رہے ہوں۔

اکثر اوقات وہی سب سے بیکار حصے ہوتے ہیں جو حقیقت میں کام کرتے ہیں:

• واضح مکمل تعریف؛
• قابلِ اعتماد روکنے کا شرط؛
• قابل تصدیق موضوعی ثبوت؛
• Independent review mechanism.

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

سیستم کی حقیقی کوالٹی کا فیصلہ یہ ہے کہ آیا آپ نے جو سسٹم بنایا ہے، وہ جانتا ہے:

• کبھی اپنے آپ کو درست سمجھیں؛
• جب آپ خود غلط ہوتے ہیں؛
• کب تھامنا ضروری ہے۔

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

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

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