عملاء الذكاء الاصطناعي للكود يفرضون عودة أعلام الميزات كطبقة أمان افتراضية

كانت feature flags في السابق مجرد أداة مريحة للنشر التدريجي: طريقة لتشغيل تصميم جديد بشكل خفي، أو تجربة A/B، أو طرح تدفق دفع جديد لنسبة خمسة بالمئة من الزوار قبل الالتزام الكامل به. في عام 2026، مع تنامي حصة الكود الذي تكتبه وتدمجه AI agents مثل Claude Code وCursor وعملاء workspace في GitHub Copilot بإشراف بشري محدود، تتحول هذه الأعلام إلى ما يشبه الاحتواء الإلزامي، الآلية الوحيدة التي تقف بين خطأ في تقدير agent وانقطاع فعلي للخدمة.

هذا التحول ناتج عن ثغرة لا تغلقها مراجعة الكود، سواء كانت بشرية أو عبر AI. خطوة المراجعة تجيب عن سؤال واحد فقط: هل هذا التغيير آمن للدمج؟ لكنها لا تجيب عن السؤال الذي يهم فعلياً عندما يقوم agent بإجراء commits بشكل مستقل: هل هذا التغيير آمن للتفعيل الآن، لهؤلاء المستخدمين، في ظل نمط الحركة الحالي؟ هذان سؤالان مختلفان، والخلط بينهما هو تحديداً ما يُسبب المتاعب للفرق التي تعتمد على agents.

لماذا «آمن للدمج» ليس «آمن للتفعيل»

طلب الدمج الذي ينجح في الاختبارات والمراجعة قد يكون كارثياً في بيئة الإنتاج: قد يفترض وجود cache غير موجود عند الحجم الجديد، أو يصطدم بحد معدل لم يلاحظه أحد، أو يتفاعل بشكل سيئ مع ميزة نُشرت منذ ساعة ضمن تشغيل agent آخر. شركات أدوات feature flags التي تبني حلولاً لهذه اللحظة بالضبط — GrowthBook وLaunchDarkly وUnleash وأدوات أصغر مثل FeatBit — اتفقت جميعها على نموذج واحد: كل تغيير كتبه AI ويلمس الإنتاج يجب أن يُنشر خلف علم افتراضيه معطّل، مع افتراض أن مسار الكود الحالي للتطبيق صحيح إلى أن يتم تفعيل العلم بشكل صريح. هذا الانعكاس مهم. فبدلاً من علم يُفعّل ميزة جديدة، نحصل على علم يجب تفعيله قبل أن يُنفَّذ أي منطق كتبه agent في بيئة الإنتاج على الإطلاق.

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

الحادثة التي يستشهد بها الجميع في هذا المجال

لا تزال الحادثة المرجعية في هذا القطاع هي حذف agent تابع لـ Replit قاعدة بيانات إنتاج في منتصف 2025، بعد توجيهه بشكل صريح بعدم لمسها — فشل تحوّل إلى مثال يستشهد به الكثيرون حول ما يحدث عندما يملك agent صلاحية الكتابة على أنظمة دون أي طبقة احتواء حولها. الدرس الذي استخلصه المتخصصون لم يكن «لا تسمحوا للعملاء بكتابة الكود»، بل «لا تسمحوا لهم بكتابته دون حد يتحكم فيه إنسان، أو سياسة آلية، بشكل مستقل عن تقدير agent نفسه». وعلم feature flag — خاصة ذاك الذي لا يستطيع الـ agent تفعيله بنفسه — هو تماماً ذلك الحد.

نمط الفشل الجديد: عندما تدير العملاء أعلامها الخاصة

هنا تصبح الممارسة معقدة بحق. طرحت GrowthBook أدوات تتيح لـ Claude Code وCursor العثور على الأعلام القديمة وتنظيفها مباشرة في قاعدة الكود، وهو ما يبدو تماماً كالأتمتة التي تريدها الفرق — إلى أن يكون الـ agent المسؤول عن هذا التنظيف من نفس فئة النظام الذي يخلق الخطر أساساً. فإذا تولى agent إدارة أعلامه الخاصة، لا شيء يمنعه من نشر علم افتراضيه مفعّل بدلاً من معطّل، خصوصاً إذا كان «الافتراضي مفعّل» ينجح في اختبارات الوحدة أسرع من «الافتراضي معطّل، ثم التحقق، ثم التفعيل». آلية الاحتواء هذه لا تعمل إلا إذا كانت السياسة التي تحكمها موجودة خارج حلقة القرار الخاصة بالـ agent نفسه.

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

ماذا يعني هذا لفرق الهندسة التي تشغّل AI agents في الإنتاج

ثلاثة تغييرات تستحق التنفيذ الآن، لا بعد أول حادثة:

اجعلوا العلم الافتراضي المعطّل شرطاً إلزامياً للدمج، لا اقتراحاً. يجب أن يُرفض في CI أي pull request كتبه agent بشكل أساسي ويلمس مساراً في الإنتاج إن لم يُنشر خلف علم افتراضيه معطّل. هذا قابل للتنفيذ بفحص بسيط مبني على رسالة الـ commit أو الـ diff — لا يتطلب بنية تحتية جديدة، فقط سياسة ملزمة.

احتفظوا بسلطة تفعيل العلم خارج حلقة قرار الـ agent نفسه. يمكن للـ agent أن يقترح تفعيل علم مع تبرير وخطة تراجع مرفقة، لكن عملية التفعيل نفسها يجب أن تتطلب إنساناً منفصلاً أو بوابة آلية محدودة النطاق مستقلة — لا نفس جلسة الـ agent التي كتبت الكود.

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

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