للكود الذي يولّده الذكاء الاصطناعي نمط فشل خاص: يبدو مكتملًا. الأسماء معقولة، والتنسيق نظيف، وفوق كل دالة توثيق. المشكلات في الأسفل: اعتمادية غير موجودة، أو خطأ يُبتلع بصمت، أو دالة مساعدة كانت موجودة أصلًا في مجلد آخر. الكود الرديء الذي يكتبه البشر يبدو رديئًا عادةً. هذا النوع لا يبدو كذلك، ولهذا لا تنجح مراجعته بالانطباع.
وهناك دليل على أن الانطباع دليل ضعيف هنا. في دراسة METR في أوائل 2025، احتاج 16 مطورًا متمرسًا في المشاريع مفتوحة المصدر إلى وقت أطول بنسبة 19% لإنجاز مهام حقيقية حين سُمح لهم بأدوات الذكاء الاصطناعي، ومع ذلك اعتقدوا بعدها أن الأدوات جعلتهم أسرع بنحو 20%. إن أخطأ الناس في تقدير سرعتهم بهذا القدر، فقد يخطئون في تقدير تعديل كود أيضًا. والعلاج الممل هو قائمة مكتوبة.
هذه هي القائمة التي نستخدمها في طلبات الدمج التي كتب وكيل ذكاء اصطناعي معظم كودها. نفترض أنك تعمل أصلًا بدورة بحث ثم تخطيط ثم تنفيذ؛ وإن لم تكن كذلك فابدأ بمقالنا عن هندسة السياق وإطار RPI، لأن معظم الكود الرديء من الذكاء الاصطناعي مشكلة سياق قبل أن يكون مشكلة مراجعة.
قبل أن تقرأ سطرًا واحدًا
- هل التعديل قابل للمراجعة؟ إن لمس عشرات الملفات لميزة واحدة فأعده ليُقسَّم. لا أحد يراجع 1,500 سطر بعناية، والوكلاء ينتجونها بسهولة.
- هل يطابق الخطة؟ ضع الخطة أو التذكرة بجانب التعديل. أي شيء في الكود ليس في الخطة إما توسع غير مطلوب في النطاق أو قرار لم يتخذه أحد عن قصد.
- هل شُغّلت الاختبارات فعلًا؟ في CI وعلى هذا الإيداع تحديدًا. عبارة "كل الاختبارات ناجحة" في ملخص الوكيل ادعاء لا نتيجة. يسمي مقالنا عن RPI مع الوكلاء الفرعيين في Claude Code هذا التحقق من الواقع لا من نص المحادثة.
الصحة: طبقة "معقول لكنه خاطئ"
- كل اعتمادية جديدة حقيقية، وهي التي قصدتها. في دراسة نُشرت في USENIX Security 2025 على 576,000 عينة كود مولّدة، كانت 5.2% على الأقل من الحزم التي اقترحتها النماذج التجارية و21.7% مما اقترحته النماذج مفتوحة المصدر غير موجودة، مع 205,474 اسمًا مختلقًا فريدًا. والمهاجم الذي يسجّل أحد هذه الأسماء يُثبَّت لدى كل من يثق بالاقتراح. افحص صفحة الحزمة في السجل والمسؤول عنها وتاريخ تنزيلاتها قبل أن يتغير ملف القفل.
- كل استدعاء API موجود في الإصدار الذي تثبّته. النماذج تخلط بين الإصدارات الرئيسية. دالة أُعيدت تسميتها قبل إصدارين ستبدو صحيحة في المراجعة وتفشل عند التشغيل.
- الحالات الطرفية معالجة، لا المسار السعيد فقط. مدخل فارغ، وnull، وملف كبير جدًا، ومنطقة زمنية غير UTC، ونص غير لاتيني، وطلب ثانٍ يصل والأول ما زال قيد التنفيذ.
- الأخطاء لا تُبتلع. ابحث عن كتل catch واسعة تسجّل الخطأ وتعيد قيمة افتراضية، وعن إعادة محاولة بلا حد، وعن بدائل تخفي فشلًا كان المستدعي يحتاج إلى معرفته.
- الاختبارات تفحص السلوك. اختبار يتحقق فقط من أن كائنًا وهميًا استُدعي لا يثبت الكثير. وراجع ملفات الاختبار نفسها: إن خُفّف تأكيد موجود في طلب الدمج نفسه فاسأل لماذا.
الملاءمة: هل ينتمي إلى هذا المشروع؟
- لا يكرر شيئًا موجودًا لديك. ابحث في المستودع عن وظيفة الدالة الجديدة قبل قبولها. الوكلاء يعيدون كتابة دوال تنسيق التاريخ وأغلفة HTTP باستمرار، لأنهم لم يروا ما لديك.
- يتبع أعرافكم. الطبقات والتسمية والتسجيل وإدارة الإعدادات. الكود الذي يعمل لكنه يتجاهل قواعد الفريق يكلف أكثر في كل مرة يلمسه أحد لاحقًا.
- لا وزن زائد. معاملات غير مستخدمة، وبدائل معلّقة في التعليقات، وتعليقات تشرح البديهي، وفحوص دفاعية لأشياء لا يمكن أن تحدث.
الأمان: الجزء الذي لا يُتجاوز
- المدخلات الجديدة مُتحقق منها ونقاط النهاية الجديدة تفحص الصلاحيات. ابحث عن SQL أو HTML مبني بدمج النصوص، وعن أسرار في الكود أو السجلات، وعن بيانات شخصية تُكتب في السجلات، وعن أي مسار يفحص تسجيل الدخول دون أن يفحص الصلاحية. الكود المولّد كثيرًا ما يصيب في فحص الدخول وينسى أن يسأل: هل يحق لهذا المستخدم رؤية هذا السجل؟
اجعل القائمة رخيصة بما يكفي لتُستخدم
القائمة التي تعيش في صفحة ويكي تُنسى عند ثالث طلب دمج. ضعها حيث يحدث العمل:
- أضف البنود الاثني عشر إلى قالب طلب الدمج كمربعات اختيار.
- اكتب الأعراف من البنود 9 إلى 11 في ملف التعليمات الذي يقرؤه وكيلك (CLAUDE.md أو AGENTS.md أو ما يشبههما)، حتى يصل عدد أقل من المخالفات إلى المراجعة أصلًا.
- دع الأدوات تتولى البنود 4 و5 و11: قائمة سماح للاعتماديات، ومدقق أنواع على الإصدارات المثبّتة، وأداة فحص للكود غير المستخدم.
- يمكن لوكيل ثانٍ أن يراجع مبدئيًا وفق القائمة ويشير إلى البنود. لكن شخصًا ما يوقّع في النهاية، لأن معنى المراجعة أن مسؤولًا قرأ الكود.
السياق هو العلاج من المنبع
يفشل البندان 9 و10 غالبًا لأن الوكيل لم يرَ دوالك المساعدة ولا قواعد فريقك. العلاج أن تعطيه التوثيق الداخلي المناسب، وأن تطلب منه أن يذكر الوثيقة التي جاء منها كل قرار. عادة الاستشهاد هذه هي نفسها التي بنينا حولها FanMind لأسئلة المستندات: الإجابة التي تذكر مصدرها يمكنك التحقق منها في ثوانٍ. وفي الكود تحوّل سؤال "لماذا فعلت ذلك بهذه الطريقة؟" إلى رابط بدل تخمين.
الأسئلة الشائعة
كيف أتحقق من جودة الكود الذي يولّده الذكاء الاصطناعي؟
راجعه وفق قائمة ثابتة لا بالانطباع: تأكد أن التعديل يطابق الخطة وأن الاختبارات شُغّلت في CI، وتحقق من كل اعتمادية واستدعاء API جديد، وابحث عن الأخطاء المبتلعة والاختبارات المخففة، وتأكد أنه لا يكرر كودًا موجودًا، وراجع التحقق من المدخلات وفحص الصلاحيات.
هل الكود المولّد بالذكاء الاصطناعي أقل جودة من كود البشر؟
ليس بالضرورة، لكنه يفشل بطريقة مختلفة. يميل إلى أن يبدو نظيفًا بينما يخفي أخطاء معقولة الشكل مثل حزم غير موجودة أو واجهات قديمة أو فحوص صلاحيات ناقصة، لذا على المراجع أن يبحث عنها تحديدًا.
ما هي هلوسة الحزم؟
هي أن يقترح النموذج حزمة غير موجودة. وجدت دراسة في USENIX Security 2025 ذلك في 5.2% على الأقل من اقتراحات الحزم لدى النماذج التجارية و21.7% لدى النماذج مفتوحة المصدر. يمكن للمهاجمين تسجيل تلك الأسماء، فتحقق من كل اعتمادية جديدة.
هل يمكن لذكاء اصطناعي آخر أن يراجع الكود المولّد؟
يمكنه فحص طلب الدمج مبدئيًا وفق قائمة واكتشاف كثير من المشكلات، لكن يجب أن يوافق شخص على الدمج. اعتبر مراجعة الذكاء الاصطناعي مرشحًا يوفر وقت البشر لا توقيعًا نهائيًا.
