کوڈنگ کے لیے AI کیسے استعمال کریں: خطرہ کم کرنے والے ورک فلوز

AI تجویز دے سکتا ہے، لیکن آپ کا ریپو فیصلہ کرتا ہے

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

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

اصول	یہ کیوں اہم ہے	ماڈل سے کیا پوچھیں
پہلے reproduce کریں	بے ترتیب پیچز کو روکتا ہے	"کوڈ تجویز کرنے سے پہلے ناکام رویہ اور شواہد دوبارہ بیان کریں۔"
دائرہ کار چھوٹا رکھیں	ریگریشن کا خطرہ کم کرتا ہے	"سب سے چھوٹی محفوظ تبدیلی تجویز کریں اور متاثرہ فائلیں فہرست کریں۔"
رویہ محفوظ رکھیں	صارفین اور معاہدوں کی حفاظت کرتا ہے	"وہ invariants بتائیں جنہیں یہ تبدیلی نہیں توڑنی چاہیے۔"
ٹیسٹس کا تقاضا کریں	جواب کو قابلِ تصدیق بناتا ہے	"ایسے ٹیسٹس لکھیں جو فکس سے پہلے ناکام اور بعد میں کامیاب ہوں۔"
مرج سے پہلے جائزہ	پُراعتماد غلطیاں پکڑتا ہے	"درستگی، سیکیورٹی اور غائب کنارے کے کیسز کے لیے اس diff کا جائزہ لیں۔"

یہ ماڈلز کے پار اہم ہے، اور ماڈلز واقعی لاگت اور رسائی میں مختلف ہیں۔ Whizi کے ماڈل کاسٹ انڈیکس پر (OpenRouter کی فہرست شدہ قیمتیں، 2026-08-20 کو حاصل کی گئیں)، 1,000 ان پٹ جمع 500 آؤٹ پٹ ٹوکنز کے ایک معیاری جواب کی لاگت Claude Sonnet 4.6 پر تقریباً $0.0105، GPT-5.6 Terra پر $0.008 اور DeepSeek V4 Flash پر $0.00028 ہے، پہلے اور آخری کے درمیان تقریباً 37 گنا کا فرق، اور تینوں 1M ٹوکن context پڑھتے ہیں۔ عملی روٹنگ اصول: کوڈ کی وضاحت اور لاگ ٹریاج کے سوالات DeepSeek V4 Flash یا Gemini 3.7 Flash جیسے سستے ماڈل کو بھیجیں، اور Claude Sonnet 4.6 یا GPT-5.6 Terra کو جائزے کے مرحلے اور ایسے کوڈ کے ری فیکٹر پلان کے لیے محفوظ رکھیں جسے آپ توڑنے کے متحمل نہیں ہو سکتے۔ OpenAI اور Anthropic کی صلاحیت کی دستاویزات بتاتی ہیں کہ کوئی ماڈل کیا کوشش کر سکتا ہے؛ وہ اوپر دیے گئے ورک فلو کا متبادل نہیں ہیں۔ ماڈلز کو اسی طرح جانچیں جیسے آپ کسی ساتھی کارکن کو جانچتے: کیا وہ غائب سیاق و سباق مانگتے ہیں، غیر یقینی کم کرتے ہیں، حدود کا احترام کرتے ہیں اور ایک ایسا نشان چھوڑتے ہیں جسے آپ تصدیق کر سکیں؟

پانچ مراحل میں ڈیبگ کریں: پیچ لگانے سے پہلے reproduce کریں

ایک قابلِ اعتماد AI ڈیبگنگ ورک فلو کے پانچ مراحل ہیں: reproduce، isolate، hypothesize، patch اور verify۔ "اسے ٹھیک کریں" سے شروع نہ کریں۔ شواہد سے شروع کریں۔ ماڈل کو ناکام کمانڈ، عین غلطی، متوقع رویہ، مشاہدہ شدہ رویہ، متعلقہ کوڈ، ماحول کی تفصیلات اور کوئی بھی حالیہ تبدیلی جو مسئلے کا سبب ہو سکتی ہے، دیں۔

مرحلہ 1: reproduction حاصل کریں۔ بیک اینڈ کوڈ کے لیے، درخواست، جواب، اسٹیٹس کوڈ، لاگز اور ناکام ٹیسٹ شامل کریں۔ فرنٹ اینڈ کوڈ کے لیے، روٹ، صارف کا عمل، براؤزر کنسول کی غلطی، نیٹ ورک جواب، کمپوننٹ کی حالت اور اگر متعلقہ ہو تو اسکرین شاٹ کی وضاحت شامل کریں۔ بلڈ کے مسائل کے لیے، کمانڈ، پیکج مینیجر، Node کا ورژن اور پہلی ناکامی کے ارد گرد مکمل غلطی شامل کریں۔

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

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

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

