لم تعد أدوات البرمجة المعتمدة على AI مجرد تجربة بجانب محرر الكود. فرق كثيرة تستخدم Codex وClaude Code وأدوات مشابهة لمراجعة pull requests، وإعادة الهيكلة، وكتابة الاختبارات، وفهم المستودعات الكبيرة. لذلك أصبحت quotas وcontext window وقواعد reset تؤثر في تخطيط العمل الهندسي نفسه.

لوحة تخطيط للحصص ونافذة السياق في وكلاء البرمجة بالذكاء الاصطناعي

خلال الأيام الماضية ظهرت المشكلة بوضوح. أظهر diff في مستودع OpenAI Codex أن بعض قيم context_window وmax_context_window تغيرت من 372000 إلى 272000 tokens. وأصبح موقع Codex Resets مؤشراً علنياً لإعلانات إعادة ضبط حدود الاستخدام. وشرح Max Woolf أن هذه resets تبدو سخية، لكنها تدفع المستخدمين إلى تنظيم العمل حول قدرة غير مضمونة.

ليست مشكلة OpenAI وحدها

يعرض Claude Code التوتر نفسه. تقول صفحة دعم Anthropic إن عرض مايو إلى أغسطس 2026 يزيد weekly usage limits بنسبة 50% للمستخدمين المؤهلين، لكنه لا يغير 5-hour limits. أي أن السعة الأسبوعية وجلسة العمل الطويلة حدان مختلفان.

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

reset مجاني قد يفسد التخطيط

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

لا ينبغي أن يعتمد sprint على عرض مؤقت. إذا كان workflow اليومي لا يعمل إلا بقدرة مجانية إضافية، فالفريق لم يحسب التكلفة الحقيقية بعد.

نافذة السياق حد للموثوقية

272k tokens رقم كبير للمحادثة العادية. لكن وكيل البرمجة يحمل أيضاً تعليمات النظام، والأدوات، والملفات، ونتائج البحث، وسجلات الاختبار، وdiffs، والأخطاء، والقرارات السابقة. المستودع الكبير يملأ هذا السياق بسرعة.

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

تعامل مع الوكلاء كبنية تحتية

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

للعمل المتوقع، قد يكون API مع budget وrouting وfallback أفضل من اشتراك مريح ظاهرياً. ويجب أن يقدم الموردون حدود سياق موثقة، وruntime changelog، وadmin usage API، وتنبيهات quota، وسياسات بيانات، وتشخيصاً محلياً.

ستبقى AI coding agents مفيدة. النضج يعني جعلها قابلة للمراقبة، ومحددة الميزانية، وقابلة للاستبدال، ومحكومة بقواعد، لا عملية تعتمد على reset عشوائي.