Waydev: سباق الرموز يقلّص عائد البرمجة بالذكاء الاصطناعي ويضخّم حجم إعادة الكتابة

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

كيف يعمل tokenmaxxing

يصف مصطلح tokenmaxxing منطقًا بسيطًا: إذا كان المطور ينفق الكثير من الرموز في Claude Code أو Cursor أو Codex، فهو يعمل بإنتاجية أعلى على ما يُفترض. وداخل الشركات أصبحت الحصص الكبيرة من حوسبة AI عنصرًا من عناصر المكانة، تمامًا كما كان عدد أسطر الكود أو عدد الـ commits في السابق.

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

وفق بيانات Waydev، التي تعمل مع نحو 50 شركة وأكثر من 10 آلاف مهندس، يرى المديرون في كثير من الأحيان صورة عليا جذابة للغاية: فنسبة 80–90% من الكود المولَّد بواسطة AI تُقبل أولًا وتدخل المستودع. لكن بعد ذلك يبدأ الجزء الأقل وضوحًا من العمل: التعديلات والتراجعات وإعادة الكتابة في الأسابيع التالية. وإذا أُخذ هذا الذيل في الحسبان، فإن النسبة الفعلية للكود الذي «استقر» فعلًا تهبط إلى 10–30%. وهنا تحديدًا ينهار وهم الإنتاجية الفورية.

المقاييس في مواجهة الأوهام

تحاول عدة شركات متخصصة في التحليلات الهندسية قياس هذه الصورة حاليًا. وقد نما الطلب إلى حد دفع اللاعبين الكبار أيضًا إلى الاستثمار في هذه الأدوات: ففي عام 2025 اشترت Atlassian شركة DX الناشئة مقابل 1 مليار دولار لتحسين قياس عائد وكلاء AI في التطوير. والخلاصة العامة متشابهة عبر المنصات المختلفة: حجم الكود المُنتَج يتزايد، أما حصة النتيجة المستدامة فلا.

• تفيد GitClear بأن المستخدمين المنتظمين لأدوات AI يسجلون code churn أعلى بمقدار 9,4 مرة مقارنة بالمطورين الذين لا يستخدمون AI، مع أن الزيادة السنوية بعد التنقية تبدو أكثر تواضعًا بكثير، إذ تبلغ نحو 25%.
• رصدت Faros AI في تقريرها الصادر في مارس 2026، عند ارتفاع حصة AI في التطوير، زيادة في حجم الـ PR بنسبة 51%، وزيادة في الأخطاء لكل PR بنسبة 28%، وارتفاعًا بمقدار خمسة أضعاف في الوقت الوسيط للمراجعة، وقفزة في code churn بنسبة 861%.
• لاحظت Jellyfish، في عينة ضمّت 7 548 مهندسًا، أن المطورين الأعلى إنفاقًا على الرموز ينجزون عددًا أكبر من الـ PR، لكن هذا الاعتماد يصبح سريعًا غير مجدٍ من حيث التكلفة.
• في بيانات Jellyfish، أنجز أعلى 20% من حيث الإنفاق على الرموز في المتوسط 23 طلب دمج (PR) مدمجًا خلال الربع، مقابل 11 لأدنى 20%، لكنهم أنفقوا على ذلك نحو 1 822 دولارًا مقابل نحو 3 دولارات تقريبًا.

ثمن الكود الزائد

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

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

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

«هذا عصر جديد لتطوير البرمجيات، وعلى الشركات أن تتكيف معه في كل الأحوال»، يرى رئيس

Waydev أليكس تشيرتشي.

ماذا يعني ذلك

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