اعتماد agentic coding افتراضياً هو تغيير في release pipeline، لا مجرّد مفتاح تشغيل

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

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

وتغييرات release pipeline لها كلفة. إن لم تدفعها مقدماً، ستدفعها أثناء الحوادث.

المحرّك هنا هو أن Anthropic ستجعل وضع Claude Code التلقائي مفعّلاً افتراضياً. عبارة “Soon require even less human oversight” تبدو كعنوان إنتاجية. عملياً، هي عنوان governance.

تشغيل agentic coding افتراضياً ليس “autocomplete أفضل”. إنه فاعل جديد داخل منظومة التسليم لديك. عامله كما تعامل مشغّلاً جديداً لـ CI runner، أو متحكماً جديداً بالنشر، أو أسلوباً جديداً لتطبيق database migrations. وإلا فلن تكون قد فعلت سوى نقل الحوادث إلى اليسار وتوسيع نطاقها.

التغيير الخفي: أنت تفوّض صلاحيات، لا مهاماً

معظم الفرق تنظر إلى agentic coding بوصفه تفويضاً للعمل: اكتب وحدة. أعد هيكلة خدمة. أضف اختبارات. حدّث التوثيق. يظل هذا الإطار مريحاً لأن الإنسان ما يزال “يوافق” على pull request.

لكن auto mode يغيّر شكل هذا الاطمئنان. يتبدّل سير العمل من “طلبت منه شفرة” إلى “نفّذ سلسلة إجراءات داخل بيئة وأنتج حالة”. لم تعد وحدة العمل مقطعاً من الشفرة، بل سلسلة قرارات.

عندما تراها بهذه الطريقة، يصبح السؤال الجوهري بسيطاً: ما الصلاحيات التي منحتها للتو، وكيف تقيّدها؟

• صلاحية الإنفاق: tokens، والحوسبة، واستدعاءات API، وأدوات الطرف الثالث.
• صلاحية التغيير: الملفات، والاعتمادات، والإعدادات، وinfrastructure-as-code.
• صلاحية الإفصاح: prompts والسياق اللذان قد يتضمنان أسراراً أو بيانات عملاء.
• صلاحية الدمج: القدرة على إدخال تغييرات بسرعة تجعل المراجعة إجراءً شكلياً.

إن لم تعرّف ذلك صراحة، يصبح الافتراضي هو “أيّاً ما تستطيع الأداة فعله”. هذه ليست سياسة. هذا تفكير تمنّي.

التشغيل الافتراضي يجب أن يطلق قائمة الفحص نفسها التي ترافق أي آلية نشر جديدة

عندما تغيّر شركة release pipeline، لا يقول أحد جاد: “دعونا نرى كيف ستسير الأمور”. تضع ميزانيات. تضيف بوابات. تسجل المصدرية. وتصمم آليات rollback.

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

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

1) ضوابط ميزانية قابلة للإنفاذ، لا مجاملات

تحوّل التدفقات agentic الكلفة المتغيرة إلى ناتج للاستقلالية. جلسة المطوّر العادية فيها احتكاك طبيعي. أما حلقة agent فقد تعمل لساعات، وتستدعي الأدوات مراراً، وتستكشف مساحة حلول واسعة.

ضع ميزانيات على ثلاثة مستويات:

• لكل مستخدم يومياً: لوقف الانزلاق غير المقصود إلى استخدام جامح.
• لكل repo أسبوعياً: لفرض الأولويات وجعل الإنفاق مرئياً لمالكي الشفرة.
• لكل تشغيل workflow: لتقييد نطاق الضرر لحلقة واحدة خاطئة.

ثم قرّر ما الذي يحدث عند بلوغ السقف. ليس رسالة Slack. بل إيقاف مُلزِم، أو خفض إلى نمط غير agentic.

2) بوابات سياسات تفهم القصد، لا الصياغة فقط

بوابات CI الحالية لديك مصممة لمخرجات حتمية: lint، واختبارات وحدات، وتحليل ساكن. هي ضرورية لكنها غير كافية، لأن الأنظمة agentic يمكن أن تغيّر طبيعة مجموعة التغييرات.

أضف بوابات تركز على القصد والنطاق:

• بوابة النطاق: تمنع التغييرات التي تمس أدلة حساسة (auth, billing, crypto, infra) ما لم تُعتمد صراحة.
• بوابة الاعتمادات: تفرض مراجعة للحزم الجديدة، وصور الحاويات الجديدة، ورفع الإصدارات بما يتجاوز patch.
• بوابة البيانات: تمنع نسخ بيانات الإنتاج إلى workspaces أو prompts أو test fixtures.
• بوابة الأسرار: توقف أي workflow يقرأ env vars أو مخازن المفاتيح ما لم تكن خطوة معتمدة بأدوات مُدقَّقة.

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