ڈیبگنگ پرامپٹ:

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

فکس پرامپٹ:

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

AI diffs کو لکھنے سے زیادہ اچھا جائزہ لیتا ہے

AI اکثر پہلے مصنف کے بجائے جائزہ لینے والے کے طور پر بہتر ہوتا ہے۔ جب آپ اس سے کسی diff کا جائزہ مانگتے ہیں، تو یہ چھوٹے ہوئے کنارے کے کیسز، سیکیورٹی کے مسائل، بوسیدہ مفروضے، ٹیسٹ کے خلا اور رویے کی تبدیلیاں تلاش کر سکتا ہے۔ اہم بات یہ ہے کہ جائزہ مخصوص بنائیں۔ اگر آپ "کیا یہ ٹھیک لگتا ہے؟" پوچھیں تو آپ کو شائستہ منظوری ملے گی۔ اگر آپ درستگی کے خطرے کے بارے میں پوچھیں، تو مفید اعتراضات ملنے کا زیادہ امکان ہے۔

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

جائزے کا شعبہ	AI کو کن سوالات کا جواب دینا چاہیے
درستگی	کیا diff واقعی تقاضے کو پورا کرتا ہے؟
ریگریشن کا خطرہ	موجودہ رویہ حادثاتی طور پر کیا بدل سکتا ہے؟
سیکیورٹی	کیا ان پٹس، auth، سیکرٹس، اجازتیں یا انجیکشن کے خطرات سنبھالے گئے ہیں؟
خرابی سنبھالنا	nulls، ٹائم آؤٹس، دوبارہ کوشش، خراب جوابات یا جزوی حالت پر کیا ہوتا ہے؟
ٹیسٹس	کون سے رویے کے دعوے کوریج میں نہیں ہیں؟
برقراری	کیا یہ مقامی نمونوں کی پیروی کرتا ہے اور تبدیلی کو قابلِ فہم رکھتا ہے؟

کوڈ ریویو پرامپٹ:

اس diff کا جائزہ ایک سخت لیکن عملی مینٹینر کی طرح لیں۔ درستگی، ریگریشن کے خطرے، سیکیورٹی، کنارے کے کیسز اور غائب ٹیسٹس پر توجہ دیں۔ معمولی اسٹائل کو نظرانداز کریں جب تک یہ حقیقی برقراری کا خطرہ پیدا نہ کرے۔ ایک جدول واپس دیں جس میں مسئلہ، ترجیح، diff سے شواہد، تجویز کردہ فکس اور درکار ٹیسٹ شامل ہو۔ مطلوبہ رویہ: [چسپاں کریں]۔ Diff: [چسپاں کریں]۔ موجودہ ٹیسٹس: [چسپاں کریں]۔

زیادہ خطرے والی تبدیلیوں کے لیے، Whizi میں compare-model-fixes ورک فلو استعمال کریں۔ وہی جائزے کا پرامپٹ دو یا تین ماڈلز میں چلائیں۔ اگر ایک ماڈل کوئی ممکنہ مسئلہ ڈھونڈے، تو اسے آنکھیں بند کر کے قبول نہ کریں؛ چیک کریں کہ کیا مسئلہ کوڈ بیس میں واقعی موجود ہے۔ مقصد مرج کرنے سے پہلے جائزے کے دائرے کو وسیع کرنا ہے، جہاں ہر اعتراض ووٹ کے طور پر گنے جانے کے بجائے کوڈ تک واپس لے جایا جاتا ہو۔

AI کے کسی ری فیکٹر کو چھونے سے پہلے invariants نام کریں

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

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

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

قدم 3: characterization ٹیسٹس لکھیں۔ کوڈ بدلنے سے پہلے، AI سے موجودہ رویہ شناخت کرنے اور اہم کیسز کو محفوظ کرنے والے ٹیسٹس کا مسودہ بنانے کو کہیں۔ یہ ٹیسٹس اس legacy کوڈ کے لیے خاص طور پر مفید ہیں جہاں ارادہ غیر واضح ہو۔ ان میں عام ان پٹس، حدی ان پٹس، ناکامی کے راستے اور ری فیکٹر کی وجہ سے جڑا ایک ریگریشن کیس شامل ہونا چاہیے۔

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

ری فیکٹر پلاننگ پرامپٹ:

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

