أدوات البرمجة بالذكاء الاصطناعي لفرق التطوير: خطة إدخال بنقاط مراجعة

حالة توضيحية. بعد ظهر يوم خميس، وفي الأسبوع الثاني من تجربة أدوات البرمجة بالذكاء الاصطناعي في شركة ناشئة للمدفوعات في عمّان، يطلب مطوّر من وكيل برمجة (أداة ذكاء اصطناعي تكتب الكود وتعدّله بنفسها) أن يصلح اختباراً فاشلاً. ينجح الاختبار لأن الوكيل خفّف شرط التحقق فيه، ثم يضيف سطراً لتتبّع الأخطاء يحفظ في السجلات كل بيانات الطلبات الواردة، ويعدّل في طريقه 40 ملفاً آخر لترتيبها شكلياً. ويوافق عليه مراجع واحد وأمامه تغيير من 1,900 سطر قبل عطلة نهاية الأسبوع.

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

موقفنا واضح: ضعوا القواعد المشتركة والصلاحيات ونقاط المراجعة الإلزامية أولاً، ثم زيدوا عدد المستخدمين. والثمن أن يكون أول أسبوعين أبطأ، لأن الوكيل سيتوقف ليطلب الإذن أكثر، وستُقسَّم طلبات الدمج (pull requests)، أي التعديلات التي تُعرض للمراجعة قبل إضافتها إلى الكود الأساسي، إلى أجزاء أصغر. في المقابل يصل كل تغيير يكتبه الوكيل صغيراً، ومرتبطاً بمهمة واضحة، ويراجعه شخص غير الذي طلبه. والخطوات الخمس التالية تصلح سواء استخدمتم Claude Code أو Cursor أو GitHub Copilot أو OpenAI Codex.

الخطوة 1: اكتبوا قواعد الفريق مرة واحدة داخل المستودع

أدوات البرمجة بالذكاء الاصطناعي الأربع تقرأ تعليمات ثابتة من ملفات داخل المستودع، لذلك تستطيعون حفظ قواعد الفريق مع الكود في نظام إدارة الإصدارات (Git). وبحسب الوثائق الرسمية لكل شركة كما راجعناها في 19 أكتوبر 2026: يقرأ Claude Code ملف CLAUDE.md الخاص بالمشروع الذي يتشاركه الفريق عبر Git، ويمكنه قراءة AGENTS.md إذا لم يوجد ملف CLAUDE.md؛ ويقرأ OpenAI Codex ملفات AGENTS.md قبل أن يبدأ أي عمل؛ ويحفظ Cursor قواعد المشروع في المجلد ‎.cursor/rules‎ ويدعم AGENTS.md؛ ويقرأ GitHub Copilot الملف ‎.github/copilot-instructions.md‎ وملفات AGENTS.md.

ننصح بملف AGENTS.md واحد يكون هو المرجع، وأي ملف خاص بأداة معيّنة يبقى قصيراً ويستورده (في Claude Code مثلاً، ملف CLAUDE.md فيه السطر @AGENTS.md، لأن Claude Code لا يقرأ AGENTS.md إذا وُجد ملف CLAUDE.md)، حتى لا تتحول أربع أدوات إلى أربع مجموعات قواعد مختلفة. واجعلوه أقصر من صفحتين. هذا قالب مختصر:

• البناء والاختبار: الأوامر كما تُكتب بالضبط، وقاعدة "شغّل الاختبارات قبل أن تقول إن المهمة انتهت".
• حدود التغيير: "عدّل الملفات التي تحتاجها المهمة فقط، ولا تُعِد كتابة كود لم يُطلب منك، وموضوع واحد في كل طلب دمج".
• مناطق حساسة: تعديلات بنية قاعدة البيانات، ومنطق الدفع، وتسجيل الدخول، وملفات البنية التحتية تحتاج مراجعاً محدداً بالاسم.
• الاختبارات: "لا تُضعف شرط تحقق ولا تحذفه كي ينجح الاختبار، واشرح سبب أي تعديل على اختبار".
• البيانات: "لا بيانات عملاء حقيقية في بيانات الاختبار أو السجلات أو المحادثات مع الوكيل؛ استخدم السجلات الوهمية في المجلد ‎/fixtures‎".
• اللغة: أين توجد النصوص العربية التي يراها المستخدم، ووجوب فحص اتجاه الصفحة من اليمين إلى اليسار بعد أي تعديل على الواجهة.

لكن انتبهوا إلى حدّ مهم: يقول توثيق Claude Code إن هذه الملفات معلومات يقرؤها الوكيل ليفهم المشروع، وليست إعدادات مُلزِمة، أي أن الوكيل قد يخالفها. وما يجب ألا يحدث أبداً مكانه الخطوة 2 أو الخطوة 3.

