پرامپٹ بمقابلہ لوپ انجینئرنگ: ایک ڈویلپر گائیڈ

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

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

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

یہ وہ جگہ ہے جہاں ایک ہی پرامپٹ اب صحیح ٹول نہیں رہا ہے اور ایک ایسے سسٹم کو ڈیزائن کرنا جو بہت سے اشارے چلاتا ہے اصل کام بن جاتا ہے۔

دو شرائط آپریشن کے ان دو طریقوں کو بیان کرتی ہیں۔

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

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

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

انڈیکس

پرامپٹ انجینئرنگ اور لوپ انجینئرنگ کی تفصیل

فوری انجینئرنگ ماڈل سے ایک بار بات کرنے کا ایک طریقہ ہے۔ آپ جو متن شامل کرتے ہیں، ساخت، مثالیں وغیرہ سب آپ کے آؤٹ پٹ کے معیار کا تعین کرتے ہیں۔

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

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

اس سائیکل کے ہر قدم میں ایک مختلف پرامپٹ، ٹول کال، API کی درخواست، یا تینوں کا مجموعہ شامل ہو سکتا ہے، اور سسٹم فیصلہ کرتا ہے کہ صارف کی مداخلت کا انتظار کیے بغیر آگے کیا ہوگا۔ یہ وہی ہے جو بند لوپ اصل میں لگتا ہے.

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

AI ورک فلو کیسے بدلے ہیں؟

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

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

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

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

ایجنٹ کے کام کے بہاؤ سے پہلے، ڈویلپرز AI اسسٹنٹس کو CI کی غلطیوں کی نشاندہی کرنے کے لیے استعمال کریں گے اور پھر دستی طور پر لاگز، ٹرائیج کے مسائل، اور پش فکسز کی جانچ کریں گے۔ GitHub Agentic Workflows ٹیموں کو سادہ مارک ڈاؤن فائلوں میں آٹومیشن کے اہداف کی وضاحت کرنے کی اجازت دیتا ہے اور کوڈنگ ایجنٹوں کے پاس GitHub ایکشنز کے اندر خود مختاری سے پوری ترتیب پر کارروائی ہوتی ہے۔

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

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

صحیح نقطہ نظر کا انتخاب کریں۔

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

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

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

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

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

لوپ انجینئرنگ کے حقیقی اخراجات اور خطرات

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

یہ وہ جگہ ہے جہاں لوپ حقیقی قدر کا اضافہ کرتا ہے:

• ہر فیصلے کے مقام پر انسانی مداخلت کے بغیر خود مختاری سے کثیر مرحلہ کاموں کو ہینڈل کرتا ہے۔

• یہ قابل اعتماد طریقے سے اور شیڈول کے مطابق چلتا ہے، بار بار چلنے والے ورک فلو کو مستقل اور دہرانے کے قابل بناتا ہے۔

• پیمانے کے کام جن کو انجام دینے کے لیے متناسب طور پر زیادہ لوگوں کی ضرورت ہوتی ہے۔

لوپس کو خطرہ لاحق ہوتا ہے جب:

• ڈیبگ کرنا زیادہ مشکل ہے۔ ایک سنگل پرامپٹ ایک ان پٹ اور ایک آؤٹ پٹ دکھاتا ہے۔ متعدد مراحل اور ٹول کالز پر محیط لوپس کو یہ سمجھنے کے لیے لاگنگ اور ٹریسنگ کی ضرورت ہوتی ہے کہ کیا ہوا ہے۔

• مرکب کی خرابیاں: مرحلہ 2 سے غلط آؤٹ پٹ مرحلہ 3 کا ان پٹ بن جاتا ہے، جو لوپ کے اختتام تک اچھا لگ سکتا ہے، لیکن مجموعی طور پر خاموشی سے غلط ہے۔

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

شروع سے تعمیر کرنے کے لئے گارڈریلز:

• تمام مراحل کو ریکارڈ کریں، نہ صرف حتمی آؤٹ پٹ۔

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

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

• کسی بھی چیز کے لیے انسانی جائزہ چیک پوائنٹس شامل کریں جو پیداوار کو متاثر کرتی ہو یا حقیقی صارفین کو متاثر کرتی ہو۔

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

پرامپٹ انجینئرنگ اور لوپ انجینئرنگ: تین حقیقی دنیا کی مثالیں۔

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

مثال 1: ای میل کا خلاصہ

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

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

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

