سبير تشرح لماذا يبدو الكود المولَّد بالذكاء الاصطناعي موثوقًا لكنه ينهار تحت الحمل الفعلي

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

لماذا يبدو الكود مقنعًا

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

لكن الشبه بالكود الجيد لا يعني أن النموذج فحص فعلًا جميع الفرضيات والقيود وسيناريوهات الفشل. وهنا تكمن فكرة ما يُسمّى «ذكاء LLM»: فالنموذج لا يفهم النظام كما يفهمه الإنسان، بل يتنبأ بالاستمرار الأكثر احتمالًا استنادًا إلى النص والكود والسياق. وحين تكون المهمة نمطية، يعمل هذا النهج بشكل جيد على نحو غير متوقع. أما حين تظهر قواعد العمل الخاصة بالأعمال، والتبعيات غير الواضحة، وحالات التسابق (race conditions)، والمدخلات النادرة، والتكاملات المعقدة، فتنكشف الثغرات.

ومن هنا الأطروحة الرئيسية في المادة: لا يكفي أن يتقن المطوّر كتابة الأوامر (prompts)، بل عليه أن يفهم كيف يخطئ النموذج تحديدًا.

أين ينكسر المنطق

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

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

«الذكاء الاصطناعي لا يفهم الكود ما دام المطوّر لا يفهم “تفكيره”».

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

كيف نعمل مع النموذج

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

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

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

ماذا يعني ذلك

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