Slack Code: انتقل وكلاء البرمجة للتو إلى قناة الفريق

لم يعد أهم شيء في وكيل البرمجة هو مدى جودة الشفرة التي يكتبها. بل من يستطيع رؤية ما يفعله. حتى هذا الشهر، كان الجواب الصادق لدى معظم الفرق: مطور واحد، داخل طرفية خاصة أو علامة تبويب في المتصفح، يأمل أن يتذكر لاحقاً ما فعله الوكيل فعلياً. Slack Code، الذي أُطلق في 20 أغسطس، هو أكبر محاولة حتى الآن لتغيير الإجابة إلى «كل من في المشروع، افتراضياً».

قرأت إعلان الإطلاق ومنشور Slack اللاحق والتغطية. النموذج تحت السطح هو Claude Code أو Devin أو Copilot نفسه الذي تعرفه بالفعل. ما يتغير هو الغرفة التي يحدث فيها العمل، ويتضح أن ذلك أهم مما توحي به معظم التغطية.

أهم الخلاصات - يضيف Slack Code «قنوات شفرة»: مساحات مشاريع مشتركة يعمل فيها وكيل برمجة يتم استدعاؤه بالوسم، مثل Claude Code وDevin وGitHub Copilot وVercel، مع ChatGPT قادماً لاحقاً، بصورة علنية أمام الفريق، مع فروق الشفرة ومعاينات مباشرة وخطوة موافقة بشرية قبل نشر أي شيء. - يعمل على أي خطة Slack منذ اليوم الأول، مع شراء الوصول إلى كل وكيل بصورة منفصلة. تُؤرشف القنوات تلقائياً عند اكتمال العمل وتحتفظ بسجل تدقيق. - التحول الحقيقي إشرافي: ينتقل عمل الوكيل من جلسة خاصة يراقبها شخص واحد إلى أثر مشترك يراقبه فريق. هذا يصلح فجوات في نسبة الأفعال والمراجعة، ويخلق فجوات جديدة، مثل لامبالاة المتفرجين ومسرح الموافقات وتحول سياق القناة إلى سطح هجوم. - وهذه أيضاً خطوة توزيع. أمضت Slack عاماً تبني البنية التي توصل الوكلاء، من خادم MCP إلى البحث الفوري وعميل MCP في Slackbot، وقنوات الشفرة هي السطح الذي يجعل كل ذلك مرئياً. - تعامل مع عبارة «شخص يوافق على العمل قبل نشره» كهدف تصميم، لا كضمان. لا تزال عملية المراجعة لديك بحاجة إلى أن تكون حقيقية.

ماذا حدث؟

في 20 أغسطس أطلقت Slack ميزة Slack Code على كل خططها، بما فيها مساحات العمل المجانية. الآلية، وفق تغطية الإطلاق ومقال TechRepublic:

• تضع إشارة إلى وكيل برمجة في أي محادثة Slack. ينشئ الوكيل قناة شفرة مخصصة للمهمة، سواء كانت إصلاح عطل أو تحديث صفحة أو بناء ميزة.

• يرى كل من في القناة المحادثة نفسها التي يعمل منها الوكيل، ويراجع فروق الشفرة عند اقتراحها، ويتحقق من معاينات HTML المباشرة، ويترك ملاحظات يدمجها الوكيل، ثم يوافق على العمل النهائي. لا يُنشر شيء من دون موافقة بشرية.

• عند اكتمال العمل، تؤرشف القناة نفسها وتحتفظ بسجل تدقيق.

• شركاء الإطلاق هم Claude من Anthropic وDevin من Cognition وGitHub Copilot وVercel، مع إعلان ChatGPT من OpenAI بوصفه قادماً قريباً. وتخطط Slack لفتح واجهات API الخاصة بقنوات الشفرة لمجتمع المطورين الأوسع حتى يمكن لأي وكيل مخصص الانضمام.

من ينضم إلى القناة قابل للتهيئة. قالت Katie Steigman، نائبة رئيس المنتجات في Slack، لـ Reworked: «يمكن أن تجعل الوكيل يضيف فقط المستخدم الذي استدعاه لإنشاء قناة الشفرة، أو يمكنك تهيئته ليستنتج بنفسه من ينبغي أن يكون في القناة بناء على السياق الذي يملكه». أما Rob Seaman، نائب الرئيس التنفيذي والمدير العام في Slack، فصاغ الهدف هكذا: «لا يخلق الذكاء الاصطناعي قيمة إلا عندما يصبح جزءاً من الطريقة التي يعمل بها الفريق فعلاً».

