سياسة AI code review: ضوابط الكود المولّد بالذكاء الاصطناعي

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

بات هذا الفصل ضرورياً الآن. ففي 17 أغسطس 2026، كشفت Wiz عن ثغرة حقن حرجة في GitHub Actions داخل مستودع عام تابع لـ Snowflake. وأدرجت عملية squash commit النهائية Copilot Autofix كمؤلف مشارك، بينما اعتبرت مراجعة GitHub الأمنية المدعومة بالذكاء الاصطناعي أن التغيير سليم. وأوضحت Wiz صراحة أنه لا يُعرف ما إذا كان تعديل الكود نفسه قد تم بمساعدة الذكاء الاصطناعي. وبعد خمسة أيام من دخول الثغرة حيز التشغيل، اكتشفها وكيل أمني ذاتي التشغيل واستغلها ضمن اختبار مصرح به.

وتفسر حسابات التكلفة سبب استمرار الفرق في طلب الأتمتة. فالفريق الذي يعالج 50 طلب سحب أسبوعياً، بواقع 30 دقيقة للمراجعة البشرية الأولية، ينفق 25 ساعة عمل هندسية. وعند تكلفة شاملة افتراضية قدرها $120 للساعة، يصل ذلك إلى $3,000 أسبوعياً قبل أي مراجعة أعمق. وتقدّر GitHub حالياً تكلفة مراجعة Copilot بما بين $0.05 و $1 من أرصدة الذكاء الاصطناعي عند مستوى الجهد Lite، أو بين $0.25 و $5 عند مستوى Balanced، إضافة إلى دقائق GitHub Actions. أصبحت الجولة الأولى رخيصة؛ أما سلطة الموافقة فلم تصبح كذلك.

ماذا تفعل سياسة AI code review فعلياً؟

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

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

يمكن اعتماد النص الآتي جوهراً للسياسة:

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

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

اعتمد ثلاثة مسارات للمراجعة

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

كيف تعمل السياسة بعيداً عن المصطلحات المعقدة؟

يتكون سير العمل من ست بوابات، تنتج كل واحدة منها دليلاً يستطيع المراجع التالي فحصه.

1. أفصح عن المساعدة. أضف إلى قالب طلب السحب حقول AI-assisted وtool وscope وhuman owner وtests run. يملك صاحب التغيير مسؤولية كل سطر، سواء كتب الذكاء الاصطناعي دالة واحدة أم المسودة الأولى كاملة.
2. صنّف المخاطر. يربط ملف سياسة صغير المسارات وأنواع التغييرات بفئات اعتيادي أو حساس أو حرج. لا ينبغي أبداً أن يسلك تغيير في .github/workflows/ المسار نفسه الذي يسلكه تصحيح خطأ مطبعي في التوثيق.
3. شغّل الفحوص الحتمية أولاً. تعني الحتمية أن المدخل نفسه ينتج نتيجة النجاح أو الفشل نفسها. ابنِ المشروع، وافحص الأنواع، وشغّل lint والاختبارات، وابحث عن الأسرار، ودقّق التبعيات، ونفّذ تحليلاً أمنياً ساكناً قبل طلب رأي من نموذج آخر. وتضع إرشادات GitHub نفسها لمراجعة الكود المولّد بالذكاء الاصطناعي الاختبارات المؤتمتة والتحليل الساكن أولاً.
4. استخدم الذكاء الاصطناعي ناقداً. اطلب منه البحث عن الحالات الناقصة، والتعارض مع المعمارية، والاختبارات المحذوفة، وواجهات API المتوهَّمة، والحزم المشبوهة، وتغييرات الصلاحيات. استخدم مراجعة بجهد أعلى للأعمال الحساسة أمنياً أو العابرة للخدمات، ولا تسمح بأن تستوفي المراجعة الذاتية للوكيل الذي كتب الكود متطلبات البوابة.
5. اجعل الحكم النهائي بشرياً. يتحقق المراجع من القصد، ويختبر السلوك عالي المخاطر، ويتحدى التبعيات الجديدة، ويقرر إن كانت التغييرات تلائم النظام. تعليقات AI خيوط للتحقق وليست نتائج مثبتة، إلى أن يؤكدها شخص أو أداة حتمية.
6. أعد الضبط بعد كل push. ألغِ الموافقات القديمة، وأعد تشغيل الفحوص المطلوبة، واطلب مراجعة أخرى عند وصول عمليات commit جديدة. وتشير GitHub إلى أن مراجعة Copilot التلقائية تعمل عادة مرة واحدة ما لم يُفعّل خيار المراجعة عند كل push.

هناك ضابطان أقل وضوحاً ينبغي إدراجهما في السياسة. أولاً، تحتاج ملفات التبعيات إلى ماسح خاص بها، لأن GitHub Copilot code review يستثني ملفات مثل package.json وGemfile.lock. ثانياً، يجب إخضاع التغييرات في ملفات تعليمات الذكاء الاصطناعي للمراجعة الحرجة. يقرأ Copilot تعليمات المستودع وتعليمات الوكلاء والمهارات من فرع المصدر الخاص بطلب السحب، ما يعني أن التغيير المقترح قد يعدّل التعليمات المستخدمة لمراجعته هو نفسه.

