أوضحت SimpleOne لماذا لا يستطيع Claude ومراجعو AI التمييز بين الكود المولّد بواسطة AI والكود البشري

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

لماذا هذا صعب

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

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

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

لم تعد هذه مسألة بناء جملة أو أفضل الممارسات، بل مسألة منطق الأعمال وسياق المشروع، الذي لا يمتلكه المراجع الآلي عادة.

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

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

• نصوص توضيحية مفصلة بشكل مفرط مع تعداد Args وReturns وكل استثناء حتى لدالة صغيرة جدًا.
• حالات حدودية غير ضرورية وفحوصات لم يطلب أحد منها ولا تتبع من بيان المشكلة.
• كيانات مختلقة حول الكود: استثناءات مخصصة أو بدالات تسجيل أو حقول مطلوبة غير موجودة في المشروع.
• fallbacks "آمنة" مثل data.get('user', {})، والتي لا تفشل على الفور لكنها تخفي المشكلة الفعلية.

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

حيث يفشل المراجعة

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

"وجد المراجع الآلي 2 من 5." اختبرت الفريق هذا على أخطاء حقيقية من

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

ماذا يعني هذا

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