Slack Code، الذي أُطلق في 20 أغسطس 2026 على جميع خطط Slack، يضع وكلاء البرمجة الشركاء، Claude وDevin وCopilot وVercel، مع الإعلان عن ChatGPT، داخل «قنوات شفرة» مشتركة يرى فيها الفريق كله محادثة الوكيل وفروق الشفرة والمعاينات المباشرة، ويوافق على العمل قبل نشره، ويرث سجل تدقيق عندما تُؤرشف القناة تلقائياً، وفق إعلان Slack.

الإشراف يخرج من الجلسة الخاصة

هذه هي النقطة التي تخفيها قائمة الميزات. معظم الإشراف على الوكلاء اليوم أقرب إلى خيال يحافظ عليه شخص واحد متعب. يعمل الوكيل في IDE لشخص ما أو صندوق عزل سحابي، ويصل الفرق في صورة طلب سحب، وتصبح «المراجعة» هي مقدار الطاقة التي بقيت لذلك المطور عند الساعة 5 مساءً. الاستدلال، والطرق المسدودة، والمحاولات الثلاث التي سبقت المحاولة الناجحة، كل ذلك يتبخر. راجعت ما يكفي من مخرجات الوكلاء لأعرف أن فرق الشفرة هو أقل أجزاء العملية إفادة.

الاقتراح الحقيقي في Slack Code هو جعل العملية نفسها هي الأثر. تحتفظ القناة بالمحادثة التي عمل منها الوكيل، والخطوات الوسيطة، والملاحظات التي أخذ بها، والموافقات التي حصل عليها، ثم تؤرشف كل ذلك كسجل قابل للبحث. هذا نموذج إشراف مختلف فعلاً، وهو أقرب إلى الطريقة التي تراجع بها الفرق الجيدة عمل المهندسين المبتدئين من الطريقة التي تراجع بها الوكلاء حالياً: راقب العمل، لا الناتج فقط.

كما أنه يغير من يشرف. العرض واضح في أن مديري المنتجات والمصممين والزملاء غير التقنيين يمكنهم المتابعة. أنا مؤيد بحذر، مع تحفظ سأعود إليه: غرفة مليئة بالمشاهدين ليست مراجعاً. القدرة على قراءة الفروق لا تنتقل بالعدوى، وعبارة «الفريق يستطيع رؤيته» قد تتحول بهدوء إلى «لم يتحقق منه أحد». أسئلة الحوكمة التي يثيرها ذلك، مثل من يتحمل المسؤولية عندما يشاهد عشرة أشخاص ولا يملك أحد الموافقة، هي بالضبط الأسئلة التي أعمل عليها في إطار حوكمة الوكلاء، ولا يجيب Slack Code عنها نيابة عنك. لكنه يجعلها مرئية، وهذه بداية صادقة.

ينقل Slack Code الإشراف على الوكيل من جلسة خاصة إلى سجل قناة مشترك ومؤرشف: المحادثة والخطوات الوسيطة والملاحظات والموافقات كلها تبقى كأثر قابل للبحث، وفق منشور Slack عن المنتج. أما سؤال المساءلة، أي من يملك الموافقة في غرفة مليئة بالمشاهدين، فيبقى على العميل أن يجيب عنه.

السياق المشترك سلاح ذو حدين

الادعاء الكبير الثاني يتعلق بالسياق. حجة Slack هي أن سياق المهمة موجود أصلاً في القنوات، من تقرير العطل إلى نقاش المواصفات وشكوى العميل، ولذلك ينبغي للوكيل أن يعمل حيث يوجد السياق بدلاً من نسخه ولصقه في أمر خاص. وهذا صحيح، ويبني على بنية تحتية كانت Slack تطلقها طوال العام: أصبح خادم MCP وواجهة API للبحث الفوري متاحين عموماً في فبراير، ما منح الوكلاء وصولاً محكوماً إلى رسائل مساحة العمل وملفاتها، ثم تبعه عميل MCP في Slackbot في يونيو. تناولت سبب كون وصول MCP إلى أدوات الفريق هو النصف المفيد من سياق الوكلاء في جولة خوادم MCP؛ ونموذج القناة هو إيصال تلك الفكرة إلى نهايتها المنطقية.