سبعة مواضع تظهر فيها قيمة السياسة أولاً

1. فرق المنصات التي تشغّل وكلاء البرمجة عبر مستودعات كثيرة

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

2. فرق SaaS التي تحمي المصادقة والفوترة وبيانات العملاء

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

3. فرق DevOps التي تصون مسارات CI/CD

تعامل مع ملفات سير العمل كبنية إنتاجية قابلة للتنفيذ. وجّه كل تغيير إلى مالك كود في DevOps، وافحص الإدراج المباشر لمحتوى غير موثوق آتٍ من issue أو طلب سحب، ودقّق صلاحيات token، واشترط خطة تراجع. تجعل حالة Wiz العائد ملموساً: فقد وصل عنوان issue عام إلى أمر shell، وكان بوسع token المكشوف قراءة مشاريع Jira داخلية. تلتقط السياسة هذا النوع من الأخطاء قبل أن يبدأ النقاش حول ما إذا كان المؤلف الأصلي إنساناً أم ذكاءً اصطناعياً.

4. قادة الهندسة الذين يطرحون Copilot أو Codex أو Claude Code

يستطيع مسؤول الطرح فصل إذن استخدام الأداة عن إذن الدمج. يحصل المطورون على توليد سريع ومراجعة أولية، فيما تظل قواعد الفروع تشترط موافقة بشرية، ونجاح مهام سير العمل، ومراجعة مالك الكود. والنتيجة تبنٍّ مدعوم بطبقة رقابة قابلة للتدقيق. وقد تساعد مراجعة وضعي Codex المحلي وGitHub في اختيار الأداة، لكن البوابة البشرية نفسها يجب أن تبقى مهما تغيّر المورد.

5. مشرفو المشاريع مفتوحة المصدر أمام طلبات سحب ضعيفة السياق

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

6. الوكالات التي تسلّم برمجيات مملوكة للعملاء

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

7. المؤسسون المنفردون الذين يطلقون المنتجات بمساعدة وكيل برمجة بالذكاء الاصطناعي

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

ما المنتج الذي يمكن بناؤه انطلاقاً من ذلك؟

السوق يدفع بالفعل مقابل المراجعة المؤتمتة. يبلغ طلب Google نحو 1,600 عملية بحث أمريكية شهرياً عن "ai powered code review platform"، و 1,300 عن "ai code review"، و 590 عن "ai code review tools". وتتقاضى CodeRabbit حالياً $24 لكل مطور شهرياً ضمن خطط Pro السنوية، و $48 لخطة Pro Plus. وتبدأ Qodo من $30 شهرياً. الفرصة ليست في روبوت آخر يعلّق على كل طلب سحب، بل في طبقة رقابة تقرر أي مراجعة يُعتد بها فعلياً.

1. بوابة طلبات سحب قائمة على policy-as-code، وهي أقوى فرصة

ابنِ GitHub App لقادة الهندسة والأمن يحوّل ملف سياسة قصيراً إلى فحوص مطلوبة. يقرأ التطبيق المسارات المتغيرة، ويتحقق من الإفصاح عن استخدام الذكاء الاصطناعي، ويحدد مسار المخاطر، ويطلب مالكي الكود المناسبين، ويتأكد من تشغيل الماسحات المطلوبة، ويبطل الموافقات القديمة، ويصدر إيصال تدقيق.

يدعم الطلب هذه الفئة: تحصد عبارة "ai powered code review platform" نحو 1,600 عملية بحث أمريكية شهرياً، فيما تحصد "ai code review" عدد 1,300 بتكلفة CPC تبلغ $63.85. يحتاج أصغر إصدار قابل للبيع إلى GitHub App، وملف سياسة للمستودع، وفحص حالة، وخدمة لتوجيه المراجعين، وجدول تدقيق. أما العقبة فهي إرهاق الإعداد؛ ولن ينجح المنتج إلا إذا غطت الإعدادات الافتراضية الجيدة حزم التقنيات الشائعة، وكان شرح الاستثناءات سهلاً.

2. موجّه المراجعين للملفات الحرجة

ابنِ أداة أضيق نطاقاً لفرق المنصات وAppSec. تراقب الأداة مسارات مثل مهام سير العمل، والبنية التحتية، وعمليات الترحيل، والمصادقة، وملفات السياسات؛ ثم ترفع جهد المراجعة، وتستدعي المالك المناسب، وتفرض إعادة المراجعة بعد كل push. ويمكنها تمرير الكود الاعتيادي عبر جولة منخفضة التكلفة، مع حجز الاستدلال المكلف والوقت البشري للتغييرات البرمجية الحرجة.

