نعم، لما تكون مراجعة الذكاء الاصطناعي طبقة واحدة من كذا طبقة، مش البوابة الوحيدة. مراجِع الذكاء الاصطناعي يقدر يقرا كل طلب دمج في أي وقت، ويلتقط الحالات المنسية والأنماط غير الآمنة والكود غير الواضح. لكنه كمان ممكن يغلط أو يتعرّض للتضليل، علشان كده الإعداد الآمن بيحاوطه بالاختبارات وحماية الفروع وشخص للتغييرات عالية المخاطر.
نقاط قوة مراجعة الذكاء الاصطناعي، وفين الأشخاص أفضل
| المهمة | مراجِع الذكاء الاصطناعي | الشخص |
|---|---|---|
| اكتشاف الحالات الطرفية المنسية والأخطاء الصغيرة | قوي | جيد، بس بيتعب |
| فحص كل تغيير على قواعدك، في كل مرة | قوي | بيختلف من يوم للتاني |
| تقييم هل التغيير هو قرار المنتج الصح | ضعيف | قوي |
| ملاحظة خطر مش موجود في الكود، زي عقد أو موعد نهائي | ضعيف | قوي |
استخدم التقسيم ده علشان تحدد فين لازم شخص يفضل مشارك. الفحوصات الروتينية للذكاء الاصطناعي، والقرارات اللي محتاجة تقدير بتفضل مع الأشخاص.
خمس طبقات حوالين كل طلب دمج
مفيش فحص واحد المفروض يشيل القرار لوحده. الإعداد الآمن بيرصّ طبقات فوق بعض، كل طبقة بتلتقط حاجة الباقيين بيفوّتوها، وطلب الدمج لازم يعدّي عليهم كلهم بالترتيب.
- الفحوصات الآلية: lint والبناء (build) والاختبارات بتدّي نتيجة نجاح أو فشل مفيش فيها جدال.
- وكلاء المراجعة: وكلاء مستقلين بيقروا التغيير وبيعلّقوا على اللي شكله غلط.
- حلقة الإصلاح: الملاحظات بترجع لوكيل الإصلاح، وبعدها الفحوصات والمراجعين بيشتغلوا تاني.
- شخص: حد إنت محدده بالاسم بيوافق على التغييرات في الأجزاء اللي الغلطة فيها مكلفة.
- حماية الفروع: منصة استضافة الكود عندك بتفرض الفحوصات والمراجعات المطلوبة، مهما كان رأي أي وكيل.
المخاطر اللي لازم تستعد لها
- موافقة غلط: المراجِع بيقول إن التغيير سليم وهو في الحقيقة مش سليم.
- التضليل: نص مخفي في تذكرة أو تعليق أو ملف ممكن يحاول يوجّه المراجِع. OWASP بتحط حقن التعليمات (prompt injection) في المرتبة الأولى في قائمة مخاطر التطبيقات المبنية على النماذج اللغوية الكبيرة.
- صلاحيات زيادة عن اللازم: المراجِع اللي يقدر يقرا الأسرار أو يغيّر في بيئة الإنتاج (production) ممكن يسبب ضرر لو اتعرّض للتضليل.
- إنه يصحّح شغله بنفسه: الوكيل اللي بيراجع الكود اللي هو كتبه بيميل إنه يوافق على نفسه.
إعداد آمن، خطوة بخطوة
- افصل اللي كتب التغيير عن المراجعين. الوكيل اللي كتب التغيير عمره ما بيوافق عليه، وأكثر من مراجِع أفضل من مراجِع واحد.
- خلّي المراجعين يعلّقوا من غير ما يعدّلوا. الملاحظات بترجع لكاتب التغيير علشان يصلّحها، فيكون لكل تغيير مسؤول واحد.
- خلّي الفحوصات الآلية هي البوابة. الاختبارات وفحوصات الأنواع (type checks) وفحوصات الجودة لازم تنجح من جديد بعد كل إصلاح. على GitHub، حماية الفروع تقدر تشترط نجاح الفحوصات ومراجعات بالموافقة قبل دمج أي حاجة.
- قيّد الصلاحيات. شغّل الوكلاء في بيئة معزولة (sandbox) من غير أسرار الإنتاج، وبالصلاحيات اللي الشغل محتاجها بس.
- اختار فين لازم شخص يوافق، زي الأجزاء الحساسة في الكود والإصدار على الإنتاج.
- احتفظ بسجل. كل تعليق مراجعة وكل إصلاح وكل موافقة لازم يبان على طلب الدمج.
مثال عملي: endpoint لاسترداد المبالغ
تذكرة توضيحية، PAY-301، "إضافة endpoint لاسترداد المبالغ": وكيل بيبنيها ويفتح طلب دمج. ودي الطريقة اللي كل طبقة بتتعامل بيها معاه.
| الطبقة | عملت إيه | النتيجة |
|---|---|---|
| الفحوصات الآلية | lint وفحص الأنواع والاختبارات اشتغلوا. اختبار لمبلغ استرداد بالسالب فشل. | اتبعت لوكيل الإصلاح. وبعد commit واحد، التشغيل التاني نجح. |
| وكلاء المراجعة | مراجِع لاحظ إن الـ endpoint مش بيتأكد أبدًا إن المستخدم مسموح له يسترد الدفعة دي. ومراجِع تاني حاول يكسره، ولقى إن مبلغ الاسترداد ممكن يكون أكبر من الدفعة الأصلية. | ملاحظتين، مكتوبين كتعليقات على طلب الدمج. |
| حلقة الإصلاح | وكيل الإصلاح أضاف فحص الصلاحية وحد أقصى للمبلغ. الفحوصات اشتغلت تاني، والمراجعين قروا النسخة الجديدة. | الملاحظتين اتقفلوا، وكل الفحوصات خضراء. |
| شخص | التغيير بيلمس مجلد المدفوعات، وهو موجود في قائمة الموافقين. الموافق بيشوف الملاحظات والإصلاحات والفحوصات الناجحة في مكان واحد. | اتوافق عليه، أو رجع بتعليق. |
| حماية الفروع | منصة استضافة الكود عندك لسه بتشترط فحوصاتها ومراجعتها. | الدمج مسموح بس لأن كل ده نجح. |
لاحظ إن المراجعين عمرهم ما عدّلوا الكود، وإن مفيش طبقة واحدة وافقت على التغيير لوحدها. في حالة زي دي، الملاحظتين من النوع اللي شخص تعبان ممكن يعدّي عليه بسرعة يوم جمعة بعد الظهر.
إيه اللي بيحصل جوه حلقة الإصلاح
الملاحظة بتروح لوكيل الإصلاح ومعاها التعليق نفسه أو سجل الفشل. وكيل الإصلاح بيعدّل الكود، والفحوصات بتشتغل تاني، والمراجعين بيقروا النسخة الجديدة. وده بيتكرر لحد ما كل حاجة تبقى خضراء.
فيه ضمانتين بيحافظوا على نزاهة الحلقة. لو الإصلاح بطّل يقرّب من النجاح، أو مخاطر التغيير زادت، التشغيل بيوقف ويسأل شخص بدل ما يحاول تاني. والاختبار اللي بيفشل بشكل عشوائي بيتعاد ويتصلّح تلقائيًا، علشان اختبار واحد مش مستقر ميوقّفش تغيير سليم.
Dutopilot بيعملها إزاي
في Dutopilot، أعضاء الفريق الافتراضيون في Dutopilot بيقروا كل طلب دمج، وهم أعضاء مستقلين مش هم اللي كتبوا الكود. اللي بيلاقوه بيروح لخطوة إصلاح تلقائية، والاختبارات وفحوصات الجودة بتشتغل تاني قبل أي دمج. الكود بيتعالج في بيئة معزولة (sandbox) مقفولة، وحماية الفروع والمراجعات المطلوبة عندك بتفضل شغّالة زي ما هي.
الأشخاص بيقرروا المعمارية قبل كتابة الكود، وبيقرروا الإصدار على الإنتاج، وتقدر تضيف موافقات في أي مكان تاني. كل تشغيل بيسيب أثر في طلبات الدمج عندك. شوف الخطوات اللي محتاجة موافقة شخص علشان تعرف تختار إزاي.
المسموح للمراجعين
- بيقروا التغيير والكود اللي حواليه، وبيكتبوا تعليقات. مش بيعملوا push لأي كود.
- بيشتغلوا في بيئة معزولة (sandbox) مقفولة من غير أسرار الإنتاج.
- هم أعضاء فريق افتراضيون في Dutopilot غير العضو اللي كتب التغيير، فمفيش حد فيهم بيصحّح شغله بنفسه.
- رأي مراجِع واحد عمره ما بيدمج أي حاجة لوحده. الموافقات والدمج بيحصلوا بس في الأماكن اللي اخترتها، والفحوصات الآلية وحماية الفروع عندك هي اللي بتقرر.
اللي بتجهّزه
- حماية الفرع الرئيسي، مع تحديد الفحوصات اللي بتشغّلها بالفعل كفحوصات مطلوبة.
- قائمة بالموافقين، وأجزاء الكود، زي المدفوعات أو تسجيل الدخول، اللي دائمًا محتاجة موافق.
- درجة الصرامة اللي تحتاجها: أنواع المشاكل اللي المراجعين يوقفوا الدمج بسببها، والأنواع اللي يكتفوا بالتنبيه عليها.
دور Forward Deployed Engineer مع فريقك
كل عميل في Dutopilot بياخد Forward Deployed Engineer (مهندس مخصص يعمل مع فريقك): مهندس من Dutopilot بيشتغل مع فريقك مباشرة. هو مش بيكتب كود منتجك، لكن بيخلّي المراجعة تناسب الكود الخاص بيك وطريقة شغل فريقك.
- بيضبط اللي المراجعين بيدوّروا عليه في الكود الخاص بيك، زي قواعد الأمان وطريقة التسمية عندكم.
- بيختار معاك أجزاء الكود اللي محتاجة موافق محدد بالاسم.
- بيقرا معاك نتائج المراجعة في أول شهر: اللي المراجعين نبّهوا عليه، واللي الأشخاص نبّهوا عليه بعدها، واللي فات من غير ما حد ياخد باله.
- بيشدد الموافقات أو يخففها حسب السجل ده، وبيكمّل الضبط مع تغيّر الكود والفريق.
إزاي تعرف إن الإعداد شغّال
احتفظ بسجل بسيط في أول شهر. لكل طلب دمج، سجّل اللي مراجِع الذكاء الاصطناعي نبّه عليه، واللي شخص نبّه عليه بعده، وهل فيه حاجة فاتت لحد ما احتاجت إصلاح بعدين. لو الأشخاص لسه بيلاقوا مشاكل حقيقية فاتت الذكاء الاصطناعي، شدّد الإعداد. ولو أغلب ملاحظات الذكاء الاصطناعي ضجيج من غير قيمة، عدّل اللي بتطلب منه يدوّر عليه قبل ما تأتمنه على أكثر.
ابدأ صغير ووسّع بالتدريج
ابدأ بمراجعة الذكاء الاصطناعي على جزء قليل المخاطر من الكود، وشخص لسه بيوافق على كل دمج. بعد كام أسبوع، شوف الذكاء الاصطناعي لقى مشاكل حقيقية كام مرة، وكام مرة فاتته مشكلة شخص اكتشفها. خفّف الموافقات في الأماكن اللي سجلها نظيف، وسيبها زي ما هي في باقي الأماكن.
الأسئلة الشائعة
هل مراجعة الذكاء الاصطناعي لازم تحل محل المراجعة البشرية؟
مش في التغييرات المكلفة أو اللي صعب الرجوع فيها. خلّي الذكاء الاصطناعي يلتقط المشاكل الروتينية، علشان الأشخاص يركزوا وقتهم على اللي محتاج تقدير، زي هل التغيير ده هو الصح أصلًا.
هل مراجِع الذكاء الاصطناعي يقدر يوافق ويدمج لوحده؟
بس في الأماكن اللي إنت بتختارها، وبس في التغييرات قليلة المخاطر. الموافقات والدمج بيحصلوا بس في الأماكن اللي اخترتها، ورأي مراجِع واحد عمره ما بيدمج لوحده: الفحوصات الآلية وحماية الفروع عندك بتفضل هي البوابة. ابدأ بإعداد صارم، وخففه بس بعد ما تشوف النتائج.
وإيه الوضع بالنسبة للأسرار وبيانات العملاء؟
خلّيها بعيد عن متناول المراجِع. في Dutopilot الكود بيتعالج في بيئة معزولة (sandbox) مقفولة، ومش بنحتفظ أبدًا بنسخة من المستودع (repository) الخاص بيك، وسجلات التشغيل ونتائج الفحوصات بتتمسح بعد 90 يوم.