لماذا لا يكفي Claude 4.6 دون سياق: أكبر نقطة عمياء في التطوير بالاعتماد على LLM

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

ليس النموذج بل السياق

من السهل في التطوير القائم على LLM الانشغال بالمقارنة بين GPT وClaude وGemini، وبصقل الموجّهات. لكن المكسب في الواقع العملي لا يأتي في الغالب من تغيير النموذج، بل من حجم المعلومات المفيدة التي يحصل عليها الوكيل قبل أول إجراء ينفّذه. فإذا ضمّ السياق بنية الخدمات وقيود البنية التحتية والمكتبات المشتركة (shared libraries) وأعراف الفريق والقرارات السابقة، يتصرف النموذج كمهندس سبق له العمل في المشروع. وإذا غاب ذلك، يبدأ حتى الوكيل القوي بالتخمين، وتخمينات بيئة الإنتاج مكلفة.

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

«الفرق هو الطريق من حل في خمس دقائق إلى ساعة من الأخطاء والتراجعات».

كيف تفشل الوكلاء

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

• الروابط بين الخدمات المصغّرة وترتيب النشر (deploy)
• خصائص المكتبات المشتركة وعقود واجهات API الداخلية
• قيود العتاد والأجهزة الافتراضية والبيئة المحلية
• قواعد الاختبار والتحقق اليدوي والتراجع عن التغييرات

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

طبقة معرفية منهجية

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

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

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

ماذا يعني ذلك

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