ویریٹر نوٹ: یہ مضمون OpenAI کے ڈیولپر ریلیشنز کے رکن ڈومینک کنڈیل سے آیا ہے، جو Codex کے "goal mode / /goal" فیچر کے استعمال کا خلاصہ پیش کرتا ہے۔ یہ ایک عام پرامپٹ ٹرک کی بجائے AI پروگرامنگ ٹولز میں ہونے والے ایک کردار کے تبدیلی پر بات کرتا ہے: Codex صرف ایک منفرد حکم کا جواب دینے والا کوڈ اسسٹنٹ نہیں رہا، بلکہ اب یہ واضح مقاصد کے گرد مستقل پیش رفت کرنے والا ایک ایجینٹ بن چکا ہے۔

/goal موڈ میں، ضروری بات یہ نہیں کہ اپنی ضروریات کو زیادہ لمبا اور تفصیلی لکھیں، بلکہ Codex کے لیے واضح اور جانچنے کے قابل خارج ہونے کے معیارات متعین کرنا ہے۔ مثال کے طور پر: "部署 وقت میں 30% کمی"، "ٹیسٹ کاوریج 100% parity تک پہنچنا"، "LCP 2.5 سیکنڈ سے کم ہونا"۔ یہ اشارے Codex کو یہ فیصلہ کرنے میں مدد دیتے ہیں کہ کام مکمل ہو گیا ہے یا نہیں، اور اسے ادھورے اور غیر واضح مقاصد میں بے حد آزمائش سے بچاتے ہیں۔ اس کے علاوہ، صارف کو Codex کو ترقی کا جائزہ لینے، نتائج کی تصدیق کرنے کے لیے کافی رہنمائی، ٹولز اور حقیقی ماحول فراہم کرنا چاہیے، تاکہ وہ صرف مقامی یا فرضی حالات میں ایک ممکنہ حل تیار نہ کرے۔

یہ مضمون خاص طور پر یاد دہانی کراتا ہے کہ ویژول ٹاسکس Codex کو تفصیلات کے گڑھے میں پھنسا دیتے ہیں۔ "100% پکسل-لیول ریکن" کی درخواست کے بجائے، ویژول مقاصد کو فنکشنل لسٹ، ڈیزائن سسٹم کے معیارات اور قابل جائزہ اشاریوں میں تقسیم کریں۔ کئی گھنٹوں یا دنوں تک جاری رہنے والے طویل مدتی ٹاسکس کے لیے، commit، draft PR، پروگریس ڈاکومنٹس، Slack اپڈیٹس یا سائیڈ چیٹ کے ذریعے مستقل طور پر ٹریک رکھنا ضروری ہے تاکہ آخر میں صرف غیر قابل رجوع تبدیلیوں کا مجموعہ حاصل نہ ہو۔

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

نیچے متن ہے:

ہم نے ہدف ماڈ (goal mode، یا /goal) متعارف کرایا ہے تاکہ آپ Codex کو کسی خاص نتیجہ تک پہنچنے میں مدد دے سکیں۔ جب آپ ایک ہدف مقرر کرتے ہیں، تو Codex وہ کام جاری رکھتا ہے جب تک کہ ہدف حاصل نہ ہو جائے — چاہے اس میں کئی گھنٹے لگ جائیں یا کئی دن۔ کچھ صارفین نے Codex کو ایک ہی ہدف کے لیے 120 گھنٹوں تک لگاتار کام کرنے دیا ہے۔

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

واضح، قابل تصدیق معیارات متعین کریں

jab aap ٹارگٹ موڈ کو فعال کرتے ہیں تو جو پرامپٹ درج کرتے ہیں، وہ ابتدائی پرامپٹ کے طور پر استعمال ہو سکتا ہے، لیکن اہم بات یہ ہے کہ یہ ٹارگٹ کا ختم ہونے کا معیار بن جائے گا۔ کوڈیک ہر راؤنڈ کے بعد چیک کرے گا: کیا یہ ٹارگٹ مکمل ہو چکا ہے؟

اس لیے، آپ کا ہدف پیغام لمبا نہیں ہونا چاہیے، بلکہ ایک واضح معیار پر مرکوز ہونا چاہیے: کس صورت میں، یہ ہدف حاصل ہو چکا ہوگا۔

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

بنانے اور ڈپلوی کرنے کے وقت کو 30 فیصد کم کریں۔

اس فیچر کو TypeScript سے Rust میں منتقل کریں اور 100% ٹیسٹ کنسسٹنسی حاصل کریں۔

پروڈکشن میں سب سے بڑی مواد کی ترسیل (Largest Contentful Paint، جو صفحے کے اہم مواد کے لوڈ ہونے کی رفتار کو ناپتا ہے) کو 2.5 سیکنڈ سے کم کرنے کے لیے ایپلیکیشن سکیلڈ کو بہتر بنائیں۔

یہ حکم ضروری طور پر ہمیشہ اعداد کو شامل نہیں کرتا، لیکن عام طور پر اعداد بعد کے مراحل کو آسان بناتے ہیں۔

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

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

آپ اپنے ہدف کو کبھی بھی تبدیل کر سکتے ہیں: کوڈیکس ایپ میں ایڈٹ بٹن پر کلک کریں، یا CLI میں دوبارہ /goal استعمال کریں۔

