أصبح توليد تطبيق أولي باستخدام وكيل برمجي أسرع بكثير من السابق، لكن المشكلة تبدأ غالبًا بعد كتابة الكود: أين ستضع قاعدة البيانات؟ كيف تضبط المصادقة والتخزين؟ من ينشر التطبيق؟ وكيف تمنع الوكيل من العبث ببيئة Production؟
هنا تحاول Zoho Catalyst 3.0 حل الجزء الذي يأتي بعد توليد الكود. المنصة صُممت كـFull-Stack Cloud يستطيع وكيل البرمجة التعامل معه مباشرة، بحيث ينتقل المشروع من Prompt إلى تطبيق منشور دون تجميع عدة خدمات سحابية يدويًا. والأهم للقارئ الخليجي أن Catalyst يدعم مركز بيانات في السعودية ضمن بنيته متعددة المناطق.
من كتابة الكود إلى تشغيل البنية التحتية
الفرق الجوهري هنا أن وكيل البرمجة لا يكتفي بإنشاء ملفات المشروع. Catalyst يوفر له خدمات Backend وقواعد البيانات والمصادقة والتخزين وServerless Functions والاستضافة وDevOps، ثم يسمح له بالتعامل معها عبر أدوات منظمة.
وتعرض Zoho تكاملات مع Claude وCursor وCodex وGemini وGitHub Copilot وDevin، ما يجعل المنصة أقرب إلى طبقة تشغيل يمكن استخدامها مع أكثر من وكيل برمجي.
Agent Skills: حتى لا يخمّن الوكيل طريقة استخدام المنصة
أحد أهم أجزاء Catalyst 3.0 هو Agent Skills. بدل أن يقرأ الوكيل توثيق المنصة من الصفر أو يخمّن أي خدمة يحتاج إليها، تزوده Skills بمعرفة منظمة عن خدمات Catalyst وSDKs وأنماط النشر والممارسات الصحيحة.
عمليًا، يستطيع الوكيل اختيار الخدمة المناسبة، بناء التطبيق وفق معمارية Catalyst، ثم الانتقال إلى التنفيذ بدل الاكتفاء بإنتاج كود قد يحتاج المطور لاحقًا إلى إعادة هندسته قبل النشر.
MCP يحوّل الوكيل من كاتب كود إلى منفذ
Catalyst يضيف أيضًا MCP Server يستطيع الوكيل من خلاله تنفيذ إجراءات فعلية على البنية التحتية. وتوضح وثائق Zoho إمكانية ربط Catalyst بعملاء MCP، بحيث يستطيع الوكيل التعامل مع موارد المنصة بدل إعطاء المستخدم تعليمات لينفذها يدويًا.
الـWorkflow يصبح أقرب إلى:
صف التطبيق → الوكيل يصمم المعمارية → يكتب الكود → ينشئ الموارد → يربط الخدمات → ينشر إلى بيئة التطوير → تراجع النتيجة → يروّج الإنسان النسخة إلى Production.
وهذه نقلة مهمة عن Vibe Coding الذي ينتهي عند ملفات كود جميلة لا توجد خلفها بنية تشغيل حقيقية.
ماذا عن الأمان عندما يستطيع Agent النشر؟
إعطاء وكيل AI صلاحية التعامل مع البنية التحتية يخلق مخاطرة واضحة، لذلك أهم ما في التصميم ليس فقط قدرة الوكيل على التنفيذ، بل الحدود المفروضة عليه.
Catalyst يفصل بيئة Development عن Production، ويتيح للوكيل ملف صلاحيات مقيّدًا، ويعطل الأوامر المدمرة في الوضع غير التفاعلي، كما يحتفظ بسجلات للتطبيق والمنصة واستدعاءات MCP حتى يمكن تتبع ما نفذه الوكيل. وتوضح Zoho أن الترويج إلى Production يظل إجراءً بشريًا يدويًا، وأن التغييرات بعد الإطلاق قابلة للتتبع والعكس.
لماذا يهم هذا المطور في السعودية؟
هنا تصبح القصة أكثر من تحديث عالمي لأداة برمجة. وثائق Catalyst الرسمية تعرض Saudi Arabia (SA) ضمن مراكز البيانات المدعومة، مع نطاقات API وحسابات مخصصة للسعودية.
هذا لا يعني تلقائيًا أن استخدام Catalyst يحقق كل متطلبات الامتثال لأي مؤسسة سعودية؛ ذلك يعتمد على نوع البيانات والقطاع والمتطلبات التنظيمية الخاصة بالمشروع. لكنه يقدم خيار بنية إقليمية يجب تقييمه عند تصميم التطبيقات التي تتطلب اعتبارات إقامة البيانات.
مثال عملي: من فكرة SaaS إلى تطبيق منشور
تخيل أنك تستخدم Codex لبناء نظام داخلي لإدارة طلبات العملاء. في Workflow تقليدي قد يولد الوكيل الواجهة والكود، ثم تبدأ أنت في اختيار قاعدة بيانات، وإعداد Authentication، وربط Storage، وضبط Backend، ثم إنشاء Pipeline للنشر.
مع Catalyst، الفكرة أن يستطيع الوكيل فهم خدمات المنصة عبر Agent Skills، ثم استخدام MCP وأدوات Catalyst لإنشاء البنية اللازمة وربطها بالمشروع داخل الحدود التي تسمح بها صلاحياته، بينما تبقى Production منفصلة عن مساحة التطوير.
القيمة إذًا ليست «AI يكتب كودًا أسرع»، بل AI يستطيع الانتقال من كتابة الكود إلى تشغيل دورة بناء أكثر اكتمالًا.
هل يلغي Catalyst دور المطور؟
لا. بل ينقل جزءًا من العمل المتكرر من المطور إلى الوكيل. القرارات المعمارية الحساسة، مراجعة الأمان، اختبار التطبيق، سياسات البيانات ومراقبة Production تبقى مسؤوليات هندسية لا ينبغي تحويلها إلى تفويض أعمى.
النموذج الأقوى هنا هو: المطور يحدد الحدود والمعمارية، والوكيل ينفذ الأعمال المتكررة داخل تلك الحدود.
بحسب اهتمامك
برمجة · AI Coding · Agents · MCP · Vibe Coding · Cloud · السعودية والخليج