Cloudflare تخفض تكلفة مراجعة الشيفرة بالذكاء الاصطناعي بنسبة 68%: من $2,43 إلى $0,77

ارتفع متوسط تكلفة المراجعة الواحدة في مراجع الشيفرة القائم على الذكاء الاصطناعي لدى Cloudflare من $1,22 إلى $2,32 بين مارس وأغسطس، وبلغ $2,43 في أغلى أسبوعين. ومع ذلك لم تتغير البنية المعمارية: فالمنسّق كان يوزّع المهام على المتخصصين أنفسهم، وظلت مستويات المخاطر نفسها تحدد عمق الفحص. في منتصف سبتمبر كلّف الفريق وكلاءه الخاصين بتتبّع وجهة استهلاك التوكنات وخفض النفقات. والنتيجة: $0,77 للمراجعة الواحدة مع تفعيل مستوى الجهد المرتفع لفحص جودة الشيفرة، أي بانخفاض 68%. وكان من الآثار الجانبية أن زمن المراجعة الوسيط انخفض من 4م09ث إلى 1م32ث.

من أين جاء الارتفاع

يفسّر هيكل الحِمل جزءًا صغيرًا من الزيادة: فحصة المراجعات في المستوى الأعلى تكلفة (المراجعة الكاملة) ارتفعت من 59% في مارس إلى 65% في أغسطس، إذ بدأ المهندسون يرسلون تغييرات أكبر. أما الإسهام الأساسي فجاء من تغيير النماذج. ففي مطلع أغسطس نُقل جميع المراجعين إلى نماذج Anthropic، لأنها أدّت هذه المهمة بشكل أفضل في الاختبارات الداخلية. وارتفعت تكلفة المهمة من $1,38 إلى $2,03. ووجد مراجع المعايير الداخلية Codex نفسه على Claude Opus 4.7، فقفز سعره للمراجعة من $0,25 إلى $0,88، أي أكثر من تكلفة المنسّق نفسه.

وكان هيكل النفقات قبل التحسين كما يلي: 23% للتوكنات الخارجة، و43% لكتابة التخزين المؤقت، و34% لقراءته. أي أن الجزء الأكبر من الأموال ذهب إلى سياق سبق أن رآه النموذج. فقد نفّذ مراجع جودة الشيفرة في المتوسط 16,6 استدعاء لـ LLM في المراجعة الواحدة، وكتب 72 ألف توكن في التخزين المؤقت وقرأ 1,08 مليون، لأن كل استدعاء يمرّر الحوار بأكمله. وارتفعت نسبة الإصابة في التخزين المؤقت (hit rate) من 85,7% إلى 97%، لكن عدد التوكنات في المراجعة ارتفع من 0,91 إلى 2,99 مليون، ولم يعوّض معدل الإصابة المرتفع هذه الزيادة. وتبلغ تكلفة الكتابة في تخزين Anthropic المؤقت 1,25 من سعر الإدخال، والقراءة 0,1، ويبقى المحتوى المكتوب صالحًا خمس دقائق دون أي طلبات.

بادئة مشتركة واستدعاءات أقل

منذ 14 سبتمبر بدأ الفريق تسجيل توكنات الاستدعاء الأول في كل جلسة وتجزئة (hash) كتلة النظام الأولى. وتبيّن أن الطلب الأول وجد تخزينًا مؤقتًا جاهزًا في 14–26% من الحالات فقط، مع أن 11–21 ألف توكن من تعريفات الأدوات وموجّه الوكيل متطابقة في جميع المستودعات. وكان السبب في OpenCode v1: فقد كان يجمع موجّه الوكيل وقسم البيئة (المجلد العامل والتاريخ) في كتلة واحدة، ويضع نقطة تخزين مؤقت وحيدة في النهاية. ولم يكن الجزء المشترك يُحفظ بشكل منفصل.

في 16 سبتمبر أُضيف مُعلِّم في نهاية الموجّه، وقسّم مكوّن إضافي الكتلة إلى جزأين ووضع نقطة التخزين المؤقت بعد الجزء المشترك. ونُقل كل ما يخص المستودع تحديدًا إلى الأمام، وتم تعطيل قائمة skills. وفي اليوم نفسه دُمج فهرس معايير Codex مباشرة في الموجّه: ففي السابق كانت الأدوار الثلاثة الأولى من الجلسة تُستهلك في قراءة هذه الملفات، أما الآن فعدد الاستدعاءات 9,6 بدلًا من 15,9، وانخفضت تكلفة التشغيل من $1,12 إلى $0,72. وبمجموعها خفّضت هذه التعديلات سعر المراجعة من $2,47 إلى $2,02.

أما التعديلات التالية في 21 و23 سبتمبر فخفّضت نحو $0,20 من تكلفة المراجعة:

• أُخفيت عن المراجعين الفرعيين أداة نشر التعليق النهائي: ففي 57–76% من الجلسات كانوا يحاولون استدعاءها، فيتلقون رفضًا من الخادم ويهدرون استدعاءً إضافيًا. والتوفير نحو 2,9 ألف توكن من التعريفات في كل طلب.
• القراءة المتوازية للملفات: في 64% من الأدوار كان مراجع الجودة ينفّذ استدعاء أداة واحدًا فقط. أما الآن فيُقرأ السياق المشترك وجميع الرقعات (patches) في الرد الأول، حتى 150 كيلوبايت.
• تخطّي المراجعين في المراجعات المتكررة: نحو ثلثي المهام مراجعات متكررة. وفي المراجعات الكاملة المتكررة تُتخطّى فحوص AGENTS.md في 56% من الحالات، وفحوص الأداء في 23%، وفحوص التوثيق في 13%.
• التوقف بعد نشر المراجعة: كان OpenCode ينفّذ دورًا إضافيًا من أجل ملخص غير مرئي، بتكلفة نحو $0,07 للمهمة.
• لم يعد انتهاء مهلة المراجع البطيء يُحتسب عطلًا لدى المزوّد؛ وانخفضت مهلات مراجع الأمان المنتهية من 1,8% من عمليات التشغيل إلى ما يقارب الصفر.
• إلغاء المهام الملغاة: من أصل 446 مهمة ملغاة في GitLab، واصلت 358 مهمة العمل. والآن تتحقق المهمة من حالتها كل 15 ثانية.

وكان أصعب تعديل هو البادئة المشتركة للمراجعين الثلاثة (جودة الشيفرة والأمان والأداء): الأدوات نفسها، وملف القواعد، وطلب الدمج (merge request) مع جميع الرقعات. يكتب أحد المراجعين التخزين المؤقت، ويقرؤه الاثنان الآخران. ولأن التخزين المؤقت يتاح بعد بدء بثّ الرد، ينتظر الآخران حتى 20 ثانية. وهذا يبطّئهما قليلًا، لكنه يوفّر نحو تسعة سنتات لكل مراجع.

النماذج والجهد والجودة

من أصل انخفاض قدره $1,67، جاء $0,65 من تعديلات الشيفرة، و$1,06 من تغيير النماذج والجهد (effort). وأُجريت المقارنة في ساعات أيام العمل قبل التغييرات وبعدها، ولذلك فهي ليست تجربة صارمة. وأُبقي للمنسّق إعداد واحد: على medium انتهت مهام المستوى الكامل أسرع بنسبة 20%. ولم يُظهر Opus 5.5 على medium فرقًا قابلًا للقياس في المحصلة وفي النتائج الحرجة مقارنةً بـ Opus 5، فيما كلّف high أكثر دون زيادة ذات دلالة في عدد النتائج المكتشفة. ولا يفسّر سعر التوكن سوى نحو $0,20 من الانخفاض، أما الباقي فجاء من تقليص الأحجام: فقراءة التخزين المؤقت في المراجعة انخفضت بنسبة 82%، والكتابة بنسبة 54%، والمخرجات بنسبة 67%.

وفي 3 أكتوبر قُسّم مراجعو Sonnet مناصفة 50/50 بين Sonnet 5 وSonnet 5.5. وبعد يومين ونصف كان Sonnet 5.5 أرخص بنسبة 62% في جودة الشيفرة، و58% في الأداء، و47% في الأمان. وسعر التوكن واحد، وكل التوفير ناتج عن عدد توكنات أقل. ينفّذ مراجع جودة الشيفرة على 5.5 medium 1,7 استدعاء بدلًا من 6,2، وأكثر من نصف عمليات التشغيل تنتهي باستدعاء واحد. وعلى high يبلغ العدد 3,4 استدعاء، مع زيادة 61% في تكلفة التشغيل (نحو سنتين للمراجعة) وزيادة 58% في النتائج الحرجة والتحذيرية، ولذلك نُقل مراجع جودة الشيفرة إلى high.

وانخفضت حصة المراجعات التي تستغرق أكثر من خمس دقائق من 37,9% إلى 0,7%، وأصبح المئين 99 أسرع من ثلاثة أرباع المراجعات في أبريل. والوسيط للمستوى الكامل: من 5م16ث إلى 1م54ث، وللمستوى lite من 2م58ث إلى 1م14ث، وللمستوى trivial من 77 إلى 30 ثانية. وبالتوازي انتقل المراجع إلى OpenCode v2: ففي الوضع الظلي (shadow mode) تطابقت قرارات الموافقة في 98% من طلبات الدمج، وتنتهي المراجعات الكاملة على v2 أسرع بنحو 13%. كما يجرّب الفريق تشغيل المراجع بالكامل على Durable Objects باستخدام pi-durable.

والسؤال الرئيسي: هل أصبحت المراجعة أكثر سطحية؟ فالنتائج الحرجة والتحذيرية لدى مراجع جودة الشيفرة أقل بنسبة 40% مما كانت عليه في نهاية أغسطس، ولدى الأمان بنسبة 56%، ولدى الأداء بنسبة 71%. لكن المؤلفين باتوا يتصرفون بناءً على الملاحظات الجدّية لجودة الشيفرة في 59% من الحالات مقابل 34% سابقًا، مع مستوى خلفي للتعديلات العشوائية يبلغ نحو 15%. أي أن المراجع يُحدث ضجيجًا أقل، وارتفعت حصة النتائج التي تفضي إلى تعديل.

أما الخلاصة العملية لمن يبنون وكلاء: قيسوا أولًا مما تتكوّن الفاتورة (لدى Cloudflare ذهب 77% إلى التخزين المؤقت)، ثم تحققوا مما إذا كان الطلب الأول في الجلسة يصيب البادئة المشتركة، وأزيلوا الأدوات التي لا يجوز للوكيل استدعاؤها، وبعد ذلك فقط قارنوا النماذج وeffort على بيانات حقيقية. وقد يقلّص الجيل الجديد من النماذج عدد الاستدعاءات بمقدار مرات دون فقدان النتائج المفيدة.