من إضافات PHP إلى App Builder: Adobe تُسنِد التحويل إلى وكلاء ذكاء اصطناعي

كل نقاش حول إعادة بناء منصة Magento ينتهي عند الجدار نفسه: الإضافات. فمتجر عمره عشر سنوات يحمل عشرات وحدات PHP — طُوِّرت داخليًا أو اشتُريت ثم عُدِّلت — تعيش داخل صميم عمليات النواة. وهذا بالضبط هو الكود الذي لم تعد نسخة SaaS، أي Adobe Commerce as a Cloud Service، تقبله: كل تخصيص يجب أن يُعاد بناؤه خارجيًا على App Builder. حتى اليوم كان هذا التحويل يُقدَّر يدويًا، وحدةً وحدة، وكثيرًا ما كان هو ما يدفن الملف. قررت Adobe تزويد هذا الورش بأداتين متكاملتين: وكيل هجرة مستضاف، ومهارات رسمية لمساعدي البرمجة الذين تستخدمهم فرقك أصلًا.

وكيل يعمل وفق مخطط معتمد

وكيل التطوير Commerce Developer Agent أداة تستضيفها Adobe ويُدخل إليها بتسجيل الدخول بحساب Adobe، وتغطي سيناريوهين: إنشاء تطبيق App Builder من صفحة بيضاء، أو تحويل إضافة Commerce قائمة. خاصيته المميزة تعني صانعي القرار مباشرة: فهو لا يولّد شيئًا من دون خطة معتمدة. يبدأ الوكيل بإنتاج مخطط معماري مقسّم إلى مراحل، يقرؤه المطوّر ويصحّحه ويعتمده قبل كتابة أي سطر من الكود. ثم تعتمد عملية التوليد على الهياكل الرسمية لـ App Builder: اشتراكات بأحداث Commerce، وWebhooks، وشاشة إعدادات للتاجر، وحفظ للبيانات. تُصدَّر النتيجة أرشيفًا جاهزًا للانضمام إلى مستودعك وسلسلة التسليم لديك.

الوثائق واضحة بالقدر نفسه بشأن الحدود، وهذا يُحسب لها. كل كود مولَّد يجب أن يُراجَع قبل أن يقترب من الإنتاج: تقدّم Adobe الوكيل بوصفه مولّد نقطة انطلاق، لا مطوّرًا مستقلًا. فهو لا يبني التكامل المستمر لديك، ولا بيئتك المحلية، ولا توصيلات API Mesh؛ والجلسة الواحدة تعالج مشروعًا واحدًا فقط، وقد يستغرق التوليد نحو خمس دقائق.

مهارات مفتوحة لمساعديك أنت

الشق الثاني ربما كان الأكثر إثارة للاهتمام للفرق المجهزة أصلًا. تنشر Adobe مهارات رسمية: أدلة عمل قابلة للتنفيذ تعلّم مساعد البرمجة أنماط App Builder الصحيحة — تهيئة تطبيق، والاشتراك في الأحداث، ووضع Webhooks، وإنشاء إعدادات التاجر أو حفظ البيانات أو واجهة إدارة، وتحويل مشروع قائم. تتبع هذه المهارات المعيار المفتوح agentskills.io وتُثبَّت بأمر واحد (npx skills add adobe/skills) في Claude Code أو Cursor أو VS Code Copilot أو Gemini CLI. ويضم المستودع العام adobe/skills، برخصة Apache 2.0، عشرات المهارات — لـ Commerce وكذلك AEM وAnalytics وWorkfront.

الفارق هنا استراتيجي. الوكيل المستضاف يُدخلك إلى أداة Adobe؛ أما المهارات فتُدخل معرفة Adobe إلى أداتك أنت. والفريق الذي يملك أصلًا انضباط المراجعة وقواعده وخط إنتاجه يتبنّى المسار الثاني من دون تغيير شيء في أسلوب التسليم — ومن دون الارتهان لخارطة طريق بوابة ما.

ما الذي يتغير في ملف الهجرة

• التقدير يتغير في طبيعته. لم يعد السؤال الصحيح كم يومًا تستغرق إعادة كتابة كل شيء، بل كم وحدة من وحداتك تندرج ضمن الأنماط المغطاة: الأحداث، وWebhooks، والإعدادات، والتخزين، وشاشات الإدارة. هذه تتحول بسرعة وبكلفة متوقعة؛ أما ما يعدّل مسار الطلب في قلب النظام فيبقى مشروع عمارة حقيقيًا.
• المراجعة تصبح بند الكلفة الأول. يصل الكود أسرع، لكن كل سطر يجب أن يُقرأ؛ فينتقل مطوّروك الكبار من مؤلفين إلى مراجعين. ومن دون بوابة مراجعة متينة — اختبارات قبول، وتكامل مستمر، وقاعدة صارمة بألا يصل شيء إلى الإنتاج من دون قراءة بشرية — لن يفعل المولّد سوى إنتاج الدَّين أسرع.
• قيد المورّد يُوزن قطعةً قطعة. تتبع المهارات معيارًا مفتوحًا وتعمل في المساعد الذي تختاره؛ غير أن الكود الهدف يبقى App Builder، أي بنية Adobe التحتية. التحويل التزام بمنصة: فاتخذ القرار لأجل المنصة، لا لأجل راحة الأداة.

من أين تبدأ

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

كُشف عن الوكيل في مؤتمر Summit في الربيع، ثم أصبح متاحًا للعموم في أواخر سبتمبر، وصار لإدارة التطبيقات App Management مدخلها في لوحة إدارة Commerce. رسالة Adobe لعام 2027 واضحة: لم تعد إعادة كتابة إضافاتك سببًا لتأجيل القرار — فالمورّد يوفّر العمّال. ويبقى عليك توفير ما لا يُولَّد: رئيس الورشة.