مثال 2: PR جائزہ

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

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

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

GitHub Agentic Workflows کے ابتدائی اختیار کرنے والوں میں سے ایک، Marks & Spencer نے اپنے پورے ذخیرہ کیٹلاگ میں اس قسم کے دوبارہ قابل استعمال ورک فلوز بنائے ہیں۔ ہم نے کمزوریوں کو حل کرنے، انحصار کو برقرار رکھنے، اور سیکیورٹی، معیار اور ترسیل کی پائپ لائنوں میں معمول کی تبدیلیوں کا جائزہ لیا۔

مثال 3: مواد کے ساتھ کام کرنا

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

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

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

اپنا پہلا لوپ بنانا کیسے شروع کریں۔

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

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

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

• اپنی ترتیب کو ڈیزائن کریں: ہر قدم کی منصوبہ بندی کریں: لوپ کو کیا لینا چاہیے، یہ ہر قدم پر کیا اشارہ دیتا ہے، آگے بڑھنے سے پہلے یہ کیا چیک کرتا ہے، اور اگلی کارروائی کو کیا متحرک کرتا ہے۔

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

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

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

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

ان اقدامات کو عملی جامہ پہنانے کے لیے، یہاں Python اور Mistral API کے ساتھ بنایا گیا ایک سادہ PR جائزہ لوپ ہے جو بالکل اس طرز کی پیروی کرتا ہے۔ مکمل کوڈ GitHub پر دستیاب ہے۔

پرامپٹ کا جائزہ لیں۔

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

SYSTEM_PROMPT = """You are an experienced code reviewer. You will be given a git diff. Review it for bugs, security issues, unclear code, and missed edge cases. Only comment on things that matter - skip style nitpicks and praise. If the diff looks fine, return an empty comments list."""

لوپ کی ساخت

لوپ کے چار مراحل ہیں: لوڈ ڈِف، حساس علاقوں کو چیک کریں، کال ماڈل، اور تبصرہ پوسٹ کریں۔

def review(diff_text: str) -> None:
    if not diff_text.strip():
        print("Empty diff - nothing to review.")
        return

    sensitive_reasons = find_sensitive_matches(diff_text)
    if sensitive_reasons:
        flag_for_human_review(sensitive_reasons)
        return

    client = Mistral(api_key=os.environ.get("MISTRAL_API_KEY"))
    comments = get_ai_review(client, diff_text)
    post_comments(comments)

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

اصل چوکیاں

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

SENSITIVE_PATH_KEYWORDS = [
    "auth", "login", "logout", "session", "password", "credential",
    "token", "jwt", "oauth", "payment", "billing", "stripe",
]

SENSITIVE_CONTENT_KEYWORDS = [
    "password", "secret", "api_key", "private_key",
    "authenticate", "authorize", "permission",
]

اس کا مطلب ہے فرق کو چھونا auth/login.py API کال کرنے سے پہلے لوپ کو روکتا ہے۔ کنسول پر ایک جھنڈا پرنٹ کیا جاتا ہے اور ٹیم کا کوئی فرد دستی طور پر جائزہ پر کارروائی کرتا ہے۔

لوپ پر عملدرآمد

ہم لوپ کی جانچ کر سکتے ہیں جس میں ایک فرق ہے: get_user_by_name جان بوجھ کر ایس کیو ایل انجیکشن کی کمزوریوں کے ساتھ افعال:

+def get_user_by_name(name):
+    query = "SELECT * FROM users WHERE name="" + name + """
+    return db.execute(query)

اس فرق پر لوپ چلانے سے درج ذیل آؤٹ پٹ پیدا ہوتا ہے۔

[CRITICAL] app.py:13 - SQL injection vulnerability: The query is constructed 
using string concatenation with user-provided input (`name`). This allows 
an attacker to inject malicious SQL code. Use parameterized queries inhttps://cdn.hashnode.com/uploads/covers/629e46c5a6bfa05457952a41/26da1a9c-4180-4ae4-89d3-6574e119a0d9.pngstead.

[WARNING] app.py:14 - The function `get_user_by_name` does not handle the 
case where no user is found. It should return `None` or raise a specific 
exception to be consistent with `get_user`.

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

حتمی خیالات

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

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

ایک کام کے ساتھ شروع کریں، وضاحت کریں کہ کامیابی کیسی نظر آتی ہے، اور وہاں سے تعمیر کریں۔