AI ایک طاقت بڑھانے والا ہے، نہ کہ رہنمائی۔مضمون کا مصنف، ذریعہ: InfoQ
AI نے آپ کو کوڈ لکھنے میں 10 گنا تیز بنادیا، اب کیا؟ زیادہ کوڈ کا مطلب ہے لمبی کمپائلیشن، بھاری ٹیسٹنگ، جام ہونے والی کوڈ ریویو، اور ایک ایسا کوڈ بیس جسے کوئی سمجھ نہیں سکتا۔ سافٹ ویئر قرض ہے، جتنا جلد لکھتے ہو، اتنا ہی زیادہ قرض ہوتا جا رہا ہے۔
گوگل کے سینئر سافٹ ویئر انجینئر ایڈم بینڈر کی چیتناؤ بہت واضح ہے: آج آپ جس طرح سافٹ ویئر بناتے ہیں، وہ 10 گنا تیز رفتاری پر ممکن نہیں۔ لیکن AI کے دور کے حقیقی فاتح وہ ٹیمیں ہیں جن کی بنیادی مہارتیں سب سے زیادہ مضبوط ہیں، کیونکہ AI صرف تقویت کرتا ہے، رہنمائی نہیں کرتا۔
گوگل I/O 2026 کے ایک پرنسپل سیشن میں، ایڈم بینڈر نے ایک ایسا سوال پیش کیا جس کے بارے میں زیادہ تر لوگوں نے ابھی تک سوچا نہیں ہے: جب AI کوڈ کی پیداوار کی رفتار کو اس قدر بڑھا دے کہ موجودہ انجینئرنگ عمل اسے برداشت نہ کر سکے، تو ہمارے ڈویلپر ایکوسسٹم میں کون سا پہلا حصہ ٹوٹ جائے گا؟ اس نے پورے سیشن کو ایک ایسے تصور سے جوڑا جس کے بارے میں آپ نے شاید کبھی سننا نہیں ہے: سافٹ ویئر ایکوسسٹم، جو سافٹ ویئر کی پیداوار کے سماجی-ٹیکنالوجیکل ایکوسسٹم کا مکمل جائزہ لینے والی ایک ڈسپلائن ہے۔ دوسرے الفاظ میں، آپ کو صرف ٹیکنالوجی نہیں دیکھنا چاہئے، بلکہ لوگوں، ثقافت اور تنظیموں میں غیر لکھے گئے قوانین کو بھی دیکھنا چاہئے۔ اس سیشن ویڈیو کے مطابق، InfoQ نے مواد کو ترتیب دیا ہے۔
مرکزی نقطہ نظر درج ذیل ہے:
- AI آپ کے کسی بھی مسئلے کو حل نہیں کرتا۔ اگر آپ کی عملدرآمد اچھی ہے، تو وہ انہیں بڑھاتا ہے۔ لیکن اگر وہ اچھی نہیں ہے، تو وہ صرف مزید پریشانیاں پیدا کرتا ہے۔
- ہر کوئی ایک بانی ہونا عمدہ ہے، جب تک کہ آپ کو ہر کسی کے بنائے گئے ہر چیز کی نگرانی نہ کرنی پڑے۔
- عملی تجربہ مقدس نہیں ہوتا۔ عمل تبدیل ہوتے رہتے ہیں، اصول اہم ہوتے ہیں۔
- ایک لائن سافٹ ویئر انجینئر کے طور پر، اس اہم لمحے میں آپ اس بات کا فیصلہ کرنے والے مرکز میں ہیں کہ سافٹ ویئر انجینئرنگ کہاں جائے گی۔ ٹولز سے لے کر ورک فلو، انجینئرنگ عمل سے لے کر انجینئرنگ کلچر تک، اگر آپ وہ نظام دیکھ سکتے ہیں جو چل رہا ہے، تو آپ لووریج تلاش کر سکتے ہیں۔
“سسٹم” کیا ہے؟
آپ کا 2026 کا کام، آپ کے 2020 میں سوچے گئے کام سے بالکل مختلف ہوگا۔ اگر میں آپ کو 2020 کے میں آج کی واقعات کی وضاحت کرنے کی کوشش کروں تو، میں اس پر ایمان نہیں لائتا۔ تبدیلیاں بہت زیادہ ہیں، اتنی زیادہ کہ ان سے نمٹنا تھوڑا مشکل ہو رہا ہے۔ میں مستقبل کا پیشن گوئی نہیں کر سکتا، لیکن میں یقین رکھتا ہوں کہ اگر ہم موجودہ سافٹ ویئر ایکوسسٹم کو دھیرے سے سمجھیں، تو کچھ جوابات ہماری تصورات سے زیادہ قریب ہیں۔
آج میں آپ کے ساتھ ایک لفظ پر بات کرنا چاہتا ہوں: سافٹ ویئر ایکولوجی (Software Ecology)۔ اس کا احساس یہ ہو سکتا ہے کہ میں نے اسے اسٹیج کے لیے ایجاد کیا ہے، لیکن نہیں، یہ ایک سنجیدہ اصطلاح ہے۔ تعریف دینے سے پہلے، میں آپ کو کچھ پس منظر فراہم کرنا چاہتا ہوں، جس میں ہم سسٹم تھنکنگ میں تھوڑا گہرا جائیں گے۔
ایک نظام میں باہمی طور پر منسلک عناصر کا ایک مجموعہ ہوتا ہے جو ایک مجموعہ قواعد کے مطابق کام کرتے ہیں اور ایک یکجا مجموعہ تشکیل دیتے ہیں۔ یہ انتہائی انتزاعی لگ سکتا ہے، لیکن آپ نظام سے ناواقف نہیں۔ مثال کے طور پر ایئر کنڈیشنر: ایک تھرموستیٹ جو مقصدی درجہ حرارت جانتا ہے، ایک ہیٹنگ، وینٹیلیشن اور ایئر کنڈیشننگ یونٹ جو درجہ حرارت بڑھانے یا کم کرنے کا کام کرتا ہے، ایک کمرہ، جب درجہ حرارت مناسب ہو جاتا ہے تو سگنل بند ہو جاتا ہے—یہ ایک نظام ہے۔
اگر آپ ایک سافٹ ویئر انجینئر ہیں، تو آپ روزانہ سسٹمز کے ساتھ کام کرتے ہیں، آپ سسٹم ڈیزائن کرتے ہیں، بناتے ہیں اور آپریٹ کرتے ہیں، اس عمل میں آپ نے ایک بات سیکھ لی ہوگی: سب کچھ جڑا ہوا ہے۔
اگلی چیز ایک ماحولیاتی نظام ہے، جو ایک خاص قسم کا نظام ہے۔ اس کی تعریف تھوڑی لمبی ہے، لیکن اہم ہے: ایک ماحولیاتی نظام ایک ڈائنامک نیٹ ورک ہے جس میں باہمی انحصار رکھنے والے افراد ہوتے ہیں جو اپنے ماحول کے ساتھ ساتھ ترقی کرتے ہیں، جس کی خصوصیت ابھرنے والی سرگرمیاں اور مرکز سے آزادی ہوتی ہے۔ عام زبان میں، ماحولیاتی نظام بہت پیچیدہ ہوتا ہے، اس کے اجزاء آپس میں گہرائی سے جڑے ہوتے ہیں، اور ہر اجزاء کا اپنا خودمختاری ہوتا ہے، جس کے ذریعے وہ فیصلے کر سکتا ہے اور اقدامات اٹھا سکتا ہے۔ اور سب سے اہم بات: ماحول نظام کا حصہ ہوتا ہے، اور آپ ان دونوں کو الگ نہیں کر سکتے۔
ایک ایکوسسٹم ایک پیچیدہ ایڈاپٹو سسٹم بھی ہے جو وقت کے ساتھ بڑھتی، تبدیل ہوتی اور ترقی کرتی ہے۔ ان میں ایک خصوصیت بھی ہوتی ہے جسے "اِمرجینٹ پراپرٹی" کہتے ہیں، یعنی وہ چیز جسے آپ کسی ایک الگ جزو کو دیکھ کر نہیں دیکھ سکتے، بلکہ جب پورا سسٹم اکٹھا ہو جائے تو اس کا رویہ ظاہر ہوتا ہے۔ بالکل اسی لیے مستقل تبدیلی، مستقل سیکھنا اور اِمرجینس کی وجہ سے ایک ایکوسسٹم میں کیا ہو رہا ہے، اسے سمجھنا بہت مشکل ہو جاتا ہے۔
اکوسسٹم کہنے پر آپ کے ذہن میں شاید پہاڑ، دریا، پرندوں کی چہچہاہٹ اور خوشگوار خوشبوآں تصور ہوتی ہیں۔ لیکن اندر کا ڈویلپر ماحول بھی ایک اکوسسٹم ہے: اس میں مختلف ٹولز اور سروسز ہیں، اپنے اپنے خیالات اور تقاضوں والے لوگ ہیں، اور کاروباری پابندیاں ہیں۔ اور یہ ایک خاص نظام ہے: سماجی تکنیکی نظام، جو انسانوں اور ٹیکنالوجی کے مل کر بنایا گیا نظام ہے۔ سماجی تکنیکی نظام بہت پیچیدہ ہوتا ہے، کیونکہ آپ تمام تکنالوجیوں سے شروع کرتے ہیں، پھر انسانوں کو بھی اس میں شامل کر دیتے ہیں۔
آپ نے شاید بغیر کسی خیال کے سماجی ٹیکنالوجی سسٹم کی حکمت عملی کو پہلے ہی محسوس کر لیا ہے۔ کیا آپ کونوی کا قانون جانتے ہیں؟: تنظیم جو ٹیکنالوجی بناتی ہے، وہ اس کی اندر کی مواصلاتی ساخت کا آئینہ دار ہوتی ہے۔ عام الفاظ میں، اگر آپ کے پاس ایک ہی کمپائلر پر چار ٹیمیں کام کر رہی ہوں، تو آپ کو ایک چار مرحلہ کمپائلر ملے گا، اور یہی بات ہے۔ کونوی کے قانون کا بنیادی مشاہدہ یہ ہے کہ ہم جس طرح ٹیکنالوجی بناتے ہیں، وہ اسے بنانے والی تنظیمی ساخت سے الگ نہیں ہو سکتی، تنظیم وہ چیز بناتی ہے جو آخرکار تعمیر ہوتی ہے۔
لیکن صرف ساخت ہی نہیں، بلکہ قیمتیں اور ثقافت بھی ڈیولپر ایکوسسٹم پر گہرا اثر ڈالتی ہیں۔ آپ کا ایکوسسٹم وہ چیز بناتا ہے جسے آپ کی تنظیم حوصلہ دیتی ہے، اور آپ کی انجینئرنگ ثقافت ڈیولپر ایکوسسٹم کے اردگرد ماحول تخلیق کرتی ہے۔ جب آپ سماجی ٹیکنیکل سسٹم کو سمجھ جائیں، تو آپ سافٹ ویئر ڈویلپمنٹ کے ہر کونے میں انہیں دیکھیں گے: آرکیٹیکچر، حادثات کے جائزے کی ثقافت، کوڈ ریویو، سیکورٹی پالیسیز—جو کچھ بھی۔ ہم جو چیزیں بناتے ہیں، اور ہم جس طرح انہیں بنانے کا انتخاب کرتے ہیں، وہ ہماری قدر کو ظاہر کرتا ہے۔ اگر ہم کافی توجہ دیں، تو ہم اس جانکاری کو استعمال کرکے اپنی قدرت کو بڑھا سکتے ہیں اور انہیں اپنی بنائی گئی چیزوں میں شامل کر سکتے ہیں۔
اب میں آپ کو ایک درست تعریف دے سکتا ہوں: سافٹ ویئر ایکولوجی وہ شعبہ ہے جو سافٹ ویئر کے پیداواری سماجی-تقنی نظام کا مکمل طور پر مطالعہ کرتا ہے۔ اگر پہلے کی باتیں کچھ انتزاعی لگیں، تو کوئی بات نہیں، اب ایک حقیقی معاملہ دیکھتے ہیں۔
گوگل کا ڈیولپر ایکوسسٹم
میں گوگل کے بارے میں بات نہیں کر رہا کیونکہ میں وہاں کام کرتا ہوں اور اس کی تعریف کر رہا ہوں، بلکہ کیونکہ یہ وہ ڈولپر ایکوسسٹم ہے جسے میں سب سے زیادہ جانتا ہوں۔ میرا مقصد یہ نہیں کہ آپ کو گوگل کی نقل کرنے کے لیے کہوں، کیونکہ اس سے آپ کو فائدہ نہیں ہوگا۔ آپ مختلف کمپنیاں ہیں، مختلف مراحل پر ہیں، اور مختلف توازن کے سامنے ہیں۔ گوگل جو بھی فیصلے کرتا ہے، وہ اس وقت کے لیے تھے جب ہم اپنا ایکوسسٹم تعمیر کر رہے تھے۔
کچھ سال پہلے ہم نے ایک کتاب لکھی، جس کا اندر کا نام "فلامنگو بُک" تھا۔ اس کتاب میں آدھا حصہ ورژن کنٹرول اور ٹیسٹنگ پر تھا، لیکن پورا پہلا حصہ انجینئرنگ کلچر پر مرکوز تھا۔ بہت سے لوگوں نے پوچھا کہ کلچر پر اتنی تفصیل کیوں دی گئی؟ کیونکہ اگر آپ Google کے کلچر کو نہیں سمجھتے، تو آپ ہمارے ان ٹیکنالوجی کے فیصلوں کو نہیں سمجھ سکتے جو ہم نے لیے، اور یہ چیزیں باہم جڑی ہوئی ہیں۔
گوگل کے کچھ منفرد ثقافتی خصوصیات ہیں۔ ہم گہرائی سے انجینئرنگ کی طرف مائل ہیں، اور اہم فیصلوں پر ہمیشہ انجینئرز موجود ہوتے ہیں؛ ہم شفافیت کو بہت اہمیت دیتے ہیں اور ممکنہ حد تک تمام دستاویزات اور کوڈ کو سب کے لیے کھلا رکھتے ہیں؛ ہم مددگاری کو فروغ دیتے ہیں، اصل میں جس کے ساتھ بھی گوگل چھوڑنے والے لوگوں سے بات کریں، ان کا پہلا ذکر زمینداروں کی مددگاری ہوگا؛ ہم کوڈ ریویو کو ایک رہنمائی کا موقع سمجھتے ہیں، نہ کہ امتحان کا جائزہ لینا؛ ہم معیاریت کو بہت اہمیت دیتے ہیں؛ ہم مستقل بہتری پر یقین رکھتے ہیں؛ ہم ذمہ داری سے آزاد انکشافات کو ترجیح دیتے ہیں؛ ہم یقین رکھتے ہیں کہ مستقل پن، ہیروئزم سے زیادہ اہم ہے، اور خودکاری، دستی محنت سے زیادہ اہم ہے۔ بالکل واضح ہے کہ ہم ہر اس خوبصورت خواہش کو پورا نہیں کرتے، لیکن یہ وہ راستہ ہے جس کی طرف ہماری ثقافت کے طور پر کوشش جاری رکھتی ہے۔
ٹیکنیکل پہلو کیا ہے؟ ایک منفرد کوڈ ریپوزٹری، جہاں تقریباً تمام کوڈ ایک ہی ریپوزٹری میں ہوتا ہے؛ مین برانچ پر ڈویلپمنٹ، جہاں ہر تبدیلی براہ راست مین برانچ میں ضم ہو جاتی ہے؛ جب آپ ایک بائنری فائل بناتے ہیں، تو تقریباً ہر لائن کوڈ سورس سے تعمیر ہوتا ہے؛ ایک یکسانہ بِلڈ ٹول چین، جس کا استعمال ہر کوئی کرتا ہے؛ عالمی ٹیسٹ آٹومیشن پلیٹ فارم، جہاں تمام ٹیسٹ ایک جگہ چلائے جاتے ہیں، روزانہ اربوں ٹیسٹ کیسز؛ ایک عالمی "آخری گرین" سگنل، جس کے ذریعے میں آپ کو ایک آسان اندر کی ویب سائٹ سے کسی بھی بِلڈ کی حالت بتا سکتا ہوں؛ ایک یکسانہ کمپوٹنگ ماحول، جس کے باعث "میرے ماشین پر کام کرتا ہے" جیسا مسئلہ تقریباً ناممکن ہو جاتا ہے؛ اعلیٰ معیاری ڈویلپر فریم ورک اور ایک چھوٹے سے مرکزی پروگرامنگ زبانوں کا مجموعہ۔
اس ثقافتی اور ٹیکنالوجی کے ملاپ نے گوگل کو آج کی شکل دی ہے، آپ نہ تو صرف ایک حصہ سمجھ سکتے ہیں اور دوسرے کو نظرانداز کر سکتے ہیں۔
مشترکہ قسمت
اگر مجھے ایک ایسا اصول منتخب کرنا ہو جو ہمیشہ ہماری رہنمائی کر رہا ہو، تو میں "مشترکہ قسمت (Shared Fate)" کو منتخب کروں گا۔ یہ ایک ایکوسسٹم اور اس کے اجزاء کے درمیان تنگ تعلق کی وضاحت کرتا ہے، جہاں ایک ایکوسسٹم میں ایک اجزاء دوسرے تمام اجزاء کو متاثر کر سکتا ہے۔ ڈویلپر ایکوسسٹم میں، مشترکہ قسمت ایک ٹیکنالوجی کا انتخاب ہے اور ایک سماجی انتخاب بھی۔ آپ صرف یہ کر کے مشترکہ قسمت حاصل نہیں کر سکتے کہ سب کو ایک ہی ٹیکنالوجی استعمال کرنے کے لیے مجبور کر دیں، آپ کو ان ٹیکنالوجیز کے منظم کرنے کے طریقے پر ایک سماجی معاہدہ بھی قائم کرنا ہوگا۔
گوگل پر، مشترکہ قسمت ایک منفرد کوڈ ریپوزٹری سے شروع ہوتی ہے۔ کمپنی کی ہر لائن کوڈ، صرف کچھ استثنائات جیسے اینڈرائیڈ اور کروم کے علاوہ، ایک مشترکہ ریپوزٹری میں ہوتی ہے۔ تمام کوڈ مین ٹرنک پر ڈالا جاتا ہے، کوئی برانچ نہیں، کوئی ورژن نمبر نہیں، سب کچھ ایک جگہ پر ہوتا ہے۔ اس مشترکہ قسمت کی وجہ سے ہم ایک فائل میں ایک سیکورٹی پچ لگا سکتے ہیں اور جانتے ہیں کہ ایک ہفتے کے اندر کمپنی کا ہر ایپلیکیشن درست ہو جائے گا۔ ایک ارب لائن کوڈ کو صرف دس لائن کے پچ سے درست کرنا، ایک سپر پاور کی طرح ہے۔
لیکن مشترکہ قسمت ہمیشہ اچھی بات نہیں ہوتی، یہ ایک انتخاب ہے۔ کچھ جگہوں پر مشترکہ قسمت مناسب نہیں ہے، جیسے پروڈکشن ماحول میں، ہم کبھی بھی ایسا نہیں چاہتے کہ ایک سروس دوسرے تمام سروسز کو ڈوبوائے، یا ایک کلัสٹر پورے علاقے کو متاثر کرے۔ اس لیے ہم نے خطرناک مشترکہ قسمت سے بچنے پر بہت زیادہ توجہ دی ہے، وہ مشترکہ قسمت جو سلسلہ وار خرابیوں کا باعث بن سکتی ہے۔ مشترکہ قسمت ایک توازن ہے، آپ کو صحیح جگہ منتخب کرنی ہوگی اور پھر یقینی بنانا ہوگا کہ یہ آپ کے لیے کام کر رہی ہے۔
بڑے پیمانے پر تبدیلی
ہمارے مشترکہ نصیب کے ماحول میں سب سے دلچسپ طور پر ظاہر ہونے والی خصوصیات میں سے ایک بڑے پیمانے پر تبدیلی ہے۔ اس بات کو نوٹ کریں: AI کے ظہور سے بہت پہلے، Google کے اندر کے ٹولز ایک ڈویلپر کو لاکھوں لائنز کو تبدیل کرنے کی صلاحیت دے چکے تھے، لاکھوں لائنز جنہیں وہ کبھی نہیں پڑھتے، کبھی دوبارہ نہیں دیکھتے، اور جن کے بارے میں وہ شاید بالکل بھی نہیں جانتے۔ ہم نے ایسے ٹولز تعمیر کیے جن کی مدد سے یہ سب خودکار طور پر ممکن ہو گیا، آج بھی یہی صورت ہے، اور ہم کم از کم پچھلے پندرہ سالوں سے ایسا ہی کرتے آ رہے ہیں۔
یہ صلاحیت ہمیں منفرد کوڈ ریپوزٹری کو مستقل طور پر ترقی دینے، زبانوں اور فریم ورکس کو اپ ڈیٹ کرنے، اور اندرونی ماحول کو سخت اور بے حرکت ہونے سے روکنے کی اجازت دیتی ہے۔ بے جا نہیں کہہ سکتے کہ بڑے پیمانے پر تبدیلیوں کے بغیر ہم آج کا Google نہیں ہوتے۔ ان ٹولز کو تیار کرنے والے ساتھی ایک پس منظر کے ہیرو کا کام کرتے ہیں، جس سے کمپنی کو درکار رفتار سے آگے بڑھنے کی اجازت ملتی ہے۔
لیکن اصل بات یہ ہے کہ اگر آپ وہ ثقافتی اور ٹیکنالوجی کے اجزاء نہیں سمجھتے جو بڑے پیمانے پر تبدیلیوں کو ممکن بناتے ہیں، تو آپ اسے حقیقت میں نہیں سمجھ سکتے۔ آپ کو کیا چاہیے؟ عام ٹیسٹنگ کی ثقافت، جس میں ہر کوئی ٹیسٹ لکھے۔ ایک یکساں ٹیسٹنگ پلیٹ فارم، جہاں آپ نتائج حاصل کرنے جاتے ہیں۔ مشترکہ بِلڈ ٹولز، جس سے آپ کا بِلڈ میرے بِلڈ کے برابر ہو۔ معیاری لائبریریاں، جس سے کمپوننٹس کو تبدیل کرتے وقت آپ کو یہ نہیں پتہ چلے کہ کون سا ورژن آپ کے لیے کام کرتا ہے اور میرے لیے نہیں۔ معیاری کوڈ ریویو، اور کوڈ ریپوزٹری کی شفافیت، تاکہ آپ جان سکیں کہ کون سا کوڈ تبدیل کرنے کی ضرورت ہے۔ بڑے پیمانے پر تبدیلی Google کے "آٹومیشن برتر ہے" کے خیال کا آخری اظہار ہے، اور یہ صرف اس صورت ممکن ہے جب پورا生态系统 مل کر کام کرے۔ آپ کسی بھی ایک حصے کو اشارہ کرکے نہیں کہہ سکتے کہ یہی وجہ ہے—تمام حصے آپس میں جڑے ہوئے ہیں۔
آپ کا ایکوسسٹم، آپ کا توازن
ہر ڈیولپر ایکوسسٹم میں ایسی نمٹنے والی خصوصیات ہوتی ہیں۔ وہ عام طور پر وہ چیزیں ہوتی ہیں جو آپ کو احساس دلاتی ہیں کہ آپ جہاں کام کرتے ہیں، وہ کچھ خاص ہے، کیونکہ وہ آپ کے کئے گئے انتخابات کا نتیجہ ہیں۔
گوگل کے ڈیولپر ایکوسسٹم نے اپنے ٹیکنالوجی اور بزنس مقاصد کے لیے ایک منفرد توازن پیدا کیا ہے۔ لیکن ہر ایکوسسٹم کی طرح، یہ تمام کاموں پر بہترین نہیں ہو سکتا۔ ہم نے انتہائی سائز، سیکورٹی اور پرفارمنس کو بہتر بنانے کا فیصلہ کیا ہے، چاہے اس کے لیے کبھی کبھار ڈیولپر پیداواریت کو متاثر ہونا پڑے—ہم اس توازن کو قبول کرتے ہیں۔ ایک پانچ افراد کی اسٹارٹ اپ کا ایکوسسٹم بالکل مختلف نظر آئے گا، جہاں رفتار اور لچک سب سے اہم ہوں گی۔
آپ میں سے زیادہ تر لوگوں کا ایکسیس پانچ افراد اور دو لاکھ کے درمیان ہے۔ آپ کو جو توازن برقرار رکھنا ہے، وہ بہت اہم ہے، کیونکہ جب آپ ان توازنات کو دیکھتے ہیں، تو آپ سمجھنے لگتے ہیں کہ اس تنظیم کی حقیقی قیمتیں کیا ہیں—وہ کیا سچ مچ پر اہمیت دیتی ہے، نہ کہ صرف الفاظ میں کہتی ہے، بلکہ آپ کے مشاہدے سے ظاہر ہونے والے انتخابات کیا بتاتے ہیں۔ جب آپ ان قیمتوں کو سمجھ جائیں، تو آپ اس طرح کے تبدیلی کو شکل دینا شروع کر سکتے ہیں۔
10 گنا کا وقت: ہر نوڈ دباؤ میں ہے
اب اس کمرے میں موجود اُس ٹوکن کھانے والے ہاتھی کے بارے میں بات کرنے کا وقت آ گیا ہے: ایک AI فرسٹ ڈویلپر ایکوسسٹم کیسے دکھائی دیتا ہے؟
صفر سے ایک مکمل نیا ایکوسسٹم تعمیر کرنا ضرور اچھا ہے، لیکن آپ میں سے کوئی بھی اس کا لطف نہیں اٹھا سکتا۔ آپ کو اپنے نرم افزار کو جاری رکھتے ہوئے اس کے تقریباً ہر حصے کو تبدیل کرنا ہوگا۔ کمپنی آپ سے یہ امید کرتی ہے کہ آپ مسلسل قیمت پیدا کرتے رہیں اور ساتھ ہی کوئی مسئلہ نہ ہونے دیں۔
اپنے آپ سے ایک سوال پوچھیں: آپ اپنے آج کے ڈیولپر ایکوسسٹم کے بارے میں کتنا جانتے ہیں؟ کیا آپ اسے مکمل طور پر نقشہ بناسکتے ہیں؟ کیا آپ جانتے ہیں کہ تمام اجزاء کہاں ہیں، صرف ٹیکنالوجی کے نہیں، بلکہ سماجی پہلوؤں کے بھی؟ کیا آپ اپنے ایکوسسٹم کو کیا بنایا جاتا ہے، اس کی فہرست بناسکتے ہیں؟ آپ کے ادارے کے دوسرے افراد کو کتنا معلوم ہے؟ اس کے فوائد اور نقصانات کیا ہیں؟ کن حدود پر رکاوٹیں ہیں؟ کہاں پابندیاں ہیں اور کہاں آزادی ہے؟ آپ کے پاس کتنی چونس ہیں؟ آپ نے کن ظاہر ہونے والی خصوصیات دیکھی ہیں؟ شاید سب سے اہم بات: اگر آپ کا ایکوسسٹم اگلے انٹھائی ماہوں میں 10 سے 15 گنا زیادہ کوڈ کا تبادلہ کرنے کے لیے مجبور ہو جائے، تو آپ جانتے ہیں کہ کون سا حصہ سب سے پہلے خراب ہو جائے گا؟
ہر ایک ڈیولپر ایکوسسٹم زمین پر ایک جڑ سے تبدیلی کا تجربہ کر رہا ہے، شاید یہ ابھی تک آپ کے ہر کونے تک نہیں پہنچا ہے، لیکن یہ آ رہا ہے، اور ہر ڈیولپر ایکوسسٹم کو اس 10 گنا کے لمحے کا سامنا کرنا پڑے گا۔ یہ ایک حیرت انگیز دور ہے، لیکن کافی پریشان کن بھی۔ گزشتہ پچاس سالوں میں ہم نے جو تمام توازن کو جان بوجھ کر ترقی دیا ہے، وہ دوبارہ ترتیب دیا جائے گا۔
کوڈ تیار کرنا 10 گنا تیز اور انجینئرنگ ترقی 10 گنا تیز کرنا، دو الگ باتیں ہیں۔ گوگل میں ہم عام طور پر کہتے ہیں کہ انجینئرنگ وقت کے ساتھ ایک ادھار ہے۔ لیکن مسئلہ یہ ہے کہ ہم اب کوڈنگ کو بہت زیادہ تیز کر رہے ہیں اور کوڈ مشین کو تیز کر رہے ہیں۔ اس لیے ہمیں اس کوڈ مشین کے اردگرد انجینئرنگ کا بہتر طریقہ تلاش کرنا ہوگا تاکہ ہم حقیقی طور پر صارفین کو نتائج فراہم کر سکیں۔ کوئی نہیں جانتا کہ یہ پیداوار میں اضافہ کتنے دور تک جائے گا، لیکن ایک بات یقینی ہے: ہم اس جگہ سے اوپر کی طرف جا رہے ہیں۔
مسئلہ یہ ہے کہ آج ہم جس طرح سافٹ ویئر بناتے اور فراہم کرتے ہیں، وہ 10 گنا یا 100 گنا رفتار سے کام نہیں کرے گا، کچھ چیزیں تبدیل ہونی ضروری ہیں۔
آئیے ایک سادہ شکل کے ڈیولپر ایکوسسٹم کے نقشے سے شروع کرتے ہیں۔ ایک ایسی دنیا میں جہاں سرگرمی 10 گنا بڑھ جائے، کیا تبدیل ہونا ضروری ہے؟
کوڈ انٹری
کوڈ لکھیں۔ اگر ہر کوئی کوڈ لکھنے میں بہت تیز ہو جائے، تو کوڈ کی مقدار بہت زیادہ ہو جائے گی، جو اچھی بات نہیں ہے۔ جیف اٹوڈ نے کہا تھا کہ سافٹ ویئر ایک ذمہ داری ہے۔ اس لیے، 10 گنا کوڈ، 10 گنا ذمہ داری۔ اور آپ کسی کو بس کچھ ٹوکن دے کر “خوش قسمت رہیں” نہیں کہہ سکتے، میں چاہتا ہوں کہ آپ تربیت کے بعد سرمایہ کاری کریں: آپ کے انجینئرنگ پریکٹس ڈاکیومنٹ کہاں ہیں؟ انہیں کیسے ترقی دیں؟ اس کے بعد سوچیں۔
سسٹم بنائیں۔ زیادہ کوڈ، بڑا سسٹم کا مطلب ہے لمبی کمپائلیشن کا وقت۔ میں یقین کے ساتھ کہہ سکتا ہوں کہ آپ کی کمپنی میں اب تک کسی نے کمپائلیشن کی تیزی پر شکایت نہیں کی ہے۔ لیکن اس بات کا اندازہ لگائیں، یہ اور بھی سست ہو جائیں گی۔ اور اگر ایجنٹ بہت زیادہ کام چلا رہا ہے، تو کمپائلیشن کی تعداد بھی تیزی سے بڑھ رہی ہے۔ کمپائلیشن وقت اور کمپوٹیشنل وسائل دونوں پر مفت نہیں ہوتی۔ شاید آپ نے کبھی نہیں دیکھا کہ آپ کتنے وقت کمپائلیشن پر خرچ کرتے ہیں، لیکن 10 گنا سائز پر آپ ضرور نوٹ کریں گے۔
کوڈ ڈیزائن۔ کیا آپ کے پاس الگ الگ صلاحیتوں کو فروغ دینے کے لیے مناسب ایجنٹ بنیادی مہارتیں ہیں؟ کیا آپ کے پاس مختلف صلاحیتوں کو تیزی سے اور محفوظ طریقے سے جوڑنے کے لیے مناسب سرور فریم ورک ہے؟ کیا آپ جانتے ہیں کہ آپ کی کمپنی میں ویب ایپلیکیشنز کے کتنے طریقے ڈپلوائمنٹ کیے جاتے ہیں؟ کتنے مختلف سرور فریم ورکس چل رہے ہیں؟ آپ ایجنٹس کے لکھے گئے کوڈ کے کمپوننٹس کی دوبارہ استعمال کو کیسے منظم کرتے ہیں؟ شاید آپ یہ سوچ رہے ہیں کہ یہ اہم نہیں۔ لیکن اگر ایجنٹس ایسے کوڈ لکھ رہے ہیں جو لکھنے میں آسان ہیں لیکن برقرار رکھنا مشکل ہے، تو اس سے حیران نہ ہوں — یہ موجودہ معیار ہے۔ ایجنٹس کوڈ لکھنے میں ماہر ہیں، لیکن وہ ہمیشہ لمبے مدت کے منظر کو نہیں سوچتے۔ میں یقین کرتا ہوں کہ وہ کوڈ اچھی طرح سے ریفیکٹر نہیں ہوگا۔ کوئی بات نہیں، ہم اس حصے کو مستقبل میں حل کر لینگے۔ لیکن حقیقت یہ ہے کہ ایجنٹس ہمارے لیے بہت زیادہ کام کر رہے ہیں، اور ہمیں روزانہ ان صلاحیتوں کو سب سے زیادہ موثر طریقے سے استعمال کرنے کا طریقہ تلاش کرنا ہوگا۔
کبھی نہ کبھی، یہ ایجینٹائزڈ کام آپ کے بائنری فائل کو اتنے بڑے بنادیں گے کہ اسے کمپائل نہیں کیا جا سکے۔ یا پھر اتنے بڑے کہ فون پر اپ لوڈ نہیں کیا جا سکے۔ کیا آپ نے کبھی یہ سوال پوچھا ہے: آپ کا سب سے بڑا کمپائل کیا جانے والا بائنری کتنا بڑا ہو سکتا ہے؟ مجھے جواب نہیں معلوم، لیکن میں جانتا ہوں کہ گوگل میں ہم حد تک پہنچ چکے ہیں، اور کچھ جگہوں پر بائنری اتنے بڑے ہو چکے ہیں کہ انہیں کمپائل نہیں کیا جا سکتا، میں یقین رکھتا ہوں کہ ہم اس کا حل نکال لیں گے۔ لیکن حقیقت یہ ہے کہ بڑے پیمانے پر بہت سارے متعدد اثرات ہوتے ہیں، اور سائز کا اثر ہر جگہ محسوس ہوتا ہے۔
شاید آپ مائیکروسروسز ٹیکنالوجی اسٹیک کے استعمال کر رہے ہیں اور سوچ رہے ہیں: میری تمام سروسز بہت چھوٹی ہیں، میں کیوں فکر کروں؟ لیکن میرا ایک سوال ہے: 10 گنا نیٹ ورک ٹریفک، 10 گنا سروسز کی تعداد، 10 گنا مواصلات، کیا آپ تیار ہیں؟ کوئی بھی scale کے اثرات سے بچ نہیں سکتا۔
کوڈ ریویو۔ اگر آپ یہ سارا کوڈ قابل اعتماد طریقے سے کمپائل نہیں کر سکتے، تو آپ کا کوڈ ریویو عمل کیسے ہوگا؟ ہر کوئی کوڈ ریویو کے بارے میں فکرمند ہے، اور اس کا ایک اچھا سبب ہے۔ ہم اس بہت انسانی عمل پر بہت زیادہ دباؤ ڈال رہے ہیں، جس کے بہت سے معاملات میں یہ رکاوٹ بن چکا ہے، اور لوگوں کو رکاوٹ بننا پسند نہیں۔ جب آپ ان پر دباؤ ڈالتے ہیں، تو وہ عجیب طریقے سے رویہ کرتے ہیں۔ 10 گنا کوڈ کی مقدار، آپ کو یا تو 10 گنا بڑے تبدیلیاں ملتی ہیں، یا پھر 10 گنا زیادہ تبدیلیاں۔ آپ کا ٹیکنیکل لیڈر ضروری ریویو کی رفتار برقرار رکھ سکتا ہے؟ زیادہ تر ٹیکنیکل لیڈرز صرف پانچ 10 گنا ڈولپرز کے ایک دن کے کوڈ کو بھی ریویو نہیں کر پاتے۔
اس لیے وہ بلکل بھی بند راستہ نہ بننے کے لیے پروسیس کو دوبارہ ترتیب دینا شروع کر دیتے ہیں، راستوں کو مختصر کر دیتے ہیں، اور یقینی بناتے ہیں کہ کوئی بھی مسدود نہ ہو، کیونکہ کوئی بھی مسدود بننا نہیں چاhta۔ آپ شاید AI کے ذریعے اس کا ایک حصہ حل کر سکتے ہیں، AI کو ڈپلوی کر کے کوڈ ریویو میں بہتری لائی جا سکتی ہے۔ لیکن یہ صرف ایک حصہ ہے، کیونکہ اگر آپ کے ٹیم ممبرز کوڈ نہیں لکھتے، تو ان کا کوڈ سے واحد ملاقات کا وقت ریویو کے وقت ہوتا ہے، اور اگر ریویو کے دوران توجہ کم ہو، تو کوڈ بیس کے ترقی پر کون نظر رکھ رہا ہے؟ کوئی نہیں۔ جلد ہی آپ کا کوڈ بیس ایک ایسا بھاری اور غیر سمجھنے والا ڈھیر بن جائے گا جسے کوئی بھی نہیں سمجھ سکتا۔
ٹوکن معاشیات۔ ٹوکن مہنگے ہیں، آپ میں سے کچھ لوگ پہلے ہی جانتے ہیں۔ بڑے پیمانے پر، ٹوکن ایک ایسا اصل خرچ ہے جسے آپ کو مدنظر رکھنا چاہیے۔ اگر کمپنی میں ہر کوئی 10 گنا یا 100 گنا ٹوکن استعمال کرنے لگ جائے تو کیا ہوگا؟ اگر آپ غلطی سے ایک دن میں پورے ماہ کا بجٹ خرچ کر دیں تو؟ اگر آپ کو فیصلہ کرنا ہو کہ ٹوکن کہاں خرچ کرنے ہیں، تو آپ جانتے ہیں کہ کہاں ترجیح دینی چاہیے؟ کیا آپ کو یہ دیکھنے کا کوئی اندازہ بھی ہے کہ ٹوکن کہاں جا رہے ہیں؟
صرف اس سادہ سسٹم کے پہلے کچھ نوڈس میں، ہم نے مسائل پہلے ہی دریافت کر لیے ہیں۔ اور بہت واضح ہے کہ کچھ چیلنجز کا دوسرا درجہ کا اثر ہوگا۔
ٹیسٹنگ اور ورژن کنٹرول
کیا آپ نے کبھی دیکھا ہے کہ آپ کی ٹیسٹ انفراسٹرکچر کتنے کمپیوٹیشنل وسائل استعمال کرتی ہے؟ گوگل پر، میں نے کبھی اپنی ٹیسٹنگ کی رفتار سے خوش نہیں ہوا۔
ہر ورژن کنٹرول میں داخل کیا جانے والا تبدیلی کا ٹیسٹ کیا جانا چاہیے۔ لیکن اس کے علاوہ، ایجینٹ ٹیسٹ چلانا پسند کرتے ہیں کیونکہ ٹیسٹ انہیں بتاتے ہیں کہ وہ اپنا کام کیسے کر رہے ہیں۔ اس لیے ایجینٹ نے اضافی کام پیدا کیا، جس سے میرا کام زیادہ ہو گیا۔ تو، 10 گنا زیادہ سبمٹس اور ایجینٹ کے ذریعے کیا گیا تمام کام، اب کتنے ٹیسٹ کمپوٹیشنل وسائل استعمال کر رہا ہے؟
واقعیت میں صورتحال زیادہ بگڑ سکتی ہے۔ ہم نے گوگل پر دیکھا ہے کہ جب کوڈ بیس بڑھتا ہے، تو انحصار کا گراف مربعی طور پر بڑھتا ہے، لکیری نہیں۔ اس لیے اگر آپ کا کوڈ بیس 10 گنا بڑھ جائے، تو آپ کو صرف 10 گنا ٹیسٹ نہیں بلکہ 100 گنا یا 1000 گنا ٹیسٹ چلانے پڑ سکتے ہیں۔ یہ ایک بہت دلچسپ چیلنج ہوگا، اور یہ کسی نہ کسی وقت آپ کے بجٹ میں ایک آئٹم بن جائے گا۔ اگر آپ ابھی ٹیسٹ کے کمپوٹیشنل وسائل پر خرچ کے بارے میں فکر نہیں کر رہے، تو میرے لیے وہ زیادہ فکر کا باعث ہے، کیونکہ اس کا مطلب ہے کہ شاید آپ کے پاس کافی ٹیسٹ نہیں ہیں، اور وہ ایجینٹس اپنے کوڈ بیس میں بنا کسی سیفٹی نیٹ کے YOLO کر رہے ہیں۔
اگر کمپائل اور ٹیسٹنگ کے مسائل حل ہو گئے ہیں، تو اب ورژن کنٹرول سسٹم پر نظر ڈالیں۔ زیادہ تر مقبول ورژن کنٹرول سسٹمز کو صرف پرفارمنس کے لیے نہیں بنایا گیا ہے؛ وہ ایک مسلسل اور ترتیب دار نظام کے لیے ڈیزائن کیے گئے ہیں۔ یہ ان کا اصل کام ہے — مکمل ریکارڈ رکھنا، نہ کہ تیزی سے دوڑنا۔ آپ کا ورژن کنٹرول سسٹم منٹ میں کتنی بار کامیٹس کھا سکتا ہے؟ میں آپ کو یقین دلاتا ہوں کہ آپ جو سوچ رہے ہیں اس سے کہیں کم۔ یہ آپ کی ضرورت کے مطابق 10 گنا تیزی سے اسکیل نہیں ہو سکتا۔ آپ نے آخری بار ورژن کنٹرول سسٹم کی پرفارمنس کے بارے میں کب سوچا؟ اگر آپ Git ڈویلپر نہیں ہیں، تو شاید کبھی نہیں سوچا۔ سچ بولوں تو، ورژن کنٹرول پرفارمنس پر بات کرنے تک پہنچ جانا اس بات کا علامہ ہے کہ کچھ اہم چیزیں بہت زیادہ گڑبڑ چکی ہیں۔ ہم ڈویلپر تجربے کے سب سے نچلے لیول پر ہیں، لیکن یہی سسٹمک تبدیلیوں کا نتیجہ ہے: وہ آپ کے سسٹم کے ہر کونے میں آتی ہیں اور کہتی ہیں، ائے، آپ نے توجہ دی؟ کیونکہ آپ نے جو کچھ متوقع نہیں کیا، وہ آ رہا ہے۔
جس کسی کے پاس بہت سارے چھوٹے ریپوزیٹریز کے ساتھ ورژن کنٹرول کا مسئلہ حل کرنے کا ارادہ ہے، وہ کسی ایسے شخص سے پوچھیں جس نے سینکڑوں یا ہزاروں چھوٹے ریپوزیٹریز چلائے ہوں، میں آپ کو یقین دلاتا ہوں کہ یہ صرف ایک نئی سیریز چیلنجز ہے، اور AI ان مسائل کو ضروری طور پر آسان نہیں بنائے گا۔
غیر متوقع فہرست
اب تک ہم صرف ان نسبتاً آسان پائے جانے والے کیپیسٹی نوڈس پر غور کر رہے ہیں، جن میں ایک عدد کو 10 سے ضرب دے کر پوچھا جاتا ہے کہ اس سے بہتر ہوگا یا بگڑے گا، اور ابھی بھی کئی غیر متوقع چیلنجز ہیں۔
اسٹریٹجی کی تصدیق کریں۔ آج آپ کی تصدیق زیادہ تر یونٹ ٹیسٹنگ اور کچھ انٹیگریشن ٹیسٹنگ پر مشتمل ہے۔ لیکن 10 گنا کوڈ اور 10 گنا سروسز کی دنیا میں، انٹیگریشن ٹیسٹنگ کوالٹی اسٹریٹجی کا سب سے اہم حصہ بن جائے گا۔ آپ میں سے کتنے لوگ اپنی آج کی انٹیگریشن ٹیسٹنگ اسٹریٹجی سے خوش ہیں؟ میں بھی خوش نہیں ہوں۔ انٹیگریشن ٹیسٹنگ واقعی مشکل ہے، اور میرے پاس ابھی تک وہ ٹولز نہیں ہیں جو میں چاہتا ہوں کہ میں انٹیگریشن ٹیسٹنگ کو اس طرح کروں۔
بولیئن کانجکشن کا مسئلہ۔ آج آپ سافٹ ویئر جاری کر رہے ہیں، اور آپ چاہتے ہیں کہ ہر ٹیسٹ کامیاب ہو، تمام بولیئن گرین ہوں، اور صرف اس صورت میں جاری کریں جب سب کچھ ٹھیک ہو—یہ منطقی بات ہے۔ لیکن جب آپ کے پاس ایک ملین ٹیسٹ ہوں اور بنیادی ٹیسٹ انفراسٹرکچر کا اپنے آپ میں ایک ملین ٹیسٹس چلانے کا قابل اعتماد طریقہ نہ ہو، تو کیا ہوگا؟ شاید سافٹ ویئر جاری کرنے کے لیے تمام بولیئن کو سچا ہونا ضروری ہونا بند ہو جائے۔ آپ کو ایک نئی حکمت عملی کی ضرورت ہوگی، جو شاید احصائی طریقے پر مبنی ہو، تاکہ آپ فہرست میں سے کون سے ٹیسٹ درست ہیں اور انہیں چلانے چاہئیں، کیونکہ آپ تمام ٹیسٹس نہیں چلا سکتے۔
بہت بڑا تبدیلی۔ جہاں دوبارہ ڈیزائن کرنا، زبان اور فریم ورک تبدیل کرنا ممکن ہو، واقعی دلچسپ ہے۔ لیکن کیا آپ کے پاس ایسا عملی عمل ہے اور سماجی معاہدہ ہے جس سے لوگوں کو لاکھوں، دس لاکھوں، کروڑوں لائنوں کے ملائی کنفلاکٹس کو مینیج کرنے میں مدد ملے؟ شاید نہیں۔ اگر کمپنی میں ہر کوئی بہت بڑی تبدیلیاں کر سکتا ہے، تو ہمیں نئے عملی عمل کی ضرورت ہوگی۔
ایجینٹ کی تحریر کی جنگ۔ ایک ایجینٹ نے تبدیلی کی، دوسرا ایجینٹ آیا اور کہا، نہیں، مجھے پسند نہیں، میں ایک مختلف تبدیلی کروں گا۔ اسے دیکھ کر مزہ آ رہا ہے، جب تک کہ آپ کو احساس نہیں ہوتا کہ آپ دونوں طرفوں کے لیے ٹوکن فیس ادا کر رہے ہیں۔
شیڈولنگ۔ آپ اپنے صارفین کو آج کتنی بار اپ ڈیٹ کرتے ہیں؟ روزانہ؟ یہ کافی اچھا ہے۔ اگر نہیں، تو یہاں ایک مسئلہ ہے: آپ کو 10 گنا زیادہ سافٹ ویئر ملے گا جو کہ کہیں نہ کہیں ڈالنا ہوگا۔ اگر آپ روزانہ اپ ڈیٹ نہیں کرتے، تو ہر تبدیلی بہت بڑی ہو جائے گی۔ اور میرے SRE دوست آپ کو بتائیں گے کہ بہت بڑی تبدیلیاں بہت خوفناک ہوتی ہیں۔ اس طرح نہ کریں۔ لیکن کوڈ کو اقدار پیدا کرنے کے لیے ڈپلوی کرنا ضروری ہے، اس لیے شاید آپ زیادہ اکثر اپ ڈیٹ کرنے کی کوشش کریں گے، جو بہت اچھا ہے، DORA کے دوست خوش ہو جائیں گے۔ لیکن ایک نقطے پر فائدہ کم ہونا شروع ہو جائے گا، فی سیکنڈ اپ ڈیٹ کرنا شاید آپ کو زیادہ فائدہ نہ دے۔ کوڈ بڑھتے رہے گا، اور آپ کو اسے کہاں رکھنا چاہیے اس بات کا پتہ لگانا ہوگا تاکہ مزید خطرات نہ پیدا ہوں۔
اندرونی API۔ میں اپنے ساتھیوں کو ہمیشہ یہی کہتا رہا ہوں کہ آپ کے تمام API اچانک عوامی ہو گئے ہیں۔ ایجنٹ آپ سے مشورہ نہیں کرے گا، یہ API تلاش کرے گا اور براہ راست کال کرے گا۔ جو کچھ بھی اس تک پہنچ سکتا ہے، وہ استعمال کرے گا، میں آپ کو ضمانت دیتا ہوں۔ اگر آپ نے کبھی اندرونی انٹرفیس اور اندرونی ڈیٹا سیٹس کو عوامی API کی طرح مضبوط نہیں بنایا، تو ایجنٹ وہ چیزیں تلاش کرے گا جنہیں آپ نہیں چاہتے کہ وہ تلاش کریں۔
جیونز کا متناقضہ۔ جیونز کہتے ہیں کہ جتنا زیادہ کسی وسائل کی قیمت سستی اور اس کا استعمال موثر ہوگا، ہم اسے اتنی زیادہ استعمال کریں گے۔ ٹوکن کا بھرپور افراط اس کا زندہ مثال ہے۔ ہم انہیں ہر جگہ لگا رہے ہیں، جس سے ہمارے کام کرنے اور کام کے بارے میں سوچنے کا طریقہ تبدیل ہو رہا ہے۔ ہم پہلے جو ناپید پیداواری محنت تھی، اسے قیمت دے رہے ہیں، اور اس سے ہمارے رویوں پر کیا اثر پڑے گا؟ میرا ابھی تک پتہ نہیں۔
واپس جائیں۔ آپ جانتے ہیں کہ آج واپس جانا بنیادی طور پر کیوں ممکن ہے؟ کیونکہ آپ سافٹ ویئر جاری کرنے کی رفتار، پیداواری ماحول میں مسائل کے پتہ چلنے کی رفتار سے تھوڑی سی سست ہے۔ اگر آپ اتنا بہت تیز سافٹ ویئر جاری کر سکیں کہ آپ کو کوئی مسئلہ پتہ چلے ہی نہیں، تو آپ کا واپس جانے کا انداز کیا ہوگا؟ ہر واپس جانے کو اس کے اوپر جمع ہونے والے متعدد متصادم تبدیلیوں کا سامنا کرنا پڑے گا۔ اس لیے صرف تیز جاری کرنا کافی نہیں، آپ کو پورے نظام کو، جس میں واپس جانا ایک اہم سیفٹی ویل بھی شامل ہے، سمجھنا ہوگا۔ بالواسطہ، آپ کو احتیاط سے ٹوکن انجن کو کہاں رکھنا ہے۔ اگر آپ کا واپس جانے کا عمل اس ایجینٹ پر منحصر ہے جس کے پاس کافی کھانا ہو، اور پہلے کسی نے اس ایجینٹ کا ٹوکن بجٹ ختم کر دیا ہو، جس کی وجہ سے آپ اب واپس نہیں جا سکتے، تو یہ شاید اچھا نہیں ہوگا۔
ہر کوئی ایک تعمیر کرنے والا ہے۔ شاید آپ نے کبھی سوچا ہو کہ کمپنی میں وہ ٹول جس سے آپ کو پسند نہیں، اس کا کوئی متبادل بنائیں۔ اب، اسے کمپنی کے ہر فرد اور ہر ٹول سے ضرب دیں۔ جب ہر کوئی مکمل طور پر مختلف ٹولز استعمال کر رہا ہو، تو کمپنی کی سماجی بناوت کیا ہوگی؟ اگر آپ کو خوش قسمتی سے ایک یکسانہ ڈیٹا بنیاد مل گئی ہو جس میں تمام ڈیٹا ایک جگہ جمع ہو رہا ہو، تو یہ اچھا ہے۔ لیکن اگر نہیں؟ ہر کوئی ایک تعمیر کرنے والا ہونا بہت عمدہ ہے، جب تک کہ آپ کو ان سب کے ذریعے بنائے گئے تمام چیزوں کو برقرار رکھنا نہ ہو۔
ٹیکنیکل لیڈرشپ کا تیز ترین کورس۔ ایک ٹیکنیکل لیڈر بننے میں اتنی دیر کیوں لگتی ہے؟ کیونکہ آپ کو فیصلے لینے کے لیے انٹیویشن، ججمنٹ اور ماہرینہ کا انباہ جمع کرنا پڑتا ہے، کیونکہ جب آپ ایک ٹیم کی قیادت کرتے ہیں تو آپ کی غلطیوں کا اثر آپ کے اکیلے کام کرنے سے بہت زیادہ ہوتا ہے۔ جب ایک نئے فارغ التحصیل کو ایک ایسا ماحول ملتا ہے جہاں وہ پچاس ایجنٹس کو فون کر سکتا ہے، لیکن اس کے پاس کوئی انٹیویشن یا ججمنٹ نہیں ہے، تو کیا غلط ہو سکتا ہے؟ میں ان دس سالوں کا تجربہ چھ ماہ میں کیسے سکھا سکتا ہوں؟ مجھے نہیں معلوم۔
انسانی توجہ ہمارے پاس سب سے قیمتی وسائل میں سے ایک ہے۔ اب بہت زیادہ شور ہے، بہت سارے ایجنٹ اور بہت سی چیزیں ہماری توجہ کے لیے مقابلہ کر رہی ہیں، اور ہمیں اس کا انتظام کرنے کا طریقہ تلاش کرنا ہوگا۔ ہم پہلے اس حقیقت سے فائدہ اٹھا رہے تھے کہ ہماری طرف سے مسائل پیدا کرنے کی صلاحیت ہماری توجہ دینے کی صلاحیت سے زیادہ نہیں ہوتی تھی، لیکن اب یہ حالت نہیں رہی۔
یہ بہت زیادہ لگ رہا ہے، کیونکہ ایک سسٹم میں، سب کچھ جڑا ہوا ہے۔ میں نے جو بھی چیلنجز کا ذکر کیا، آپ ان میں سے کسی بھی ایک کو صرف سسٹم کے ایک نوڈ کو دیکھ کر حل نہیں کر سکتے، آپ کو پورے سسٹم کو دیکھنا ہوگا۔
agent پر مبنی ڈیویلپمنٹ کے مطابق ہونے کے لیے، ہمیں سب کو لازماً سسٹمی انداز میں مسلسل سوچنا سیکھنا ہوگا۔ جب آپ کسی سسٹم کے بارے میں سوچ رہے ہوں، تو یہ وہ چیزیں ہیں جن پر آپ کو توجہ دینی چاہیے: چیزیں کیسے بڑی ہو رہی ہیں، وقت کے ساتھ بدلنے والے اثرات، سبب و مسبب (cause and effect) کا بہاؤ کس سمت جا رہا ہے، کون سے نوڈز اپنے تمام پڑوسیوں سے بات کر رہے ہیں، ابھار (emergence) کیسا دکھتا ہے، وہ چیزیں کیا ہیں جو پتہ نہیں کہاں سے اچانک سامنے آ جاتی ہیں۔ پھر incentive mechanisms کا کیا؟ اس میں سماجی اور تکنیکی دونوں شامل ہیں، capacity، feedback loops اور bottlenecks؛ یہ سب سسٹم اینالیسس کے ٹولز ہیں۔
یہ پیچیدہ لگتا ہے، لیکن آپ کو صرف دو سوالات کی ضرورت ہے: کیوں (Why؟)، اور اگر (What if؟)۔ کیوں ہمارے اندراجی ٹیسٹ اتنے کم ہیں؟ اگر ہمارے پاس یونٹ ٹیسٹس کے بجائے زیادہ اندراجی ٹیسٹس ہوں؟ کیوں ہم ان خاص زبانوں کا استعمال کرتے ہیں؟ اگر AI نے تمام کوڈ لکھ دیا ہو تو؟
"کیوں" وہ ڈرِل ہے جو آپ استعمال کرتے ہیں تاکہ نظام کے مرکز تک جا سکیں اور اس کے کام کرنے کا طریقہ سمجھ سکیں۔ آپ سب کو کیوں پوچھنا آتا ہے، لیکن "اگر" کا حصہ زیادہ مشکل ہے۔ "اگر"، اس سے ڈر لگ سکتا ہے، اگر یہ آپ کو ان عملوں کو چھوڑنے کے لیے مجبور کرے جنہیں آپ نے پہلے بہت اچھی طرح ڈیزائن کیا تھا۔ اگر آپ اس کا ٹیسٹ نہیں کرتے؟ اگر آپ بالکل ٹیسٹ نہیں لکھتے؟ زیادہ دور نہ جائیں۔ لیکن اگر آپ اسے ہونے دیں، تو "اگر" بہت دلچسپ بھی ہو سکتا ہے۔
AI ایک طاقت بڑھانے والا ہے، نہ کہ رہنمائی
AI ایک طاقت بڑھانے والا ہے۔ یہ خیال میرے DORA کے دوستوں سے آیا، جن کی گزشتہ سال کی AI ڈویلپمنٹ رپورٹ میں یہ تعلق دریافت ہوا کہ جن ٹیموں نے حقیقت میں چیزوں کو سمجھ لیا، انہوں نے یہ سمجھ لیا کہ AI کو کس طرح طاقت بڑھانے والا بنایا جائے۔
AI آپ کو زیادہ دے سکتا ہے۔ زیادہ ٹیسٹ، زیادہ دستاویزات، زیادہ کوڈ، لیکن زیادہ انتشار بھی۔ بڑھانا ایک مقدار ہے، راستہ نہیں۔ AI کو یہ نہیں پرواہ کہ وہ چیزیں کہاں گئیں، یہ صرف آپ کو زیادہ دیتا ہے۔ DORA نے اصل میں یہ پایا کہ جو ٹیمیں بنیادی مہارتوں میں مضبوط ہوتی ہیں، وہ بڑھانے کے اثر کو مفید سمت کی طرف مائل کر سکتی ہیں۔
یہ سوال اٹھاتا ہے: آپ اپنی بنیادی مہارتوں کے بارے میں کیا محسوس کرتے ہیں؟ آپ کی کمپنی کی فیصلہ سازی کی ثقافت کیا ہے؟ آپ اسے بہتر بنانے کے لیے کیا کر سکتے ہیں؟ ٹیکنالوجی کی حکمت عملی کیا ہے؟ کیا کوئی ڈویلپر پیداواریت پر توجہ دے رہا ہے؟ آج تنظیم کے لوگ کس طرح تعاون کر رہے ہیں؟ سیکورٹی کی حالت کیا ہے؟ کوڈ کی صحت، ریلیز کی صفائی، اور قابلیت کیا ہے؟ AI آپ کے لیے کوئی مسئلہ خود بخود حل نہیں کرتا۔ اگر آپ کے عمل اچھے ہیں، تو وہ انہیں بڑھاتا ہے۔ لیکن اگر وہ اچھے نہیں ہیں، تو وہ صرف مزید پریشانیاں پیدا کرتا ہے۔
لیکن یہاں تک کہ بنیادی مہارتوں کو مضبوط بنانے کے باوجود، ہم ایک حقیقی سفر سے گزرنے والے ہیں۔ میں اندازہ لگاتا ہوں کہ 2030 تک، ہمارا آج کا ڈویلپر ایکوسسٹم، 2001 کے دور کی طرح ہم سے اتنی دور لگے گا جتنی ہم آج 2001 کو دیکھتے ہیں۔ 2001 میں ہم CD-ROM کے ذریعے سافٹ ویئر جاری کرتے تھے، اور 2030 تک ہم اتنی ہی دور ہو سکتے ہیں۔
جب آپ اپنی بنیادی مہارتوں کو مضبوط بنانے کے سفر پر ہیں، تو میں آپ کو چار باتیں دیتا ہوں جن پر آپ سفر کے دوران سوچ سکتے ہیں۔
سب سے پہلا، بنیادی ڈھانچے کی صلاحیت۔ اگر آپ نہیں جانتے کہ آپ کے پاس کتنے وسائل دستیاب ہیں، تو آپ AI نہیں ڈپلوی کر سکتے، نہ ہی کمپیوٹنگ وسائل، آپ کو ان کا پتہ لگانے کا ایک اچھا طریقہ درکار ہے۔
دوم، تصدیق کی پالیسی۔ آپ ایسے سافٹ ویئر کو جاری نہیں کر سکتے اور نہ ہی کرنا چاہیے جس کی تصدیق نہ ہو۔ لیکن تصدیق کی پالیسیاں بدل رہی ہیں، اب وقت آ گیا ہے کہ آپ اسے واضح کر لیں۔ انٹیگریشن ٹیسٹنگ آپ کا سب سے اہم ہتھیار بن جائے گی، اور شاید آپ کے پاس ابھی تک مناسب ٹولز نہ ہوں۔
تیسری بات، الگ کرنا۔ آپ کو مختلف مقاصد کے لیے بہت سے کوڈ ملیں گے، جن میں سے کچھ مقاصد پہلے کبھی کوڈ کے ذریعے حاصل نہیں کیے گئے۔ یہ بات ٹھیک ہے، لیکن آپ نہیں چاہتے کہ ایک دلچسپ پروٹو ٹائپ کوڈ حقیقی پیداواری ماحول میں داخل ہو جائے۔ مزہ کرنے والی چیزوں کو کمائی والی چیزوں کو مت پریشان کرنا۔
چوتھا، تجريد۔ ہم تجريد کو اس لیے بناتے ہیں تاکہ ڈیولپرز بدترین فیصلوں سے بچ سکیں، جس کی وجہ سے ہمارے پاس لائبریریاں اور فریم ورکس ہیں۔ کوئی بھی ویب سرور کو صفر سے نہیں لکھتا۔ ایجنٹ کو بہت سارے فیصلے کرنے دینا اسی قسم کے نتائج کا باعث بنے گا، اس لیے آپ کو ایجنٹ کے لیے اچھی تجريد درکار ہے تاکہ وہ اس پر عمل کرے۔ انہیں بدترین اختیارات مت دیں۔
آپ کو ایک اور بات قبول کرنی ہوگی: انجینئرنگ کے طریقہ کار مقدس نہیں ہوتے۔ طریقہ کار تبدیل ہوتے رہتے ہیں، اصولوں کی اہمیت ہوتی ہے۔ اسے کہنا آسان ہے لیکن اسے کرنا مشکل ہے، اگر آپ نے کبھی اپنی ٹیم کو اس طرح سافٹ ویئر ٹیسٹ کرنے کے پیچھے کیوں، یا پبلشر پروسیس کیوں اس طرح کام کرتا ہے، اس کے بارے میں سوچا نہیں تو آپ اسے ترقی نہیں دے سکتے۔ اصولوں کو سمجھنا ہی آپ کو اس 10 گنا کے لمحے کو عبور کرنے کی طاقت اور اعتماد دے گا۔
اب صافٹ ویئر انجینئرز کے لیے ایک دلچسپ دور ہے۔ ہمارے کام کا ہر پہلو دوبارہ تعریف کیا جا رہا ہے؛ ہمیں اب تک کے کسی بھی وقت کی نسبت زیادہ تخلیقی صلاحیت کی ضرورت ہے؛ ہمیں سیکھنے کی ضرورت ہے جیسے کہ کنٹیکس مینجمنٹ، ٹوکن اقتصادیات، ماڈل ڈرِفٹ جیسے مسائل کا مقابلہ کرنے کے لیے؛ ہمیں تخلیقی صلاحیت کی ضرورت ہے؛ ہمیں سب کچھ بہتر بنانے کے جذبے میں مبتلا نہ ہونا چاہیے، اور تلاش کو فروغ دینا چاہیے۔
ایک سوال جو میری نیند اڑا رہا ہے، اسے صرف بہتر بنانے سے حل نہیں کیا جا سکتا: جب کوڈ بیس بڑھتا جائے تو ہم اس پر اپنا عقلی کنٹرول کیسے برقرار رکھیں؟ عقلی کنٹرول کا مطلب ہے کہ انسان اپنے سامنے والی چیز کے بارے میں استدلال کر سکتا ہے۔ ہم اس جنگ کو کم از کم پندرہ سال سے ہار چکے ہیں، ہمارے سب سے بڑے سسٹم اب کسی ایک شخص کے دماغ کی حد سے بھی آگے نکل چکے ہیں۔ اگر آپ کو یقین نہیں، تو ایک تجربہ کریں: اپنی ٹیم کے ہر فرد سے سسٹم آرکیٹیکچر ڈائیگرام بنوانے کو کہیں، اور دیکھیں کہ آپ کو کتنے مختلف ورژن ملیں گے۔
ہمارے بہت سے سافٹ ویئر سسٹم بہت کمزور ہوتے ہیں، ایک بری کوڈ لائن یا ایک غلط کنفیگریشن فلگ ایک ملین لائن کے سسٹم کو تباہ کر سکتی ہے، جس کی وجہ سے آپ کو تبدیلی کرنے سے پہلے دو بار سوچنا پڑتا ہے۔ لیکن AI کے بارے میں میرا ایک بہت دلچسپ خیال ہے: ایک مسلسل اپڈیٹ ہونے والا، تقریباً انٹرایکٹو آرکیٹیکچر سپیس جس کے بارے میں میں سوال پوچھ سکتا ہوں۔ اگر ہم اس کی صلاحیت مشرقی ساحل پر منتقل کر دیں تو کیا ہوگا؟ اگر صارفین کی تعداد اچانک 40 فیصد بڑھ جائے تو؟ آج کے لحاظ سے، حتیٰ کہ ایک درمیانے سائز کے سسٹم کے لیے بھی اس طرح کا کام فنکشنل طور پر تقریباً ناممکن ہے، کیونکہ متغیرات بہت زیادہ ہیں۔ لیکن AI بہت بڑے ڈیٹا سیٹس کو سمجھ سکتا ہے، اس لیے مجھے لگتا ہے کہ یہاں کچھ حاصل کرنے کو ملتا ہے۔
اس سوال کو پسند کرنے کا سبب یہ ہے کہ ہم صرف کوڈ کے مشین کو تیز تر چلانے پر محدود نہیں ہیں، ہم یہ پوچھ رہے ہیں کہ ہم نے جو کچھ بنایا ہے اس کی سمجھ کو کیسے گہرا کیا جائے؟
تبدیلیاں بہت تیزی سے ہو رہی ہیں، جن سے زیادہ تر تمہاری زندگیوں میں کبھی نہیں ہوئیں۔ اب تم کر سکنے والی سب سے اہم باتوں میں سے ایک یہ ہے کہ جو لوگ مشکل میں ہیں، ان کی مدد کرو، اور جو ابھی تک سمجھ نہیں پائے، ان کو راہ دکھاؤ۔ ہم سب مختلف رفتار سے آگے بڑھ رہے ہیں، اور اس تبدیلی کا مقابلہ مختلف طریقوں سے کر رہے ہیں۔ اپنے آپ کو پیچھے رہتے محسوس کرنا آسان بات ہے۔
ماہر انجینئرز، مینٹر بن جائیں۔ جن لوگوں کو مشکل کا سامنا ہے، ان کی مدد کریں۔ اگر آپ نے AI ڈیولپمنٹ ورک فلو کو سمجھ لیا ہے، تو اسے دوسرے لوگوں کے ساتھ شیئر کریں، یہ کوئی قیمتی راز نہیں ہے۔ ٹیکنیکل لیڈ، آپ کو شرکت کرنا ہوگا اور اپنی کمپنی میں سافٹ ویئر انجینئرنگ کے رخ کو ہدایت کرنے میں مدد کرنا ہوگا۔ اگر آپ سافٹ ویئر کی معیار یا ڈیزائن سے دلچسپی رکھتے ہیں، تو اس کے لیے اپنی آواز بلند کریں۔ آج کے یہاں موجود تمام لوگوں کو یہی کرنا ہے، آپ کے بوس شاید نہیں کریں گے۔
اگر ہم ڈویلپر ایکوسسٹم کو ایک زندہ ایکوسسٹم کے طور پر سمجھیں، تو ہم سب نے ہر درخت کے ہر شاخ پر ہر پتے کو ایک خاص زندہ شکل کی طرح دیکھنے اور دیکھ بھال کرنے کے عادی ہو چکے ہیں۔ لیکن جلد ہی، ہمیں صرف ایک درخت نہیں، بلکہ پورے جنگل کی دیکھ بھال کرنی ہوگی۔ اور آپ ایک جنگل کی دیکھ بھال صرف ایک درخت پر نظر رکھ کر نہیں کر سکتے، آپ کو جنگل کو ایک ایکوسسٹم کے طور پر دیکھنا ہوگا۔
نظاماتی تبدیلی کا ایک خاصہ یہ ہے کہ وہ ایک ساتھ، ہر جگہ اور ہر چیز پر ہوتی ہے، اتنا بڑا کہ لگتا ہے کہ کچھ بھی تھام نہیں سکتا۔ ابھی اس لمحے، آپ کو لگ سکتا ہے کہ کوئی بھی چیز آپ کو اس طرح کی تبدیلیوں کی لہر میں، جو لگ بھگ ہر ہفتے آ رہی ہیں، قائم نہیں رکھ سکتی۔ لیکن جیسا کہ ہم نے ابھی دیکھا، ایک نظام میں، سب کچھ جڑا ہوا ہے، اور چھوٹے اقدامات بڑے نتائج پیدا کر سکتے ہیں۔
جیسے دکھائی دے رہا ہے، AI کا تبدیل ہونا صرف کمپنی کے لیڈرز کا شعبہ نہیں ہے۔ ایک لائن کے سافٹ ویئر انجینئر کے طور پر، اس اہم لمحے میں آپ اس بات کے مرکز میں ہیں کہ سافٹ ویئر انجینئرنگ کہاں جا رہی ہے۔ ٹولز سے لے کر ورک فلو، انجینئرنگ پریکٹس سے لے کر انجینئرنگ کلچر تک، اگر آپ وہ نظام دیکھ سکتے ہیں جو چل رہا ہے، تو آپ لووریج تلاش کر سکتے ہیں۔ آپ کے پاس جتنی خود مختاری ہے، وہ آپ کو لگتی ہے اس سے زیادہ ہے—اس خود مختاری کو اپنی تنظیم، اپنی ٹیم اور اپنے لیے مستقبل بنانے کے لیے استعمال کریں۔