انخفاض حدود Claude Code: هل الوكلاء يخلقون جبالًا جديدة من "كود قديم"؟

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

كاتب المقال، المصدر: LeiFeng.com

الكود مكتوب بالفعل من قبل العميل، لكن العميل اللاحق لم يعد يعرف لماذا كتب العميل السابق بهذه الطريقة.

تم تمديد مكافأة الربع الأسبوعية +50% لـ Claude Code، التي كانت مقررة في الأصل للانتهاء في 19 أغسطس، من قبل Anthropic حتى 31 أغسطس. وتقريبًا في نفس الوقت المحدد للانتهاء، ظهرت مناقشة على Hacker News حول تكلفة استخدام Claude Code: لاحظ العديد من المستخدمين أن مهمة غير معقدة للغاية يمكن أن تستهلك الحصة بسرعة بعد بضع جولات من تشغيل العميل.

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

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

حدود الحساب في الترميز العادي للدردشة واضحة. أدخل قطعة من الشيفرة، وقراءة النموذج لها، ثم يقدم شرحًا أو حلًا للتعديل، وتنتهي هذه الجولة تقريبًا.

تم استبدال الوحدة الأساسية لـ Claude Code بحلقة الوكيل. يلاحظ النموذج الحالة الحالية، ثم يقرر أي ملف يجب قراءته أو أي أمر يجب تنفيذه؛ وبعد أن تعيد الأدوات النتائج، يجري النموذج تقييمًا آخر.

قراءة الشفرة المصدرية، البحث عن الإشارات، تشغيل الاختبارات، عرض فرق Git، تعديل الملفات — يبدو وكأنه حركة متصلة، لكن في جانب النموذج، إنه سلسلة من طلبات الاستدلال المستقلة. كما يُصنف المستند الرسمي لـ Claude Code هذا الدور التكراري "الاستدلال من قبل النموذج — استدعاء الأداة — الاستدلال بناءً على النتيجة" كأساس لطريقة عمل العامل.

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

ربما حتى هذه النقطة، بدأ فقط في كتابة تلك السطور القليلة من الكود. لذلك،diff لا توجد نسبة ثابتة تقريبًا بين حجم التغييرات وكمية الحساب. قد توجد فقط 3 عمليات استدلال خلف 5 أسطر من التصحيح، أو قد تكون قد مرت بـ 30 تفاعلًا بالأدوات.

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

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

هذا أيضًا نقطة بداية تغيير هيكل تكلفة Coding Agent: أصبحت كمية الحساب تعتمد على "عدد الخطوات × الوزن الذي تحمله كل خطوة"، وليس على عدد الأسطر التي كُتبت.

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

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

يمكن لذاكرة التخزين المؤقت للتعليمات البرمجية تخفيف هذه المشكلة. توضح الوثائق الرسمية لـ Claude Code بوضوح أنه بدون تخزين مؤقت للتعليمات البرمجية، يجب معالجة كامل السجل مرة أخرى في كل طلب؛ بعد تحقيق التخزين المؤقت، يمكن إعادة استخدام البادئة المستقرة التي تم معالجتها مسبقًا، مما يقلل من الحسابات المتكررة والتكاليف.

لكن التخزين المؤقت يحل مشكلة "هل يمكن إعادة استخدام نفس التاريخ بسعر أقل"، ولا يحل مشكلة "هل يجب الاستمرار في وجود هذا التاريخ". بعد أن يتم تحقيق الحالة القديمة لـ 100K Token من خلال التخزين المؤقت بسعر أقل، لا تزال تحتل السياق، ولا تزال الحالة التي بُني عليها الاستنتاج الحالي.

于是可以把一个长任务粗略写成：第 t 步的输入规模，大约等于稳定前缀 S，加上当前有效工作集 W_t，再加这一轮刚产生的新信息 Δ_t。

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

في نموذج مبسط بشكل متطرف وخالٍ تمامًا من التخزين المؤقت والتنظيف، إذا كان الحالة الفعالة المضافة في كل دورة تقريبًا متساوية، فسيظهر إجمالي المعالجة بنية تراكمية تقترب من 1 + 2 + 3 + … + n، أي أن عدد الخطوات زاد فقط بمقدار الضعف، بينما قد يزداد عدد الحالات التاريخية التي تم معالجتها في المهمة بشكل أسرع.

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

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

