Revolut تنقل 2000 مطور إلى GLM وتخفض نفقات الذكاء الاصطناعي بنسبة 90%

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

ما الذي فعلته الشركة تحديداً

وفقاً للتقارير، نقلت Revolut نحو 2000 مطور من Claude Code وCodex إلى نموذج GLM المفتوح من شركة Z.ai الصينية. وأصبح سعر مليون توكن نحو $0,30، أي أرخص بمقدار 10 مرات من السابق. وتشير التقارير إلى أن إجمالي نفقات الشركة على الذكاء الاصطناعي انخفض بنسبة 90%.

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

ماذا حققت هذه الخطوة بالأرقام

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

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

أين ينبغي توخي الحذر

أولاً: لا تزال الأرقام مستمدة من رواية منقولة ومنشور واحد. ولا يوجد تدقيق مستقل، كما أننا لا نعرف تحديداً كيف احتسبت Revolut الوفر، أو عدد المهام التي بقيت على النماذج المغلقة، أو نسبة التعديلات التي لا يزال المهندسون يجرونها يدوياً. ومن السهل تفسير عنوان مثل «الاستبدال الكامل» على نطاق أوسع مما حدث فعلياً.

ثانياً: توفير 90% من تكلفة التوكنات لا يعني تحقيق مكسب بنسبة 90%. فإذا كان GLM أقل كفاءة في حل أصعب المهام، فسيُستهلك جزء من الوقت في استكمال العمل. تبدو مؤشرات 60% و70% جذابة، لكن من غير الواضح ما المهام التي قيس عليها الأداء وما أساس المقارنة.

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

ما الذي ينبغي فعله عملياً

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

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

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