Habr AI: كيف تحوّلت نماذج LLM الباهظة إلى «مدير حالة» وخفّضت تكاليف التطوير

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

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

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

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

لماذا غُيّرت الأدوار

لاحظ الفريق أثناء الاختبارات أن للنماذج المختلفة «طباعًا» عملية بالفعل. فـ Gemini 3 Pro يتصرف كمطوّر مفرط الثقة وقد يحيد عن المواصفات الأصلية. أما MiniMax M2.5 فعلى العكس حذر، ويقرأ نصف المشروع قبل أن يخطو خطوته الأولى. وأظهر Claude Sonnet 4.6 أفضل توازن بين الاستقلالية والانضباط، لكن استخدامه في كل إجراء صغير تبيّن أنه مكلف أكثر مما تحتمله شركة ناشئة. ومن هنا نشأت الفكرة الجديدة: النموذج القوي يُوضع للرقابة لا للمهام الروتينية.

«المدير العام لا يجري مكالمات باردة».

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

• وكيل واحد يتولى المواصفات الفنية الواحدة من البداية إلى النهاية، ويصحّح أخطاءه بنفسه.
• يعمل الوكيل فقط على «مكتب عمل» محدود من 5–8 ملفات، لا على المستودع كله.
• عند إغلاق الملف يحفظ ذاكرة موجزة بما وجده من معلومات مفيدة، كي لا يحمل الشيفرة المصدرية كاملة في السياق.
• لا يكتب أذكى نموذج الشيفرة بنفسه، بل يعمل مديرَ حالة للعامل الأرخص.

كيف يعمل المدير

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

يؤدي مدير الحالة أربع مهام متتالية:

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

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

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

ما معنى ذلك

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