سرخیاں ہمیں مسلسل یہ بتاتی رہتی ہیں کہ AI سافٹ ویئر ڈویلپرز کو غیر ضروری بنا دے گی۔ میں اس پر یقین نہیں رکھتا۔ اصل خطرہ یہ نہیں ہے کہ مشینیں انجینئرنگ پر قبضہ کر لیں گی۔ اصل خطرہ یہ ہے کہ انجینئرز سوچنے کی مشکل محنت کرنا چھوڑ دیں گے۔
سافٹ ویئر کبھی بھی صرف سنٹیکس (syntax) ٹائپ کرنے کا نام نہیں تھا۔ یہ ہمیشہ پیچیدگیوں کو ذہن میں رکھنے، ناکامی کے ممکنہ طریقوں (failure modes) کو سمجھنے، اور تب سمجھوتہ کرنے (trade-offs) کے بارے میں تھا جب کوئی بھی آپشن مکمل طور پر درست نہ ہو۔ AI نے کوڈ تیار کرنے کی رفتار تو بدل دی ہے، لیکن اس وجہ کو نہیں بدلا کہ ہمیں انسانوں کی ضرورت کیوں ہے۔ بلکہ، اس نے واضح سوچ کو مزید قیمتی اور نایاب بنا دیا ہے۔
پہلا ڈرافٹ انجینئرنگ نہیں ہے
میں دیکھ رہا ہوں کہ جونیئر ڈویلپرز کی ایک بڑھتی ہوئی تعداد ChatGPT یا Claude کو اس سینئر انجینئر کے طور پر دیکھتی ہے جو اگلی کرسی پر بیٹھا ہو۔ وہ ٹکٹ کی تفصیل پیسٹ کرتے ہیں، جواب کاپی کرتے ہیں، ٹیسٹ چلاتے ہیں، اور اسے کمٹ (commit) کر دیتے ہیں۔ اگر کوڈ کمپائل ہو جائے، تو کام ختم۔ یہ عمل تیز ہے، بغیر کسی رکاوٹ کے ہے، لیکن خطرناک ہے۔
AI کا استعمال مسئلہ نہیں ہے۔ میں اسے استعمال کرتا ہوں۔ میں جن زیادہ سے زیادہ باصلاحیت انجینئرز کو جانتا ہوں، وہ اسے استعمال کرتے ہیں۔ مسئلہ تب شروع ہوتا ہے جب AI کمرے میں موجود واحد انجینئر بن جائے۔ صرف اس لیے پہلی تجویز کو قبول کر لینا کہ وہ کام کر رہی ہے، انجینئرنگ نہیں ہے۔ یہ اپنے فیصلے کرنے کی صلاحیت (judgment) کو ایک ایسے ماڈل کے سپرد کر دینا ہے جو آپ کے صارفین، آپ کے کاروباری حالات، یا اس بات سے واقف نہیں کہ آخری بار آپ کا سسٹم رات کے 2 بجے کیسے ناکام ہوا تھا۔
لارج لینگویج ماڈلز (LLMs) انتہائی اعتماد کے ساتھ جوابات دیتے ہیں، چاہے وہ مکمل طور پر غلط ہی کیوں نہ ہوں۔ ایک انجینئر نے AI سے ایک اسکیل ایبل (scalable) آرکیٹیکچر ڈیزائن کرنے کو کہا۔ ماڈل نے ایک تفصیلی اور مستند تجویز پیش کی جو مکمل طور پر ایک ایسے فیچر کے گرد بنی تھی جو اصل پروڈکٹ میں موجود ہی نہیں تھا۔ یہ دیکھنے میں درست لگ رہا تھا۔ یہ اندرونی طور پر مستقل مزاج (consistent) تھا۔ لیکن یہ بالکل بیکار تھا۔ خطرہ صرف یہ نہیں ہے کہ AI غلط معلومات (hallucinations) دیتا ہے۔ خطرہ یہ ہے کہ اب بہت سے لوگ ان غلط معلومات پر بھروسہ کر لیتے ہیں کیونکہ ان کے پاس جھوٹ کو پہچاننے کے لیے ضروری سیاق و سباق (context) نہیں رہتا۔
آپ رکاوٹوں سے سیکھتے ہیں
جب میں اس بارے میں سوچتا ہوں کہ میں نے ایک جونیئر ڈویلپر سے ایک ایسا شخص بننے تک کا سفر کیسے طے کیا جو پورے سسٹم کی ذمہ داری لے سکے، تو مجھے وہ سنٹیکس یاد نہیں آتا جو میں نے حفظ کیا تھا۔ مجھے سسٹم کے بند ہونے (outages) کے واقعات یاد ہیں۔ مجھے وہ سست کوئریز (slow queries) یاد ہیں جن کا سراغ مجھے خود لگانا پڑا، وہ ریس کنڈیشنز (race conditions) جو صرف پروڈکشن لوڈ کے دوران ظاہر ہوتی تھیں، اور وہ ڈیپلائمنٹس (deployments) جو اس لیے ناکام ہوئیں کیونکہ میرا لوکل ماحول اصل دنیا جیسا نہیں تھا۔
ڈیبگنگ (Debugging) وہ جگہ ہے جہاں اصل سیکھنے کا عمل ہوتا ہے۔ جب آپ کوڈ کو دستی طور پر (manually) مرحلہ وار دیکھتے ہیں، تو آپ کو سمجھ آتا ہے کہ سسٹم اصل میں کیوں ناکام ہوتے ہیں۔ آپ کو معلوم ہوتا ہے کہ رکاوٹیں (bottlenecks) کہاں پیدا ہوتی ہیں۔ آپ سیکھتے ہیں کہ جب آپ دس صارفین والے ڈیمو سے دس ہزار بیک وقت درخواستیں (concurrent requests) سنبھالنے والے پروڈکشن سسٹم کی طرف بڑھتے ہیں، تو آرکیٹیکچر کیسا برتاؤ کرتا ہے۔ آپ اپنی روح میں یہ بات جذب کر لیتے ہیں کہ پروڈکشن ایک اچھی طرح سے تیار کردہ ڈیمو سے کیسے مختلف ہوتی ہے۔
یہ تمام علم کسی تیار شدہ جواب کو قبول کرنے سے حاصل نہیں ہوتا۔ یہ مسئلے سے لڑنے سے حاصل ہوتا ہے۔ اگر AI ہر جدوجہد کو ختم کر دیتا ہے، اگر وہ کوڈ لکھتا ہے، بگ (bugs) ٹھیک کرتا ہے اور ناکامیوں کی وضاحت کر دیتا ہے، تو ڈویلپرز کی اگلی نسل اپنی سینئرٹی کیسے حاصل کرے گی؟ تجربہ کوئی ایسی سرٹیفکیٹ نہیں ہے جسے آپ ڈاؤن لوڈ کر سکیں۔ یہ وہ نشانات (scar tissue) ہیں جو آپ پروڈکشن کے واقعات اور ناکام ڈیپلائمنٹس سے حاصل کرتے ہیں۔ اگر آپ رکاوٹوں کو ختم کر دیں گے، تو آپ ترقی کے راستے کو بھی ختم کر دیں گے۔
فیصلہ سازی تخلیق سے بہتر ہے
کچھ عرصے کے لیے، انڈسٹری نے 'پرامپٹ انجینئرنگ' (prompt engineering) کو ریزیومے پر لکھنے کے لیے ایک نئی مہارت کے طور پر پیش کیا۔ اس سے اصل مقصد بالکل نظر انداز ہو گیا۔ AI سے بھرپور ماحول میں سب سے قیمتی صلاحیت آپشنز پیدا کرنا نہیں ہے۔ بلکہ یہ جاننا ہے کہ کن تجاویز کو مسترد کرنا ہے۔
میں جن بہترین انجینئرز کے ساتھ کام کرتا ہوں، وہ سب سے زیادہ پرامپٹس نہیں لکھتے۔ وہ مشکل ترین سوالات پوچھتے ہیں۔ وہ جانتے ہیں کہ کب ایک ریفیکٹر (refactor) کوئی چھپی ہوئی وابستگی (dependency) پیدا کر رہا ہے۔ وہ پہچان لیتے ہیں کہ کب ایک تیار کردہ ٹیسٹ صرف 'ہیپی پاتھ' (happy path) کو کور کر رہا ہے لیکن اس 'ایج کیس' (edge case) کو نظر انداز کر رہا ہے جو کسٹمر کے ڈیٹا کو خراب کر سکتا ہے۔ وہ بالکل درست کوڈ کو دیکھ کر کہہ سکتے ہیں، "یہ کوڈ تو ٹھیک ہے، لیکن آرکیٹیکچر غلط ہے۔"
یہ آخری جملہ دو بالکل مختلف ثقافتوں کے درمیان فرق کی لکیر ہے۔ AI-assisted انجینئرنگ کا مطلب ہے کہ آپ مشین کو ڈھانچہ (scaffolding) تیار کرنے، پیٹرنز تلاش کرنے، یا بوائلر پلیٹ (boilerplate) کوڈ کو خودکار بنانے کے لیے استعمال کرتے ہیں جبکہ آپ کا دماغ فیصلے کرتا ہے۔ AI-dependent انجینئرنگ کا مطلب ہے کہ آپ مشین کو گاڑی چلانے (کنٹرول کرنے) کے لیے چھوڑ دیتے ہیں۔ بہت سی تنظیمیں خاموشی سے انحصار (dependency) کی طرف بڑھ رہی ہیں کیونکہ قلیل مدت میں یہ تیز محسوس ہوتا ہے۔ تیز ہونا درست ہونے کے برابر نہیں ہے۔
وہ کام جو اب بھی انسانوں کا ہے
اے آئی ڈویلپمنٹ لائف سائیکل کے تقریباً ہر حصے کی رفتار بڑھا سکتا ہے، پھر بھی کچھ بنیادی طریقے ایسے ہیں جنہیں مکمل طور پر انسانی ہی رہنا چاہیے۔ سسٹم ڈیزائن کے لیے متضاد رکاوٹوں کے درمیان توازن برقرار رکھنا ضروری ہے: لاگت، لیٹنسی، بھروسہ مندی، اور مستقبل کی دیکھ بھال۔ آرکیٹیکچر ریویوز کا انحصار ادارہ جاتی یادداشت اور ثانوی اثرات کا اندازہ لگانے کی صلاحیت پر ہوتا ہے۔ رہنمائی کے لیے ایسے شخص کی ضرورت ہوتی ہے جس نے خود ان ناکامیوں کا سامنا کیا ہو جن کے بارے میں وہ آپ کو خبردار کر رہا ہے۔ پروڈکٹ کی گہری سمجھ صارفین سے بات کرنے اور حقیقی حالات میں ان کے رویوں کو دیکھنے سے آتی ہے، نہ کہ صرف ٹریننگ ڈیٹا پڑھنے سے۔
انجینئرنگ کا فیصلہ (Engineering judgment) ان تمام تجربات کا مجموعہ ہے۔ یہ وہ دھیمی آواز ہے جو آپ کو بتاتی ہے کہ ایک مائیگریشن جمعہ کی دوپہر کو ریلیز کرنا بہت پرخطر ہے، چاہے کوڈ ریویو پاس ہی کیوں نہ ہو گیا ہو۔ یہ وہ وجدان ہے جو بتاتا ہے کہ کارکردگی میں بہتری کا موجودہ قدم بعد میں سیکیورٹی کا مسئلہ پیدا کر سکتا ہے۔ ایک LLM کے پاس کوئی وجدان نہیں ہوتا۔ اس کے پاس صرف پیٹرنز ہوتے ہیں۔ پیٹرنز مفید تو ہیں، لیکن وہ فیصلہ کرنے کی صلاحیت نہیں ہیں۔
اس وقت بھرتی کرنے والی کمپنیوں کو ان لوگوں کے لیے اپنی ترجیحات بدل لینی چاہئیں جو محض AI ٹولز استعمال کرنے میں ماہر ہیں۔ ایسے لوگوں کو بھرتی کریں جو AI کو چیلنج کر سکیں۔ ایسے امیدواروں کی تلاش کریں جو رکیں، تیار شدہ آؤٹ پٹ کو غور سے پڑھیں، اور وضاحت کریں کہ وہ اس سے کیوں اختلاف کرتے ہیں۔ یہی وہ انجینئرز ہیں جو آپ کے سسٹمز کو مستحکم رکھیں گے جب تیار شدہ کوڈ پروڈکشن کی پیچیدہ حقیقتوں سے ٹکرائے گا۔
بغیر قطب نما کے رفتار میں اضافہ
اے آئی کو ایک ایکسلریٹر پیڈل کے طور پر سمجھیں۔ ایک ایسی کار میں جس کے ساتھ...