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

كيف تسير مهمة البرمجة داخل القناة؟

يمكن أن يبدأ سير العمل بفكرة أو بلاغ عن خلل أو طلب لتحديث موقع أو إضافة ميزة جديدة:

1. يذكر أحد أعضاء الفريق وكيلًا برمجيًا مدعومًا.
2. ينشئ الوكيل قناة كود مخصصة للمهمة.
3. يضيف المشاركون المتطلبات والقيود وسياق المشروع.
4. يضع الوكيل خطة ويقترح التغييرات.
5. يراجع الفريق العمل، بما في ذلك فروق الشيفرة والمعاينات المتاحة.
6. يستطيع الأعضاء توجيه الوكيل إلى مسار آخر أو الموافقة على الخطوة التالية.

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

لماذا يشارك مديرو المنتجات والمصممون؟

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

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

هذا لا يعني أن وكيل الذكاء الاصطناعي أصبح صاحب القرار النهائي؛ بل يغيّر مكان التعاون ويجعل عمل الوكيل متاحًا للفحص أمام عدد أكبر من أصحاب المصلحة.

الموافقة البشرية تظل أساسية

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

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

سجل قابل للبحث وضوابط Slack المعتادة

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

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

أما الفائدة العملية فهي استمرارية السياق: إذ يمكن أن تبقى متطلبات المشروع وقراراته ومراجعاته ونشاط الوكيل مرتبطة بالمحادثة التي بدأ منها العمل.

التوافر والتكاملات عند الإطلاق

قالت Salesforce إن Slack Code متاح على جميع خطط Slack عند الإطلاق. وشملت التكاملات الأولى التي أُعلن عنها وكلاء من Anthropic وGitHub وCognition وVercel، كما عُرض ChatGPT ضمن الوكلاء القادرين على المشاركة.

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

موقع Slack Code في استراتيجية Salesforce

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

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

الخلاصة

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

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

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

كيف تسير مهمة البرمجة داخل القناة؟

يمكن أن يبدأ سير العمل بفكرة أو بلاغ عن خلل أو طلب لتحديث موقع أو إضافة ميزة جديدة:

1. يذكر أحد أعضاء الفريق وكيلًا برمجيًا مدعومًا.
2. ينشئ الوكيل قناة كود مخصصة للمهمة.
3. يضيف المشاركون المتطلبات والقيود وسياق المشروع.
4. يضع الوكيل خطة ويقترح التغييرات.
5. يراجع الفريق العمل، بما في ذلك فروق الشيفرة والمعاينات المتاحة.
6. يستطيع الأعضاء توجيه الوكيل إلى مسار آخر أو الموافقة على الخطوة التالية.

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

لماذا يشارك مديرو المنتجات والمصممون؟

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

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

هذا لا يعني أن وكيل الذكاء الاصطناعي أصبح صاحب القرار النهائي؛ بل يغيّر مكان التعاون ويجعل عمل الوكيل متاحًا للفحص أمام عدد أكبر من أصحاب المصلحة.

الموافقة البشرية تظل أساسية

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

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

سجل قابل للبحث وضوابط Slack المعتادة

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

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

أما الفائدة العملية فهي استمرارية السياق: إذ يمكن أن تبقى متطلبات المشروع وقراراته ومراجعاته ونشاط الوكيل مرتبطة بالمحادثة التي بدأ منها العمل.

التوافر والتكاملات عند الإطلاق

قالت Salesforce إن Slack Code متاح على جميع خطط Slack عند الإطلاق. وشملت التكاملات الأولى التي أُعلن عنها وكلاء من Anthropic وGitHub وCognition وVercel، كما عُرض ChatGPT ضمن الوكلاء القادرين على المشاركة.

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

موقع Slack Code في استراتيجية Salesforce

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

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

الخلاصة

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

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