أدوات مراجعة الكود بالذكاء الاصطناعي نقلت العقبة، لم تُزِلها

كان من المفترض أن تُقلّص أدوات مراجعة الكود بالذكاء الاصطناعي الوقت بين فتح طلب سحب (Pull Request) ودمجه. وقد نجحت في ذلك لمجموعة محدودة من الفحوصات. لكن بالنسبة للمهمة الأساسية للمراجع — تحديد ما إذا كان التغيير صحيحاً وآمناً فعلاً — تُقرّ معظم الفرق التي تشغّل هذه الأدوات على نطاق واسع بأنها استبدلت عقبة بأخرى: الوقت الذي كان يُصرف سابقاً على قراءة الفرق (diff) يُصرف الآن على تحديد أي تعليقات البوت تستحق القراءة.

تجاوز التبني الدليل على الفعالية

وجد استبيان Stack Overflow لعام 2025 أن 47% من المطورين المحترفين استخدموا مراجعة الكود المدعومة بالذكاء الاصطناعي في العام السابق. واستبيان JetBrains لنفس الدورة سجّل 44%. ارتفعت هذه الأرقام بسرعة — أظهر كلا الاستبيانين تقريباً تضاعفاً عن عامين سابقين. التبني، بعبارة أخرى، لم يعد السؤال المثير للاهتمام. السؤال هو ما إذا كانت الأدوات تكشف فعلاً الأخطاء المهمة دون دفنها في الضجيج.

مشكلة الإيجابيات الكاذبة حقيقية، وينبغي التعامل مع أرقام البائعين بحذر

معيار قياس من مارس 2026 من Signal65، اختبر خمس أدوات مراجعة تجارية مقابل أخطاء تاريخية حقيقية في ستة مستودعات مفتوحة المصدر، منح CodeRabbit دقة 95.88%. هذا الرقم يأتي من دراسة بتكليف من البائع ويجب وزنه وفقاً لذلك — أرقام الدقة من معايير مُصممة حول نقاط قوة جهة ممولة واحدة نادراً ما تنجو عند التطبيق على قاعدة كود غير ذات صلة.

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

أين تعمل الأدوات فعلاً بشكل جيد

أوضح الانتصارات ضيقة وآلية: الإشارة إلى الأسرار المُدمجة في الكود (hardcoded secrets)، رصد أنماط حقن SQL، تطبيق دليل الأسلوب، واكتشاف فئة معينة من أخطاء المؤشر الفارغ (null-pointer) والأخطاء الحسابية الطفيفة (off-by-one) التي تظهر باستمرار في الفروقات. هذه مسائل مطابقة أنماط، وأدوات LLM جيدة في مطابقة الأنماط عبر السياق الكامل للفرق بطريقة لا يفعلها أداة فحص الأسلوب (linter).

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

ما الذي يقلل العقبة فعلياً

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

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