-->

نظرة عامة

انتشر مؤخرًا اقتباس بسرعة في مجتمعات المطورين: يُقال إن مبتكر Claude Code صرّح بأن “Fable 5 صار يكتب 100% من شيفرتي، وهو أقوى من Opus بثلاثة أضعاف على الأقل.” بمفردها، جملة كهذه أقرب إلى ادعاء تسويقي يصعب التحقق منه. لذلك يفصل هذا المقال أمرين عن قصد: ما هو مؤكَّد رسميًا، وتحليل كيف تُغيِّر هذه الحقائق المؤكَّدة طريقة عمل فرق الهندسة فعليًا.

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

نفصل الحقائق المؤكَّدة عن الاقتباس

أولًا، يبقى الرقمان “100%” و”ثلاثة أضعاف” اقتباسًا فحسب. فالمصدر تصريح فردي، وطريقة القياس غير معلنة. لا نتعامل مع هذه الأرقام بوصفها حقيقة في المتن.

أما ما تؤكده الوثائق العامة فهو الآتي. إن Claude Fable 5 هو أقدر نموذج متقدم متاح للعموم تطرحه Anthropic، وقد أُعلن في يونيو 2026 إلى جانب نموذج Claude Mythos 5 محدود الإصدار. معرّف النموذج هو claude-fable-5. التسعير 10 دولارات لكل مليون رمز إدخال و50 دولارًا لكل مليون رمز إخراج، أي نحو ضعف سعر Opus 4.8. المعالجة الدُّفعية بنصف ذلك عند 5 دولارات للإدخال و25 دولارًا للإخراج، ويهبط الإدخال عند إصابة ذاكرة التخزين المؤقت للموجِّهات إلى دولار واحد لكل مليون رمز. نافذة السياق مليون رمز افتراضيًا، مع إخراج يصل إلى 128 ألف رمز لكل طلب.

أما من حيث الأداء، فادعاء الشركة المعلن هو أنه في معيار تحليلي أساسي يقيس المهام التحليلية المعقدة طويلة الأمد، صار أول من يتجاوز 90%، بتحسُّن نحو 10 نقاط على Opus [تقدير: وفق إعلان الشركة]. كما أوضح فريق Claude Code أنه لأن Fable 5 يعمل لفترة أطول ويتحقق من نفسه وينتج شيفرة أعلى جودة، فإن دور الإنسان ينتقل من “مراقبة ما إذا كان يؤدي العمل بشكل صحيح” إلى “توجيه ما إذا كان يؤدي العمل الصحيح”. هذه الجملة الأخيرة هي في الواقع أهم نقطة في هذا المقال.

ما الذي يختلف في البرمجة الوكيلية

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

[ الإنسان: يحدد النية/الهدف ]
        |
        v
[ الوكيل: يضع خطة ] ---> [ يكتب الشيفرة ] ---> [ اختبار/تشغيل ]
        ^                                            |
        |                                            v
[ الإنسان: مراجعة الاتجاه (توجيه) ] <--- [ حلقة تحقق/إصلاح ذاتي ]
                                              |
                                              v
                                   [ تقديم التغيير عند النجاح ]

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

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

ماذا يعني “كتابة الذكاء الاصطناعي 100% من الشيفرة” لفريق

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

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

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

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

تطبيقه على منصة ThakiCloud السحابية على Kubernetes

يطرح هذا الاتجاه أسئلة تشغيلية ملموسة على مزوّد المنصة. من منظور حزمة ThakiCloud، إليك ثلاث نقاط.

أولًا، بنية التكلفة. سعر رمز الإخراج في Fable 5 هو 50 دولارًا لكل مليون رمز، وهو ليس رخيصًا بأي حال. حين يشغّل الوكيل حلقة ذاتية طويلة، يصبح استهلاك الرموز غير قابل للمقارنة بتبادل سؤال وجواب واحد. حتى الحالة المذكورة سابقًا ببناء لعبة صغيرة واحدة في تمريرة واحدة استهلكت نحو 910 آلاف رمز. لذا فلاستخدام البرمجة الوكيلية على مستوى المؤسسة، تحتاج إلى انضباط في تتبُّع ميزانية الرموز لكل وحدة عمل، وتوجيه النماذج وفق صعوبة المهمة. نماذج رخيصة للاستكشاف البسيط وقراءة الملفات، ونماذج متقدمة فقط للاستدلال المعقد متعدد الخطوات. كما أن تصميمًا يخفض تكلفة الإدخال بنسبة 90% عبر التخزين المؤقت للموجِّهات هو أيضًا رافعة أساسية لضبط التكلفة. تتعامل ThakiCloud مع هذا النوع من التوجيه ونظافة التخزين المؤقت بوصفه إعدادًا افتراضيًا على مستوى المنصة.

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

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

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

القيود والحجج المضادة

لتجنّب قبول هذا الاتجاه دون نقد، نذكر الحجج المضادة بوضوح.

أولًا، الأرقام المقتبسة غير مُتحقَّق منها. “100%” و”ثلاثة أضعاف” تعبيرات تدور دون تعريف قياس، وادعاءات من هذا النوع لا يمكن أن تكون أساسًا لقرار تبنّي أداة. يجب أن يأتي قرار التبنّي الفعلي من تجربة صغيرة وقياس على قاعدة شيفرتك أنت.

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

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

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

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

المصادر

참고

Hermes Bible: Hermes Agent 문서와 실전 워크플로를 한 번에 검색합니다

 

Nous Research의 Hermes Agent 공식 문서 169페이지와 커뮤니티가 만든 실전 워크플로 28개를 한곳에 색인해 ⌘K 한 번으로 검색하는 비공식 커뮤니티 사이트입니다. 무엇을 담고 있고, 공식 문서와 어떻게 다른지, 그리고 1000개가 넘는 스킬과 룰을 운용하는 T...

Fable 5가 내 코드의 100%를 쓴다는 말, 플랫폼 관점에서 따져봅니다

 

Claude Code를 만든 사람이 ‘Fable 5가 내 코드의 100%를 쓰고 있고 Opus보다 최소 3배 강력하다’고 말했다는 인용이 돌았습니다. 검증되지 않은 수치는 인용으로만 두고, 공식적으로 확인되는 사실(가격, 컨텍스트, 벤치마크)과 에이전트형 코딩이 실제로 무엇을 바꾸...