التكلفة الخفية للذكاء الاصطناعي في أطر عمل JavaScript

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

قام نولان لوسون، الذي أمضى سنوات في استبدال الأعراف الشائعة في الواجهات الأمامية بقياسات فعلية، بالخطوة البديهية التي لم يكلّف أحد نفسه عناء تنفيذها. صمّم تطبيقًا صغيرًا لكنه غير بسيط عن بوكيمون، يتضمن البحث والتصفية وصفحات التفاصيل وبيانات من PokéAPI، ثم طلب من وكيل برمجة بناءه بإثنتي عشرة طريقة مختلفة: Astro وNext.js وNuxt وSvelteKit وReact Router وSolidStart وQwik وAngular وTanStack Start وHono مع htmx وGracile مع Lit، وVite عادي بلا أي إطار واجهة. حصل كل إطار على خمس تشغيلات مستقلة بنفس الموجّه، وخضع كل بناء لمجموعة اختبارات توافق حتى لا يتمكن الوكيل من الغش، وقُيّمت النتائج حسب التكلفة والوقت والتوكنات ومقاييس Lighthouse. ليست التجربة مثالية، ولوسون نفسه يعترف بذلك. لكنها أول محاولة صادقة رأيتها لوضع سعر لقرار تتخذه معظم الفرق بناءً على الانطباعات وحدها.

ماذا قاس الاختبار فعلاً

كان الإعداد محايدًا عن قصد. حصل الوكيل على المواصفات، وطُلب منه استخدام أحدث نسخة من الإطار المحدد، وتُرك ليختار بنيته بنفسه، سواءً SSR أو CSR أو غيرهما. وحين يوفّر الإطار خادم MCP رسميًا أو مهارة وكيل أو إضافة، أُتيحت هذه الأدوات، حتى لا يشتكي أي إطار من أنه غير ممثل بشكل كافٍ في بيانات التدريب. أُجريت اختبارات التوافق على شجرة إمكانية الوصول بدلًا من DOM الخام، وكان لذلك أهمية لأن أحد المنافسين يعرض محتواه عبر Shadow DOM. حصل كل إطار على خمس تشغيلات، وأُعلنت النتائج كقيم وسيطية (median)، باستثناء Angular الذي فشل مرتين في إنتاج تطبيق قابل للاختبار أصلًا، لذلك جاءت بعض أرقامه من ثلاث تشغيلات فقط.

• تراوحت تكلفة البناء بين نحو 2.67 و4.97 دولار للتطبيق الواحد كقيمة وسيطية، أي فارق يقارب ضعفين بين أرخص الأطر وأغلاها.
• استهلاك التوكنات يحكي القصة نفسها بصوت أعلى: حوالي 4 ملايين توكن لأرخص المكدسات، وقرابة 10 ملايين لأغلاها.
• الوقت الفعلي تبع التكلفة عن قرب، من حوالي 8 دقائق في الطرف السريع إلى 17 دقيقة في الطرف البطيء.
• كانت SvelteKit وGracile+Lit وAngular الأغلى باستمرار، بينما كانت Astro وثنائي Hono+htmx الأرخص باستمرار.
• المفاجأة أن بناء Vite بلا إطار تفوق أداؤه على عدة أطر فعلية. فالبنية، حتى بالنسبة للآلة، أفضل من غياب البنية.

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

لماذا تجعل بعض الأطر وكلاء الذكاء الاصطناعي مكلفين

بعد سنوات من تدريب النماذج وتقييمها، أجد النتائج أقل غموضًا مما تبدو. ثلاث آليات تفسر معظم الفروق، ولا علاقة لأي منها بكون إطار ما "أفضل" بالمعنى التقليدي.

كثافة بيانات التدريب هي القدر

أكبر ميزة لـ React في عصر الوكلاء ليست نموذج برمجته، بل أن عقدًا من الدروس التعليمية ومستودعات GitHub وإجابات Stack Overflow ضغط أنماطه داخل أوزان كل نموذج متقدم. الوكيل الذي يكتب React يسترجع المعلومات في أغلب الأحيان. أما الوكيل الذي يكتب Gracile فيكتشف أغلب الأشياء بنفسه: في تشغيلات الاختبار، لجأ الوكلاء الذين لا يعرفون الإطار إلى استنساخ مستودعه أو قراءة كوده المترجم من داخل node_modules. هذه توكنات تُحرق على تعليم تمهيدي قبل أن يوجد أي كود للمستخدم. الديناميكية نفسها تعيد تشكيل طريقة بحث المطورين عن المعرفة عمومًا، وقد كتبت عن ما يحدث لـمجموعة معرفة المطورين مع تراجع Stack Overflow، وزاوية الأطر حالة خاصة وحادة: الأدوات غير الشائعة لا تفتقر إلى المجتمع فحسب، بل تفتقر إلى الحضور داخل النموذج نفسه.

تغيّر الواجهات البرمجية ضريبة توكنات متكررة

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

الإسهاب يتراكم عبر الحلقة

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

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

مشكلة زهر النرد في اختبارات الوكلاء