ہدایات فراہم کرنے کی کوشش کریں

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

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

مثلاً، میرے ساتھی @reach_vb نے ایک تجربے میں ایسا کیا: انہوں نے Codex کو بتایا کہ Google Colab تک پہنچنے کے لیے Chrome براؤزر استعمال کیا جا سکتا ہے، اور کچھ قابل قبول حدود بیان کیں، جیسے کہ Codex کو ماڈل تربیت دیتے وقت خود ڈیٹا سیٹ بنانے کی اجازت دی جائے۔

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

ایک دوسری طرح یہ ہے کہ آپ Codex کو پلان موڈ میں ابتدائی تحقیق کرنے دیں اور اسے ممکنہ حل کو ریکارڈ کرنے کے لیے ایک پلان فائل بنانے دیں، اس کے بعد اپنے مقصد کو اس پلان کا حوالہ دیں۔

پیشرفت کو قابلِ اندازہ بنائیں

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

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

لیکن دوسرے اہداف کے لیے، آپ کو بہتر ہوگا کہ Codex کے ساتھ براہ راست سوچیں: کون سے ٹولز ترقی کا جائزہ لینے میں مدد کرتے ہیں؟ یا اسے کچھ اشارے دیں کہ وہ یہ کیسے طے کرے کہ وہ اپنے مقصد کی طرف قریب آ رہا ہے۔ مثال کے طور پر، دو اسکرین شاٹس کے لیے ویژوئل فرق کا موازنہ کرنے والا ٹول بنائیں، یا آپ جس ایجینٹ کو ڈیبگ کر رہے ہیں اس کے لیے ایک ایوان ایوالویشن سیٹ تیار کریں۔

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

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

مثلاً، کوڈیکس کسی UI کو "پکسل فور پکسل" درست کرنے کے لیے ڈیزائن ریفرنس کا ٹکڑا کاٹ کر صفحے میں اندراج کر سکتا ہے؛ یا ٹیسٹ پاس ریٹ کو 100% تک لانے کے لیے ٹیسٹ کوریج کو کم کر سکتا ہے۔ یہ وہ طریقے نہیں ہیں جن کا آپ واقعی چاہتے ہیں۔

ایک حقیقی ماحول بنائیں

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

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

مثال کے طور پر، ہم نے developers.openai.com کی تعمیر اور ڈیپلویمنٹ کے وقت کو بہتر بنانے کے لیے ڈیبگ کیا تھا۔ اس وقت ہم پہلے ہی ڈیپلویمنٹ پیشکش کا استعمال کر رہے تھے، اس لیے Codex ان پیشکش ماحولوں کا استعمال کرکے ڈیپلویمنٹ کر سکتا تھا اور متعلقہ لاگس دیکھ سکتا تھا۔ لیکن مسئلہ یہ تھا کہ ہماری پیشکش ڈیپلویمنٹس، مکمل پروڈکشن ماحول کے مقابلے میں، کچھ تعمیر کے راستوں کو معطل کر دیتی تھیں۔

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

اسی طرح، آپ Codex کو کمپیوٹر استعمال کرنے کے لیے استعمال کر سکتے ہیں (ماڈل کو حقیقی ایپلیکیشن انٹرفیس کو آپریٹ کرنے کی صلاحیت) تاکہ حقیقی ایپلیکیشنز کا ٹیسٹ کیا جا سکے۔ کچھ iOS پرفارمنس مسائل کو بہتر بنانے کے لیے، @dimillian نے سب سے زیادہ درست ٹیسٹ ماحول حاصل کرنے کے لیے اصل ڈیوائسز کا استعمال بھی کیا۔

بصری مقاصد کو محتاط طور پر طے کریں

کوڈیک کو ایک ویژوئل ہدف دیں، جیسے "اس تصویر کے مطابق اس UI کو 100% پیکسل فور پیکسل ریکن کریں"، یہ واقعی پرکشش ہے۔ لیکن مخصوص سیٹنگ کے مطابق، یہ پریشانی بھی پیدا کر سکتا ہے۔

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

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

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

پیش رفت کا جائزہ لیں

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

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

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

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

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

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

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

صاف کریں اور نتائج کی تصدیق کریں

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

عام طور پر، خاص طور پر آپٹیمائزیشن کے کاموں میں، میں نے پایا ہے کہ Codex کو اس کے کیے گئے کام کا جائزہ لینے اور جانچنے کے لیے متاثر کرنا مفید ہوتا ہے۔ آپ پہلے /review کے ذریعے ایک مقامی کوڈ ریویو چلا سکتے ہیں، لیکن Codex کو اس بات پر مزید گہرائی سے غور کرنے کی ضرورت ہوتی ہے: اس نے مقصد حاصل کرنے کے لیے کون سے راستے آزمائے؟ کون سی کوششیں کامیاب رہیں؟ کون سی ناکام رہیں؟ اور پھر اس کے مطابق کوڈ کو صاف کریں۔

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

اپنے اگلے کام کے لیے بھی ایک ہدف مقرر کریں

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

آپ نے /goal کا استعمال کیا کیا؟