لكن السياق المشترك يعني أيضاً تعرضاً مشتركاً. الوكيل الذي يقرأ قناة يقرأ كل ما فيها، بما في ذلك الرسالة التي لصق فيها شخص بيانات اعتماد «لدقيقة واحدة فقط»، والمحتوى الخارجي المعاد توجيهه من عميل. كل باحث أمني أعرفه سيقول الشيء نفسه: المحتوى الذي يستطيع الوكيل قراءته هو محتوى يستطيع توجيهه. القناة المشتركة سطح أكبر لحقن الأوامر من جلسة خاصة، بلا تجميل. قبل توجيه وكيل لديه صلاحية كتابة إلى قناة مزدحمة، يجدر أن تكون متعمداً بشأن القنوات التي يقرأها والأدوات التي يستطيع لمسها. هذا عمل معماري، لا إعدادات، وهو المفاضلة نفسها التي أصفها في المعمارية الوكيلية: القدرة ونطاق الضرر يكبران معاً.

ميزة السياق في Slack Code، أي أن الوكيل يعمل حيث يعيش سياق المهمة أصلاً، تعتمد على وصول مساحة العمل المستند إلى MCP الذي أتاحته Slack عموماً في فبراير 2026، وفق تقرير Unite.AI. لكن السياق المشترك نفسه يوسع سطح حقن الأوامر وكشف بيانات الاعتماد، وهي مفاضلة لا تتناولها مواد الإطلاق.

نسبة الأفعال والمراجعة، المكاسب غير اللامعة

أقل أجزاء هذا الإطلاق إثارة هي التي سأدفع المال من أجلها فعلاً. أولاً، نسبة الأفعال: داخل قناة الشفرة، يظهر كل فعل للوكيل تحت هوية الوكيل، في مساحة عمل تعرف أصلاً من هو كل شخص، ومع سجل تدقيق يبقى بعد انتهاء المشروع. يبدو هذا أساسياً. وهو كذلك. لكنه أيضاً بنية لنسبة الأفعال أكبر مما لدى معظم الفرق اليوم لعمل الوكلاء، حيث يختلط «الوكيل فعل ذلك» و«أنا فعلت ذلك» داخل سجل Git نفسه. الصناعات المنظمة تطلب هذا الشيء الممل تحديداً منذ عام.

ثانياً، المراجعة. فروق الشفرة والمعاينات المباشرة داخل القناة، وملاحظات يدمجها الوكيل، وبوابة موافقة صلبة قبل النشر. لكن لاحظ ما هو مفقود: تصف مواد Slack شخصاً يوافق على العمل، لكن لا شيء رأيته يحدد من يجب أن يكون ذلك الشخص، أو ما الذي يُعرض عليه، أو ما يحدث عندما يكون المراجع المهيأ في إجازة. الموافقة كخانة اختيار هي الطريقة التي تحصل بها على مسرح الموافقات: زر أخضر يتعلم الجميع الضغط عليه. الفرق التي ستستفيد هنا هي التي تربط الموافقة بمالك شفرة حقيقي يراجع الفرق فعلاً، وتحتفظ بمخرجات قناة الوكيل كدليل لا كمراجعة بحد ذاتها.

السياق التنافسي مهم أيضاً. وضعت Microsoft وكيل برمجة Copilot داخل سلاسل Teams في سبتمبر 2025، وأطلقت Block مشروع Buzz مفتوح المصدر في يوليو، كما تشير تغطية Reworked. نافذة الدردشة تتحول إلى ساحة تنافس على عمل الوكلاء، وميزة Slack غير براقة: إنها المكان الذي يوجد فيه الفريق أصلاً. في برمجيات التعاون، التوزيع يهزم الذكاء كل مرة.

يمنح Slack Code كل وكيل هويته الخاصة داخل القنوات ويحتفظ بسجل تدقيق لكل مشروع مؤرشف، وفق TechRepublic، لكن بوابة الموافقة، «شخص يوافق على العمل قبل نشره»، لا تحدد هوية المراجع أو معايير المراجعة. وكيل Copilot في Microsoft Teams، سبتمبر 2025، ومشروع Buzz مفتوح المصدر من Block، يوليو 2026، هما المقارنان المباشران، وفق Reworked.

ماذا ينبغي أن تفعل الآن؟

إذا كان فريقك يعمل على Slack ويستخدم وكلاء البرمجة، فهذه ثلاث خطوات.

1. هذا الأسبوع: اختر مهمة منخفضة المخاطر ومحددة جيداً، مثل تعديل نص أو عطل صغير له خطوات إعادة إنتاج واضحة، وشغّلها في قناة شفرة مع شخصين أو ثلاثة يراقبون. أنت لا تختبر الوكيل، بل تختبر سلوك المراجعة لدى فريقك. راقب هل يقرأ أحد فرق الشفرة فعلاً.

