لعبة "سرقة الراكون" تكشف الفرق بين نماذج الذكاء الاصطناعي في كتابة الكود

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

الفكرة نفسها لها تاريخ غريب. ابتكرها ويليسون قبل أربع سنوات باستخدام GPT-3 وDALL-E، ثم أعاد استخدامها كأمر توجيهي (Prompt) لكلود فيبل 5، وبشكل منفصل لـ Codex Desktop العامل بنموذج GPT-5.6 Sol Ultra.

نسختان، طموح مختلف

كلود فيبل 5 لعبها بأمان. أنتج لعبة براكون واحد يتجوّل في حديقة خلفية يجمع العملات والأسماك، تفسير متواضع لكنه يؤدي الغرض المطلوب.

أما GPT-5.6 Sol Ultra فذهب إلى مدى أبعد. نسخته، التي بُنيت داخل Codex Desktop، وضعت اللاعبين في متحف حيث يُنقذون اثنين من رفاق الراكون ويتراكمون فوق بعضهم فعلياً للوصول إلى السردينة الذهبية وسرقتها. هذا الطموح الإضافي في البناء يتماشى مع طريقة عمل Sol Ultra، الذي يعتمد بكثافة على وكلاء فرعيين (Sub-agents)، أي أنه يفوّض أجزاء من العمل لنسخ منه تعمل بالتوازي.

ثغرة بصرية لم يلحظها النظام

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

Codex Desktop قضى 52 دقيقة على مشروع "سرقة الراكون" ومع ذلك فوّت كرة العين الضخمة العائمة فوق رأس كل راكون.

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

ماذا يعني هذا لفرق التطوير

المقارنة غير رسمية، مجرد أمر توجيهي واحد جُرّب مرة واحدة على كل نظام، لكنها تتفق مع نمط أوسع لاحظه مطوّرون آخرون في أدوات الترميز الوكيلية (Agentic Coding). التفويض الأكبر للوكلاء الفرعيين والطموح البنائي قد يُنتج ميزات أغنى، لكنه لا يترجم تلقائياً إلى جودة أفضل. مراجعة لقطات الشاشة كانت حاضرة في هذه الحالة لكنها لم تكن فعّالة، ما يشير إلى أن ضمان الجودة البصري (Visual QA) يبقى من أضعف الحلقات في مسارات الترميز المستقلة حتى مع استمرار تحسّن جانب توليد الكود نفسه.

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