إعادة كتابة Campfire بالـ agents في Rust وElixir وGo تكشف أن المقارنة كانت بين مواصفات مختلفة
المغزى: حين لا يحدد الطلب الموجَّه إلى الـ agent قرارات التصميم، يتخذها الموديل بصمت، فتصبح مقارنة اللغات مقارنة بين قرارات لم يرها أحد.
أعاد DHH كتابة تطبيق Campfire من Rails إلى Rust باستخدام الـ agents، دون أن يقرأ الكود بنفسه، ثم أضاف نسختين بلغتي Elixir وGo وقارن بينها. وفي مقال نُشر في 11 أكتوبر 2026، يرى المطوّر Piotr Sarnacki أن المقارنة سقطت قبل قياس أي رقم.
فنسخة Rust لم تحافظ على التوافق الكامل مع الأصل. أسقطت الـ CSRF token لتسهيل الـ caching، واستغنت عن Redis لصالح طوابير داخل العملية نفسها. أما نسخة Elixir فبقيت قريبة جدًا من أصل Rails.
ولا علاقة لهذا باللغات. فأسئلة مثل الحفاظ على التوافق مع النسخة القديمة، أو تفضيل زمن الاستجابة على عدد الطلبات، أو قبول ضياع إشعار بعد انقطاع، ليس لها إجابة واحدة صحيحة. وحين لا يذكرها الطلب الموجَّه إلى الموديل، يجيب عنها الموديل بنفسه، ولا يظهر ذلك لمن يقرأ النتيجة.
ثم جاء قياس أدق في طلب دمج فتحه Zach Daniels في مستودع نسخة Elixir بين 4 و7 أكتوبر 2026. قاس تسليم إشعارات الرسائل الجديدة تحت حمل زائد شديد بـ 64 ناشرًا، على جهاز Fly بـ 16 vCPU خُصص منها 4 للخادم. فسلّمت نسخة Rust بين 1% و9% من الرسائل، وانقطع بين 233 و554 عميلًا. وسلّمت نسخته بـ Elixir 100% من الرسائل دون أي انقطاع.
ولا يعني ذلك أن Rust أبطأ. فطلب الدمج نفسه يقول إن Rust ما زالت أسرع في الظروف العادية، وإن سلوك إعادة الاتصال أُضيف إلى أداة القياس، فنتائج الحمل الزائد لا تُقارن مباشرة بقياسات سابقة. والفرق ظهر في السلوك تحت الضغط، وهي صفة لا يقيسها اختبار السرعة المعتاد.
ويصبح أمام الفرق التي تستعمل الـ agents لإعادة كتابة أنظمة قائمة سؤال يسبق اختيار اللغة: ما القرارات التي اتخذها الموديل ولم تُكتب في الطلب، وكيف تُقاس قبل الاعتماد على النتيجة.