تحصد عبارة "AI code review tools" نحو 590 عملية بحث أمريكية شهرياً، وتحمل نية تجارية، وتُظهر اتجاهاً سنوياً بنسبة 50% في مجموعة بيانات الكلمات المفتاحية. وتضيف عبارة "Secure code review" عدد 170 عملية بحث شهرياً بتكلفة CPC تبلغ $50.19. يتكون MVP من قواعد للمسارات، وتكامل مع CODEOWNERS، وواجهة check-run، وتوجيه للمراجعات يراعي الميزانية. أما العقبة فهي تمدد الفئة؛ إذ ينبغي للأداة أن تكمل SAST وفحص الأسرار وتحليل التبعيات، لا أن تسوّق نفسها بديلاً عنها.

3. إيصال منشأ تغييرات الذكاء الاصطناعي

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

توجد نحو 210 عمليات بحث أمريكية شهرياً عن "ai generated code detector"، بتكلفة CPC تبلغ $16.70. يشير هذا الطلب إلى قلق حقيقي، لكن اكتشاف المؤلف هو الوعد الخطأ للمنتج. النسخة القابلة للبيع تمنح المشترين دليلاً على المراجعة والمسؤولية بدلاً من ذلك. أما العقبة فهي المشاركة: إذا استطاعت الفرق تجاوز الإفصاح، تحول الإيصال إلى إجراء شكلي. حماية الفروع وتكامل الهوية هما جوهر المنتج، وليسا إضافتين اختياريتين.

كما أن فجوة الاستشهادات ما زالت مفتوحة. لم يُظهر فحص استشهادات ChatGPT أي مصادر متكررة يُستشهد بها لعبارة "ai code review tools". ويمكن لمنتج ينشر مخطط سياسة صارماً وشفافاً ومحدد الإصدارات أن يصبح طبقة مرجعية، فيما يبيع منتج الإنفاذ المبني خلفها.

الحدود والخلاصة الصريحة

مراجعة AI مرشح مفيد، وليست حجة أمان مكتملة. تقول GitHub إن مراجعة Copilot قد تفوّت مشكلات ويجب استكمالها بمراجعة بشرية. كما أنها تستثني بعض الملفات، وقد تتراجع إلى وضع أقل قدرة عند غياب runners، وتتوقف عند نفاد ميزانيات أرصدة الذكاء الاصطناعي. ولا ينبغي لأي من هذه الظروف أن يخفض معيار الدمج بصمت.

للإصلاح الذاتي بالوكلاء الحد نفسه. يستطيع نظام GitHub المتاح في public preview استكشاف قاعدة كود، واقتراح إصلاح، وإعادة تشغيل CodeQL، وفتح مسودة طلب سحب، وغالباً ما يفعل ذلك خلال دقيقتين إلى أربع دقائق. وتقول GitHub أيضاً إنه يعمل وفق best-effort، ولا يستطيع تأكيد إصلاح بعض الاستعلامات المخصصة أو الموسّعة أمنياً، ولا يضمن جودة إصلاحات التنبيهات الصادرة من جهات خارجية. نجاح إعادة التشغيل باللون الأخضر يثبت أن أداة كشف واحدة توقفت عن الشكوى، لكنه لا يثبت سلامة سلوك الأعمال أو نموذج الصلاحيات أو سير العمل المحيط.

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

خطوة يوم الاثنين

على مدير الهندسة، يوم الاثنين، إضافة خمسة حقول إلى قالب طلب السحب: AI-assisted، وtool، وscope، وhuman owner، وtests run. ثم يصنّف .github/workflows/ والمصادقة والمدفوعات والبنية التحتية للإنتاج والأسرار وعمليات الترحيل المدمرة على أنها حرجة. وبعد ذلك يشترط نجاح CI، ومراجعة مالك الكود، وإبطال الموافقات القديمة، وموافقة شخص ثانٍ على تلك المسارات. وهذا يكفي لتحويل رأي حول كود الذكاء الاصطناعي إلى نسخة أولى قابلة للإنفاذ.

هل ينبغي أن أراجع الكود الذي كتبه الذكاء الاصطناعي؟

نعم. شغّل الاختبارات والماسحات الحتمية أولاً، واستخدم مراجعة AI كناقد إضافي، ثم حمّل شخصاً محدداً مسؤولية الدمج. ويجب ألا تستوفي مراجعة AI قاعدة الموافقة البشرية المطلوبة.

هل يستطيع ChatGPT مراجعة الكود؟

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

ما أفضل AI لمراجعة الكود؟

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

هل توجد أداة مجانية لمراجعة الكود بالذكاء الاصطناعي؟

توجد مكونات مجانية أو مشمولة ضمن خدمات قائمة. لا يتطلب Copilot Autofix الكلاسيكي من GitHub اشتراكاً في Copilot، ولا يستهلك أرصدة الذكاء الاصطناعي للمستودعات المؤهلة، كما تستطيع أدوات CI الحالية فرض كثير من الفحوص الحتمية. لكن السياسة المتكاملة تظل بحاجة إلى الإعداد والمراجعة البشرية.

إذا أردت دمج بوابة المراجعة هذه في سير عملك الهندسي، فتعرّف إلى أنظمة الذكاء الاصطناعي للإنتاج.