سافٹ ویئر ٹیموں کے لیے مصنوعی ذہانت: ورکنگ ماڈل اور حدود

فائدہ:

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

سافٹ ویئر ڈویلپر کا دن شاذ و نادر ہی "شروع سے کوڈ لکھنے" میں صرف ہوتا ہے۔ حقیقی وقت؛ کسی اور کے لکھے ہوئے کوڈ کو پڑھنا، بگ کو دوبارہ پیش کرنے کی کوشش کرنا، لاگ کو اسکین کرنا (چلتے وقت ایپلی کیشن کے ذریعے تیار کردہ لاگ لائنز)، ٹیسٹ لکھنا، PR لکھنا (پل کی درخواست - ایک انضمام کی درخواست جہاں ٹیم کے جائزے کے لیے کوڈ میں تبدیلی جمع کروائی جاتی ہے) وضاحت اور دستاویزات کو اپ ڈیٹ کرنا۔ مصنوعی ذہانت (AI) ایک سپیڈ ملٹیپلر ہے جو تقریباً تمام ان دیکھی نوکریوں کو چھو سکتی ہے۔ لیکن اسے محفوظ طریقے سے استعمال کرنے کی پہلی شرط یہ ہے کہ یہ صحیح طریقے سے سمجھیں کہ یہ کیا ہے اور کیا نہیں۔

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

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

کوڈنگ اسسٹنٹ اصل میں کیا کرتا ہے؟

زیادہ تر کوڈنگ اسسٹنٹس ایک بڑے لینگویج ماڈل پر بنائے گئے ہیں (LLM—ایک AI جس میں متن اور کوڈ کی بھاری مقدار پر تربیت حاصل کی گئی ہے جو اگلے ممکنہ "ٹکڑے" کی پیش گوئی کرتا ہے)۔ ماڈل ایک انسان کی طرح کوڈ کو "سمجھ" نہیں سکتا۔ یہ آپ کے دیے گئے سیاق و سباق کا سب سے زیادہ ممکنہ تسلسل پیدا کرتا ہے، ان نمونوں کی بنیاد پر جو یہ مثالوں کے بہت بڑے تالاب سے سیکھتا ہے۔ یہ بظاہر آسان طریقہ کار عملی طور پر حیرت انگیز طور پر ماہر نتائج دیتا ہے - کیونکہ زیادہ تر سافٹ ویئر دہرائے جانے والے پیٹرن پر مشتمل ہوتا ہے: ایک HTTP درخواست، ایک لوپ، ایک نال چیک، ایک ٹیسٹ پیٹرن۔

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

طاقت اور کمزوریوں کا نقشہ

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

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

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

مشن کی قسم

AI کا کردار

آدمی کا کردار

بوائلر پلیٹ/کنکال تیار کریں۔

مسودہ تیار کرتا ہے۔

موافقت، جائزے

کوڈ کی تفصیل

ایک فوری خلاصہ دیتا ہے۔

کوڈ میں اہم حصے کی تصدیق کرتا ہے۔

تحریری ٹیسٹ

کیس تجویز کرتا ہے۔

کوریج اور درستگی کی تصدیق کرتا ہے۔

حفاظتی تنقیدی منطق

مددگار خیال

فیصلہ اور ذمہ داری مکمل طور پر انسانوں پر ہے۔

API/لائبریری کا استعمال

نمونہ تیار کرتا ہے۔

وجود اور ورژن کی تصدیق کرتا ہے۔

تعمیراتی فیصلہ

طرح طرح کے اختیارات

سیاق و سباق کو جانتے ہوئے منتخب اور دفاع کرتا ہے۔

مرحلہ وار: بنیادی ورکنگ سائیکل

1. کام کو واضح کریں۔ اگر آپ ایک جملے میں اپنی مرضی کے مطابق نہیں لکھ سکتے تو نہ ہی ماڈل لکھ سکتے ہیں۔ پہلے کی غیر یقینی صورتحال ان پٹ میں داخل ہوتی ہے، یہ آؤٹ پٹ میں اتنی ہی بڑھتی ہے۔
2. سیاق و سباق دیں۔ پرامپٹ میں متعلقہ کوڈ، مکمل ایرر میسج، زبان/فریم ورک ورژن اور رکاوٹیں شامل کریں۔ "اس کو ٹھیک کریں" مت کہو، "Python 3.11، FastAPI 0.110؛ یہ فنکشن 500 ایرر دیتا ہے، جب درخواست کی باڈی خالی ہوتی ہے تو یہ پھٹ جاتا ہے"۔
3. مسلط کرنے کا کردار اور شکل۔ ایک فریم ورک جیسا کہ "آپ ایک سینئر گو ڈویلپر ہیں؛ صرف کوڈ دیں اور دو جملوں کا استدلال" آؤٹ پٹ کو فوکس کرتا ہے۔
4. چھوٹے سے پوچھیں۔ اسے ایک بڑی درخواست کے بجائے قدموں میں تقسیم کریں۔ ہر قدم کی الگ سے تصدیق کریں۔ بڑی تبدیلیاں خطرناک ہیں کیونکہ ان کی تصدیق کرنا مشکل ہے اور غلطیوں کو چھپانے کا خطرہ ہے۔
5. تصدیق کریں۔ اسے چلائیں، اسے آزمائیں، اسے بصری طور پر پڑھیں۔ غیر تصدیق شدہ AI کوڈ ایک "خاکہ" ہے، "حل" نہیں ہے۔ یہ سائیکل کا سب سے غیر گفت و شنید قدم ہے۔