الخطوة 2: حددوا الصلاحيات في الإعدادات وليس في التعليمات المكتوبة

الصلاحيات تحدد ما يستطيع الوكيل فعله دون أن يسأل. اضبطوها من مكان واحد، واحفظوها في المستودع.

• Claude Code: يشرح توثيق إعدادات Claude Code ملف إعدادات المشروع المشترك ‎.claude/settings.json‎ الذي يحفظه الفريق في نظام إدارة الإصدارات، وقواعد السماح والسؤال والمنع (ومن أمثلته منع قراءة ملفات ‎.env‎)، والإعدادات التي تديرها المؤسسة ولها الأولوية على كل المستويات الأخرى.
• OpenAI Codex: تقول صفحة الموافقات والأمان في توثيق Codex إن الوكيل يعمل والوصول إلى الشبكة مغلق في الوضع الافتراضي، وتوصي بوضع Auto للمجلدات الخاضعة لإدارة الإصدارات، أي الكتابة داخل مجلد العمل مع طلب الموافقة عند الحاجة. أبقوا هذا الوضع، واجعلوا الوصول الكامل استثناءً يوافق عليه شخص محدد بالاسم.
• Cursor: قواعد المشروع في ‎.cursor/rules‎ محفوظة في نظام إدارة الإصدارات، وفي خطتي Team وEnterprise يستطيع مديرو الحسابات وضع قواعد للفريق من لوحة التحكم وجعلها إلزامية.
• GitHub Copilot cloud agent: بحسب توثيق GitHub، لا يستطيع الوكيل رفع تعديلاته إلا إلى فرع واحد (فرع طلب الدمج الذي طُلب منه العمل عليه، أو فرع جديد يبدأ اسمه بـ ‎copilot/‎)، ووصوله إلى الإنترنت مقيّد، ولا تعمل مهام GitHub Actions على طلب الدمج الذي يفتحه، في الوضع الافتراضي، حتى يوافق عليها مستخدم لديه صلاحية الكتابة (ويمكن تغيير هذا الإعداد، فأبقوه كما هو).

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

الخطوة 3: ضعوا نقاط المراجعة حيث لا يستطيع الوكيل تجاوزها

المراجعة تكشف ما لم تمنعه القواعد والصلاحيات، لذلك اجعلوها شرطاً في منصة Git نفسها. على GitHub تسمح قواعد حماية الفروع باشتراط عدد محدد من الموافقات قبل الدمج، وموافقة المسؤولين عن الكود (code owners)، وإلغاء الموافقات القديمة عند إضافة تعديلات جديدة، وموافقة شخص غير الذي رفع آخر تعديل، ونجاح الفحوص الآلية. وإن كنتم على منصة أخرى، فابحثوا عن الإعدادات المقابلة قبل بدء التجربة.

ويضيف GitHub في صفحة المخاطر وطرق الحد منها الخاصة بـ Copilot cloud agent قاعدة مفيدة: المستخدم الذي طلب من الوكيل فتح طلب الدمج لا يستطيع الموافقة عليه. ننصح بالقاعدة نفسها في كل الأدوات: من طلب العمل من الوكيل هو صاحب التغيير، وليس مراجعه.

وأضيفوا قاعدة لا تفرضها أي منصة: طلب الدمج الذي لا يستطيع المراجع قراءته جيداً في نحو 20 دقيقة يُعاد إلى صاحبه لتقسيمه. ولو طُبّقت هذه القاعدة وحدها لأوقفت طلب يوم الخميس في القصة أعلاه.

الخطوة 4: أبعدوا الأسرار والبيانات الحقيقية عن متناول الوكيل

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

1. منع القراءة: قواعد منع لملفات ‎.env‎ ومخازن المفاتيح ومجلدات بيانات الدخول إلى السحابة، في إعدادات كل أداة توفّر ذلك (مثل قواعد المنع في Claude Code)، محفوظة مع المستودع.
2. منع الرفع: ميزة الحماية عند الرفع (push protection) في GitHub توقف أي رفع يحتوي على أسرار، وهذه الحماية على مستوى المستودع غير مفعّلة افتراضياً، وتحتاج إلى تفعيل GitHub Secret Protection. فعّلوها قبل التجربة، لا بعد أول تسرّب.
3. بيانات وهمية: بيانات الاختبار وملفات التعبئة الأولية لقاعدة البيانات وما يُكتب للوكيل كلها تستخدم سجلات غير حقيقية. فعلى سبيل المثال، يمكن لفريق تقنية صحية في الرياض أن يحفظ في المستودع بيانات مرضى مولّدة آلياً، حتى لا يلصق أحد سجلاً حقيقياً في محادثته مع الوكيل.

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