لماذا يتوسع مجموعة العمل بهذه السرعة؟ إن مخرجات الأداة هي مصدر كبير. يحتوي الكود المصدر على بنية على الأقل، بينما غالبًا لا تحتوي السجلات على أي بنية.

一次 grep يمكن أن تعيد مئات الإشارات، وقد ينتج بناء واحد كمًا كبيرًا من التحذيرات، وقد يحمل فشل اختبار واحد مسارًا كاملاً للخطأ، كما أن Docker ومحررات الترجمة وأدوات إدارة الحزم تنتج كميات كبيرة من النصوص التي لا تملك قيمة طويلة الأمد للمهمة.

افترض أن اختبار الخطوة 10 أنتج سجلات بـ 8K رمز. عند دخوله السياق لأول مرة، كان فقط 8K رمز. لكن العميل سيستمر في التحقق من الشيفرة المصدرية، وتعديلها، وإعادة الاختبار، وكلما ظلت هذه السجلات ضمن السجلات الفعالة، فإنها ستزيد من الوزن الأساسي للعديد من الطلبات اللاحقة.

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

وبالتالي، فإن وضع 8K Token في الجولة السابقة لانتهاء المهمة، مقارنةً بوضعها في بداية المهمة، يؤدي إلى تأثيرات مختلفة تمامًا. كما أن Claude Code يقلل الآن بشكل نشط من هذا التلوث. وتشير التوصيات الرسمية إلى استخدام sub-agent لعزل المهام ذات الإخراج العالي، وتشير صراحةً إلى أن نتائج البحث والسجلات ومحتوى الملفات الكثيرة تستهلك سياق الجلسة الرئيسية؛ كما أن تعريف الأدوات نفسه يستهلك مساحة، وبالتالي فإن كبر مجموعة الأدوات يزيد أيضًا من عبء الحالة.

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

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

وبالتالي تقع المهمة الطويلة في مأزق: الاحتفاظ بسجلات تاريخية كثيرة يجعل كل خطوة لاحقة أكثر ثقلًا؛ بينما التنظيف المفرط يجعل العميل يعيد استرجاع المعلومات التي رآها سابقًا باستمرار.

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

هنا فقط، تصبح الضغط والذاكرة ووكلاء الفرعيين ذات معنى حقيقي.

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

من منظور النظام، تشبه عملية التجميع عملية إعادة تدوير نفايات دلالية. التحدي يكمن في أن إعادة تدوير النفايات العادية تحدد ما إذا كان هناك أي إشارات إلى هذا الكائن، بينما يجب على الوكيل تحديد ما إذا كانت هذه المعلومات ستظل ذات معنى في المستقبل.

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

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

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

يُشير مستند السياق الخاص بـ Claude Code بوضوح إلى أن بعض القواعد المحدودة بالمسار والملفات CLAUDE.md المُضمنة سيتم تلخيصها وتقليل حجمها مع الجلسة، ويتطلب إعادة تحميلها قراءة الملفات المطابقة مرة أخرى.

يحاول Memory حل مشكلة الحفظ الطويل الأمد للمعرفة. يمكن لملف CLAUDE.md و auto memory في الدليل الجذر استخراج محتويات مثل أوامر البناء ومواصفات المشروع وتجارب التصحيح من المحادثات قصيرة الأجل وإعادة تحميلها عند بدء المحادثة. لكن Anthropic حددت بوضوح أن هذه الـ memory لا تزال جزءًا من السياق ولا تُعد تكوينات إلزامية.

هذا الفرق حاسم. إذا تم كتابة "لا يمكن الوصول المباشر إلى قاعدة البيانات هنا" فقط في الذاكرة، فهي لا تزال جملة لغة طبيعية يحتاج النموذج إلى فهمها واتباعها. ولكن إذا تم كتابة نفس القاعدة كـ dependency lint أو قيد نوعي أو فحص CI، فإنها تصبح ثابتة برمجية لا يمكن تجاوزها بسهولة.

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

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

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

