سافٹ ویئر انجینئرنگ ختم ہو چکی ہے۔ ٹیک ٹویٹر (tech Twitter) پر بلند آوازیں آپ کو یہی باور کروانا چاہتی ہیں۔ وہ AI ٹولز کی اسکرین ریکارڈنگز شیئر کرتے ہیں جو محض ایک پیراگراف کے پرامپٹ (prompt) سے مکمل ایپلی کیشنز تیار کر دیتے ہیں، اور پھر پوچھتے ہیں کہ کوئی انسان کو کوڈ لکھنے کے لیے پیسے کیوں دے گا۔ یہ گھبراہٹ قابلِ فہم ہے، لیکن یہ اصل مقصد کو بالکل نظر انداز کر دیتی ہے۔

AI انجینئرز کے لیے نہیں آ رہا۔ یہ ان لوگوں کے لیے ہے جو ٹائپنگ کی رفتار کو تکنیکی فیصلہ سازی (technical judgment) سمجھنے کی غلطی کرتے ہیں۔ کوڈنگ اور انجینئرنگ کے درمیان ایک بہت بڑا فرق ہے، اور یہی وہ فرق ہے جہاں یہ پورا پیشہ قائم ہے۔

ایک AI اسسٹنٹ آپ کے کافی پینے سے پہلے ہی آپ کو کسی فیچر کو نافذ (implement) کرنے کے پانچ مختلف طریقے بتا سکتا ہے۔ رکاوٹ (bottleneck) اب بدل چکی ہے۔ اب ہم ایک خالی فائل کو دیکھ کر یہ سوچتے نہیں رہ جاتے کہ آغاز کیسے کریں۔ بلکہ ہم پانچ ممکنہ حلوں کو دیکھ کر یہ سوچتے ہیں کہ ان میں سے کون سا حل اس وقت تباہ نہیں ہوگا جب اصل ٹریفک آنا شروع ہوگی۔ وہ فیصلہ کرنا ہی انجینئرنگ ہے۔ باقی سب کچھ محض سنٹیکس (syntax) ہے۔

ڈیمو پروڈکٹ نہیں ہے

کسی بھی AI کوڈنگ ڈیمو کو دیکھیں اور آپ دیکھیں گے کہ منٹوں میں ایک خوبصورت انٹرفیس تیار ہو جاتا ہے۔ لیکن جو آپ نہیں دیکھیں گے وہ یہ ہے کہ لوڈ (load) پڑنے پر ڈیٹا بیس کنکشن پول (database connection pool) کیسے ختم ہو جاتا ہے۔ آپ کسی API اینڈ پوائنٹ پر مِسنگ ریٹ لمٹس (rate limits)، آڈٹ لاگز کی عدم موجودگی، یا ہر صارف کے انٹرایکشن کو آبجیکٹ بکٹ (object bucket) میں محفوظ کرنے کے اسٹوریج اخراجات نہیں دیکھیں گے کیونکہ AI نے اسے ڈیٹا ڈالنے کے لیے ایک آسان جگہ سمجھ لیا تھا۔

پروڈکشن سسٹم کے لیے اسکیل ایبلٹی (scalability)، سیکیورٹی، پرفارمنس اور لاگت کے کنٹرول کی ضرورت ہوتی ہے۔ یہ خصوصیات اسپرنٹ ریویو (sprint review) میں نظر نہیں آتیں۔ یہ صرف اس وقت ظاہر ہوتی ہیں جب اصل صارفین اپنی غیر متوقع عادات، اپنے ایج کیسز (edge cases)، اور آپ کی توقع کے مطابق بٹن دبانے سے انکار کے ساتھ آتے ہیں۔ میں نے بہت سے ایسے AI سے مدد یافتہ پروجیکٹس دیکھے ہیں جو QA میں تو بہترین نظر آتے تھے لیکن لانچ کے ایک ہفتے بعد مہنگے سبق بن گئے۔

کام کرنے والا کوڈ اب سستا ہو گیا ہے۔ اچھی انجینئرنگ نہیں ہوئی۔

اب کیا اہمیت رکھتا ہے

اس تبدیلی میں وہ انجینئرز ترقی کر رہے ہیں جو سب سے تیز ٹائپ نہیں کرتے، بلکہ وہ ہیں جو ایک لائن بھی جنریٹ ہونے سے پہلے جانتے ہیں کہ کون سے سوالات پوچھنے ہیں۔

  • وہ مسائل کو واضح طور پر بیان کرتے ہیں۔ اگر آپ اجازت دیں تو ایک AI ماڈل خوشی خوشی غلط مسئلہ حل کر دے گا۔ یہ ایک ایسے ریڈ ہیوی (read-heavy) ڈیش بورڈ کے لیے ایک پیچیدہ کیشنگ لیئر (caching layer) بنا دے گا جو صرف چھ اندرونی تجزیہ کاروں (analysts) کے لیے استعمال ہوتا ہے۔ یہ یہ پوچھنے کے لیے نہیں رکے گا کہ آیا اصل مسئلہ ڈیٹا بیس انڈیکس کی کمی ہے یا بنیادی طور پر خراب ڈیٹا ماڈل۔ ایک ماہر انجینئر مسئلے کو اس وقت تک دوبارہ ترتیب دیتا ہے جب تک کہ حل واضح نہ ہو جائے، چاہے اس حل میں کوڈ شامل ہو یا نہ ہو۔

  • وہ بڑے سسٹمز کو چھوٹے حصوں میں تقسیم کرتے ہیں۔ AI مقامی سیاق و سباق (local context) میں مہارت رکھتا ہے۔ یہ ایک سنگل فنکشن، ایک سنگل کمپوننٹ، یا ایک سنگل ٹیسٹ لکھ سکتا ہے۔ لیکن یہ پورے ڈسٹری بیوٹڈ آرکیٹیکچر (distributed architecture) کو ذہن میں رکھنے میں مشکل محسوس کرتا ہے۔ وہ انجینئرز جو ایک مونو لیتھ (monolith) کو توڑ سکتے ہیں، سروسز کے گرد حدود مقرر کر سکتے ہیں، اور ٹیموں کے درمیان معاہدے (contracts) طے کر سکتے ہیں، وہی جنریٹ شدہ کوڈ کے ٹکڑوں کو پائیدار سسٹمز میں تبدیل کرتے ہیں۔

  • وہ AI کی تجاویز کو چیلنج کرتے ہیں۔ ماڈل کا اعتماد محض ایک سراب ہے۔ یہ ایسی آرکیٹیکچرز تجویز کرے گا جو نیٹ ورک لیٹنسی (network latency) کو نظر انداز کرتی ہیں، ایسی لائبریریز کی سفارش کرے گا جو برسوں پہلے ختم (deprecated) ہو چکی ہیں، یا ایسے فیچرز حل کرنے کی کوشش کرے گا جو درحقیقت ضروریات (requirements) میں موجود ہی نہیں ہیں۔