الخطوة 5: قيسوا جودة التسليم لا عدد الأسطر

عدد الأسطر التي كتبها الوكيل يبيّن كم كُتب، ولا يبيّن هل أصبح الفريق يسلّم برمجيات أفضل. ننصح بخط أساس، أي قياس الوضع الحالي خلال الأسابيع الأربعة السابقة للتجربة، ثم المقارنة به بمقاييس يفهمها الفريق. يذكر دليل DORA لمقاييس تسليم البرمجيات (آخر تحديث 5 يناير 2026) خمسة مقاييس، منها نسبة التغييرات الفاشلة، أي نسبة عمليات النشر التي تحتاج تدخلاً فورياً بعدها، ونسبة إعادة العمل، أي نسبة عمليات النشر غير المخطط لها التي سببها عطل في النظام الذي يستخدمه العملاء (بيئة الإنتاج).

وتابعوا إلى جانبها هذه الأرقام، مع الفصل بين طلبات الدمج التي ساعد فيها الوكيل وغيرها:

• الحجم الوسيط لطلب الدمج (القيمة التي تقع في المنتصف)، والوقت حتى أول مراجعة؛
• طلبات الدمج التي تراجع الفريق عنها بعد دمجها أو أُعيد فتحها خلال 14 يوماً؛
• الأسرار التي أوقفتها قواعد المنع أو الحماية عند الرفع، بوصفها إشارة إلى حاجة تدريبية لا درجة تقييم؛
• استبيان قصير من خمسة أسئلة للمطورين كل أسبوعين: أين وفّر الوكيل الوقت، وأين أضاعه.

وإذا ارتفعت نسبة التغييرات الفاشلة مع ارتفاع سرعة التسليم، فأوقفوا إضافة مستخدمين جدد وشدّدوا الخطوة 3 أولاً.

مثالان توضيحيان من الأردن والخليج

مثال توضيحي: شركة برمجيات في عمّان فيها 15 مطوّراً. تبني بوابات إلكترونية لعملائها بواجهات تجمع العربية والإنجليزية، وليس لديها فريق أمن مستقل. تبدأ باستخدام Claude Code مع ستة متطوعين، وملف AGENTS.md مشترك، وقواعد منع محفوظة في المستودع، وموافقة المسؤول عن الكود على أي تعديل في تسجيل الدخول. وإذا أظهرت أرقام الأسبوع الثالث أن طلبات الوكيل يُعاد فتحها بسبب أخطاء في اتجاه الصفحات العربية، يضيف الفريق قاعدة لذلك في AGENTS.md وفحصاً آلياً يقارن لقطات الشاشة.

مثال توضيحي: الفريق التقني الداخلي لمجموعة تجزئة في الرياض. يستخدم المطورون Copilot داخل محرر الكود، وبعضهم يفضّل Cursor. بدلاً من فرض أداة واحدة، يوحّد قائد الفريق القواعد: ملف AGENTS.md واحد تقرؤه الأداتان، وقواعد فريق إلزامية في Cursor، وحصر عمل Copilot cloud agent في الاختبارات والتوثيق خلال الشهر الأول. ثم يسمح للوكيل بتعديل منطق العمل عندما لا تزيد نسبة التراجع عن طلباته على نسبة التراجع عن طلبات المطورين أنفسهم.

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

اختاروا فريقاً واحداً ومستودعاً واحداً وأربعة أسابيع. اكتبوا AGENTS.md في الأسبوع الأول، واحفظوا الصلاحيات وقواعد حماية الفروع قبل أول طلب دمج يفتحه الوكيل، وراجعوا الأرقام مع الفريق في الأسبوع الرابع. تساعدكم خدمة تمكين فرق هندسة البرمجيات بالذكاء الاصطناعي (ET3) على إطلاق Cursor أو Claude Code أو Codex أو Copilot مع قواعد مشتركة وصلاحيات ونقاط مراجعة إلزامية وطريقة واضحة للتعامل مع الأسرار. وتوضح صفحة وكلاء البرمجة أين تناسب هذه الخدمة، ويغطي مختبر التمكين بقية أقسام المؤسسة. وتركّز معسكرات هندسة الذكاء الاصطناعي ومجتمع المطورين (AH5) في عمّان على وكلاء البرمجة وبناء الأنظمة بالوكلاء. وإن لم تكونوا متأكدين من نقطة البداية، فخدمة مسح واقع الذكاء الاصطناعي في شركتكم المجانية محادثة مدتها 45 دقيقة تنتهي بخطوة تالية مكتوبة.

المختبر المرتبط: مختبر التمكين ↖