ما هي الحالات التي تحتاج إلى حفظ بدقة عالية، وما هي الحالات التي يكفي الاحتفاظ بموجز عنها؟ هذا السؤال سيؤثر مباشرة على جودة الكود اللاحق.

بعد فهم هيكل التنفيذ السابق، عند النظر إلى الحد الأسبوعي لـ Claude Code، سيتضح أن من الصعب على المنصة الاستمرار في قياس الوكلاء بناءً على "عدد الرسائل"، لأن الرسالة الواحدة فقدت معناها الثابت.

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

يُغلف Claude Code هذا الأمر باستخدام قيود التمرير وحصص أسبوعية؛ الآن يُحسب Codex بوضوح وفقًا لـ input token وcached input token وoutput token؛ بينما توفر خطط Cursor مجموعات استخدام مختلفة للعُملاء، وستتأثر استهلاكات النماذج الخارجية بأسعار واجهة برمجة تطبيقات النموذج.

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

قد يجد النموذج السبب الجذري بسرعة، أو قد يطرح عدة افتراضات خاطئة متتالية؛ قد يمر الاختبار في مرة واحدة، أو قد يدخل في حلقة تدقيق طويلة؛ قد يحتاج فقط إلى عامل واحد، أو قد يتم تقسيمه إلى عدة عوامل فرعية.

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

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

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

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

ويمكن أن تتقاطع حالات الاستعادة غير الفعالة هذه مع تقنية الدين في المستوى السفلي.

يمكن هنا تجريد برنامج يتم صيانته بواسطة وكيل برمجي كمجموعة من حالتين تتطوران في آنٍ واحد. إحداهما هي حالة الكود R_t. تشمل الملفات والأنواع والواجهات والاختبارات وGit commit هذه الطبقة. السطر الذي أُضيف في الخطوة العشرين من الوكيل retry، ما دام لم يُحذف، لا يزال موجودًا بكامله عند فتح الملف في الخطوة المائة. يحتفظ الكود بدقة عالية بالتغييرات السابقة.

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

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

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

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

تم حفظ queue بالكامل في الكود. بعد التشغيل لفترة طويلة، قد تبقى حالة التصميم فقط كالتالي: "هنا يتم استخدام queue لحل مشكلة race condition".

لاحقًا، ظهر خطأ عرضي في B أيضًا. عندما قرأ العامل الكود مرة أخرى، قام تلقائيًا بتوصيل B إلى الطابور الحالي.

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

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

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

حول وكيل البرمجة "تسليم الموظفين" إلى "تسليم السياق". تبدو الخطوة 20 والخطوة 100 كأنهما جلسة واحدة من Claude Code، لكن الحالة التصميمية التي حصلتا عليها ليست متطابقة تمامًا. من منظور المعلومات، تشبه أكثر مهندسين اثنين يحافظان على مستودع واحد من خلال وثيقة تسليم تتناقص باستمرار.

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

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

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

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

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

إنه ليس مشكلة في قدرة نموذج واحد، بل مشكلة نظام تتعلق بعدم اتساق دقة حفظ حالة الكود والحالة التصميمية.

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

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

السؤال التالي سيكون: كم من المعلومات السببية ذات القيمة للقرارات المستقبلية سيحتفظ بها وكيل بعد 50 خطوة، 100 خطوة؟

يمكنك تسميته معدل صيانة الحالة.

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

بعض المعرفة مناسبة للتخزين في الذاكرة، مثل طرق بناء المشروع وعادات التطوير؛ بعض القرارات يجب أن تُدرج في ADR منظم أو فهرس الكود؛ بينما تلك التي يُعد انتهاكها خرقًا للحدود المعمارية للنظام، فمن الأفضل كتابتها مباشرة في النوعيات والاختبارات وقواعد التدقيق والاعتمادات وCI.

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

إذا كانت نسبة الدقة منخفضة، كلما طال وقت تشغيل العامل، زاد عدد الألغام التي يزرعها في النظام.

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

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

إحدى الجمل الشائعة في الكود التقليدي الموروث: "لا تلمس هذا الجزء، لا نعرف لماذا سيُفجّر."

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