SimpleOne تُظهر لماذا لا يميّز Claude ومراجعو الذكاء الاصطناعي بين كود الذكاء الاصطناعي وكود البشر

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

لماذا هذا صعب

جمع الفريق في المقال عدة أزواج من الدوال: التحقق من البريد الإلكتروني، وطلب إلى API، وتحميل الإعدادات، وحساب الخصم. في كل زوج كتب إنسان أحد النسختين، وكتبت نموذج الأخرى.

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

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

ما الذي يفضح الكود الاصطناعي

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

• docstring مفرطة التفصيل تسرد Args وReturns وكل استثناء، حتى لدالة صغيرة جدًا.
• حالات حدّية (edge cases) وفحوصات زائدة لم يطلبها أحد ولا تنبع من صياغة المهمة.
• كيانات مختلقة حول الكود: استثناءات مخصصة أو مسجِّلات (loggers) أو حقول إلزامية غير موجودة في المشروع.
• بدائل «آمنة» (fallback) مثل data.get('user', {}) لا تُسقط البرنامج فورًا، لكنها تُخفي المشكلة الحقيقية.

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

أين تنهار المراجعة

المشكلة التي تصفها SimpleOne لا تقتصر على جودة نموذج واحد. فإذا ولّد Claude الكود ثم فحصه أداة ذكاء اصطناعي أخرى وفق الأنماط ذاتها، يحصل الفريق على حلقة مغلقة من الثقة الاصطناعية. كل شيء يبدو أخضر: الأنواع موجودة، ومعالجة الأخطاء موجودة، والتعليقات موجودة. لكن المراجعة قد لا تلاحظ أن UserFetchError غير موجود في المشروع، وأن secret_key ظهر فجأة دون أي متطلبات، وأن الإرجاع «الصامت» لقاموس فارغ سيستنزف لاحقًا ساعات في البحث عن الخطأ.

«مراجع الذكاء الاصطناعي وجد 2 من 5». اختبر الفريق ذلك على أخطاء حقيقية

من بيئة الإنتاج. لم يلتقط المراجع الآلي سوى حالتين بسيطتين: متغير غير مستخدم وغياب فحص null. وفاتته أمور تحتاج إلى سياق المشروع: خطأ منطقي في الحساب، وحالة تسابق (race condition) عند الطلبات المتوازية، وترتيب خاطئ لعمليات الترحيل (migrations).

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

ماذا يعني هذا

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