Meta اب engineers کو AI tokens پر نہیں پرکھے گا، اصل معیار کام کا اثر ہوگا
Meta نے یکم ستمبر 2026 کی داخلی guidance میں engineers کو واضح کیا کہ AI adoption dashboards یا token counts سے ان کے کام کا اثر نہیں جانچا جائے گا۔ Maher Saba اور Santosh Janardhan کے memo کا جائزہ لینے والی The Information کی رپورٹ کے مطابق managers اب کام کے معیار، رفتار، مسئلے کی پیچیدگی اور سنبھالے گئے دائرۂ کار کو دیکھیں گے۔
یہ AI tools سے پیچھے ہٹنے کا اعلان نہیں بلکہ performance evaluation کی حد بندی ہے: مطلوبہ نتیجہ AI یا دوسرے طریقوں سے حاصل کیا جا سکتا ہے، مگر زیادہ AI استعمال بذاتِ خود بہتر کارکردگی کا ثبوت نہیں ہوگا۔ WIRED کی ملازمین اور Meta کے ترجمان پر مبنی رپورٹ تصدیق کرتی ہے کہ نئی عبارت میں “usage of AI” اور “AI Native” جیسے حوالوں کی جگہ contributions اور impact پر زور دیا گیا ہے۔
نئی guidance میں اصل تبدیلی کیا ہے
نئے متن نے tool activity اور کام کے اثر کو الگ کر دیا ہے۔ engineer نے کتنے tokens استعمال کیے یا adoption dashboard پر اس کی سرگرمی کتنی تھی، یہ اعداد impact طے نہیں کریں گے؛ بنیادی سوال یہ ہوگا کہ اس نے کیا تیار کیا اور اس کام نے کیا نتیجہ دیا۔
Meta کے ترجمان Tracy Clayton کا مؤقف ہے کہ کمپنی ہمیشہ ملازمین کو ان کی contributions پر جانچتی رہی ہے اور “AI Native” labels performance evaluation میں استعمال نہیں ہوئے۔ ملازمین نے WIRED کو بتایا کہ عبارت کی تبدیلی بظاہر محدود ہے، لیکن اس سے ایسی جگہ AI استعمال کرنے کا دباؤ کم ہو سکتا ہے جہاں وہ کام کے لیے موزوں نہ ہو۔ یوں دستیاب شواہد کسی مکمل AI-policy reversal کے بجائے review guidance اور اس کے قابلِ اطلاق معیار میں تبدیلی دکھاتے ہیں۔
Meta نے مکمل memo عوامی طور پر جاری نہیں کیا۔ اس لیے یہ نتیجہ اخذ نہیں کیا جا سکتا کہ کمپنی نے AI adoption کی وسیع حکمتِ عملی ترک کر دی ہے یا داخلی usage data جمع کرنا بند کر دیا ہے؛ تصدیق شدہ بات صرف یہ ہے کہ adoption dashboards اور token totals کو engineer کے impact کا فیصلہ نہیں بنانا۔
Managers اب کن شواہد پر فیصلہ کریں گے
داخلی memo میں چار واضح جہتیں سامنے آتی ہیں: output quality، velocity، problem complexity اور scope۔ CIO کی 4 ستمبر کی خبر بھی انہی پیمانوں کو نقل کرتی ہے اور AI consumption کو employee impact سے الگ قرار دیتی ہے۔
ان جہتوں کا مطلب یہ نہیں کہ ہر engineer کو ایک ہی خام عدد پر درجہ دیا جا سکتا ہے۔ تیز delivery تبھی مفید ہے جب code قابلِ اعتماد ہو اور review، testing یا بعد کی مرمت بچایا ہوا وقت واپس نہ لے لے۔ اسی طرح ایک پیچیدہ بنیادی مسئلے کا حل بظاہر کم features پیدا کر سکتا ہے، مگر اس کا technical یا business impact زیادہ ہو سکتا ہے۔
Meta کی guidance کو ایک قابلِ عمل measurement frame میں یوں الگ رکھا جا سکتا ہے:
- Adoption: کیا AI مناسب کام میں استعمال ہوا اور engineer اس کے output کی جانچ کر سکا؟ یہ tool proficiency کا اشارہ ہے، حتمی performance score نہیں۔
- Output quality: کیا تیار شدہ code یا system درست، محفوظ، قابلِ دیکھ بھال اور طے شدہ معیار کے مطابق ہے؟
- Delivery speed: کیا مفید کام جلد مکمل ہوا، اور کیا review، testing اور rework کو شامل کرنے کے بعد بھی وقت کی بچت برقرار رہی؟
- Problem complexity and scope: مسئلہ کتنا غیر واضح یا مشکل تھا، اور engineer نے کتنی ذمہ داری سنبھالی؟ خام ticket count یہ فرق نہیں دکھاتا۔
- Outcome and impact: کیا تبدیلی استعمال میں آئی، کسی رکاوٹ کو دور کیا یا طے شدہ product، reliability یا business objective کو آگے بڑھایا؟
Token count productivity کیوں ثابت نہیں کرتا
Token count AI system کو بھیجے گئے اور اس سے پیدا ہونے والے متن کی مقدار بتاتا ہے۔ یہ cost، capacity اور adoption کی نگرانی میں کام آ سکتا ہے، مگر اس میں task کا مقصد، output کی صحت، مسئلے کی مشکل اور نتیجے کی قدر شامل نہیں ہوتی۔ مختلف models، prompts اور workflows ایک ہی قابلِ قبول نتیجے کے لیے مختلف مقدار میں tokens استعمال کر سکتے ہیں۔
اسی لیے زیادہ consumption کو اچھی performance سمجھنے سے incentive بگڑ سکتا ہے۔ ملازم مختصر اور مؤثر راستے کے بجائے بار بار prompts چلانے، غیر ضروری agents بنانے یا ایسے کام کو automate کرنے کی طرف مائل ہو سکتا ہے جو براہِ راست زیادہ بہتر انداز میں مکمل ہو جاتا۔ dashboard سرگرمی دکھائے گا، لیکن یہ نہیں بتائے گا کہ اس سرگرمی نے نتیجہ بہتر کیا یا صرف گنتی بڑھائی۔
اس کا مطلب token data کو مکمل طور پر بے فائدہ سمجھنا بھی نہیں۔ کوئی تنظیم اسے infrastructure cost، licenses کی طلب، training gaps یا tool rollout دیکھنے کے لیے استعمال کر سکتی ہے۔ اہم امتیاز یہ ہے کہ diagnostic metric کو performance verdict نہ بنایا جائے: AI usage ایک input ہے، جبکہ قابلِ اعتماد کام اور اس کا اثر outcomes ہیں۔
پاکستانی engineering teams کے لیے measurement checklist
پاکستان میں AI coding assistants اپنانے والی teams کے لیے اس خبر کا براہِ راست مطلب evaluation design سے ہے۔ licenses، active users، prompts یا tokens کی گنتی rollout کی رفتار دکھا سکتی ہے، لیکن اس سے یہ ثابت نہیں ہوتا کہ releases بہتر ہوئے، incidents کم ہوئے یا customer-facing کام جلد پہنچا۔
Review سے پہلے مطلوبہ نتیجہ اور اس کے شواہد طے کرنا زیادہ مضبوط طریقہ ہے۔ ایک فرضی مثال میں، اگر engineer نے AI کی مدد سے migration script بنائی تو appraisal میں tokens کے بجائے migration کی درست تکمیل، test results، review findings، مجموعی delivery time اور production outcome دیکھا جائے گا۔ یہ measurement کی مثال ہے، Meta کے کسی حقیقی project کی تفصیل نہیں۔
AI proficiency الگ competency رہ سکتی ہے: مناسب tool منتخب کرنا، generated output کی تصدیق، حساس معلومات کی حفاظت اور غلط جواب کی شناخت۔ اسے delivery impact میں ضم کر دینے سے یہ معلوم کرنا مشکل ہو جاتا ہے کہ اچھا نتیجہ مضبوط engineering judgment سے آیا یا محض زیادہ tool activity سے۔
فی الحال نئی guidance کا اصول واضح ہے، مگر Meta نے مختلف engineering units کے لیے scoring method، وزن یا اگلے review cycle کے نفاذ کی تفصیل عام نہیں کی۔ اصل عملی تصویر تب سامنے آئے گی جب معلوم ہو کہ managers quality، velocity، complexity، scope اور outcome کے شواہد کو کس طرح جمع اور باہم متوازن کرتے ہیں۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