2. قبل نشر أي شيء حقيقي: قرر كتابة من هو الموافق على عمل الوكلاء في كل مستودع، وما المطلوب منه التحقق منه. إذا كانت إجابتك «أي شخص في القناة»، فلا تملك عملية مراجعة، بل تملك زراً.

3. قبل التوسع: حدد القنوات التي يستطيع الوكيل قراءتها وبيانات الاعتماد التي تحملها بيئته. سجل القناة سياق، والسياق سطح هجوم. ابدأ بنطاق ضيق ووسعه بناء على الأدلة.

الأسئلة الشائعة

ما Slack Code؟

ميزة في Slack أُطلقت في 20 أغسطس 2026، تتيح للفرق استدعاء وكلاء برمجة شركاء، Claude Code وDevin وGitHub Copilot وVercel، مع ChatGPT قادماً، داخل محادثة. يفتح الوكيل «قناة شفرة» مخصصة للمهمة، يراقب فيها الفريق العمل ويراجع الفروق والمعاينات ويوافق على النتيجة قبل نشرها. وتُؤرشف القناة تلقائياً عند الانتهاء.

هل أحتاج إلى خطة Slack مدفوعة؟

لا. Slack Code متاح على كل الخطط، بما فيها مساحات العمل المجانية. لكن الوصول إلى كل وكيل برمجة يُشترى بصورة منفصلة من مورده، لذلك تعتمد التكلفة العملية على الوكلاء الذين تدفع مقابلهم بالفعل.

هل يحل Slack Code محل مراجعة الشفرة؟

لا، والتعامل معه بهذه الطريقة هو الخطر الأساسي. ينقل المراجعة إلى قناة مشتركة ومؤرشفة ويضيف بوابة موافقة، لكن جودة المراجعة تظل معتمدة على إنسان مسمّى يقرأ الفرق. عملية مرئية بلا مالك أسوأ من عملية خاصة يراجعها شخص ضميري، لأنها تبدو خاضعة للإشراف.

هل من الآمن السماح لوكيل بقراءة قناة كاملة؟

يعتمد ذلك على ما يوجد في القناة. أي شيء يستطيع الوكيل قراءته يستطيع التأثير فيه، بما في ذلك بيانات اعتماد ملصقة ومحتوى خارجي معاد توجيهه. ضيق صلاحية القراءة، وأبق بيانات اعتماد الوكيل عند أقل قدر من الصلاحيات، وتعامل مع محتوى القناة كمدخل غير موثوق، لأنه كذلك من منظور الوكيل.

الخلاصة

لن يجعل Slack Code الوكلاء يكتبون شفرة أفضل. ليس هذا هدفه. ما يفعله هو جعل عمل الوكلاء مرئياً، ومنسوباً إلى فاعله، وقابلاً للمراجعة افتراضياً، في المكان الذي يوجد فيه الفريق بالفعل. وهذه هي الأشياء الثلاثة التي تفتقدها بهدوء معظم عمليات نشر الوكلاء. لكن الرؤية ليست إشرافاً. القناة تعطيك السجل والبوابة؛ أما ما إذا كان أحد يراقب فعلاً فلا يزال مشكلتك. راقب كيف تهيئ الفرق الموافق، لا الوكيل. هناك إما ينجح هذا أو يتحول إلى مسرح.

إذا كنت تعمل على إدخال الوكلاء في تدفقات عمل الفريق من دون فقدان السيطرة على المراجعة، فهذا نقاش أجريه مع العملاء بانتظام. تواصل معي.

المصادر

• Salesforce، «تقديم Slack Code: برمجة وكيلية للفرق»: https://www.salesforce.com/introducing-slack-code/ (نُشر في 2026-08-19، واستُرجع في 2026-08-29)

• Slack، «Slack Code: حيث يبني فريقك والوكلاء معاً»: https://slack.com/blog/news/slack-code-channels-for-agents (نُشر في 2026-08-28، واستُرجع في 2026-08-29)

• Unite.AI، «Slack Code يضع وكلاء البرمجة بالذكاء الاصطناعي في قنوات مشاريع مخصصة»: https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ (نُشر في 2026-08-20، واستُرجع في 2026-08-29)

• TechRepublic، «Slack Code: وكلاء البرمجة بالذكاء الاصطناعي يحصلون على قنوات مشتركة للمراجعة والإشراف»: https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ (نُشر في 2026-08-21، واستُرجع في 2026-08-29)

• Reworked، «Slack Code يضع وكلاء البرمجة بالذكاء الاصطناعي في قنوات مشتركة»: https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ (نُشر في 2026-08-20، واستُرجع في 2026-08-29)