VOL106: Claude Opus 5 is Here 🚀
أنثروبيك أطلقت Claude Opus 5 وبتقدمه باعتباره الموديل العملي الأقوى للاستخدام اليومي: قريب جدًا من مستوى موديلها الأعلى Claude Fable 5 في البرمجة والمهام المعقدة.
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩
أهلًا وسهلًا بكم في العدد 106 من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.
🌟 مواضيع النشرة لهذا الأسبوع 🌟
الـ AI في سطور: Opus 5 is Here 🔥
شروحات رسومية بالورقة والقلم: Context Rot 🚀
مقالات: الجزء الثاني من سلسةDevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series علي اقرأ تك ✏️
Opus 5 is Here 🔥
نشرة جديدة وموديل جديد و كل أسبوع وأنتم طيبين أعزائنا المبرمجين كوباية شاي و تعالوا نشوف ماذا يقدم لنا الموديل الجديد 🤷♀️
الخبر بيقول إيه؟
Anthropic أطلقت Claude Opus 5 يوم 24 يوليو 2026، وبتقدمه باعتباره الموديل العملي الأقوى عندها للاستخدام اليومي: قريب جدًا من مستوى موديلها الأعلى Claude Fable 5 في البرمجة والمهام المعقدة، لكن بتكلفة أقل تقريبًا للنصف في بعض اختبارات الـcoding agents. وفي نفس الوقت سعر الـAPI الأساسي لم يتغير عن Opus 4.8.
الفكرة الأساسية مش إن الموديل «بيكتب كود أسرع» فقط، لكن إنه أصبح أفضل في:
فهم مشاكل أكبر وأكثر غموضًا.
الاستمرار في مهام طويلة متعددة الخطوات.
التحقق من شغله بدل تسليم أول حل يعمل.
اكتشاف السبب الجذري للـbugs.
استخدام الأدوات وبناء وسائل اختبار لنفسه عند الحاجة.
الحفاظ على جودة أكثر ثباتًا بين تشغيل وآخر
كل دي بالطبع مشاكل بنقابلها حاليًا في استخدامنا لمعظم ال Models و لكن شوفنا تحسن كبير في Fable 5 بالأخص في جزء ال Long Tasks اللي ممكن ينفذها ال Agents ولكن لأن الحياة لا تحلو بلا ثمن ف Fable 5 جه فبتسعير غالي بالفعل!
الشركة هنا بتحاول تنافس نفسها بإنها تنزل موديل “بيحاول يقرب من نفس الكفاءة” ولكن بنصف الثمن,لأن السعر حاليًا هيفرق بشكل كبير في تبني موديلات الشركة ولا لاء وبالأخص بعد ما الموديلات مفتوحة المصدر أو الموديلات الصينية بالتحديد كفاءتها عليت جدًا بسعر قليل وابتدت تلحق بال Flagship Models.
طبعًا المشاكل اللي فوق ممكن نقلل تأثيرها في معظم الموديلات لو المستخدم بيقسم ال Prompts بدل ما يدي ال Agent مهام طويلة وأنه يكون مبرمج واعي وبيراجع ورا ال Model بشكل ناقد وفعال ودا اللي بنكسل نعمله فخلونا نشوف مميزات الموديل في الأجزاء دي.
ما يهم المبرمجين بالتفصيل
1. تحسن واضح في الـdebugging والـroot-cause analysis
أهم مثال عرضته Anthropic كان bug حقيقي في package manager مفتوح المصدر. Opus 5 لم يصلح الـsymptom الظاهر فقط، لكنه وصل للسبب الأساسي واكتشف edge case كان ناقصًا من الـpatch الذي اقترحه المجتمع.
ودي نقطة مهمة جدًا؛ لأن مشكلة موديلات البرمجة عادةً مش إنها لا تستطيع إنتاج fix، بل إنها تنتج fix يجعل الاختبار ينجح بينما يترك المشكلة الأساسية أو حالات أخرى غير مغطاة.
عمليًا استخدمه في:
التحقيق في production incidents.
تحليل race conditions والمشاكل المتقطعة.
تتبع bug عبر أكثر من service.
مراجعة fix والتأكد أنه لا يعالج الحالة الظاهرة فقط.
2. أفضل في المهام الكبيرة التي كنا نقسمها يدويًا
الـearly users ذكروا أنه تعامل مع تغييرات واسعة داخل codebases، واستمر في المهمة مع feedback متكرر، ونفذ أعمالًا كانوا عادةً سيقسمونها إلى tickets أو prompts أصغر.
وده معناه أن الـagent يمكن أن يأخذ feature أكبر نسبيًا:
افهم المتطلبات → استكشف الـcodebase → اقترح التصميم → نفذ → اختبر → راجع الـdiff.
لكن ده مش معناه أنك تديله Jira ticket وتعمل merge مباشرة. الأفضل أنه يكون عندك checkpoints واضحة بعد الـplan، وبعد التنفيذ، وقبل الـmerge.
3. الـdiffs أنظف والـcode review أقوى
عدة شركات في الإعلان أشارت إلى أن Opus 5 بينتج diffs أصغر، dead code أقل، وبيكتشف Bugs دقيقة مرتبطة بالـcodebase نفسه. كمان وقت مراجعة الـ PR لا يقفز مباشرة للتنفيذ، بل يتحقق من الـbranches والـPR template وتأثير التغيير على الاختبارات.
بالنسبة للمطور، قد تكون أقوى استخداماته:
independent review بعد أن ينفذ Agent آخر التغيير.
البحث عن missing acceptance criteria.
مراجعة backward compatibility.
اكتشاف تغييرات جانبية غير مطلوبة.
فحص error handling والـobservability والـtest coverage.
وده في رأيي أهم من زيادة سرعة كتابة الكود نفسها؛ لأن القيمة الحقيقية بتظهر لما يقل عدد الـrounds بين «الكود خلص» و«التغيير خلاص مناسب للـproduction».
4. مستوى الجهد أصبح قرار تكلفة وهندسة
Opus 5 يدعم مستويات مختلفة من effort، بحيث تختار بين استدلال أكبر وجودة أعلى، أو استهلاك tokens أقل ونتيجة أسرع وأرخص. Anthropic تقول إن الموديل يتفوق من ناحية الأداء مقابل التكلفة على مستويات high وxhigh وmax في اختبارات البرمجة التي عرضتها.
ممكن تتعامل معها كده:
Low effort: تعديلات صغيرة، شرح كود، boilerplate، tests بسيطة.
High effort: feature متوسطة، review، debugging معروف النطاق.
Max effort: incident معقد، architecture، migration، refactoring واسع أو bug غامض.
الأفضل أن تختبر كل نوع مهمة داخل فريقك وتحدد أقل effort يحقق مستوى الجودة المطلوب.
5. السعر لم يرتفع عن Opus 4.8
السعر المعلن للـAPI هو:
$5 لكل مليون input tokens
$25 لكل مليون output tokens
وهو نفس سعر Opus 4.8. ويوجد Fast mode بسرعة تقارب 2.5 مرة السرعة الافتراضية، لكنه بسعر مضاعف على Claude Platform.
النقطة المهمة هنا أن التكلفة الحقيقية لا تُقاس بسعر الـtoken فقط. لو الموديل بينجز المهمة من محاولات أقل، tool calls أقل، وبدون إعادة شرح مستمرة، فقد يكون أرخص لكل task حتى لو كان أغلى من موديل صغير لكل token.
تحديثان مهمان لبناء الـ Agents
تغيير الأدوات أثناء المحادثة دون كسر الـprompt cache
أصبح ممكنًا تغيير الأدوات المتاحة للموديل أثناء نفس المحادثة من غير invalidation للـprompt cache.
مثلًا:
تبدأ بأدوات قراءة الـrepository فقط.
بعد اعتماد الـplan تسمح بأداة تعديل الملفات.
بعد التنفيذ تضيف test runner.
قبل النشر تسمح بأداة deployment محدودة.
ده أفضل أمنيًا وأقل تكلفة من إعطاء الـagent كل الصلاحيات من البداية. الخاصية ما زالت beta.
Automatic fallbacks
تستطيع إعداد الـAPI بحيث لو طلب تم إيقافه بواسطة safety classifier في Opus 5، يتم توجيهه تلقائيًا لموديل آخر بدل فشل الطلب بالكامل.
ده مفيد للـproduction reliability، لكن يجب تسجيل اسم الموديل الذي نفذ الطلب فعليًا؛ لأن جودة وسلوك النتيجة قد يتغيران عند الـfallback.
الخلاصة للمبرمجين
زي ما تعودنا بناخد الأرقام في اعلانات النماذج مع شوية ملح من عندنا لأن بعضها مبني على internal evaluations أو شهادات early-access customers ويعني كل هذه الأشياء لا تخلو من حبة ال Marketing!
عشان كدا لا تعتبر الـbenchmarks ضمان للأداء على الـ repository الخاص بك. والأفضل قبل اعتماده أن تعمل eval صغيرة من مهامكم الحقيقية:
10 bugs قديمة معروفة الأسباب.
5 features متوسطة.
10 PR reviews.
مهمة refactoring كبيرة.
مهمة frontend مع visual verification.
وقارن بين نسبة النجاح من أول مرة، جودة الـdiff، عدد الـturns، إجمالي التكلفة، وعدد المشاكل التي اكتشفها البشر بعده.
ولو الأرقام انعكست فعلًا على المشاريع الحقيقية، فأفضل مكان له مش autocomplete أو سؤال برمجي صغير، ولكن الـagentic software engineering workflows: تنفيذ feature كاملة، debugging معقد، code review مستقل، refactoring واسع، والتحقق من أن التغيير جاهز فعلًا للشحن.
إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉
بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉
أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!
مع كل دا بيفضل المجتمع مفيش أي أرقام أو بيانات تقدر ترسم صورة حقيقية ليه تساعدنا نطوره ونتواصل أكتر من كدا.
مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.
الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨
LLMs Context Rot 🚀
ممكن تدي الـ LLM عشرات الآلاف من الـ tokens، وتحط قدامه كل الـ documentation والـ code والـ requirements ولكن برضه يطلعلك بإجابة مختلفة من غير أهم شرط في التاسك اصلًا.
المشكلة هنا مش إن المعلومة مش موجودة، لكن إن الموديل ماعرفش يستخدمها بكفاءة وسط كل كمية الـContext ده. وده اللي بيتسمى Context Rot أو “تدهور السياق”.
يعني إيه Context Rot؟
كل ما الـ Context يكبر ويتملى بتفاصيل كتيرة، ومعلومات متكررة، وقرارات قديمة أو تعليمات عكس بعضها، قدرة الموديل على تمييز المعلومة المهمة واستخدامها صح ممكن تقل.
فتخيل إنك قلت للـCoding Agent في بداية التاسك:
ممنوع نعمل retry للـdeclined payments.
وبعدها دخلت له:
ملفات Code كتير
Logs طويلة
Documentation قديمة
محاولات تنفيذ فشلت
Comments من الـCode Review
Requirements اتغيرت أثناء الشغل
في الآخر ممكن يعمل retry فعلًا، رغم إن الشرط الأصلي ما زال موجودًا داخل الـContext.
فالمعلومة موجودة… ولكن تأثيرها ضاع وسط الزحمة.
المشكلة بتظهر إزاي؟
أشهر شكل من أشكال الـ Context Rot هو Lost in the Middle: المعلومة المهمة بتكون مدفونة في نص Context طويل، فيركز الموديل على المعلومات الموجودة في البداية أو القريبة من الطلب الحالي.
وممكن كمان تحصل بسبب:
Noise: تفاصيل كتير مالهاش علاقة مباشرة بالقرار الحالي.
Conflicts: تعليمات أو Documents بتقول حاجات متعارضة.
الـ Stale Context زي : Plan أو Assumption قديم ما زال موجودًا رغم إنه اتغير.
Error Accumulation: افتراض صغير غلط بيتكرر في الخطوات التالية، لحد ما الموديل يبدأ يتعامل معاه كأنه Fact مؤكدة.
وده بيفسر ليه أحيانًا الـAgent يبدأ التاسك بشكل كويس، وبعد محادثة طويلة تلاقيه:
نسي Acceptance Criterion.
رجع نفذ Requirement قديم.
كرر Bug كان صلحه قبل كدا .
كتب Tests تثبت الـImplementation بتاعه، مش السلوك المطلوب.
بدأ يناقش قرار الفريق حسمه من فترة.
إيه اللي يهمك كمبرمج؟
أهم نقطة: متتعاملش مع الـContext كأنه Database.
كون الموديل يقدر يستقبل 100 ألف أو مليون token مش معناه إن أفضل حل إنك تبعتله كل حاجة عندك، فبدل ما تسأل:
إزاي أحط أكبر كمية معلومات في الـContext؟
اسأل:
إيه أقل كمية معلومات صحيحة يحتاجها الموديل عشان ينفذ الخطوة الحالية؟
الخلاصة
الـContext الكبير مش بالضرورة Context جيد ولكن الـContext الجيد لازم يكون:
Relevant + Current + Structured
في تطبيقات الـLLMs والـAI Agents، شغلك مش مجرد إنك “تحط المعلومات قدام الموديل”، لكن إنك تدير انتباهه وتحدد له إيه المهم في كل خطوة.
سؤال: هل لاحظتم قبل كده إن الـ Coding Agent بدأ التاسك بشكل ممتاز، لكن كل ما المحادثة طولت بدأ ينسى Requirements أو يكرر أخطاء قديمة؟ اكتبولنا في التعليقات حصل معاكم ايه؟
DevOps Beyond the Tools
نزلنا ٣ مقالات جديدة في سلسلة DevOps & Cloud Computing Series، السلسلة موجهة للمبتدئين هتساعدك تبني فهم حقيقي لمجال ال DevOps. هنسأل بنستخدم كل أداة ليه بلغة بسيطة، ونوضح أهميتها وإزاي بتسهّل شغلنا، قبل ما نتكلم عن طريقة استخدامها. ☁️⚙️
ودا لأن كتير من الناس بتبدأ تتعلم DevOps و Cloud Computing على إنه أدوات زي Docker وKubernetes وTerraform، لكن من غير ما تفهم ليه الأدوات دي موجودة أصلًا، وإيه المشكلة اللي بتحلها، وإمتى نستخدمها. 🤔
المقالات الأربعة الأولى:
المقالات الثلاث الجديدة:
نتمنى السلسلة تكون بداية سهلة لأي حد عايز يدخل مجال الـ DevOps والـ Cloud Computing ويكون فاهم كل أداة ابتدأت منين قبل ما يستخدمها 💪
السلسلة من كتابة : Alaa Nassar🌟
بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
