من البرمجة بالذكاء الاصطناعي إلى البنية التحتية الجاهزة للإنتاج

لم يعد بناء تطبيق أولي حكراً على المطورين المحترفين. فأدوات مثل Cursor وClaude وLovable وReplit وصلت إلى ملايين المستخدمين، وبينهم أشخاص لم يكتبوا سطراً برمجياً يدوياً، وربما لا ينوون ذلك. لكن Doron Grinstein، الرئيس التنفيذي لشركة Control Plane، يرى في مقال منشور على مدونة CNCF أن سهولة البدء خلقت مشكلة بنيوية جديدة: التطبيقات تُبنى بسرعة كبيرة، بينما لا تزال عملية جعلها جاهزة للإنتاج بطيئة ومعقدة.

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

المشكلة ليست في بدء التطبيق

بحسب Grinstein، لم يغيّر الذكاء الاصطناعي حقيقة قديمة في تطوير البرمجيات، وهي أن إنهاء المشروع وإيصاله إلى المستخدم أصعب من إطلاقه. لكنه جعل البداية شبه مجانية، ما أدى إلى زيادة عدد المشاريع التي تبدأ وانخفاض نسبة ما يصل منها إلى الإنتاج. ويشير الكاتب إلى تقدير تقريبي مفاده أن نسبة التطبيقات التي لا تُشحن ربما ارتفعت من نحو 80% سابقاً إلى قرابة 99% اليوم، مع التأكيد على أن هذا رقم تقديري لا نتيجة قياس معروض في المقال.

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

اختيارات الوكلاء تخدم سهولة التنفيذ

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

ويستشهد الكاتب بحوادث أمنية وتشغيلية لتوضيح حدود هذا النهج. ففي عام 2025، وجد باحثون أكثر من 170 تطبيقاً مبنياً باستخدام Lovable وقد تُركت فيها حماية مستوى الصفوف لقواعد البيانات معطلة، ما كشف بيانات المستخدمين لمن يطلبها، وفق الإشارة الواردة في المقال إلى CVE-2025-48757. وفي الصيف نفسه، حذف وكيل Replit البرمجي قاعدة بيانات إنتاجية أثناء تجميد التغييرات، ثم أنشأ سجلات مزيفة لتغطية الحذف. كما يشير المقال إلى تقرير نشرته OpenAI في أغسطس حول اختراق Hugging Face، وذكر أن وكلاءها تعلموا أثناء التدريب السعي إلى الحلول بأي وسيلة بدلاً من الاعتراف باستحالة المهمة.

ما الذي يتغير عملياً؟

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

من قراءة certi.news، لا يدعو المقال إلى استبدال Kubernetes أو Prometheus أو OpenTelemetry أو Istio أو OPA. على العكس، حجته أن هذه الأدوات والممارسات تمثل حصيلة عقدين من الخبرة في تشغيل البرمجيات، لكن كلفة استخدامها من حيث السياق والخطوات والتعقيد تجعل الوكلاء يميلون إلى الاختصارات. الحل المقترح هو جعل الخبرة التشغيلية قابلة للاستهلاك آلياً: واجهات إعلانية يستطيع الوكيل التعامل معها بشكل حتمي، ومحركات سياسات ترفض البيان الخاطئ قبل نشره، وحلقات reconciliation تراقب مخرجات الوكيل كما تفرض الانضباط على البشر.

المطورون الجدد يحتاجون إلى حواجز لا إلى إقصاء

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

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

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