ایک جونیئر ڈویلپر کسی نامانوس library کے استعمال کے لیے AI assistant سے کہہ سکتا ہے، چلتا ہوا کوڈ لے سکتا ہے اور اگلے کام پر جاسکتا ہے۔ فیچر اس وقت تیار ہوسکتا ہے جب ڈویلپر یہ نہ سمجھا ہو کہ وہ کیوں کام کرتا ہے۔ یہ بات اس وقت اہم ہوگی جب اگلی مرتبہ کوڈ ناکام ہو، ضرورت بدل جائے یا کسی کو طے کرنا پڑے کہ assistant کی تجویز کردہ مرمت محفوظ ہے یا نہیں۔
سافٹ ویئر انجینئر Alexandru Nedelcu نے یہ خدشہ ایک 22 ستمبر کے مضمون میں اٹھایا۔ ان کا کہنا ہے کہ ڈویلپر کوڈ پڑھنے، انتخاب کرنے اور غلطیوں کے نتائج بھگتنے سے فیصلہ سازی سیکھتے ہیں۔ ان کی پیش گوئی کہ کچھ کمپنیاں AI کے خلاف پالیسیوں کی تشہیر کریں گی، رائے ہے، دیکھی گئی صنعتی تبدیلی نہیں۔ جنوری میں شائع ایک الگ تجربہ سیکھنے کے سوال کو محدود اور قابلِجانچ شکل دیتا ہے: AI کی مدد سے کام مکمل کرنے کے فوراً بعد پروگرامرز نے کیا سمجھا؟ Anthropic کی تحقیقی رپورٹ
بڑی تبدیلی
- کیا بدلا: AI کے باعث منطق سمجھے بغیر مکمل سافٹ ویئر جمع کرانا آسان ہوگیا ہے۔ کسی نوآموز کے سمجھانے یا مرمت کرنے کی مشق سے پہلے ہی AI implementation فراہم کرسکتا ہے۔
- یہ کیوں اہم ہے: مینیجر آج زیادہ پیداوار حاصل کرسکتے ہیں، جبکہ وہ راستہ کمزور پڑسکتا ہے جس سے جونیئر عملہ کل کی خرابیوں کی تشخیص کرنے والا ماہر بنتا ہے۔ یہ خطرہ نامانوس تصورات والے کام میں سب سے زیادہ ہے؛ مانوس کام میں مدد پھر بھی مفید ہوسکتی ہے۔
- کس بات پر نظر رکھیں: ٹیمیں سیکھنے کو کام کی فراہمی کا حصہ سمجھنا شروع کرسکتی ہیں اور AI کی مدد سے کیے گئے کام کی وضاحت، تشخیص اور تبدیلی کے لیے وقت رکھ سکتی ہیں۔ ایسا ہو تو بھرتی کے امتحان اور coding مصنوعات رفتار کے ساتھ سمجھ کا مظاہرہ بھی انعام دے سکتی ہیں۔
کام مکمل ہونا اور مہارت سیکھنا الگ نتائج ہیں
ایک 52 پروگرامرز کا بے ترتیب مطالعہ کیا گیا جس میں شرکا نے Trio نامی نامانوس Python library استعمال کرکے دو coding کام مکمل کیے۔ آدھے شرکا کو coding ماحول میں AI assistant میسر تھا اور آدھوں کو نہیں۔ سب جانتے تھے کہ بعد میں quiz ہوگا۔ کام کے تھوڑی ہی دیر بعد ہونے والے quiz میں تصورات، کوڈ پڑھنے اور debugging کی جانچ ہوئی۔
AI گروپ کا اوسط اسکور 50% تھا، جبکہ AI کے بغیر کام کرنے والے گروپ کا 67%: فرق 17 percentage points ہے، 17% نسبتی کمی نہیں۔ debugging کے سوالوں میں سب سے بڑا فرق تھا۔ AI گروپ اوسطاً تقریباً دو منٹ جلدی مکمل ہوا، مگر وقت کا یہ فرق اعدادوشمار کے لحاظ سے اہم نہیں تھا۔ یہ ایک library سے مختصر واقفیت اور فوراً لیے گئے ٹیسٹ کے نتائج ہیں، ڈویلپرز کے کیریئر یا عملی پیداواری نظام کے معیار کی پیمائش نہیں۔ محققین کے نتائج اور حدود
محققین نے یہ بھی دیکھا کہ شرکا نے assistant کیسے استعمال کیا۔ کچھ نے زیادہ تر کوڈ اور debugging کا کام اسے سونپا؛ دوسروں نے وضاحتیں مانگیں یا تصورات خود سمجھنے کی کوشش کی۔ زیادہ فعال انداز میں شامل گروپوں کے اسکور عموماً بہتر تھے، مگر ان چھوٹے گروپوں کی شناخت بعد میں کی گئی۔ شرکا کو AI تک رسائی کے لیے بے ترتیب تقسیم کیا گیا تھا، بات چیت کے کسی خاص طریقے کے لیے نہیں۔ وضاحت مانگنا سیکھنے والے کی مدد کرسکتا ہے، لیکن یہ مطالعہ ثابت نہیں کرتا کہ کوئی ایک prompt یا workflow سیکھنے کے فرق کو روکتا ہے۔ مقالے کا تعامل کا تجزیہ
غلطی اکثر وہ لمحہ ہے جب نیا سیکھنے والا جانتا ہے کہ library کیا مفروضہ کرتی ہے۔ اگر assistant ابتدائی implementation اور اس کی مرمت دونوں سنبھال لے تو ڈویلپر کو ان مفروضوں میں سے کم نظر آسکتے ہیں۔ debugging کے فرق کی یہ ایک ممکنہ وضاحت ہے۔
رفتار بھی اہم ہے، اور جواب کام کے لحاظ سے بدلتا ہے
دوسرے حالات میں AI کی مدد سے coding تیز بھی ہوئی ہے۔ GitHub Copilot کے ایک کنٹرول شدہ تجربے میں 95 پیشہ ور freelancers کو JavaScript HTTP server بنانے کا کام دیا گیا۔ جنہوں نے کام مکمل کیا، ان میں Copilot گروپ نے اوسطاً تقریباً 71 منٹ میں کام کیا، جبکہ control گروپ نے تقریباً 161 منٹ لیے؛ وقت میں 55.8% کمی۔ محققین نے نہیں جانچا کہ ان پروگرامرز نے بعد میں کیا سیکھا۔ یہ محدود implementation کا کام تھا، نامانوس library سے تعارف اور اس کے بعد سمجھ کا quiz نہیں۔
دونوں نتائج مینیجر کے لیے مفید ہوسکتے ہیں۔ اگر تجربہ کار ڈویلپر AI سے دہرائے جانے والے کام کم کرے تو بچا ہوا وقت حقیقی فائدہ ہوسکتا ہے۔ لیکن جب کام نیا نظام سیکھنا ہو تو تیز پیداوار اور گہری سمجھ کو الگ جانچنا چاہیے۔ AI پر مکمل پابندی ممکنہ فائدے ضائع کردے گی، مگر یہ جواب نہیں دے گی کہ لوگ کام کی نگرانی کرنا کیسے سیکھیں۔
Nedelcu کا مضمون تجربے سے آگے جاتا ہے۔ ان کا کہنا ہے کہ قابلِمرمت ہونے کی حقیقت مہینوں یا برسوں میں سامنے آتی ہے اور غلطیوں کی ذمہ داری سے تجربہ بڑھتا ہے۔ مطالعہ طویل مدت کی maintainability نہیں ناپتا اور نہ دکھاتا ہے کہ AI استعمال کرنے والے سیکھنا بالکل چھوڑ دیتے ہیں۔ ان کا مفید چیلنج تنظیمی ہے: اگر ٹیم مشق کے کام تیزی سے دوسروں کے سپرد کرے تو مستقبل کے troubleshooter یہ تجربہ کہاں سے حاصل کریں گے؟ Nedelcu کا مضمون
کوڈ چلنے کے بعد سیکھنے والے سے وضاحت طلب کریں
ایک عملی طریقہ یہ ہے کہ نوآموز کو AI کی مدد سے کام دیں اور پھر کام کو کامیاب سیکھنے کا نتیجہ ماننے سے پہلے ایک مختصر، آزادانہ جانچ طلب کریں۔ یہ ہماری تجویز کردہ مشق ہے، دونوں مطالعات میں سے کسی کا آزمایا ہوا intervention نہیں:
- وضاحت: assistant سے پوچھے بغیر بتائیں کہ کوڈ کا نامانوس حصہ کیوں کام کرتا ہے، وہ کیا فرض کرتا ہے اور کیا چیز اسے ناکام کرسکتی ہے۔ سینئر انجینئر اصل تبدیلی سے متعلق ایک ضمنی سوال پوچھ سکتا ہے۔
- تشخیص: محفوظ test branch میں ایک چھوٹی، حقیقت پسندانہ خرابی ڈالیں۔ سیکھنے والے سے وجہ تلاش کرنے کو کہیں اور پوچھیں کہ کس مشاہدے سے ایک دلکش مگر غلط مرمت خارج ہوئی۔ مقصد استدلال ہے، کوئی کمانڈ رٹنا نہیں۔
- تبدیلی: ضرورت بدلیں اور سیکھنے والے سے implementation اور اس کے tests میں تبدیلی کرنے کو کہیں۔ وہ AI استعمال کرسکتا ہے، مگر نئی صورتِ حال کا دفاع اور ان باتوں کی نشاندہی کرسکے جن کی تصدیق ابھی باقی ہے۔
مثلاً assistant کوئی نیا asynchronous عمل لکھے تو reviewer پوچھ سکتا ہے کہ درمیان میں منسوخ ہونے پر کیا ہوگا۔ ڈویلپر کو عمل کا راستہ سمجھانا اور بدلی ہوئی شرط آزمانی چاہیے۔ صرف code review خرابی پکڑ سکتا ہے، مگر سیکھنے والے کو اگلی خرابی سنبھالنے کے قابل نہ بنائے۔ مجوزہ جانچ پوچھتی ہے کہ فراہم کردہ کوڈ کے ساتھ علم بھی منتقل ہوا یا نہیں۔
اس کا مطلب یہ نہیں کہ ہر معمول کے ticket کو امتحان بنایا جائے۔ ٹیم یہ مشق نامانوس libraries، بار بار آنے والی خرابیوں یا ایسے کام کے لیے مخصوص کرسکتی ہے جس کی ذمہ داری جونیئر ساتھی کو آگے چل کر ملنی ہو۔ اس میں ادا شدہ وقت اور نظام سمجھنے والا reviewer درکار ہوتا ہے۔ اگر انتظامیہ صرف merge کیے گئے کام اور بچائے گئے وقت کو گنے تو ممکن ہے سب سے پہلے یہی اخراجات کم ہوں۔ اس سے آج کی پیداوار بڑھنے کے باوجود تربیت کا مسئلہ گہرا ہوگا۔
شاگردی کا سوال بھرتی اور مصنوعات کے ڈیزائن تک جاتا ہے
جونیئر عہدوں میں اکثر کام کی فراہمی کے ساتھ زیرنگرانی مشق بھی شامل ہوتی ہے۔ جب امیدوار تیار شدہ متاثرکن feature دکھا سکے مگر اپنی سوچ کا عمل نہ بتائے تو AI یہ معاملہ بدل دیتا ہے۔ آجر polished repository کو آزادانہ مہارت کا ثبوت سمجھنے کے بجائے امیدوار سے کام کے چھوٹے حصے کی وضاحت اور تبدیلی مانگ سکتے ہیں۔ یہ بھرتی کے لیے تجویز ہے، موجودہ رجحان کا ثبوت نہیں۔ جانچ میں عہدے کے لیے ضروری صلاحیت دیکھی جائے، ہر امیدوار کو tools کے بغیر کام کرنے پر مجبور نہ کیا جائے۔
coding مصنوعات کو بھی ایسا ہی انتخاب کرنا ہے۔ assistant فوری جواب کے لیے بہتر بنایا جاسکتا ہے، یا مفروضے دیکھنے، تصوری سوال پوچھنے اور حل دکھانے سے پہلے تبدیلی آزمانے میں مدد دے سکتا ہے۔ مطالعے میں دیکھے گئے تعامل کے انداز دوسری صورت کو آزمانے کے قابل بناتے ہیں، مگر یہ ثابت نہیں کرتے کہ کوئی خاص interface بہتر سکھاتا ہے۔ آجروں کے لیے اس سے ملتا جلتا خریداری کا سوال یہ ہے کہ tool عملے کو اپنے output کا جائزہ لینا اور اسے بدلنا سکھاتا ہے یا صرف یہ کہ وہ کتنا کوڈ بناتا ہے۔
مختصر quiz یہ نہیں بتاسکتا کہ پانچ سال میں کون ماہر بنے گا۔ لیکن یہ دکھاتا ہے کہ نامانوس کام پر قبول شدہ implementation، سمجھ کے ثبوت کا کمزور متبادل کیوں ہے۔ جو ٹیم automation کے ساتھ اگلی نسل کی مہارت بھی چاہتی ہے، اسے مشق کی گنجائش رکھنی اور یہ جانچنا ہوگا کہ جواب بدلنے پر لوگ کیا کرسکتے ہیں۔