3) مصدرية تصمد أمام مراجعة حادث

عندما يتعطل شيء ما ستسأل: “لماذا فعلنا هذا؟” إذا كانت الإجابة “الـ agent قرّر”، فأنت تخسر منذ البداية. ليس لأن الذكاء الاصطناعي غير مفيد، بل لأنك لن تتعلم دون قابلية تتبع.

تحتاج إلى مصدرية تربط بين:

• Prompt والسياق: ما التعليمات وما المدخلات المستخدمة.
• استدعاءات الأدوات: ما الأوامر التي نُفذت، وما APIs التي استُدعيت، وما الملفات التي قُرئت.
• النتائج: diffs، ونتائج الاختبارات، ومخرجات البناء، وبيانات النشر الوصفية.
• اعتمادات البشر: من اعتمد ماذا، وفي أي نقطة من السلسلة.

خزّنها كما تخزّن سجلات البناء: غير قابلة للتلاعب بما يكفي للثقة، ومتاحة بما يكفي للتشخيص.

4) خطة rollback وKill switch تم اختبارهما عملياً

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

• مسارات تراجع سريعة: feature flags، وافتراضات نشر آمنة، وmigrations قابلة للتراجع.
• Kill switch للـ agent: تحكم واحد لتعطيل auto mode عبر المؤسسة، أو لكل repo، دون انتظار امتثال كل فريق على حدة.
• أوضاع التجميد: القدرة على قفل المناطق الحساسة على تغييرات بشرية فقط أثناء الحوادث أو التدقيق.

يرتبط ذلك بنمط أوسع كتبت عنه في امتلاك المزيد من الـ stack. كل قدرة جديدة تعني أيضاً طرقاً جديدة للفشل. والاستقلالية تضاعف ذلك ما لم تصمم لوقف الفشل مبكراً.

درس عملي: السرعة بلا control plane تُنتج دين جودة “صامتاً”

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

يدفع agentic coding في الاتجاه نفسه. إذا اعتمدت على “مراجعين أبطال”، ستخسر. المراجعة لا تتوسع جيداً. التحكم يتوسع جيداً.

الدلالة العملية غير مريحة: لا يمكنك “شراء” إنتاجية agentic عبر المقاعد وحدها. تحتاج إلى تمويل المنظومة المحيطة. إن لم تفعل، ستستمر الأداة في إنتاج المخرجات، لكن المؤسسة ستتحمل الكلفة على شكل ضغط حوادث، وإعادة عمل، وتراجع تدريجي في الثقة بالأتمتة.

كيف تطلقه هذا الربع دون تحويل repos إلى كازينو

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

1. حدد مستويات للاستقلالية: اقتراح فقط، PR-author، tool-caller في sandbox، tool-caller في بيئة مشتركة. واربط كل مستوى بضوابط صريحة.
2. اختر repoين: واحد منخفض المخاطر وآخر عالي القيمة من حيث التعلم. تجنب مسار الإيراد الأساسي في البداية، لكن لا تختبئ في مشاريع تجريبية.
3. قم بالقياس قبل التوسع: إنفاق tokens، ووقت الدمج، ومعدل rollback، وعدد الحوادث، و“الوقت البشري لكل تغيير تم شحنه”.
4. أضف بوابات حيث الحوادث مكلفة: auth، billing، infra، تصدير البيانات. لا تحاول تغطية كل شيء دفعة واحدة.
5. درّب على kill switch: نفّذ تمريناً. تأكد أن تعطيل auto mode يوقف التدفقات فعلياً ولا يكسر عمليات البناء.

إن أردت زاوية مكملة، فمقالي السابق Build on the Stack You Have يطبق منطق الإطلاق نفسه على الذكاء الاصطناعي بصورة أشمل: المكاسب التراكمية تأتي من تبنٍّ مضبوط، لا من انتشار متحمّس غير منضبط.

رأيي: الاستقلالية الافتراضية مقبولة، لكن فقط للفرق القادرة على إثبات التحكم

سيصبح auto mode افتراضياً أمراً عادياً. السؤال هو: هل يصبح عادياً بطريقة تزيد موثوقية الأنظمة، أم بطريقة تسرّع تغييرات بلا مالك؟

إذا تعاملت مع agentic coding كأنه تغيير في release pipeline، فستنتهي بسجلات أفضل، وسياسات أوضح، وقابلية تراجع كان يفترض أن تبنيها أصلاً. وإذا تعاملت معه كتفضيل مطوّر، فستوسع المشكلات نفسها التي لديك: ملكية غير واضحة، وبوابات ضعيفة، ومراجعات حوادث تنتهي بهزّ الأكتاف.

لست بحاجة إلى الإبطاء. أنت بحاجة إلى جعل الاستقلالية مفهومة، ومحددة الحدود، وقابلة للإيقاف.