تین چھوٹے کیسز

کیس 1 - وقت کی بچت حقیقی لیکن معمولی ہے۔ جب ایک ٹیم نے AI کے ساتھ نئے CRUD (Create-Read-update-delete) کے اختتامی نکات کو ترتیب دیا، تو پہلے ڈرافٹ کا وقت تقریباً 40 منٹ سے گھٹ کر 8 منٹ رہ گیا۔ تاہم، جائزہ اور جانچ کے ساتھ، کل وقت 25 منٹ تھا۔ لہذا حقیقی فائدہ 40 سے 25 تک ہے، تقریباً 38 فیصد۔ یہ شرح، "ہم نے 10 گنا تیز ہو گئی ہے" کی توقع کے بجائے ماپا، ایک پائیدار فائدہ ہے۔

کیس 2 - ہیلوسینیشن مہنگا ہے۔ ایک ڈویلپر نے بغیر تصدیق کے AI-suggested requests.get_json() کال کا استعمال کیا۔ ایسا کوئی طریقہ نہیں تھا۔ کوڈ مرتب نہ ہونے پر 20 منٹ ضائع ہو گئے۔ ایک سادہ "کیا یہ طریقہ واقعی موجود ہے؟" تصدیق نقصان کو دوبارہ ترتیب دے گی۔

کیس 3 - اچھا سیاق و سباق آؤٹ پٹ کو دوگنا کرتا ہے۔ اسی بگ کے لیے، ایک ڈویلپر نے صرف لکھا "مجھے ایک غلطی ہو رہی ہے" اور دوسرے نے مکمل اسٹیک ٹریس، ورژن، اور ان پٹ کا نمونہ شامل کیا۔ مؤخر الذکر کو پہلی کوشش میں صحیح حل مل گیا۔ پہلے والے نے تین بار گزارے۔ فرق ماڈل میں نہیں بلکہ ان پٹ میں تھا۔

چار کاپی ایبل ٹیمپلیٹس

ایک عام مقصد، طاقتور آغاز کا اشارہ:

کردار: آپ ایک تجربہ کار {{language}} ڈویلپر ہیں۔ Task: {{what_want}}Context:- Framework/version: {{framework_and_version}}- رکاوٹیں: {{performance, style, انحصار کے اصول}}قواعد:- غیر موجود لائبریری/فنکشن کا استعمال نہ کریں؛ اگر آپ کو یقین نہیں ہے تو اسے "تصدیق" کے بطور نشان زد کریں۔ - پہلے، ایک مختصر منصوبہ، پھر کوڈ، پھر جواز کے 2 جملے دیں۔ - قابل امتحان، ورکنگ کوڈ تیار کریں۔

غیر یقینی صورتحال کو واپس ماڈل میں فلٹر کرنے کے لیے:

ذیل میں کام کو حل کرنے سے پہلے، کم از کم 3 پوائنٹس کی فہرست بنائیں جو آپ کو سوالات کے طور پر غائب یا غیر واضح نظر آتے ہیں۔ جواب دینے سے پہلے کوڈ مت لکھیں۔ Task: {{task}}

آؤٹ پٹ کو خود چیک کرنے کے لیے:

آپ نے درج ذیل کوڈ تیار کیا ہے۔ اب اپنا کردار تبدیل کریں اور اس کوڈ پر تنقید کریں:- 3 کیسز (ایج کیسز) کی فہرست بنائیں جو شاید کام نہ کریں۔ نشان زد کریں- درست ورژن دیں۔ کوڈ:{{code}}

کسی فیصلے کو اختیارات میں تقسیم کرنے کے لیے:

{{problem}} کے لیے 2-3 حل کے طریقے تجویز کریں۔ ہر ایک کے لیے: مختصر تفصیل، جمع/مائنس، کب انتخاب کرنا ہے۔ ٹیبلر شکل میں دیں۔ میرے لیے انتخاب نہ کریں؛ صرف آپشن کو واضح کریں۔

کمزور فوری / مضبوط اشارہ

کمزور: "اس کوڈ میں بگ کو ٹھیک کریں۔" (کونسی غلطی؟ کون سی زبان؟ متوقع سلوک کیا ہے؟)

مضبوط: "Python 3.11 / FastAPI 0.110۔ مندرجہ ذیل اختتامی نقطہ KeyError کے ساتھ 500 واپس کرتا ہے جب درخواست کی باڈی خالی آتی ہے؛ میں چاہتا ہوں کہ یہ 400 واپس کرے اور خالی باڈی پر معنی خیز پیغام آئے۔ پہلے وجہ بیان کریں، پھر درست فنکشن دیں، پھر اس منظر نامے کے لیے ایک ٹیسٹ لکھیں۔ [code]"

طاقتور ورژن؛ یہ زبان، ورژن، اصل غلطی، متوقع رویہ اور آؤٹ پٹ فارمیٹ دیتا ہے۔ ماڈل کو اب پیش گوئی کرنے کی ضرورت نہیں ہے۔

عام غلطیاں

• تصدیق کے بغیر اعتماد کرنا۔ سب سے عام اور مہنگی غلطی۔ کوڈ کو مرتب اور جانچنے تک "حل" نہ کہیں۔
• سیاق و سباق کے بغیر سوالات پوچھنا۔ ورژن، غلطی کے متن اور پابندیوں کے بغیر جواب عام اور اکثر غلط ہوتا ہے۔
• ایک بہت بڑی درخواست۔ ایک ساتھ 300 لائن پروڈکشن کی درخواست کرنے اور اس کا جائزہ لینے کے قابل نہ ہونا غلطیاں پوشیدہ کر دیتا ہے۔
• ماڈل کے خود اعتمادی کو ثبوت کے طور پر غلط سمجھنا۔ AI اعتماد کے ساتھ کچھ غلط کہہ سکتا ہے۔ ٹون درستگی کا اشارہ نہیں ہے۔
• کمپنی کے راز کو تصادفی طور پر چسپاں کرنا۔ پرائیویٹ کیز، کسٹمر ڈیٹا یا پرائیویٹ سورس کوڈ کو غیر منظور شدہ ٹولز میں داخل نہیں کیا جانا چاہیے (ہم یونٹ 10 میں اس موضوع پر غور کریں گے)۔

اشارہ: ہر AI آؤٹ پٹ کو "یہ ایک مسودہ ہے۔" سمجھیں۔ یہ واحد ذہنی عادت زیادہ تر خطرات کو ختم کر دیتی ہے جو آپ پورے ماڈیول میں دیکھیں گے۔

خلاصہ میں

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

درخواست کا کام

سافٹ ویئر کے تین کام لکھیں جو آپ نے پچھلے ہفتے میں کیے تھے (مثلاً ایک بگ فکس، ایک ٹیسٹ، ایک README اپ ڈیٹ)۔ ہر ایک کے لیے "طاقتوں اور کمزوریوں کا نقشہ" دیکھیں اور ایک جملے میں بیان کریں کہ اگر آپ کے پاس AI ایسا کرتا تو آپ کا اور AI کا کردار کیا ہوتا۔ پھر ان میں سے ایک ٹاسک AI کو اوپر "اسٹارٹ پرامپٹ" ٹیمپلیٹ کے ساتھ دیں اور چلائیں اور آؤٹ پٹ کی تصدیق کریں۔ نوٹ کریں کہ آپ نے کتنے منٹ بچائے اور کتنی غلطیاں آپ کو ٹھیک کرنی تھیں۔

چیک لسٹ

• میں نے محسوس کیا کہ LLM پیٹرن تیار کرتا ہے، کوڈ کو "سمجھتا" نہیں۔
• میں ٹوکن، سیاق و سباق ونڈو اور پرامپٹ کے تصورات کو ایک جملے میں بیان کر سکتا ہوں۔
• میں کاموں کی اقسام میں فرق کر سکتا ہوں جہاں AI مضبوط اور کمزور ہے۔
• میں جانتا ہوں کہ فریب کاری کیا ہے اور واحد تریاق تصدیق ہے۔
• میں نے "تجویز، پیداوار، تصدیق" سائیکل کو اپنے کام کے لیے ڈھال لیا۔
• میں ایک ٹھوس مثال میں مضبوط پرامپٹ اور کمزور پرامپٹ کے درمیان فرق دکھا سکتا ہوں۔