لماذا يكتب OpenCode والنماذج القوية اختبارات خضراء لكنها عديمة الفائدة — وكيفية إصلاح ذلك

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

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

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

يؤكد المؤلف أن المشكلة لا تنحصر في الأدوات القديمة. في الاجتماع، استخدموا GLM 4.7 و OpenCode — مكدس حديث تماماً بمعايير عام 2026. علاوة على ذلك، خليفة النموذج، GLM-5.1، تصدر SWE-Bench Pro في أبريل 2026 برصيد 58.4%، وحقق OpenCode نفسه حوالي 140 ألف نجم على GitHub في ذلك الوقت. لكن النتيجة، وفقاً لصيغة المؤلف، تحددها ليس ثلاثة، بل أربعة عوامل: النموذج والوكيل والعملية وجودة قاعدة الكود. إذا اقتربت أي منها من الصفر، تقترب النتيجة من الإلغاء.

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

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

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

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