یونٹ ٹیسٹ پرامپٹ:

نفاذ کی تبدیلیوں سے پہلے ٹیسٹس لکھیں۔ یہاں دکھایا گیا موجودہ ٹیسٹ اسٹائل استعمال کریں: [چسپاں کریں]۔ برقرار رکھا جانے والا رویہ: [چسپاں کریں]۔ زیرِ جانچ کوڈ: [چسپاں کریں]۔ واپس دیں: ٹیسٹ کے نام، سیٹ اپ، ان پٹ، متوقع نتیجہ اور ہر ٹیسٹ کیوں اہم ہے۔ happy path، حدی کیس، غلطی کیس اور ریگریشن کیس شامل کریں۔

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

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

کوڈنگ کا کام	پہلے کیا مانگیں	جواب کو کیا ثابت کرتا ہے
ڈیبگنگ	ہر ایک کے پیچھے شواہد کے ساتھ درجہ بند بنیادی وجوہات	ایک ریگریشن ٹیسٹ جو فکس سے پہلے ناکام اور بعد میں کامیاب ہو
کوڈ ریویو	درستگی، ریگریشن کا خطرہ، سیکیورٹی، کنارے کے کیسز اور ٹیسٹ کے خلا	diff میں ایک مخصوص سطر تک ہر مسئلہ کا سراغ
ری فیکٹرنگ	کسی بھی نفاذی تبدیلی سے پہلے invariants اور مرحلہ وار منصوبہ	ہر مرحلے کے آخر میں characterization ٹیسٹس اب بھی کامیاب ہوں
ٹیسٹس لکھنا	happy path، حدی، غلطی اور ریگریشن کیسز	ہر ٹیسٹ کسی رویے کے دعوے سے مماثل ہو
کوڈ کی وضاحت	مقصد، ان پٹس، آؤٹ پٹس، ڈیٹا کا بہاؤ، انحصار اور ناکامی کے انداز	کوڈ میں نظر آنے والے حقائق مفروضوں سے الگ ہوں

کوڈ کی وضاحت کا پرامپٹ:

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

محفوظ کوڈنگ کا پرامپٹ:

اس کوڈ کا سیکیورٹی خطرات کے لیے جائزہ لیں۔ auth، اجازتوں، انجیکشن، سیکرٹس، تصدیق، غیر محفوظ ری ڈائریکٹس، فائل ہینڈلنگ، انحصار کے خطرے اور حساس ڈیٹا کے افشا پر توجہ دیں۔ صرف شواہد، اثر، تجویز کردہ فکس اور ٹیسٹ یا دستی چیک کے ساتھ مسائل واپس دیں۔ کوڈ/diff: [چسپاں کریں]۔

Compare-model-fixes پرامپٹ:

میں ایک کوڈنگ کام کے لیے AI ماڈلز کا موازنہ کر رہا ہوں۔ صرف فراہم کردہ سیاق و سباق استعمال کریں۔ بنیادی وجہ، سب سے چھوٹا محفوظ فکس، ٹیسٹس، خطرات، مفروضے اور سوالات واپس دیں۔ اعتماد کو 1-5 پر درجہ دیں اور فہرست کریں کہ کون سے شواہد آپ کا جواب بدل دیں گے۔ کام: [چسپاں کریں]۔ سیاق و سباق: [چسپاں کریں]۔

AI سے بنائے گئے کوڈ کو قبول کرنے سے پہلے QA چیک لسٹ:

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

ایک دیانتدار حد: Whizi ایک چیٹ ورک اسپیس ہے، IDE پلگ ان نہیں۔ ٹائپ کرتے وقت ان لائن آٹو کمپلیٹ کے لیے، ایک وقف شدہ IDE اسسٹنٹ جیتتا ہے۔ Whizi چیک پوائنٹس پر اپنی جگہ بناتا ہے: وہی ڈیبگنگ یا جائزے کا پرامپٹ Claude Sonnet 4.6، GPT-5.6 Terra اور DeepSeek V4 Pro میں چسپاں کریں، پھر شواہد، دائرہ کار، ٹیسٹس اور خطرے کے مطابق آؤٹ پٹس کو اسکور کریں۔ اگر آپ ماڈل منتخب کرنے کا گائیڈ چاہتے ہیں تو کوڈنگ کے لیے ChatGPT کے متبادل سے شروع کریں، قیمتوں پر پلانز کا موازنہ کریں، یا اپنے کوڈ پر یہ ورک فلو چلانے کے لیے اکاؤنٹ بنائیں۔