هنا تعود عادات تقييم نماذج التعلم الآلي القديمة إلى الواجهة، لأن أهم تفصيل في الدراسة كله هو هوامش الخطأ. مخرجات نماذج اللغة توزيع احتمالي، وليست قيمة ثابتة. كانت القيمة الوسيطة لتكلفة بناء React Router أعلى بنحو دولار من Hono+htmx، ومع ذلك كانت أرخص تشغيلة فردية لـ React Router أقل من أغلى تشغيلة لـ Hono. التداخل بين النطاقات كبير. تراوحت تشغيلات SvelteKit بين 3.20 و6.80 دولارات تقريبًا. أحيانًا يكون الوكيل محظوظًا فيتجه بعيدًا عن المسار، ويحرق بضعة ملايين من التوكنات لأسباب لا علاقة لها بالإطار.

بيانات استخدام الأدوات تؤكد الفكرة نفسها. شحنت الأطر خوادم MCP وملفات مهارات، واستخدمها الوكلاء... أحيانًا. لم يُلمس خادم MCP الخاص بـ Nuxt في خمس تشغيلات. اكتُشفت ملفات مهارات TanStack Start في تشغيلتين من خمس. استُخدمت مهارة React Router في كل مرة. الموجّه نفسه والبيئة نفسها، وسلوك مختلف تمامًا، وهذه هي الطبيعة العشوائية للأداة. وهذا يعني أن كل سلسلة على تويتر تدّعي أن "الإطار X أفضل بكثير للوكلاء، لذلك أعدت كتابة تطبيقي كله" مبنية على ظهيرة واحدة من البرمجة بالانطباع، وهي تقيس الضوضاء. تشغيلة واحدة حكاية شخصية. إذا كنت ستسمح للتكلفة بالتأثير على قرار معماري، وأنا أرى أنك يجب أن تفعل، فاطلب القيم الوسيطة عبر تشغيلات متكررة قبل أن تصدّق أي شيء، بما في ذلك هذا الاختبار.

في جودة المخرجات، كل شيء يتقارب إلى المقبول

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

المقياس الجودي الوحيد الذي ظهر فيه تفاوت حقيقي هو حجم JavaScript المشحون: صفر KiB لبناءي Astro وHono+htmx المبنيين على الجزر، وحتى نحو 142 KiB لأثقل مخرجات SPA. ظل Total Blocking Time ضئيلًا في كل الحالات، وكانت قراءة LCP مشوشة أكثر من أن تُستخلص منها نتيجة واضحة. وتنطبق هنا تحفظان صادقان: تطبيق الاختبار أقرب إلى Wikipedia منه إلى Figma، وهو بالتالي يحابي معماريات الصفحات المتعددة، وLighthouse نفسه منحاز بنيويًا ضد تطبيقات SPA. ومع ذلك، تستحق نتيجة JavaScript البسيط وقفة: الوكيل الذي طُلب منه استخدام Vite عادي بلا إطار أنتج درجات أسوأ من عدة أطر فعلية، بما في ذلك أعلى تغيّر تخطيط تراكمي بين كل البناءات. الأطر تُرمّز الأعراف، والوكلاء يعتمدون على الأعراف بشدة. أعطِ النموذج مسارًا معبّدًا يبقَ فيه، وأعطِه حقلًا فارغًا يرتجل، ولا يكون ارتجاله دائمًا جيدًا.

ما الذي لا يستطيع هذا الاختبار إخبارك به

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

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

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

كيف تقيس تكلفة الذكاء الاصطناعي لمكدسك

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

1. اختر شريحة رأسية تمثل عملك الحقيقي، ميزة تلمس طبقة البيانات وإدارة الحالة والواجهة معًا، لا صفحة هبوط.
2. اكتب اختبارات التوافق أولًا. الاختبارات هي بوابة الجودة وأداة منع الغش معًا، والوكيل بلا اختبارات سيعلن النصر مبكرًا.
3. شغّل الموجّه نفسه خمس مرات على الأقل لكل مكدس أو إعداد مرشح. أبلغ عن القيم الوسيطة والنطاقات، وليس عن تشغيلات منفردة أبدًا.
4. سجّل إجمالي التوكنات (مقسومة إلى قراءات الكاش والمدخلات والمخرجات)، والوقت الفعلي، والتكلفة، وعدد استدعاءات الأدوات وحلقات إعادة المحاولة.
5. تتبّع كم من التوكنات يذهب إلى قراءات الوثائق، كأدلة الترحيل وسجلات التغييرات والبحث في node_modules. هذه هي ضريبة عجز بيانات التدريب، وقد قسته مباشرة.
6. أعد تشغيل الاختبار بعد الترقيات الكبرى للإطار. تنجرف تكلفة الذكاء الاصطناعي مع تغيّر الواجهات البرمجية وتحرك حدود بيانات التدريب.

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

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

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

الخلاصة العملية

هل ينبغي أن تعيد كتابة تطبيق Angular الخاص بك بـ Astro لأن الوكلاء يجدونه أرخص؟ لا. الفروق بالدولار صغيرة، والتفاوت كبير، وتطبيق الاختبار لعبة صغيرة، وترحيلك سيكلّف توكنات وكلاء أكثر مما ستوفره خلال عقد. أي شخص يبيعك ترحيل إطار "من أجل الوكلاء" يقوم بالاستدلال القائم على الانطباع نفسه الذي اعتادته الصناعة دائمًا، لكن مع مبرر جديد ملصوق عليه.

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