لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 109 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• Opus 5.5 Delivers Fable-level Performance at 40% Lower Cost than Opus 5 🔥

• How Claude’s text watermark works ?! 📝

• Method Channel In Flutter pt.1 📱

Opus 5.5 Delivers Fable-level Performance at 40% Lower Cost than Opus 5🔥

Anthropic نزّلت يوم 22 سبتمبر 2026 موديل جديد اسمه Claude Opus 5.5، وده أول موديل في عيلة 5.5. أداؤه في معظم الشغل قريب من Claude Fable 5.1 (الموديل الأتقل عندهم)، وبيتكلف حوالي 40% أقل من Opus 5 في الاستخدام العادي، وبيطلّع الكلام أسرع بأكتر من 30%.

هو الأول في الـ benchmarks بتاعة الـ agentic coding والـ computer use وشغل المكاتب. كمان جاي بنظام أمان أقوى، وSonnet 5.5 وHaiku 5.5 نازلين في الأسابيع الجاية.

ما يهم المبرمجين

1. الفلوس، وهي أهم نقطة في الخبر كله.

الأسعار لكل مليون توكن بقت: input بـ $4، وoutput بـ $20، والـ cache reads بـ $0.20 بس، والـ cache writes بـ $5. الـ cache reads نزلت 60% عن Opus 5، ودي أهم حاجة لو بتشغّل agents أو شغل كود طويل، لأنها هي اللي بتاكل معظم الفاتورة. وكمان الموديل بيحل المهمة بعدد توكنز أقل، فالتوفير الحقيقي أكبر من فرق السعر لوحده. وفيه Fast mode في Claude Code والـ API، أسرع لحد 2.5 مرة، بس سعره الضعف ($8 / $40).

فبالنسبة للناس المعتمدين علي claude وبالأساس Opus 5 دا معناه مع Opus 5.5 الفواتير أقل والنتائج أحسن.

وبالنسبة لأخواتنا اللي بالفعل راحوا ل Codex من أجل Sol & Astra ففرق السعر( بنتكلم من 20% ل 40% أرخص) يخلينا نجرب من جديد Claude و نحكم علي القيمة المضافة بالفعل بين استخدامنا ل Codex و Claude.

2. جرّب الـ effort المتوسط الأول. الأرقام بتقول إن Opus 5.5 على الـ default (medium) بيغلب Opus 5 على max، وبيقفل مع GPT-6 Astra أو يغلبه بتكلفة من خُمس لـ 40% منه. يعني متحطش max على كل حاجة من غير ما تجرب.

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

3. شاطر في الشغل الطويل. أمثلة من المقال: migration لـ 680 ألف سطر في أقل من يوم، وaudit لكودبيز 200 ألف سطر في أقل من 3 ساعات بدل أكتر من 20 ساعة مع Opus 5، وتحويل HAProxy من C لـ Rust وعدّى تقريبًا كل الـ regression tests. وناس زي Stripe وClio سابوه شغال لوحده ليلة كاملة على كذا repo.

4. من تغييرات في الـ API لازم تاخد بالك منها إن الـ thinking مبقاش ينفع يتقفل خالص في Opus 5.5. لو الكود بتاعك بيبعت thinking disabled، راجعه.

5. قيود الأمان. لأن قدراته في الـ cybersecurity عالية جدًا، معظم مهام الأمن السيبراني بتتحوّل تلقائيًا لـ Opus 4.8. تصليح الباجز العادي في كودك ماشي عادي، بس لو شغلك pentesting أو security research، هتحتاج تقدّم على Cyber Verification Program.

6. أأمن كـ agent. مقاومته للـ prompt injection أحسن (من الأقل في نسبة نجاح الهجمات)، وبيحاول يتخطى الحدود المرسومة له أقل بحوالي 85%. ده مهم لو بتسيبه يشتغل على السيستم بتاعك من غير ما تراقبه.

7. الكتابة بقت أنضف.أنثروبيك بتقول إن الـ comments والـ PR descriptions والشرح بقوا أقصر وأوضح، ودي كانت شكوى مشهورة من Opus 5 ودي شخصيًا هبقي أسعد إنسانة في التاريخ بسبب كمية الصداع اللي بيسببه قراءة كلامه غير المفهوم 🫠

8. لو مشترك (Pro/Max/Team). الـ usage limits بتاعة الخمس ساعات زادت، وفيه rate limit reset تقدر تحتفظ بيه وتستخدمه وقت ما تحب.

و أخيرأ, مسودة الخبر دا اسخدمنا Opus 5.5 عشان يكتبها 😅

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

فاضل ٤ أيام علي نهاية الإستبيان، الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

How Claude’s text watermark works 📝

في الشهر الماضي Anthropic أعلنت عن تقنية جديدة اسمها Text Watermarking لتمييز النصوص اللي Claude ساهم في كتابتها أو تعديلها عشان تمتثل للوائح الإتحاد الأوروبي اللي بتلزم كل مزودين خدمات ال AI بتوفير طرق للتعرف علي أن المحتوي دا تم توليده أو كتابته بالذكاء الاصطناعي.

الخبر بأمانة مكنش مريح للناس وابتدت تطلع أسئلة عن كيفية عمل ال Watermark وهل دلوقتي claude هيضيف Hidden Characters بداخل النصوص اللي بيولدها ولا إيه اللي هيحصل؟!

ورقة وقلم وخلونا نفهم آلية عمل ال Watermarking ببساطة لأنها حقيقة مثيرة للإعجاب..

الفكرة هنا مختلفة عن أدوات الـAI Detection التقليدية. بدل ما النظام يحاول بعد ما النص يتكتب يكتشف من أسلوبه إذا كان مولّد بالذكاء الاصطناعي، Claude من البداية بيضيف أثناء عملية التوليد بصمة إحصائية غير مرئية للنص.

💡 شوفت إحصائية دي عزيزي المبرمج دا معناه إن مفيش Hidden Characters ولا أي حاجة زيادة علي النص اللي تم توليده.

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

آلية العمل

دا بيحصل عن طريق إن Claude في كل خطوة بيختار الـnext token من مجموعة احتمالات، والـwatermark بيستغل عملية الاختيار دي بحيث يخلق pattern إحصائي معين باستخدام آلية بسيطة بأن الأرقام العشوائية اللي بيستخدمها لتحديد الكلمات تتبع نمط محدد.

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

ودا المثال اللي Anthropic أوردته في مقالها عن الWatermark ، لو عندنا الجملة:

“The weather today was cold and…”

فمستبعد إن الكلمة اللي بعدها تكون “sugary”، لكن من المحتمل جدًا تكون “overcast” أو “grey”. وفي الظروف العادية، مش هيفرق كتير للقارئ أنهي كلمة من الاتنين النموذج اختارها، لأن معنى الجملة في الحالتين تقريبًا واحد. في الحالات دي، الاختيار بيتم عن طريق رقم عشوائي.

الـWatermarking بيستغل الاختيارات البسيطة دي، اللي بتحصل مرات كتير جدًا أثناء توليد النص، علشان يسيب نمط إحصائي معين جوه ردود Claude. النمط ده مش ممكن القارئ يلاحظه، لكن ممكن اكتشافه بواسطة أي جهة عندها المفتاح (key) اللي بيحدد النمط ده.

لما الـwatermarking يكون مفعّل، الاختيارات لسه بتتم بشكل عشوائي، لكن مصدر العشوائية هو اللي بيتغير. بدل ما Claude يستخدم مولّد أرقام عشوائية عادي علشان يختار الكلمة الجاية، بيستخدم الـkey مع شوية من الكلمات اللي اتقالت قبل كده علشان يحدد الكلمة اللي هيختارها.

بمعنى آخر، الكلمات اللي Claude بيختارها لسه عشوائية، لكن دلوقتي نقدر نبص على تسلسل الكلمات بالكامل ونشوف هل هو متوافق مع الاختيارات اللي كان Claude هيعملها لو كان بيستخدم الـkey ده. لو التسلسل متوافق، نقدر نحسب احتمالية إن النص اتولد بواسطة Claude.

والأهم إن ده مش معناه إن Claude هيبدأ دايمًا يفضّل كلمات معينة زي overcast أو grey. زي النص العادي تمامًا، ممكن يختار overcast في جملة وgrey في جملة تانية، حسب الكلمات اللي قبلها.

وكمان الـwatermarking مش بيجبر Claude إنه يختار كلمة هو أصلًا مكنش هيختارها. يعني مثلًا مش هيخلي Claude يستخدم كلمة غريبة زي “nubilous”، وهي مرادف أقل شيوعًا لكلمات زي overcast أو grey، لو كان Claude في الظروف العادية غالبًا مش هيستخدمها أصلًا.

فكدا عندنا آلية watermark مرنة جدًا ولا تؤثر علي جودة النص الموّلد والحقيقة إن دي ليست اختراع Anthropic و لكنها مبنية علي ورقة بحثية SynthID-Text approach نشرتها Google DeepMind سنة 2024 فيNature paper. وفي آليات أخري ممكن تتبناها شركات ال AI الأخري ولكن الفكرة العامة زي ما وضحنا.

ملاحظات هامة عن ال Watermarks

النقطة المهمة إن الـwatermark مش دليل قطعي إن Claude كتب النص بالكامل؛ هو أقرب إلى probabilistic signal يشير إلى وجود Claude involvement. فلو Claude كتب مقال كامل، هتكون البصمة الإحصائية أوضح. أما لو استخدمناه فقط لتصحيح grammar أو punctuation في نص كتبه إنسان، فعدد التغييرات هيكون محدود، وبالتالي ممكن تكون الإشارة أضعف أو غير قابلة للكشف. كذلك لو الAI كتب نص وأنت أعدت كتابته بنفسك بشكل كامل ال Watermark هتختفي لأن اختياراك للكلمات وترتيبها مختلف.

ونفس الفكرة تنطبق على الكود: لأن البرمجة فيها اختيارات كثيرة لازم تكون محددة بدقة، مساحة الـwatermarking أقل من النص الطبيعي، وبالتالي تأثير التقنية على الكود محدود. وفي المقابل، الترجمة ممكن تكون أكثر قابلية للـwatermarking لأن Claude بيعيد توليد معظم النص. وإعادة كتابة النص بالكامل، سواء بواسطة إنسان أو نموذج AI آخر، ممكن كمان تقلل أو تزيل البصمة.

Anthropic بتوضح كمان إن التقنية مش AI detector عام؛ يعني عدم اكتشاف watermark من Claude لا يعني إن النص مكتوب بواسطة إنسان، لأنه ممكن يكون مولّد باستخدام ChatGPT أو Gemini أو أي نموذج آخر. الهدف تحديدًا هو إثبات أو تقدير مشاركة Claude في إنتاج المحتوى.

الشركة أعلنت كمان إن الـ Detection API في private preview لمجموعة من الجهات، منها الباحثون، المؤسسات التعليمية، وسائل الإعلام، والجهات التنظيمية.

Method Channel In Flutter pt.1 📱

فاكرين لما اتكلمنا عن Platform Channels وقلنا إنها الجسر اللي بيوصل Flutter بعالم الـ Native؟ 🤔

طب لو اتطلب مننا تاسك بيقول: “هات نسبة البطارية دلوقتي” أو “نفّذلي الـ function دي اللي موجودة أصلا في Android”، هنستخدم إيه بالظبط من الـ Platform Channels التلاتة؟

هنا بالظبط بييجي دور MethodChannel 🚀

في المقال ده هنعرف يعني إيه Method Channel، وهي شغّالة إزاي، والرسالة بتاخد إيه من طريق علشان توصل من Dart لـ Android والعكس، وهنطبّق كل ده على مثال عملي كامل.

1 - يعني إيه Method Channel؟ 🤔

من أنواع الـ Platform Channels اللي اتكلمنا عنها، عندنا:

• MethodChannel

• EventChannel

• BasicMessageChannel

في المقال ده هنركّز على أهم نوع فيهم، وهو MethodChannel.

الـ MethodChannel هي قناة بيستخدمها Flutter علشان يتواصل مع الكود الـ Native في Android أو iOS، عن طريق انه بيستدعي methods بشكل Asynchronous.

بيستخدم لما يكون عندك method معينة بتتنفذ وبترجّع نتيجة بعدها على طول، زي ما اقول للـ Android مثلًا: “نفّذلي function اسمها getBatteryLevel، جيبلي نسبة البطارية دلوقتي، ورجّعلي النتيجة في الأبلكيشن.

💡خد بالك : مش بس Flutter هو اللي بينادي على الـ Native، لأ Android أو iOS كمان يقدروا ينادوا على كود Dart. التواصل بيمشي في الاتجاهين اكنك بتكلم واحد في التليفون و بيرد عليك من الناحية التانية.

2 - إمتى نستخدم Method Channel؟

بنستخدمها لما يكون عندنا عملية أو method معينة محتاجين ننفذها على الـ Native، ونرجّع منها نتيجة. زي مثلًا:

• قراءة مستوى البطارية

• الوصول لإمكانيات معينة في الجهاز

• استخدام API موجود في Android أو iOS ومش متاح مباشرة في Flutter

• التعامل مع كود Native موجود عندنا بالفعل

الفكرة الأساسية عندنا بتتلخص ف ان :

3 - Method channel بتتكوّن من إيه؟

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 108 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• Jev System One Model 🔥

• Google Home MCP Server 🚀

• Claude Code Projects 🤖

Jev System One Model 🔥

معظم استخدامات الـ AI دلوقتي مبنية على LLMs: تبعت للـ model الـ prompt، وهو يبدأ يولد tokens واحدة ورا التانية لحد ما يطلعلك response، وبعدها الـ application يحاول يحول الـ response ده لـ JSON أو decision يقدر يتعامل معاه.

شركة TypeSafe AI شايفة إن ده overkill في حالات كتير، وعشان كده أعلنت عن Jev، أول model عندهم من نوع جديد بيسموه System One Models.

بدل ما Jev يولد text، إنت بتحددله مجموعة decisions ممكنة، وهو يرجعلك typed decision + probability/confidence بشكل مباشر.

يعني لو عندك support ticket مثلًا، بدل ما تطلب من LLM:

"Read this ticket and return JSON containing its category..."

Jev معمول من الأساس إنه يرجع:

billing: 0.91
technical: 0.06
other: 0.03

من غير text generation في النص.

وده مخليه مناسب لحاجات زي classification، routing، scoring والـautomation جوه الـbackend systems. وTypeSafe بتقول إن Jev في بعض الـ workflows بتاعتهم وصل لـ 193.6x أسرع و444.6x أرخص من استخدام frontier LLMs، لكن مهم ناخد بالنا إن دي أرقام من benchmarks الشركة نفسها ولسه Jev في early access.

الفكرة المثيرة هنا مش إن Jev هيستبدل ChatGPT أو Claude؛ هو أصلًا مش معمول عشان يتكلم معاك، ولكن الفكرة هي إننا ممكن نشوف نوع جديد من الـmodels متخصص في: machine → AI → machine

بدل النموذج الحالي: human → AI → human

ولكن ده مش كل حاجة! لإن بعض الناس شايفة إن الحل ده موجود منذ قديم الأزل وإنه من فئة الـ Zero-shot tasks بل كمان فيه حلول أفضل للـ Text Classification. ولكن طريقة تسويقه والعرض اللي طلع بيها اللي خلت عليه Hype كبير!

وممكن قريب نسأل نفسنا قبل ما نحط LLM جوه كل workflow: هل أنا فعلًا محتاج model يولد language؟ ولا أنا محتاج decision وبس؟

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

Google Home MCP Server 🚀

أخيرًا الـ MCP خرج شوية من عالم الـ developers، وده بنشوفه من خلال شركة Google اللي بدأت Early Access لـ Google Home MCP Server، واللي بيسمح لأي AI assistant أو development tool بيدعم Model Context Protocol إنه يتعامل مباشرة مع Google Home.

يعني agent زي Claude أو ChatGPT أو أي MCP client ممكن — بعد ما تديله authorization — يعرف حالة الأجهزة الموجودة في البيت، يراجع event history ويتحكم في connected devices.

مثلًا بدل ما تعمل automation ثابتة:

الساعة 11 اقفل كل الأنوار.

ممكن يبقى عندك agent يفهم instruction زي:

“لما أتأكد إني خرجت من البيت، اقفل الأنوار والأجهزة اللي مش محتاجها، ولو حصل أي activity غريب بعد كده عرفني.”

أو تسأله:

“حصل إيه في البيت من الساعة 3 للساعة 6؟”

وهو يقدر يستخدم event history والأجهزة المتصلة عشان يجاوبك.

Google حاطة safety restrictions، مثلًا Home MCP مش بيسمح للـagent إنه يعمل sensitive actions زي unlocking doors، وبتحذر إن توصيل agent ببيتك ممكن يخليه ينفذ actions غير متوقعة لو الـagent نفسه تصرف بشكل غلط.

وده يمكن أهم جزء في الخبر.

لأن MCP بدأ كطريقة تخلي AI Agents تتعامل مع APIs وdeveloper tools، لكن دلوقتي بنشوفه يدخل عالم الأجهزة الحقيقية.

يعني بدل: Agent → GitHub / Database / Slack

بدأنا نوصل لـ: Agent → Lights / Cameras / Thermostat / Home

ولو الاتجاه ده كمل، MCP ممكن يتحول من protocol للـAI tools إلى واحدة من الطرق الأساسية اللي الـagents تتعامل بيها مع العالم حواليها!

Claude Code Projects 🤖

Anthropic بدأت تختبر شكل جديد من Claude Code Projects، والفكرة هنا مش مجرد إن Claude Code يفتكر الـproject بتاعك، بل إنت ممكن تديله goal كبير، زي:

اعمل migration للـ authentication system، حدّث الـ tests، وعدل الـ documentation.

بدل ما session واحدة تعمل كل ده بالترتيب، فيه coordinator يقسم الشغل لـ threads مختلفة، وكل thread عبارة عن Claude Code cloud session كاملة بتشتغل في نفس الوقت.

واحد ممكن يشتغل على الـ backend، واحد على الـ tests، وواحد على الـ documentation، وكل واحد شغال على branch منفصل، بينما الـcoordinator متابع كل الشغل وعنده shared project memory.

ولو قفلت الـlaptop، الـthreads نفسها بتفضل شغالة لأنها cloud sessions.. وده تطور مهم جدًا في شكل الـCoding Agents.

من فترة كنا بنتعامل مع: Developer → Coding Agent

لكن الاتجاه اللي بيتشكل دلوقتي أقرب لـ:

Developer → Coordinator Agent → Multiple Coding Agents

يعني دور المطور ممكن يتحول تدريجيًا من كتابة وتنفيذ كل task بنفسه، إلى إنه يحدد الـgoa l والـ constraints ويراجع شغل مجموعة agents بتشتغل بالتوازي.

وطبعًا parallel agents مش معناها parallel magic؛ لو اتنين عدلوا نفس الجزء في الـcode، لسه ممكن يبقى عندك merge conflicts عادي جدًا، وكمان كل thread عبارة عن session مستقلة، فالاستخدام ممكن يستهلك الـlimits أسرع.

والجدير بالذكر إن الشكل ده من استخدام الـ Coding Agents ناس كتير بدأته من بدري خصوصًا في بناء الـ Harness الخاصة بيهم وبالأخص في جزء الـ Agentic Software Development Lifecycle واللي بيقوم على نفس الفكرة إن فيه Multiple-Agents بيعملوا أكتر من حاجة.

الفكرة هنا إن جزء الـ Implementation ذات نفسه بقى بيتم على أكتر من Sessions مختلفة وفيه Orchestrator يقدر يوازن بينهم بدل ما كنا بنعمل ده على Scale الـ task الواحدة.

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في ثالث عدد مميز من سلسلة Engineering Radar من النشرة الأسبوعية لاقرأ-تِك 🚀

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

أخبار الـ AI اتراكمت علينا لأن شهر أغسطس وسبتمبر كان فيه الكثير من المفاجأت فقولنا نرجعلكم بعدد ثالث من Engineering Radar وفيه أهم الأخبار ونشوف ازاي نستفيد منها كمبرمجين, فيلا بينا!

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• The Powerful Stealth AI Model Ox Alpha

• Anthropic Launches Claude Fable 5.1

• OpenAI Launches GPT-6 Astra

The Powerful Stealth AI Model ‘Ox Alpha’

تخيل تستخدم موديل AI على مشروعك، وتكتشف بعد أسبوع إنك كنت بتختبره لصالح شركة من أكبر شركات الـAI أصلًا، من غير ما تعرف.

ده تقريبًا اللي حصل مع Ox Alpha.

في 20 أغسطس ظهر موديل جديد على OpenRouter وOpenCode باسم Ox Alpha، من غير أي إعلان رسمي عن الشركة اللي وراه. الموديل جذب انتباه المطورين بسرعة بسبب أدائه والمواصفات اللي قدمها: نافذة سياق تصل إلى مليون Token، قدرات قوية في الـreasoning والـcoding، دعم للـmultimodal input، وإتاحة شبه مجانية للاستخدام.

طبيعي جدًا إن مجتمع الـAI يبدأ يحاول يعرف: مين ورا Ox Alpha؟

ومع الاستخدام بدأت تظهر بصمات تقنية مثيرة للاهتمام. الـtokenizer كان مطابقًا لـGLM 5.3، والـvideo encoder تصرف بنفس طريقة GLM5V، وحتى بعض أكواد الأخطاء التي ترجعها الـAPI كانت تشير إلى نفس البنية التحتية الخاصة بـZ.ai. وقتها بدأت فرضية أن Z.ai هي الشركة وراء Ox Alpha لكن لم يكن هناك تأكيد رسمي.

وفي 26 أغسطس أعلنت Z.ai الحقيقة: Ox Alpha كان في الأساس GLM 5.3 Flash يتم اختباره بشكل stealth قبل إطلاقه رسميًا.

والجزء المثير هنا أن التجربة لم تكن مجرد beta صغيرة؛ Ox Alpha خدم أكثر من 44 تريليون Token لأكثر من 500 ألف مستخدم، عبر أكثر من 13 مليون session، ووصل في إحدى المراحل إلى أكثر من 10% من إجمالي استخدام OpenCode.

بمعنى آخر، Z.ai كانت بتجمع feedback من استخدام حقيقي وعلى نطاق ضخم، بينما معظم المستخدمين لا يعرفون أصلًا من يقف وراء الموديل.

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

طيب، إيه اللي يميز GLM 5.3 Flash؟

الموديل مبني كـ Mixture-of-Experts، بإجمالي 320 مليار Parameter، لكن 18 مليار فقط بتكون active لكل Token. وهو ما يساعد على تقليل تكلفة الـinference مقارنةً بما قد تتوقعه من موديل بهذا الحجم.

كما يستخدم Hybrid Attention يجمع بين Sparse وLinear Attention للتعامل بكفاءة أكبر مع الـlong context، وتم تدريبه على حوالي 30 تريليون Token متعدد الوسائط، مع إمكانية التحكم في مستوى الـreasoning بين low وhigh وmax.

ما يهم المبرمجين

أهم نقطة بالنسبة لينا مش أرقام الـbenchmarks نفسها زي ما وضحنا قبل كدا إن الأرقام لا يعتمد عليها بشكل كبير، وإنما نوع المهام التي تم تصميم الموديل من أجلها.

GLM 5.3 Flash موجه بقوة نحو الـcoding والـagentic workflows؛ وبشكل أكبر من كتابة function صغيرة ،ولكن إنك تعطيه repository كبيرة ومهمة متعددة الخطوات وتجعله يقرأ الكود، يفهم الـarchitecture، يستخدم الـtools، يشغل tests، ويستمر في العمل عبر context طويل.

وثاني أهم حاجة لأنه open-weight بترخيص MIT، وبالتالي تستطيع استخدام الأوزان وتعديلها وFine-tune الموديل وتشغيله على infrastructure خاصة بك، بدل أن تكون مقيدًا بالكامل بـAPI مغلقة.

وثالث أهم حاجة إنك حتي لو هتستخدم ال API فهو رخيص جدًا مقارنة بأسعار ناس كدا🤷‍♀️

ومن هنا أعتقد أن Ox Alpha يستحق اهتمامنا فعلًا ونشوف هل يقدر يضيف قيمة في شغلنا اليومي ولا لأ.. ممكن استخدامه كـcoding agent، أو كـbackend لمهام تحتاج إلى context ضخم، أو داخل بيئة خاصة عندما تكون خصوصية الكود والبيانات مهمة.

Anthropic Launches Claude Fable 5.1

Anthropic أطلقت Claude Fable 5.1، موديل جديد أقوى من اللي قبله و أنتو عارفين بقية القصة؛ مش هنعيد كل كلام التسويق بتاعهم إنهم بيحاولو يغيروا الطريقة اللي بنستخدم بيها الـAI في البرمجة من “مساعد يكتب كود” إلى Agent قادر ياخد مهمة كبيرة ويشتغل عليها لساعات من غير ما يحتاج متابعة مستمرة لأنه بالفعل دا ال Main Stream خلاص هنتكلم بس في أهم نقطتين

Anthropic بتصف Fable 5.1 بأنه أقوى موديل لديها حاليًا للـcoding والـknowledge work، وهو نفس الـunderlying model الموجود في Claude Mythos 5.1، لكن مع safeguards مختلفة. Mythos مخصص حاليًا لجهات مختارة تعمل في cybersecurity وlife sciences، بينما Fable 5.1 هو النسخة المتاحة بشكل عام.

بالنسبة لنا كمبرمجين أهم نقطة هي : إيه اللي Fable 5.1 بيعمله بشكل مختلف عن Opus 5 اللي إحنا متعودين عليه؟

الفرق الأساسي مش إن Fable “بيفهم الكود أحسن شوية”، وإنما في القدرة على تنفيذ مهام طويلة ومعقدة end-to-end. Anthropic صممت Fable 5.1 بحيث يقدر يتعامل مع مشروع يمتد عبر codebase كاملة، يعمل planning، يستخدم الأدوات، يكتب ويشغل tests، يراجع شغله، ويكمل من النقطة اللي وقف عندها بدل ما يتوه مع طول المهمة، وده ظاهر في نتائج ال BenchMarking بفروقات مش جذرية أوي ولكن لصالح Fable 5.1.

وده يقودنا للنقطة اللي أعتقد إنها أهم ميزة فعلية للمبرمج: Fable 5.1 أفضل عندما تكون المشكلة نفسها غير واضحة، وليس فقط عندما يكون المطلوب تنفيذ solution معروف. هو أكثر قدرة على اكتشاف root cause، والتحقق من النتائج، وإعادة ترتيب خطواته عندما يكتشف أن افتراضًا سابقًا كان خطأ.

وودا ظهر في تجارب الشركات، Datadog قالت إنه نجح في تشخيص أعقد production incidents لديهم، وPlaid اختبرته على تغيير امتد عبر أكثر من 8 services وثلاثة codebases، وتمكن من تتبع الـworkflow كاملًا من الـservice call حتى الـfunctions والـdatabase rows.

طيب وال Pricing ؟

سعر Fable 5.1 هو $10 لكل مليون input tokens و$50 لكل مليون output tokens، وهو نفس سعر Fable 5. الجديد والمهم هو أن cache reads أصبحت $0.25 لكل مليون Token، أي أقل بـ75%. بس من هذا التغيير

Anthropic بتقدر أن التكلفة الإجمالية تنخفض بحوالي 25% في الاستخدامات العادية، وقد تصل إلى حوالي 45% في الـhighly-agentic workloads التي تعيد استخدام كميات كبيرة من الـcontext..

الخلاصة

Opus 5 لا يزال موديل قوي جدًا ومصمم للاستخدام اليومي ومعظم الناس بتميل لاستخدامه، بينما Fable 5.1 موجه أكثر للمهام اللي تستفيد من frontier-level intelligence + long-running autonomy.

بالتالي، لو أنت بتستخدم Claude كـdaily coding assistant عشان تعمل refactoring صغير، تكتب function، تصلح bug واضح، أو تسأل عن implementation، مش لازم كل حاجة تتحول إلى Fable.

لكن لو المهمة على مشروع كبير من نوع : “افهم الـarchitecture دي، دور على سبب المشكلة، عدّل عدة أجزاء في المشروع، اكتب tests، شغّلها، راجع النتائج، وكمل لحد ما توصل لحل production-ready”، فهنا Fable 5.1 هو النوع من الـupgrade اللي ممكن يفرق فعلًا.

🚀 OpenAI Launches GPT-6 Astra

OpenAI أعلنت عن GPT-6 Astra باعتباره أحسن موديلاتها أداءًا، مع تركيز واضح على software engineering، computer use، browsing، cybersecurity، والـprofessional work.

والأرقام التي أعلنتها الشركة ملفتة جدًا: Astra حقق 98% في FrontierMath Tier 4، و99.9% في ARC-AGI-3، و100% في ExploitBench، كما أصبح أقوى بكثير في التعامل مع الكمبيوتر والمتصفح، وهي قدرات مهمة لأن الموديل لم يعد يعمل فقط داخل نافذة chat، وإنما يستطيع تنفيذ سلسلة من الأفعال داخل بيئة عمل حقيقية.

وأهم حاجة شوفناها في الإعلان إن فيه تغييرات واضحة في طريقة شغل الـcoding agents نفسها اتغيرت.

أهم المميزات:

• أقوى في الـagentic coding، مش بس code generation. OpenAI بتقول إن Astra بيحتاج iterations أقل عشان يوصل لكود قريب من production quality، وبيتحسن بشكل ملحوظ مع زيادة الـeffort لأنه يعمل verification أكتر، browser testing أكتر، ويميل لتشغيل الكود فعليًا بدل مجرد تعديل files بشكل مباشر. ده معناه إن القيمة الأكبر هتظهر في مهام زي feature كاملة، debugging طويل، refactoring، migrations، واختبارات E2E، مش في autocomplete أو snippet صغير.

• أقوى في computer use والـbrowser workflows. الموديل يقدر يبني موقع، يشغله، يتفاعل مع الـUI، ويعمل frontend QA بشكل أكثر استقلالية. OpenAI بتقول إن الأداء على OSWorld 2.0 وصل إلى 72.6% مقابل 65.7% لـGPT-5.6 Sol، وبوقت أقل بحوالي 47% في المحاكاة المذكورة. وده مهم لأن الـcoding agent الحديث لم يعد بس يكتب code؛ هو بيحتاج يفتح التطبيق ويختبره زي المستخدم.

• أحسن في التعامل مع التعليمات المتغيرة. من مشاكل الـagents الحالية إنك لو عدلت requirement في نص المهمة، أحيانًا الموديل ينسى الهدف الأساسي أو يتعامل مع التعديل كأنه task جديدة. Astra متدرب بشكل أفضل على الحفاظ على الهدف الأصلي، دمج requirement جديد، والإجابة على side questions من غير ما يضيع السياق العام. دي نقطة مهمة جدًا في الشغل الحقيقي لأن الـrequirements نادرًا ما تفضل ثابتة.

• أكثر تحفظًا في حدود الصلاحيات. OpenAI بتقول إنها اختبرت موقف يكون فيه الهدف صعب أو مستحيل، وشافت هل الموديل يتجاوز الـauthorized scope عشان ينجز المهمة. في eval مذكور بالإعلان، GPT-5.6 Sol تجاوز النطاق المسموح في 48% من الحالات بدون production safeguards، بينما Astra سجل 0%. ده مهم للـagents اللي عندها shell، browser، GitHub، cloud access، أو deployment permissions

• إدارة الـcontext الطويلة اتغيرت بشكل مهم. بدل الاعتماد فقط على compaction اللي بيلخص المحادثة لما الـcontext يخلص، Codex مع Astra يقدر يحتفظ بـnotes عبر نوافذ context مختلفة، وكمان يعمل search في الـcontext القديم نفسه عشان يرجع requirement أو test result أو tool output قديم. دي نقطة مهمة جدًا في الـlarge refactors والـdebugging sessions الطويلة لأن الـagent أقل عرضة إنه “ينسى” ليه حل سابق فشل.

طيب وال Pricing ؟

سعر Astra في الـOpenAI API هو $10 لكل مليون input tokens و$50 لكل مليون output tokens، مع cached input بسعر $1 لكل مليون token. وإذا تجاوز الـinput في الطلب 272K Token، تتضاعف تكلفة الـinput والـcache وتزيد تكلفة الـoutput إلى 1.5×، لذلك استخدامه مع context ضخم يحتاج إلى حساب التكلفة بتركيز.

فلازال مكلف زي Fable و الاستخدامات يفضل تكون محسوبة من جهتك كمبرمج.

معظمنا بيعتمد منذ فترة علي Claude و Opus بالتحديد ولكن من فترة قريبة ابتدينا نشوف تحول نحول Codex وأظن هذا التحول ممكن يزيد مع وجود Astra حاليًا. والسبب أن أكبر تطور في Astra مش أنه يكتب كودًا أفضل منك أو حتى أفضل من Opus، وإنما أنه بيخلي المهمة التي تقدر تفوضها للـAI أكبر وتطلع بجودة كبيرة؛ مع تدخلك أنت للتوجيه والمراجعة والقرارات المهمة في أوقات أقل.

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 107 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• VS Code Rubber Duck Agent 🔥

• AWS Agent Toolkit 🚀

• Cloudflare AI-enforced Engineering Standards 🤖

VS Code Rubber Duck Agent 🔥

الـ IDE بتاع VS Code بيجرب فكرة جديدة: وهي إنه يخلي Agent تاني يراجع شغل الـ Agent .. ودي فكرة منتشرة بقالها فترة في الشركات وبدأوا يطبقوها!

واحدة من أكبر المشاكل مع الـ Coding Agents دلوقتي إننا ساعات بنتعامل معاهم كأنهم Developer وReviewer في نفس الوقت، فالـAgent يكتب الـ implementation، ويكتب الـ tests، وبعدها يبص على الشغل ويقولك: Found the shooting gun!

بس في الـ Software Engineering إحنا أصلًا بنحاول نتجنب ده .. علشان كده عندنا Code Review وحد تاني يبص على الـchange بعين مختلفة. فـ VS Code بدأ يجرب نفس الفكرة مع الـAI من خلال feature جديدة اسمها Rubber Duck.

الفكرة ببساطة إن الـprimary agent، زي Copilot، يقدر يستدعي model تاني ياخد دور الـ critic ويبص على الـ plan أو الـ code أو الـ tests ويقول له:

• هل في logic errors؟

• هل الـdesign نفسه فيه مشكلة؟

• هل في security issue؟

• هل ناقص test coverage؟

• هل في edge case الـAgent الأول مخدش باله منها؟

وبعدها بيرجع feedback مصنف لـ blocking issues و non-blocking issues و suggestions، والـ primary agent هو اللي بيقرر يتصرف إزاي بناءً عليه. فالـRubber Duck نفسه read-only، يعني مش بيروح يعدل الملفات أو يشغل commands.

والأجمل من ده كله إن VS Code ممكن يستدعيه تلقائيًا في الشغل الـ non-trivial كذلك: فمثلًا بعد الـplanning، أو أثناء implementation معقدة، أو حتى بعد كتابة الـ tests، أو لو الـ Agent فضل يغلط أكتر من مرة.

ليه ده مهم؟

لأننا غالبًا داخلين على مرحلة جديدة ومختلفة وهي مرحلة إن الـ AI Coding فيها مش هتبقى:

Developer → Agent → Code

لكن أقرب لـ:

Developer → Builder Agent → Reviewer Agent → Code

وده تغيير مهم في طريقة تفكيرنا في الـCoding Agents .. لان الفترة الجاية زي ماحنا ملاحظين العائق والـ Bottleneck دلوقتي هي في كمية الـ AI Output اللي طالع ومحتاج يتعمله Review ، فالفترة الجاية غالبًا مش هتكون تحت مسمى كتابة الكود .. ولكن هيكون دورنا متحور أكتر في “مراجة الكود اللي طالع من الـ AI” ، ومراجعة مدى الآمان اللي الكود بيغطيه.

فكل ما الـAgents تبقى قادرة تنتج code أسرع، المشكلة هتتحرك من “مين هيكتب الكود؟” إلى “مين هيتأكد إن الكود ده صح؟” وطبعًا وجود Agent تاني مش معناه إن الـHuman Review مبقاش مهم، لكنه بيضيف verification layer قبل ما الـchange أصلًا يوصل للمراجع البشري ويسهل عليه المراجعة.

والسؤال هنا: لو بتستخدم Coding Agent دلوقتي، هل بتخليه هو نفسه يكتب ويراجع شغله؟ ولا بدأت تعمل independent review step فعلًا؟

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉


أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

AWS Agent Toolkit 🚀

لو بتستعمل أي Coding Agent فأكيد لاحظت إن أحيانا كتير بيفترض حاجات مش موجودة في الـ Documentations وأحيانًا بيتسخدم حاجات Outdated، وعشان كده AWS عايزة الـ Coding Agent بتاعك يبطل يخمن!

لو جربت قبل كده تطلب من Claude Code أو Codex أو Cursor يبني لك حاجة على AWS، غالبًا شفت واحد من السيناريوهات دي:

يقترح service مش أنسب اختيار، أو يستخدم API أو configuration قديمة خصوصًا مع الـ SDK Configurations، أو يبني حاجة شغالة فعلًا لكن بعيدة عن AWS best practices.

وده منطقي، لإن الـCoding Agent عنده معرفة عامة جدًا عن AWS، لكن AWS نفسها فيها آلاف الـAPIs وعشرات الخدمات اللي بتتغير باستمرار.

علشان كده AWS بدأت تدفع بقوة ناحية الـ Agent Toolkit for AWS.

الـToolkit بيدي Coding Agents زي Claude Code وCodex وCursor وKiro حاجتين مهمين:

1. Skills فيها workflows وbest practices وknowledge متخصصة في AWS وطبعًا up-to-date.

2. وAWS MCP Server يخلي الـAgent يتعامل مع AWS من خلال interface معمولة أصلًا للـAgents، مع access خاضع لـIAM وauditability.

والـsetup نفسه بقى مباشر من AWS CLI:

aws configure agent-toolkit

الـCLI يكتشف الـCoding Agents الموجودة عندك، يثبت لهم الـAWS Skills المناسبة، ويقدر كمان يجهز AWS MCP Server connection.

AWS بتقول إن الـToolkit حاليًا فيه 40+ Agent Skills، والـMCP Server بيوفر interface لأكثر من 15,000 AWS APIs.

هل الـ Platforms هتبدأ تتبع النهج ده؟

الأهم هنا مش الـtool نفسها اللي AWS عملتها ولكن الأهم هو الاتجاه العام ده واللي بينور في دماغنا فكرة مختلفة عن طريقة تعاملنا عامة مع الـ Cloud أو أي Platforms تانية.

لحد قريب احنا بنحاول نحط كل حاجة للـAgent في: AGENTS.md أو prompt طويل فيه architecture وbest practices وتعليمات المشروع، ولكن دلوقتي الـplatform نفسها بدأت تقول:

أنا هدي الـAgent المعرفة والأدوات اللي محتاجها علشان يشتغل عندي صح.

وده غالبًا شكل مهم من أشكال الـAgent ecosystem اللي جاي، فبدل ما الـAgent يعتمد بس على المعلومات اللي اتدرب عليها، هيبقى عنده combination من:

Model + Skills + MCP + Project Context + Guardrails

وده هيخلي جودة الـAgent مش معتمدة بس على “أنهي model بتستخدم؟”، لكن كمان على إيه الـenvironment اللي مجهزهاله؟

فالمرة الجاية لما Coding Agent يعمل AWS architecture مش منطقية، المشكلة مش هتكون في الـmodel… ولكن هتكون في عدم وجود الـcontext والـtools اللي انت مقدرتش توفرهاله بشكل سليم.

Cloudflare AI-enforced Engineering Standards 🤖

Cloudflare عندها 230 ألف سبب يخلوك تعيد التفكير في الـ Engineering Guidelines .. كل شركة تقريبًا عندها شوية rules المفروض الـ Engineers يمشوا عليها، سواء بقىWiki، Confluence، RFCs، README files، رسائل Slack قديمة…

المشكلة إن وجود الـrule مش معناه إن كل Developer شافها، فاكرها، أو حتى يعرف إنها موجودة.

Cloudflare قررت تتعامل مع المشكلة بطريقة مختلفة، فبدل ما الـ Engineering Standards تفضل مجرد Documentation، جمعتها في source of truth اسمه Cloudflare Codex، وبقت الـ AI systems نفسها تستهلك الـstandards دي أثناء الـ Software Development Lifecycle.

فمثلًا عندهم AI Code Reviewer بيراجع الـ Merge Requests ويشوف هل الـ change ماشية مع الـengineering standards ولا لأ.. لو rule عبارة عن recommendation، ممكن يطلعها كـ feedback عادي، لكن لو الـ RFC enforced وفيها requirement من نوع MUST، الـ reviewer ممكن يمنع approval للـchange.

والأرقام في الحقيقة كانت ملفتة:

من بداية النظام ده، الـAI Code Reviewer اكتشف تقريبًا 230,000 violations للـEngineering Standards، وحوالي 16,000 منهم كانوا violations قوية كفاية إن الـapproval يتوقف بسببها.

والفكرة مش واقفة بس عند الـcode review .. ولكن Cloudflare عندها كمان Spec Reviewer Agent بيراجع الـ technical designs قبل ما implementation تبدأ أصلًا، وكمان systems بتستخدم نفس الـ standards في أجزاء تانية من الـ engineering lifecycle.

Enforcing Engineering Knowledge

وده بيخلينا نعيد التفكير في إنه يمكن أفضل استخدام للـ AI داخل Engineering Teams مش إنه يكتب code أكتر، ولكن إنه يخلي الـengineering knowledge اللي عند الشركة قابلة للتنفيذ.

فبدل ما تكتب:

“كل service لازم تكون بتتبع الـ Rules دي” في Document وبتتمنى الناس تقراه وتفتكره.

ممكن تخلي الـ CI أو Reviewer Agent يعرف الـ rule، يكتشف مخالفتها، ويشرح للـDeveloper ليه الـchange مش متوافقة معاها، ووقتها الـ Engineering Standards تبدأ تتحول لمعرفة قابلة للتنفيذ.

وده خصوصًا مهم مع انتشار الـCoding Agents.

لأن لو الـAI بقى قادر ينتج changes أسرع بعشرات المرات، فأنت محتاج الـquality controls والـengineering standards تكبر بنفس السرعة، وإلا هتزود سرعة إنتاج الكود… وسرعة إنتاج المشاكل معاه.

والسؤال المهم هنا لأي Engineering Team: تفتكرواكام rule عندكم مكتوبة في Confluence محدش بيفتكرها غير لما بتحصل المشكلة؟

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في ثاني عدد مميز من سلسلة Engineering Radar من النشرة الأسبوعية لاقرأ-تِك 🚀

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

أخبار الـ AI كانت مثيرة للاهتمام أخر 10 أيام فقولنا نرجعلكم بعدد ثاني Engineering Radar وفيه أهم الأخبار ونشوف ازاي نستفيد منها كمبرمجين, فيلا بينا!

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• AI Coding Agents: Adoption Trends In 2026 🤖

• DeepSeek Harness: What is it 🔥

• Replit expands access to software creation with GPT‑5.6 Luna 🧑‍💻

AI Coding Agents: Adoption Trends In 2026 🤖

JetBrains نشرت يوم 18 أغسطس 2026 تحليل بعنوان “AI Coding Agents: Adoption Trends” مبني على Developer Ecosystem Survey 2026، والـsurvey دي شملت أكتر من 15,000 professional developer حول العالم، والبيانات اتجمعت بين مايو ويوليو 2026.

أهم نتيجة في التقرير إننا مش إننا بننتقل من مرحلة AI assistant بيكمل لك السطر لمرحلة Coding Agent بياخد task كاملة ويشتغل عليها ولكن إن دا بقى جزء طبيعي من الـ developer workflow مش بس حاجة advanced developers بيجربوها.

الصورة الكبيرة

بحسب JetBrains:

• 90% من الـprofessional developers بيستخدموا AI coding agents في الشغل مرة على الأقل أسبوعيًا.

• 68% بيستخدموهم يوميًا.

ودي قفزة ضخمة جدًا لو قارنتها ببيانات JetBrains قبلها بشهور. في يناير 2026 مثلًا، JetBrains كانت بتقول إن حوالي 22% فقط كانوا بيستخدموا coding agents، وإن معظم استخدام الـAI كان لسه individual productivity أكتر من كونه workflow كامل جوه الـSDLC.

أكثر الأدوات استخدامًا و تبنيًا في بيئات العمل

التقرير عرض مقارنات بين أشهر ال Coding Agents من ناحية “ ايه هي أشهر الأدوات الخاصة بال coding agents “ اللي سمعت عنها وتم وضعها تحت ال Awareness Section

و المقارنة الثانية كانت عن استخدامك لل Coding Agent في العمل في جزء تطوير البرمجيات

الأرقام بتظهر إن في الصدارة Claude Code و يليه Github Copilot و من ثم Codex و Cursor لكن إتجاه الحركة هو اللي مثير للاهتمام لأن في النسخة الأقدم من التقرير في يناير ٢٠٢٦ كان معدل استخدام Claude Code في العمل بس 18% من المشاركين والرقم وصل ل 39% في التقرير في أغسطس ودي وتيرة سريعة جدًا لتغير أساليب المبرمجين في شغلهم.

GitHub Copilot كمان فقد الصدارة بعد ما كان لفترة طويلة تقريبًا synonym لـAI coding. لكن استخدامه في العمل نزل من: 29% → 21% مع إن الـawareness بتاعه لسه حوالي 79%. ودا بيورينا إن الـautocomplete لسه مفيد جدًا، لكن بقى feature جوه workflow أكبر، مش هو الـworkflow نفسه.

ما يهم المبرمجين

تعلم استخدام Agent أهم من تعلم Prompt Engineering

المهارة المطلوبة بتتحول من:

How do I write a clever prompt?

إلى:

How do I delegate engineering work correctly?

فبدل ما اكتب

Write this wishlist service for me 

هقدمله المهمة يطلع منها خطة تنفيد وكمان معاها كل الشروط و التوجيهات اللي تطلعها في أحسن شكل + شروط الاختبار ومراجعة الكود

We need to add a Wishlist feature.

A logged-in user should be able to:

save a product
remove a saved product
list their saved products

Before writing code:

Inspect the repository and understand how authenticated users are represented.
Find how similar user-owned resources are modeled.
Check the existing API conventions, error handling, pagination, and database patterns.
Check whether there are existing product availability/deletion rules we need to respect.
Propose an implementation plan and identify any ambiguous requirements.

Constraints:

A user cannot save the same product twice.
Removing something that isn't saved should be idempotent.
Don't introduce a new architectural pattern if an existing one fits.
Follow the existing API conventions.
Don't modify unrelated code.

After the plan is approved:

implement the feature
add unit/integration tests
run the relevant test suites
run lint/static checks
review your own diff for regressions or unnecessary complexity
summarize the final design decisions and any remaining risks

من التقرير واضح إن دورنا بيتحول من "كاتب Code" إلى "Controller of Code Generation"

لو الـagent يقدر يعمل:

read ticket
↓
inspect repository
↓
write code
↓
run tests
↓
fix errors
↓
open PR

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

• نهتم بجودة ال Design والاتجاه اللي هطلب من الAgent يمشي فيه

• نهتم بجودة ال Harness و القواعد اللي ال Agent بيتبعها في فهم وتوليد واختبار الاكواد

DeepSeek Harness: What is it 🔥

تم إطلاق DeepSeek Harness (dsh) في Developer Preview يوم 13 أغسطس 2026. وهو مهم لأنه مش موديل جديد، بل Harness وهي الطبقة اللي بتحوّل الموديل من chatbot إلى agent فعلي قادر يشتغل على مشروعك. DeepSeek عاملاه open source تحت MIT، والفكرة الأساسية فيه: Everything is a plugin.

أولاً تلخيصًا ما هو ال Harness ؟

الـLLM لوحده بيعرف يفكر ويولد text، لكنه مش عارف:

• يقرأ repository ولا يشغل terminal ولا يعدل files ولا يحتفظ بـsession ولا يعمل sub-agents ولا حتي يشغل tests.

الـHarness هو البنية اللي حوالين الموديل وبتخليه قادر ينفذ الحاجات دي ودا اللي بيخليه Agent. و DeepSeek بتلخصها كده:

Agent = Model + Harness

وده concept مهم جدًا؛ لأن جودة الـcoding agent مش معتمدة على ذكاء الموديل فقط. طريقة إدارة الـcontext والـtools والـagent loop والـsandbox ممكن تعمل فرق كبير جدًا في النتيجة

طيب إيه المختلف في DeepSeek Harness؟

المبدأ الأساسي هو:

Everything is a Plugin

مش بس الـtools plugins، تقريبًا كل حاجة plugin:

• Model

• Tools

• Skills

• Agent loop

• Sessions

• Storage

• Sandbox

• Subagents

• Scheduling

• UI

حتى الـagent loop نفسه قابل للاستبدال. ودي نقطة مختلفة عن إنك تقول عندي coding agent وأقدر أضيفله MCP tool. هنا الفكرة أقرب إلى عندي kernel صغير، وأنا أكوّن فوقه الـagent اللي أنا عايزه.

DeepSeek Harness مبني فوق framework اسمه Cordis. الـkernel نفسه لا يحمل معظم الـagent logic. دوره الأساسي إدارة:

• تحميل plugins.

• dependencies بينها.

• services.

• events.

• lifecycle.

وبعد كده الـplugins هي اللي تبني الـagent.

يعني ممكن يكون عندك الأساس وكل حاجة تحطها بعد كدا ك Plugin:

Cordis Kernel

├── Claude model plugin

├── GitHub tools plugin

├── Bash plugin

├── Filesystem plugin

├── Sandbox plugin

├── Planning plugin

├── Subagent plugin

├── Memory plugin

├── Agent loop plugin

ودا هيخلي استبدال أي جزء في ال Flow سهل جدأ تستبدل Claude بـDeepSeek أو sandbox محلي بـremote sandbox من غير ما تعيد بناء الـagent كله. ودي أهم نقطة للمبرمجين لأن معظمنا حاليًا بيستخدم:

Claude Code
Codex
Cursor

كـproducts ب Agents جاهزة وأنا بس بخصص الAgents دي لأداء مهام معينة.

DeepSeek Harness أقرب إنه يكون platform لبناء agent بتاعك أنت.

يعني بدل:

Use Claude Code
       +
add MCP servers
       +
add AGENTS.md

تقدر تعمل ال Agent من الصفر وتزود ال Plugins المناسبة لشغلك، وده هيكون أهم سبب يخلي المشروع واخد ال 176K Stars على Github في الوقت القصير دا.

المميزات التي يقدمها

• Model مش مربوط بـDeepSeek

لكن architecture معمولة بحيث الـLLM adapter نفسه plugin.

الـdocs موضحة إن إضافة model provider معناها تسجيل adapter على ctx.llm.

يعني theoretically تقدر تشغل Claude أو GPT أو Gemini أو حتي Local Model فوق نفس الـHarness.

وده مهم جدًا لأنك تقدر تعمل benchmark حقيقي للنماذج المختلفة. (GPT vs Claude vs DeepSeek ) بنفس الأدوات والسياق والمهمة و ال Harness.

بدل ما تقارن Claude Code مع Codex، وفي الحالة دي بتغير الموديل والـharness في نفس الوقت.

• الـ Agent Loop نفسه Plugin

فكرة إن ال Agent Loop نفسه مش hardcoded فكرة ذكية جدًا وبتسمح بتخصيص كبير للمبرمجين.

الـloop الطبيعي:

Prompt
  ↓
Model
  ↓
Tool Call
  ↓
Result
  ↓
Model
  ↓
Tool
  ↓
...

هنا حتى الـagent loop نفسه جزء قابل للتبديل.

يعني ممكن تعمل agent loop :

Plan
 ↓
Implement
 ↓
Test
 ↓
Review
 ↓
Fix

أو:

Investigate
 ↓
Generate 3 hypotheses
 ↓
Test hypotheses
 ↓
Choose root cause

أو حتى loop خاص بالـSDLC بتاع شركتك.

• وجود Standard Mode

ده coding agent شبه اللي إحنا متعودين عليه وعنده نفس ال capabilities زي ال file editing و ال subagents و ال Skills وغيرها يعني تقدر تستخدمه مباشرة من غير ما تبني framework.

• بيقدم أيضًا Creator Mode

وده معمول للناس اللي عايزة تبني Agent Harnesses فالـagent يقدر يشوف runtime الحالي و يجرب plugins ويركب capabilities ويبني presets جديدة.

يعني بدل ما تعدل config بنفسك طوال الوقت:

Build me an agent specialized for reviewing Spring Boot PRs.

والفكرة إن الـagent يساعدك تركب الـplugins المناسبة.

• Forking Sessions

الـHarness بيدعم إنك تعمل fork لل Agent Session. وده مفيد جدًا في exploration والـplanning لأنه وقت التخطيط ممكن يعرض أكثر من فرضية ونحتاج نعملها Investigation , فهنا يقدر يفتح أكثر من Session عشان يفكر فيها في الافتراضات المختلفة داخل ال Plan.

ما يهم المبرمجين

ال DSH بيعرض نفسه كمنافس قوي جدًا ل Claude Code وبكفاءة عالية ومفتوحة المصدر فيستحق التجربة لكن مش هابني عليه production platform دلوقتي من غير abstraction حواليه، لأن DeepSeek نفسها محذرة بوضوح إن المشروع ما زال Developer Preview وإن APIs ممكن يحصل فيها breaking changes. لكن اللي نتعلمه منه حتي لو مش هنستخدمه هو إننا نفصل الـModel عن الـHarness. فما تبنيش architecture مربوط بـClaude أو GPT. لأنه واضح إن ال Open Source سيأتي وبقوة - يارب - و نقدر بعد Adaptation من السوق ننتقل رسميًا ليه.

Replit expands access to software creation with GPT‑5.6 Luna 🧑‍💻

في 19 أغسطس 2026 Replit أعلنت إنها عملت Free Mode جوه Replit Agent، والموديل اللي مشغله هو GPT-5.6 Luna. الهدف إن الناس تقدر تخطط، تسأل، تستكشف، وتطوّر فكرة التطبيق من غير ما تقلق من استهلاك usage/tokens

هنا Replit بتفصل بين مرحلتين: التفكير في الحاجة وبناء الحاجة. في Free Mode تقدر تتناقش مع الـAgent عن الـarchitecture، الـfeatures، الـUX، التحسينات، أو المشاكل في المشروع، وهو شايف full project context. ولما تبقى جاهز للتنفيذ، تنتقل لـBuild Mode. ولو المهمة احتاجت reasoning أقوى، Replit ممكن يعمل routing لـGPT-5.6 Sol وبعدها يرجع تاني لـLuna، مع الحفاظ على نفس project context.

طيب إيه اللي يهم المبرمجين فعلًا؟

أول حاجة مهمة هي Model Routing. بدل ما كل task تروح لأقوى وأغلى موديل، Replit بتستخدم موديل أرخص وأسرع كـdefault، وتطلع للموديل الأقوى بس لما المهمة تحتاجه:

• بشكل أساسي تستخدم GPT Luna

• المهمة محتاجة Reasoning أقوي؟ بننقل ل GPT Sol

  وده ممكن يقلل التكلفة بشكل ضخم من غير ما تضحي بالجودة في المهام الصعبة. OpenAI نفسها بتقول إن تحسن price/performance هو اللي خلى Replit قادرة توفر التجربة دي لملايين المستخدمين.

ثاني حاجة هي إن Context continuity بقت جزء من الـproduct architecture، مش مجرد feature لطيفة. Replit بتأكد إنك لما تنتقل بين الاستكشاف والتنفيذ أو حتى بين موديلين، الـproject context يفضل موجود.

ودي مرتبطة جدًا باللي اتكلمنا عنه قبل كده في Harness Engineering: إن الموديل وحده مش كفاية. إدارة الـcontext حواليه ممكن تكون أهم من فرق صغير في benchmark.

ثالث حاجة، Replit بتغيّر مفهوم "free AI coding". زمان الـfree tier غالبًا معناه prompts قليلة أو موديل ضعيف. هنا هم بيحاولوا يخلو جزء كبير من الـsoftware development workflow نفسه free: التفكير، الـplanning، الـfeedback، والـanalysis، وبعدين فقط التنفيذ الفعلي أو reasoning الأكثر تكلفة يبقى له economics مختلفة.

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

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

فرق الهندسة في Stripe و Tempo بيقدموا open protocol جديد علشان الـ Agents تقدر تشتري ساندوتشات فول وطعمية بطريقة سهلة وبدون تدخل بشري. فيا ترى ايه اللي هيحصل لما الـ Agents يبدأ يبقى معاهم محفافظ ؟ وهل يا ترى هنوصل لمرحلة إن ممكن الـ Agents تشتري الحاجات اللي احنا عاوزينها بسهولة وبدون تدخل بشري فعلًا؟

تخيّل إنك مدي الـ coding agent عندك task: “حلّل الـ logs، ولو محتاج dataset مدفوعة اشتريها، وشغّل الـ browser session، واستخدم أفضل model للمهمة دي، وابعتلي النتيجة لما تخلص”.

الطبيعي واللي بنشوفه هو إن الـ agent عارف يخطط، وعارف يستدعي الـ APIs، ويستخدم كمان الـ tools، ولكن أول ما بيقابل خدمة مدفوعة، كل ده بيقف: فانت محتاج تعمل account، تختار plan، تدخل card، تعدّي الـ 3DS، وتنسخ الـ API key.

دي مش مشكلة intelligence؛ ولكن دي مشكلة إن الـ payment infrastructure اتبنت للبشر.

في مارس 2026، Stripe وTempo قدّموا Machine Payments Protocol — MPP: open protocol يخلي أي client آلي يطلب resource، يعرف سعره، يقدّم payment credential، وياخد النتيجة والـ receipt جوه نفس HTTP flow.

الفكرة شكلها صغيرة: HTTP 402 Payment Required بدل pricing page. لكن لو نجحت، هي ممكن تغيّر شكل الـ APIs، الـ SaaS، والـ internet economy نفسها.

الخلاصة قبل الدخول في التفاصيل

الـ MPP مش wallet، ومش blockchain، ومش payment processor جديد، ولكن هو لغة تفاوض موحّدة بين machine عايزة تشتري وservice عايزة تبيع.

الـ flow الأساسي:

1. الـ agent يطلب resource أو ينادي tool.

2. الـ service ترد بـ 402 ومعاها Challenge: السعر، العملة، والـ payment methods المقبولة.

3. الـ agent يطبّق spending policy، وممكن يطلب human approval.

4. الـ agent يبعت Credential تثبت إنه authorizes الدفع.

5. الـ service تتحقق وتعمل settlement على rail مناسب.

6. الـ service ترجع الـ resource ومعاه Receipt.

أهم نقطة: الـ protocol منفصلة عن طريقة تحريك الفلوس .. فنفس الـ handshake ممكن يشتغل فوق stablecoins، أو cards وLink عن طريق Shared Payment Tokens — SPTs، ومع methods تانية مستقبلًا.

المشكلة اللي MPP بتحاول تحلها فعلًا

الـ agent النهارده يقدر يكتشف tool عن طريق MCP، يفهم الـ schema، ويبعت request صح، ولكن الـ discovery والـ execution مش للدفع. والـ billing التقليدي بيفترض إن فيه إنسان هيعمل onboarding مرة واحدة:

Read more

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 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.

مثلًا:

1. تبدأ بأدوات قراءة الـrepository فقط.

2. بعد اعتماد الـplan تسمح بأداة تعديل الملفات.

3. بعد التنفيذ تضيف test runner.

4. قبل النشر تسمح بأداة 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 Beyond the Tools: Intro of DevOps and Cloud Computing Series

• Why Cloud Computing Appeared?

• Why Docker Appeared?

• Why Kubernetes Appeared?

المقالات الثلاث الجديدة:

• Why Terraform Appeared?

• Why CI/CD Appeared?

• Monitoring vs. Observability

  نتمنى السلسلة تكون بداية سهلة لأي حد عايز يدخل مجال الـ DevOps والـ Cloud Computing ويكون فاهم كل أداة ابتدأت منين قبل ما يستخدمها 💪

السلسلة من كتابة : Alaa Nassar🌟

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 105 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• الـ AI في سطور: Kimi K3 Outperforms Claude Fable 5 in Frontend Coding 🔥

• شروحات رسومية بالورقة والقلم: Batch API In LLMs Explained 🚀

• مقالات: سلسلة جديدة للمبتدأين علي اقرأ تك بعنوان DevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series ✏️

Kimi- K3 Outperforms Claude Fable 5 in Frontend Coding 🔥

أعلنت Moonshot AI عن إطلاق Kimi K3، أحدث نماذجها مفتوحة الأوزان (Open Weight)، بحجم 2.8 تريليون بارامتر، مع Context Window تصل إلى 1M Token ، ودعم مدمج لفهم الصور (Native Vision).

لكن الإعلان مكنش بس إطلاق نموذج جديد، ولكن جه بنتائج لافتة.

ففي تصنيف LLM Arena، قدر Kimi K3 ينتقل من المركز الثامن عشر إلى المركز الأول في فئة Frontend Code، متفوقًا على Claude Fable 5.

أبرز ما جاء مع Kimi K3

• أداء تنافسي مع أفضل النماذج لأنه قرب بالفعل من أداء Claude Fable 5 وGPT-5.6 Sol

• عرض عملي مثير للإعجاب
  في تجربة مباشرة، استخدم فريق Moonshot مجموعة من وكلاء الذكاء الاصطناعي (Agent Swarm)، واستغرقوا حوالي 3 ساعات لبناء نسخة تعمل بالكامل داخل المتصفح من ل macOS 27! و مش بس كدا دا فيها :تصميم Liquid Glass, تطبيقات تحاكي تطبيقات النظام الأصلية ولعبة شطرنج تعمل بشكل كامل

• الإتاحة
  النموذج متوفر حاليًا عبر Kimi.com وواجهة Kimi API، بينما تخطط Moonshot لإتاحة الأوزان الكاملة للنموذج كمصدر مفتوح في 27 يوليو 2026.

• التسعير
  تبدأ تكلفة استخدام الـ API من:

• 3 دولارات لكل مليون توكن إدخال غير مخزنة مؤقتًا (Uncached Input Tokens)

• 15 دولارًا لكل مليون توكن إخراج

وهي نفس الأسعار المعلنة لنموذج Claude Sonnet.

ليه إعلان النموذج دا مهم؟

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

تسعير Kimi K3 بمستوى قريب من Claude Sonnet بيعكس ثقة Moonshot في قدرات النموذج، وبيأكد أن المنافسة لم تعد تعتمد على انخفاض التكلفة، بل على جودة النتائج الفعلية.

والأهم أن تفوق Kimi K3 في مهام ال Frontend بهذا الشكل بيشير إلى تحول واضح في السوق؛ فلم يعد هناك الفارق الكبير اللي كان يفصل بين النماذج مفتوحة الأوزان والنماذج المغلقة. واليوم أصبحت النماذج المفتوحة قادرة على المنافسة، بل والتفوق، في بعض أكثر المهام تعقيدًا.

وقت واعد جدًا للنماذج مفتوحة المصدر، هل ممكن الفترات اللي جاية تتبناها الشركات بشكل رسمي؟! قولولنا رأيكم🤔

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉


أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

Batch API in LLM Explained ⚙️

Batch API معناه إنك تجمع عدد كبير من الطلبات المستقلة وتبعتها كدفعة واحدة، بدل ما تبعت كل request وتستنى الرد لحظيًا. مزود الخدمة يعالجها في الخلفية خلال فترة زمنية محددة، غالبًا ساعات أو حتى 24 ساعة، مقابل سعر أقل من الـAPI العادي. فعند مزود زي OpenAI Batch API بيخلي التكلفة 50% أقل!

تخيّل عندك 50,000 ticket من Jira / Zendesk / Intercom، وعاوز تصنّفهم مثلًا إلى:

Billing, Bug, Feature Request, Account, Technical Support, Refund, Other

بدل ما تبعت كل ticket للـ API وتستنى الرد فورًا، بتجهّزهم كلهم كـ batch job وتبعته مرة واحدة، والنتيجة ترجعلك لاحقًا.

الفكرة ببساطة بدل الشكل ده:

Ticket 1 → API → wait → result
Ticket 2 → API → wait → result
Ticket 3 → API → wait → result

يبقى الشكل كده:

Tickets file:
- Ticket 1
- Ticket 2
- Ticket 3
- ...
- Ticket 50,000

        ↓

Batch API

        ↓

Results file لاحقًا

في المثال اللي ذكرته، السعر ينزل للنصف من $10 input / $50 output لكل مليون token إلى $5 input / $25 output عند استخدام الـBatch API. طبعًا دا قلل التكلفة ولم تخسر شيئاَ لأن المهمة ممكن تخلص بشكل Asynch.

امتى استخدم الـ Batch API ؟

الـBatch API مناسب للمهام اللي مش محتاجة رد فوري، أي حاجة تقدر تعملها بشكل Asynch زي:

• تلخيص آلاف الملفات

• تصنيف tickets

• تحليل logs علي مدار اليوم

• إنشاء embeddings أو metadata

• مراجعة كمية كبيرة من PRs القديمة

• تشغيل evaluations على prompts وموديلات مختلفة.

  لكنه غير مناسب لواجهة chatbot مباشرة أو coding assistant أثناء ما أنت بتكتب كود، لأن المهام دي بطبيعتها Synchronous وبتحتاج رد فوري وتفاعل و مش هينفع تنتظر نتيجة الدفعة بدل الاستجابة اللحظية.

  ما الفرق بينه وبين ال Prompt Caching ؟

  الاثنين بيوفروا في فاتورة استخدامك لل LLMs ولكن كل واحد ليه دوره وشرحنا ال Prompt Caching في ورقة وقلم من قبل تقدروا تشوفوه من هنا.

• باختصار: استخدم prompt caching لما نفس السياق الطويل بيتكرر في requests كثيرة واستخدم Batch API لما عندك requests كثيرة لكن مش محتاج نتائجها فورًا.

DevOps Beyond the Tools

كتير من الناس بتبدأ تتعلم DevOps و Cloud Computing على إنه أدوات زي Docker وKubernetes وTerraform، لكن من غير ما تفهم ليه الأدوات دي موجودة أصلًا، وإيه المشكلة اللي بتحلها، وإمتى نستخدمها. 🤔

علشان كده بدأت سلسلة DevOps & Cloud Computing Series، سلسلة موجهة للمبتدئين هتساعدك تبني فهم حقيقي لمجال ال DevOps. هنسأل بنستخدم كل أداة ليه بلغة بسيطة، ونوضح أهميتها وإزاي بتسهّل شغلنا، قبل ما نتكلم عن طريقة استخدامها. ☁️⚙️

هدفنا إنك تخرج من كل مقال فاهم الفكرة قبل الأداة، وتكون قادر تربط بين التقنيات المختلفة بدل ما تحفظها بشكل منفصل. 🚀

نزل إلي الآن ٤ مقالات من السلسلة:

• DevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series

• Why Cloud Computing Appeared?

• Why Docker Appeared?

• Why Kubernetes Appeared?

نتمنى السلسلة تكون بداية سهلة لأي حد عايز يدخل مجال الـ DevOps والـ Cloud Computing ويكون فاهم كل أداة ابتدأت منين قبل ما يستخدمها 💪

سلسلة جديدة مميزة بالعربي من كتابة : Alaa Nassar🌟

تقدروا تشوفوا أول مقال كامل من هنا وقراءة ممتعة 🎉

قراءة المقال الأول

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

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

فريق الـ Engineering في Slack، بدأ يجرب حاجة اسمها Agentic Testing — بمعنى تاني تسيب الـ AI agent يعمل الـ testing بدل ما تكتبه بإيدك. والسؤال المهم هنا: هل ده هيحل محل الـ tests التقليدية؟ ولا مكانه مختلف خالص؟ وايه المميزات اللي بيقدمها؟

مصطلحات مهمة — Terminologies

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

• الـ E2E Testing (End-to-End): ده اختبار بيتأكد إن التطبيق شغال من أوله لآخره زي ما المستخدم الحقيقي هيستخدمه، يعني بدل ما تختبر function صغيرة لوحدها، إنت بتمثّل رحلة كاملة: افتح الصفحة → اضغط زرار → اكتب حاجة → اتأكد إن النتيجة ظهرت صحيحة.

• الـ Deterministic Test: هو عبارة عن test “محدد سلفًا” — بيعمل نفس الخطوات بالظبط في كل مرة، ولو الظروف اتغيرت بيفشل .. بمعنى تاني هو بيكون test متوقّع ومكرر.

• الـ Playwright: من أشهر الـ frameworks لكتابة الـ E2E tests للمواقع ، وبيتحكم في المتصفح بالكود (يفتح صفحات، يضغط، يكتب... إلخ).

• الـ MCP (Model Context Protocol): بروتوكول بيسمح للـ agent إنه يتكلم مع أدوات خارجية بطريقة منظّمة (structured)، فهنا Playwright MCP بيدّي الـ agent أوامر جاهزة للمتصفح.

الانتقال من اختبار “الرحلة” لـ “الهدف” — الفرق الجوهري

الفكرة كلها بتبدأ من هنا: الـ test التقليدي بيختبر رحلة محددة جوه الـ UI:

click → click → type → assert

يعني إنت بتقوله بالظبط: دوس هنا، بعدين هنا، اكتب كده، وبعدين اتأكد إن كذا حصل .. ولو أي حاجة اتحركت من مكانها، الـ test طبعًا بيقع.

بينما الـ agent بيشتغل بطريقة تانية ومختلفة خالص: إنت بتديله هدف (goal)، وهو اللي بيدبّر نفسه:

goal → agent adapts → verify result

فمثلًا بنقوله: “ابعت رسالة في thread” — وهو بقى يشوف إزاي يعملها .. الجملة اللي ممكن تلخّص الفكرة كلها هي إن:

الـ Tests بتفرض رحلة محددة بينما الـ Agents بتتحقق من الهدف (Tests enforce journeys. Agents verify goals.)

الـ Diagram ده بيوضّح الفرق:

في تجارب Slack، الـ workflow العام فضل ثابت (مثلًا: login → search → result → clear)، لكن الخطوات بالتفصيل اتغيرت من run للتاني، فالـ agent كان بياخد طرق مختلفة يوصل بيها لنفس النتيجة:

• طرق إدخال مختلفة (يدوس على اقتراح في الـ search vs يدوس Enter)

• أنماط navigation مختلفة (يفتح الـ search من جديد vs يستخدم الـ state الموجود)

• خطوات زيادة أو ناقصة (ضغطات زيادة، snapshots، أو خطوات وسيطة)

المشكلة الحقيقية

الـ agentic testing شكله حلو وجميل، بس فيه سؤال محرج شوية لازم نسأله:

حاجة بتكلّف من 15 لـ 30 دولار في الـ run الواحد وبتاخد أكتر من 10 دقايق — هل ممكن تدخل فعلًا في workflow حقيقي؟

من أول نظرة الإجابة تبان إن بكل تأكيد “لأ”... بس بعد أكتر من 200 run، هنلاقي Slack اكتشفت إنها حاجة مختلفة جوهريًا عن الـ tests التقليدية، وممكن تبقى reliable جدًا، وليها مكان واضح في الـ testing stack.

السبب في كل ده هو التطور اللي حصل في الـ LLMs مؤخرًا، واللي خلّى الـ agents تقدر تكتب كود، وتعمل debug للـ failures، وتتفاعل مع الـ UI مباشرة بسهولة وسلاسة.

التجربة نفسها

عشان يفهموا الـ agent-driven tests ازاي تقدر تـ Fit وتكون جزء أساسي وضمن هيكلة الـ Testing Stack، فـ Slack شغّلت أكتر من 200 execution عن طريق إعدادات مختلفة، وكانوا هدفهم إنهم يقيسوا من خلالها 3 حاجات: الـ reliability، السرعة، والتكلفة.

نماذج التنفيذ — Execution Models

جرّبوا ٣ طرق مختلفة:

1. الـ Agent + Playwright MCP: الـ agent بيتعامل مع المتصفح من خلال الـ Playwright MCP، بيستخدم أوامر جاهزة (دوس على element، اكتب input، اقرا الـ DOM state...) مع الاحتفاظ بالـ context (snapshots و logs).

2. الـ Generated Playwright Tests: هنا الـ agent بياخد وصف بلغة عادية جدًا، ويكتب كود Playwright حقيقي (deterministic)، يشغّله كـ E2E test عادي، ويظبطه شوية بشوية لحد ما ينجح.

3. الـ Agent + Playwright CLI: الـ agent بيشغّل أوامر Playwright من الـ shell، وبينفّذ خطوة واحدة كل مرة، ويقرر اللي بعدها بناءً على حالة الـ UI الجديدة.

إعدادات التجربة — Setup

• الـ Model للـ MCP/CLI كان: Claude Sonnet 4.5

• الـ Model للـ Generated Tests كان : Claude Opus 4.6

• التنفيذ: Claude Code بوضع non-interactive (claude -p)

• كل التجارب اتعملت في test workspaces ببيانات مش حقيقية (non-production data) — ودي نقطة مهمة جدًا للأمان.

الـ Flows اللي اتجربت

استخدموا 2 flows بس بمستويات تعقيد مختلفة، وثبّتوهم في كل التجارب عشان المقارنة تبقى عادلة:

• الـ Thread Reply (بسيط): ~15–20 خطوة — يعمل channel، يبعت رسالة، يرد في thread، ويتأكد من حالة الـ thread.

• الـ Search Discovery (متوسط): ~25–30 خطوة — يكتب search queries، يتنقّل في النتايج، يتحرك بين الـ views المختلفة (search, channels, threads)، ويتأكد من النتايج.

شكل الـ Input

للطرق اللي فيها agent، جرّبوا نوعين من الـ Inputs:

• الـ Natural Language (NL): تعليمات مكتوبة بلغة بشرية عادية بالتفصيل (مثلًا: “رد في thread، واتأكد إنه ظهر في All Threads”).

• الـ Structured YAML: نفس الـ workflow بس بصيغة منظّمة، بخطوات و actions و targets و expected outcomes واضحة.

والفرق هنا مكنش في كمية التفاصيل، ولكن الفرق في إزاي التفاصيل متمثّلة: الـ NL بيحتاج الـ agent يفسّر ويترجم الكلام لأفعال، أما الـ YAML فبيحدد الربط ده بشكل صريح أكتر وبشكل مباشر.

Experiment Matrix

كل Configuration اشتغل تقريبًا 20 مرة:

النتايج — اللي لاحظوها

خلونا نفصّص النقاط دي واحدة واحدة.

1) الاعتمادية — Reliability

أكتر pattern واضح شافوه: هو إن الـ reliability بتتغير كل ما الـ flow يبقى أعقد.

• الـ Playwright MCP كان الأكثر ثباتًا — failure قريب من الصفر في السيناريوهات البسيطة، وبين 0–12% في الأعقد.

• الـ Playwright CLI كان failure أعلى (تقريبًا 12–20%)، ومعظم المشاكل كانت من حاجات تنفيذية زي الـ authentication، توقيت الـ navigation، وعدم استقرار الـ session — مش من تفكير الـ model نفسه.

• الـ Generated Tests كانت كويسة في البسيط (~8%)، بس اتدهورت بشكل كبير في الأعقد (~48%). الحلو إنها مكانتش غلط تمامًا — كانت بتكمّل 70–80% من الـ flow وبعدين تقع في آخر تفاعل أو assertion.

ليه الفرق ده؟ السبب الأرجح هو إزاي كل طريقة بتتعامل مع الـ state:

Read more

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 104 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• إنطلاق إستبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

• الـ AI في سطور: OpenAI Launches GPT-5.6 🔥

• شروحات رسومية بالورقة والقلم: Prompt Caching Explained 🚀

• أدوات وتقنيات ومشاريع عربية: ملتقى إتقان لتقنيات القرآن ✨

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

OpenAI Launches GPT-5.6 🔥

الموديلات مبقتش بتجاوبك بس… بقت بتقسّم الشغل على نفسها! 🌞

أعلنت OpenAI عن عائلة GPT-5.6 الجديدة، والمكوّنة من 3 موديلات:

• Sol للمهام المعقدة اللي محتاجة أعلى مستوى من التفكير.

• Terra لتحقيق توازن بين الجودة والتكلفة.

• Luna للمهام السريعة والـ workloads الكبيرة.

بس بعيدًا عن أرقام الـ benchmarks المعتادة، أكتر حاجة مثيرة للاهتمام في GPT-5.6 مش إنه «أذكى شوية» من الجيل اللي قبله ، ولكن الفكرة إن OpenAI بتحاول تغيّر المقياس اللي بنحكم بيه على الموديلات أصلًا.

بدل ما تسأل: الموديل عرف يحل كام سؤال؟

السؤال بقى: قدر يكمّل كام مهمة حقيقية؟ استخدم كام Tool Call؟ استهلك كام Token؟ واحتاج منك تدخل كام مرة؟

OpenAI بتقول إن GPT-5.6 بقى أفضل في المهام الطويلة اللي محتاجة تخطيط، استخدام أدوات، مراجعة النتيجة والاستمرار لحد ما المهمة تخلص، مع استهلاك Tokens ووقت أقل في عدد من الاختبارات. وفي تجارب Lovable مثلًا، الموديل احتاج خطوات وTool Calls أقل، وقلّل عدد المهام اللي بتقف في النص.

وده مهم لأن تكلفة الـ AI Agent مش سعر الـ Token بس، ولكن التكلفة الحقيقية هي:

عدد المحاولات + الوقت الضايع + تدخل الإنسان + المهام اللي فشلت واضطريت تبدأها من الأول.

من وكيل واحد — لفريق من الوكلاء

GPT-5.6 بيقدّم كمان وضع جديد اسمه Ultra، بيشغّل 4 Agents بالتوازي بشكل افتراضي، وكل Agent يشتغل على جزء مختلف من المشكلة قبل ما النتائج تتجمع في إجابة أو تنفيذ واحد.

يعني بدل ما الـ Agent يعمل:

بحث → انتظار → تحليل → انتظار → مراجعة

يقدر يقسّم البحث والتحليل والمراجعة على أكتر من Agent في نفس الوقت.

وده تقريبًا نفس اللي بنعمله في فرق البرمجيات: مش بنحاول نخلي مهندس واحد يعمل كل حاجة أسرع، لكن بنقسّم المشكلة لمسارات شغل مستقلة. وده بقى الاتجاه السائد نوعًا ما من كل الـ Agentic Workflows اللي موجودة وازاي يخلوا الـ SDLC موجود من خلال الـ Agents.

لكن الاستقلالية الأعلى محتاجة رقابة أعلى

القوة دي ليها جانب تاني مهم.

في الـ System Card هنلاقي إن OpenAI قالت إن GPT-5.6 أحيانًا بيكون أكثر إصرارًا على إكمال المهمة لدرجة إنه ممكن يتجاوز نية المستخدم أو ينفذ تصرفات لم تُطلب منه بوضوح، رغم إن المعدلات المطلقة ما زالت منخفضة.

ولكن ده معناه إن كل ما الـ Agents تبقى أقدر على التنفيذ، تصميم الصلاحيات والـ approvals والـ audit logs والـ rollback mechanisms هيبقى أهم من كتابة الـ Prompt ذات نفسه.

الخلاصة:
GPT-5.6 مش مجرد موديل قوي؛ بل هو خطوة إضافية مهمة في تصميم أنظمة الـ AI اللي بقت بتستلم هدف كبير، تقسّمه لمهام أصغر، وتستخدم الأدوات المتاحة، وتراجع نفسها، وتسلّم نتيجة شبه جاهزة للمستخدم.

وكالعادة علشان كده المرحلة الجاية مش هتكون منافسة بين الـ Models وبس… وده اللي شايفينه من بعد Claude Opus للـ Fable وكذلك من باقي الشركات .. ولكن المنافسة الحقيقية بقت بين الـ Agent Harnesses والأنظمة اللي بتعرف توظّف الموديلات دي بأمان وكفاءة أفضل.

Prompt Caching Explained 🚀

الـ Prompt Caching معناه إنك بتخلي مزود الـAPI يحتفظ مؤقتًا بجزء ثابت ومتكرر من الـprompt، بدل ما تبعته ويتحسب عليك بالكامل مع كل request. مثلًا لو عندك system prompt طويل فيه قواعد المشروع، أو documentation، أو أجزاء ثابتة من الـcodebase، وتستخدمهم مع كل سؤال جديد؛ أول مرة بتبعتهم عادي، وبعد كده الطلبات التالية بتشير لنفس المحتوى المخزّن. النتيجة إن تكلفة الـinput tokens المتكررة بتقل، وأحيانًا ال latency كمان يتحسن.

مثال بسيط: لو عندك prompt ثابت حجمه 100 ألف token، وكل مرة بتضيف له سؤال جديد حجمه 500 token. من غير caching، هتدفع تكلفة الـ100,500 token في كل طلب. مع caching، بتدفع تكلفة إنشاء الـcache في البداية، وبعدها تدفع سعر أقل بكثير على الـ100 ألف token المخزنين، بالإضافة لتكلفة السؤال الجديد.

فرتّب دايمًا الـ prompts بحيث المحتوى الثابت ييجي الأول، والمحتوى المتغيّر ييجي في الآخر. لو أكتر من 50% من الـ input tokens بتتكرر بين الطلبات، يبقى الأفضل تفعّل الـ caching.

و كمان حاليًا كل الشركات الكبيرة بقت بتدعمه بشكل تلقائي لأنه ممكن يوفر لحد 50% من التكلفة و يسرع وقت الاستجابة بنسبة 80%.

• OpenAI تدعمه بشكل تلقائي

• Anthropic بشكل صريح

• Google Gemini بشكل ضمني أو صريح

• DeepSeek بشكل تلقائي.

ليه الـ Prompt Caching مهم؟

في حاجتين بيأثروا على مشاريع الـ LLM في بيئة الإنتاج: التكلفة ووقت الاستجابة. والـ Prompt Caching بيعالج الاتنين.

معظم الفرق بتكتشف ده بالطريقة الصعبة. الـ proof of concept بيشتغل بشكل ممتاز، وبعد كده الترافيك بيزيد، والفاتورة بتوصل وبنُصدم بالأرقام!

والأصعب إن أغلب تطبيقات الـ LLM في ال Production بتعيد معالجة نفس الـ context آلاف المرات يوميًا: نفس الـ system prompt، ونفس تعريفات الأدوات، ونفس المستندات المرجعية. وكل طلب بيدفع التكلفة الكاملة على tokens النموذج شافها قبل كده.

كيف يعمل الـ Prompt Caching؟

خلينا متفقين إن الـ Prompt Caching مش بيخزن إجابات النموذج ولا بيعمل Semantic Caching هو بيخزن (حسابات ال Key-Value Pairs) للأجزاء الثابتة من ال Prompt بتاعك وبيعيد النموذج استخدامها وقت ما يجد تشابه بين جزء من الطلب الجديد والقيم المتخزنة عنده بالفعل فيقسم ال Prompt لجزءين:

• جزء ثابت (Static): بيحصل علي قيمته من ال Cache بدون استخدام.

• جزء متغير (Dynamic): بيقوم بحسابه واستخدام tokens جديدة في هذه العملية.

اكمل القراءة

ملتقى إتقان لتقنيات القرآن ✨

يوم الجمعة 10 يوليو كان بداية لأكبر تجمع للتقنيات القرآنية في القاهرة في موسمه الثاني واللي كان بيضم فعاليات مثمرة واللي نتمنى تكرار مثل هذه الفعاليات الجميلة في الوطن العربي والمشاركة فيها .. الملتقى كان بيضم:

• عروض لـ 10 مشاريع قرآنية مشاركة

• جلسات تعارف ونقاش مفتوح بين الحضور

• استعراض أبرز إنجازات المجتمع في التقنيات القرآنية

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في أول عدد مميز من سلسلة Engineering Radar من النشرة الأسبوعية لاقرأ-تِك 🚀

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

أخبار الـ AI كترت علينا أخر 10 أيام فقولنا نميز العدد ده بأهم الأخبار ونشوف ازاي نستفيد منها كمبرمجين, فيلا بينا!

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• OpenAI Previews GPT-5.6 Sol 🌞

• Claude Fable 5 has Returned 🚀

• GLM-5.2 :The Open Source Finally in the Frontier 🔥

OpenAI Previews GPT-5.6 Sol

أعلنت OpenAI عن إطلاق نسخة تجريبية محدودة من نموذجها الجديد GPT-5.6 Sol، تحت إشراف الحكومة الأمريكية.

الشركة كمان نزلت نموذجين أقل سعرًا:

• Terra: بسعر يقارب نصف سعر GPT-5.5 مع أداء متقارب.

• Luna: كخيار اقتصادي منخفض التكلفة.

  وبحسب المتطلبات الحكومية، الإطلاق هيبدأ مع 20 شريك موثوق فقط الحكومة هي اللي قامت باختيارهم، لحد ما يتم حسم شروط الإتاحة العامة، واللي متوقع تحصل من نصف لأخر يوليو.

من ناحية الأداء، GPT-5.6 Sol حقق 88.8% على اختبار TerminalBench 2.1 الخاص بال Coding Agents ، متفوقًا بشكل طفيف على Claude Mythos 5 اللي سجل 88%. أما وضع “Ultra” متعدد الوكلاء فوصل إلى 91.9%

ومن المتوقع إن التكامل مع Cerebras خلال يوليو يرفع السرعة إلى 750 توكن في الثانية. ورغم إن سعره مماثل لـ GPT-5.5، تحسين كفاءة استهلاك التوكنز ممكن يقلل تكلفة تنفيذ المهام الفعلية بشكل ملحوظ.

قدرات سيبرانية أقوى مع ضوابط حماية أشد

الأهم إن النماذج الثلاثة الجديدة OpenAI صنفتها High Cybersecurity Risk. وده معناه إن أقوى النماذج المتاحة حاليًا، مثل Anthropic Fable 5 وMythos 5، بالإضافة إلى Sol وTerra وLuna من OpenAI، مش هتكون متاحة لعامة المستخدمين قبل مراجعات الأمن السيبراني الحكومية الأمريكية.فالسؤال دلوقتي مبقاش: مين عنده أفضل نموذج؟ لكنه بقى: أي نموذج مسموح لنا فعلًا نستخدمه؟

تم تطوير GPT-5.6 Sol وTerra وLuna مع أقوى إجراءات حماية طبقتها الشركة حتى الآن، بحيث تتناسب ال safeguards مع مستوى قدرات كل نموذج. الهدف هو أن تظل الحماية فعّالة أمام محاولات إساءة الاستخدام الواقعية، من غير ما تعطل الاستخدامات المشروعة مثل مراجعة الكود، البحث عن الثغرات، تطوير التحديثات الأمنية، الـdebugging، التعليم الأمني، والاختبارات الدفاعية.

النموذج GPT-5.6 Sol أفضل في مساعدة فرق الأمن على اكتشاف الثغرات وإصلاحها، لكنه لا يستطيع بشكل موثوق تنفيذ هجوم سيبراني كامل من البداية للنهاية. في اختبارات على Chromium وFirefox، قدر يحدد bugs وعناصر أساسية قد تدخل في بناء exploit، لكنه لم ينجح بشكل مستقل في إنتاج exploit كامل وفعّال ضمن ظروف الاختبار.

النموذج لا يتجاوز مستوى “Cyber Critical” حسب إطار التقييم الخاص بالشركة، لكن بسبب تطور قدراته بشكل ملحوظ واحتمال دمجه مع أدوات أخرى. الفكرة هي زيادة فائدته للمطورين وفرق الـdefensive security، مع جعل الاستخدام الهجومي المحظور أصعب وأقل قابلية للتنفيذ وأسهل في الاكتشاف.

اللي يهمنا كمبرمجين

هل أرقام ال Benchmarks فعلاً مفيدة؟

قراءة أخبار ال Models الجديدة من الشركات وأرقام ال Benchmark المبهرة دايمًا محتاجين ناخدها بإن عليها رشة ملح من المبالغة عشان التسويق.

بالفعل أرقام الـbenchmarking بتديك إشارة مفيدة، لكن نادرًا ما تكون حكمًا نهائيًا على جودة الموديل في شغلك. اعتبرها مؤشر اتجاه وليس ضمان أداء.

السبب إن كل Benchmark بيقيس شريحة ضيقة من القدرات تحت ظروف ثابتة: prompt محدد، بيانات تقييم معينة، أدوات محددة، وعدد محاولات أو budget معين. بينما شغلك الحقيقي فيه codebase خاص، conventions داخل الفريق، dependencies، أخطاء غير متوقعة، صلاحيات، واحتياج لفهم سياق طويل. موديل متفوق بـ3% في benchmark ممكن ما يفرقش معاك إطلاقًا، وموديل أقل في الرقم لكنه أسرع وأرخص وأكثر ثباتًا قد يكون أفضل في الإنتاج.

بنركّز كمان على نوع الـbenchmark نفسه. Benchmark مثل TerminalBench بيقيس قدرة الـagent على تنفيذ مهام في terminal، وبالتالي أقرب لسيناريوهات مثل تصليح bug، تشغيل tests، التعامل مع Git، أو تعديل ملفات متعددة. لكنه لا يثبت بالضرورة أن الموديل هيكتب architecture مناسب لمشروعك أو هيفهم business logic صح.

بالمقابل، benchmarks من نوع SWE-bench مفيدة أكثر في إصلاح issues داخل repositories حقيقية، لكنها برضه ممكن تتأثر بطريقة إعداد الـagent والأدوات المتاحة له.

الخطط البديلة ضرورية

زي ما وضحنا في أكثر من نشرة قبل كدا خطورة ال Vendor lock-in وبما إن الإتاحة العامة (طول الوقت) للنماذج دي غير مضمونة، ابنِ الـworkflow بحيث لا يرتبط بموديل واحد أو مورد واحد. استخدم abstraction layer للـLLM provider، وثبّت prompts و evaluation suite خاصة بمشروعك، واحتفظ بخيارات بديلة من OpenAI وAnthropic أو نماذج مفتوحة المصدر حسب متطلبات الخصوصية. ولو بتبني منتج معتمد على الذكاء الاصطناعي، متوعدش العملاء بميزة مبنية على موديل غير متاح للعامة. صمّم المنتج بحيث يعمل بمستوى جودة مقبول على الموديلات المتاحة حاليًا، ثم حسّنه تدريجيًا عند توفر موديلات أقوى.

Claude Fable 5 has Returned 🚀

تحت شعار “عاد إليكم من جديد!”

بعد 19 يوم من المنع، نموذج Claude Fable 5 رجع متاح عالميًا من خلال Claude.ai وClaude Code وClaude Cowork.

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

خلال الفترة دي Anthropic درّبت Safety Classifier جديد يقدر يمنع الطريقة دي بشكل موثوق، وبعدها الحكومة رفعت القيود يوم 30 يونيو.

Anthropic رجّعت النموذج مع Classifiers جديدة هدفها منع إساءة الاستخدام في الأمن السيبراني. لكن خلال مرحلة الضبط وتقليل الـfalse positives، ممكن بعض من مهام البرمجة والـdebugging تتحول مؤقتًا إلى Opus 4.8 بدل Fable 5.

وفي نفس الوقت، نموذج Mythos 5 بيرجع بشكل محدود لمجموعة من المؤسسات الأمريكية ضمن برنامج Glasswing. بالنسبة للمطورين، رجوع Fable 5 إلى Claude Code يعتبر أهم حدث لمستخدمين Claude الفترة دي لأنه قبل المنع كان بالفعل سايب انطباع كويس عن كفاءته!

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

هل هيكون دا التسلسل الطبيعي بعد كدا لكل ال Frontier AI Labs بأنها لازم تعدي علي فقرة مفاوضات مع الحكومة عشان تتأكد من عدم إساءة استخدام النماذج في الهجمات الأمنية؟ دا وارد جدًا لأننا شايفين دلوقتي OpenAI داخلة ب GPT-5.6 Sol في نفس العملية مع اعتراضها الشديد عليها.

الجدير بالذكر إن شركة Anthropic، بالتعاون مع Amazon وMicrosoft وGoogle، بتشتغل على معيار موحّد على مستوى الصناعة لتقييم مدى خطورة محاولات كسر حماية نماذج الذكاء الاصطناعي (AI jailbreaks).

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

اللي يهمنا كمبرمجين

• النموذج أصبح متاح ومستخدمين Claude Code في مجتمعنا العربي كتير فابعتولنا تقييماتكم علي استخدامه وهنضيفها للنشرة باذن الله!

• النموذج بيوفر Context Window بتوصل إلى مليون توكن، ودي ميزة عملية كبيرة في الشغل داخل Codebases كبيرة أو Agentic Tasks طويلة؟

• من الناحية المالية، سعره بالفعل عالي، يأتي Fable 5 بـ 10$/Input و50$/Output ودا ضعف سعر Opus 4.8 وضعف سعر GPT-5.5 تقريبًا على المدخلات بس استخدام ال Prompt Caching و ال Batch API بيقلل التكلفة للنص, على كل حال لازم ناخذ بالنا من الفواتير!

  ---

GLM-5.2 :The Open Source Finally in the Frontier 🔥

شركة Z.ai أطلقت نموذج GLM-5.2، وهو نموذج مفتوح الأوزان بحجم 744B Parameter وبيعتمد على بنية Mixture-of-Experts. النموذج بيدعم ContextWindow لحد مليون token، ومرخّص برخصة MIT.

حاليًا بيُقال إنه أقوى نموذج مفتوح الأوزان في اختبارات الأداء، وبيتفوق على GPT-5.5 في عدد من اختبارات هندسة البرمجيات، مع أسعار API أقل بكتير من النماذج المغلقة أو المملوكة.

لكن لازم نقرأ الأرقام دي بحذر: الـbenchmarks بتوضح اتجاه الأداء، لكنها مش ضمان إن النموذج هيكون الأفضل على مشروعك. التجربة الحقيقية بتعتمد على الـstack، حجم الـrepository، جودة الـtests، طريقة بناء الـagent، والـtools اللي بتسمح له يستخدمها.

التركيز الأساسي في GLM-5.2 هو إنه ينجز مهام هندسة برمجيات فعلية، مش مجرد يولّد snippets أو يشرح كود. المفروض يقدر يفهم المشكلة، يخطط للحل، يعدّل ملفات متعددة، يشغّل أدوات واختبارات، ويراجع النتيجة.

أهم تفاصيل النموذج

• حقق أعلى نتيجة بين النماذج مفتوحة الأوزان على مؤشر Artificial Analysis Intelligence Index.

• بيستخدم رخصة MIT، وده معناه إنك تقدر تستخدمه تجاريًا من غير قيود كبيرة، تستضيفه محليًا، وتعمل له fine-tuning من غير قيود استخدام أو حدود جغرافية. ده بيخليه اختيار مناسب لو عندك متطلبات خصوصية، أو بيانات حساسة، أو عايز تقلل اعتمادك على APIs مغلقة.

• تشغيله محليًا يحتاج على الأقل 256GB RAM للنسخ المضغوطة أو الـquantized، بالإضافة إلى 24GB VRAM لو هتستخدم MoE offloading. فعمليًا النموذج مناسب أكثر لسيرفرات قوية، cloud instances، أو فرق عندها بنية تحتية مخصصة، مش لجهاز مطور عادي.

• حاليًا النموذج لا يدعم الرؤية، يعني لا يقدر يفهم أو يحلل الصور اللي بتبعتهاله بالتالي، لو شغلك بيعتمد على تحليل واجهات من صور، debugging من screenshots، أو multimodal workflows، هتحتاج موديل تاني أو pipeline إضافي.

الفجوة بين النماذج مفتوحة الأوزان والنماذج المملوكة كانت تاريخيًا بتتقاس بالشهور، لكن GLM-5.2 بيشير إن الفجوة في مهام البرمجة ممكن تكون قربت جدًا من الصفر.

النقطة اللي لسه محتاجة تقييم هي كفاءة الـreasoning: النموذج بيستهلك في المتوسط حوالي 43 ألف output token لكل مهمة، وده يقارب 3 أضعاف استهلاك GPT-5.5. عمليًا، ده ممكن يخلي تنفيذ المهام أبطأ وأكثر تكلفة من ناحية وقت المعالجة داخل production pipelines، حتى لو سعر الـAPI نفسه

الكفاءة والتكلفة

رغم إن النموذج مفتوح الأوزان وأسعار الـAPI بتاعته أقل من نماذج مغلقة كتير، فيه نقطة مهمة تخص كفاءة الـreasoning. النموذج بيستخدم في المتوسط حوالي 43 ألف output token لكل مهمة، وده قريب من 3 أضعاف استهلاك GPT-5.5 حسب المقال. عمليًا، ده ممكن يزود وقت تنفيذ المهمة ويأثر على throughput في الـproduction pipelines، حتى لو تكلفة الـtoken نفسها أقل.

بمعنى آخر: سعر الـAPI الأقل مش بالضرورة معناه إن تكلفة المهمة النهائية أقل. لو النموذج بيحتاج tokens أكتر ووقت أطول علشان يوصل لنفس النتيجة، لازم تقارن على أساس تكلفة المهمة الناجحة، مش سعر المليون token فقط.

الخلاصة للمبرمجين

GLM-5.2 بيقرب جدًا من مستوى النماذج المغلقة في مهام البرمجة، مع ميزة كبيرة وهي حرية التشغيل والتعديل تحت رخصة MIT. ده يخليه خيار قوي للفرق اللي عايزة self-hosting، خصوصية أعلى، وتحكم كامل في الـdeployment.

لكن قبل ما تعتمد عليه في الإنتاج، اختبره على مهام من مشروعك: bugs، refactoring، كتابة tests، code review، وتشغيل الـagents داخل الـCI. قارن بينه وبين البدائل في نسبة نجاح الـtests، وقت التنفيذ، عدد الـtokens، وعدد التدخلات البشرية المطلوبة. النموذج الأفضل مش بالضرورة الأعلى في الـbenchmark، لكنه اللي ينجز شغلك بدقة وبأقل تكلفة تشغيل فعلية.

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 103 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• ال AI في سطور: OpenCode - A Look on the AI Code Agent with 8M Monthly users 🔥

• شروحات رسومية بالورقة والقلم: SLOs Explained 🚀

• أدوات وتقنيات عربية: ApexYard - SDLC-as-code 🧰

هذا الأسبوع في أخبار جديدة احنا مش هنتكلم عنها زي إطلاق Anthropic لـ ClaudeTag وهو ببساطة إضافة claude كزميل عمل Always-on في slack لأنها بالفعل ميزة جديدة هنستني نشوف في الاستخدام عاملة ايه!

هنتكلم المرة دي عن Opencode فيلا بينا!

OpenCode – وكيل البرمجة مفتوح المصدر 🔥

ما هو Opencode ؟

OpenCode هو عبارة عن (AI Coding Agent) مفتوح المصدر، مصمم إنه يساعدك تكتب وتطوّر الكود بيقوم بنفس مهمة Claude Code الفرق إنه مفتوح المصدر وبيتيح لك استخدام 75+ LLM Model من جهات مختلفة بينما كلود بيستخدم فقط Anthropic Models.

بنتكلم عن Opencode ليه هذه النشرة؟

• المشروع بيستخدمه ٨ مليون مبرمج شهريًا وعليه أكثر من 160 ألف نجمة على GitHub وأكثر من حوالي 900 مساهم فدعونا نلقى نظره عن سر تبنيهم واستخدامهم ليه من وسط معركة ال Coding Agents اللي حوالينا!

• المشروع بيقدم أداء كويس فعلاً و مع دا هو مفتوح المصدر، فبيحمي من مشكلة الـ Vendor lock-in

OpenCode بيقدم إيه؟

• تقدر تستخدم نماذج مجانية جاهزة، أو توصل أي موديل AI من أي مزود خدمة, زي Anthropic و OpenAI و Google وغيرهم كتير. وتقدر تعتمد على أكثر من موديل خلال المشروع الواحد فكمثال ممكن تستخدم GPT للكود و Gemini للبحث و Claude للـ Refactoring.

• متاح كتطبيق:

  • Terminal

  • Desktop App لا يزال BETA

  • Extension للـ IDEs المختلفة.

دعم ذكي للـ LSP

ال Language Server Protocol ببساطة بروتوكول بيخلي محرر الكود (VS Code مثلًا) يتواصل مع “سيرفر” فاهم لغة البرمجة علشان يوفر مميزات ذكية أثناء الكتابة زي ال Auto-completion و Go to Definition و ال Error Detection و غيرها

الـ AI لو اعتمد على قراءة الملفات فقط هيكون فهمه محدود, لكن لما OpenCode يوصل للـ LSP بتاع المشروع يقدر يسأل أسئلة زي: مين بيستخدم الكلاس ده؟ إيه نوع المتغير ده؟

ف Opencode بيستخدم ال LSP المناسب مع لغة البرمجة المستخدمة في المشروع و يحمّل تلقائيًا أدوات تحليل الكود المناسبة للمشروع، بحيث ال LLM Model يبقى فاهم هيكل الكود بشكل أدق و يشتغل كأنه مطور فاتح المشروع في VS Code فعلًا، مش مجرد موديل بيقرأ نصوص.

تشغيل أكتر من Agent في نفس الوقت

ممكن تشغّل أكتر من جلسة أو Agent بالتوازي على نفس المشروع علشان تنجز مهام متعددة بشكل أسرع.

فكمثال ممكن تعمل Frontend Agent و Backend Agent و Security Agent و Testing Agent وكلهم يشتغلوا علي المشروع في نفس الوقت!

مشاركة الجلسات

تقدر تشارك لينك لأي Session مع زميل أو فريق العمل للمراجعة أو ال Debugging.

حرية اختيار الموديل

طبعًا حرية اختيار الموديل بتخليك تختبر LLMs مختلفة لمهام مختلفة في الكود و دا بيفرق بالطبع في التكلفة والأداء وبتحمينا من الـ Vendor lock-in وهنا عندنا أكثر من ميزة لأنه:

• بيدعم أكتر من 75 مزود نماذج ذكاء اصطناعي، وكمان بيدعم النماذج المحلية (Local Models)

• بيدعم GitHub Copilot فممكن تسجل دخول بحساب GitHub وتستخدم اشتراك Copilot الحالي بتاعك.

• دعم ChatGPT Plus و Pro فممكن تربط حساب OpenAI وتستفيد من اشتراك ChatGPT Plus أو Pro مباشرة من داخل OpenCode.

ما الفرق بينه وبين Claude Code

الفرق في الأداء بين الاثنين بيأتي من مكانين:

• النموذج المُستخدم

  ودا السبب اللي لاحظ معظم المطورين إنه بيعمل فرق في تجربتهم في الاتنين و بالأخص مع OC استخدامه مع نماذج قوية بيدي بالفعل نتائج قوية.

• ال Harness

  الأداتين ال Harness بتاعهم مختلف وكل لما كان ال Harness أحسن دا بيساعد بشكل كبير في تحسين النتائج و تقليل التكاليف.

شوفنا Feedback من مطورين كثير بيستخدموا الاثنين والتعليقات كلها بتشير إلى إن الأداء متقارب ولكن CC يتفوق ف المهام الأكثر تعقيدًا ولكن OpenCode أكثر مرونة بكثير وبيسمحلك ب customisation عالي. الاختيار بينهم بيعتمد بشكل كبير علي احتياجتك والمقارنة هنا ممكن تساعد لكن شوفنا كذلك كثير من المطورين بيستخدموا الاثنين فلم لا؟! قولونا رأيكم في التعليقات لو استخدمتم الاثنين أو عندكم خبرة مع Opencode ورأيكم عنه.

SLOs Explained 🚀

في أي نظام حقيقي، السؤال مش بيكون: “هل السيستم شغال؟”
لأن غالبًا الإجابة آه… بس السؤال الأهم هو: شغال قد إيه بشكل يعتمد عليه؟

هنا بتيجي فكرة الـ SLO — Service Level Objective.

ما هي الـ SLOs؟ وليه تهمك كمهندس؟

ببساطة، الـ SLO هو هدف واضح للموثوقية.
يعني بدل ما نقول: “عايزين السيستم يبقى stable”، بنقول حاجة قابلة للقياس:

99.9% من طلبات الدفع لازم تنجح خلال آخر 30 يوم.

أو:

95% من صفحات البحث لازم تفتح في أقل من 500ms.

الفكرة هنا إننا بنحوّل الإحساس العام إلى رقم واضح الفريق كله فاهمه.

الـ SLO غالبًا بيتكوّن من 3 حاجات أساسية:

SLI: الحاجة اللي بنقيسها فعلًا، زي نسبة النجاح، latency، أو availability.
Target: الهدف المطلوب، زي 99.9%.
Time Window: الفترة اللي بنقيس عليها، زي أسبوع، شهر، أو آخر 30 يوم.

وفيه مفهوم مهم جدًا اسمه Error Budget.

لو هدفك إن 99.9% من الطلبات تنجح، فده معناه ضمنيًا إنك سامح بـ 0.1% فشل. النسبة الصغيرة دي هي الـ Error Budget: المساحة اللي تقدر “تغلط” فيها من غير ما المستخدمين يتأثروا بشكل كبير.

وده بيخلي القرارات أوضح جدًا.

لو عندك Error Budget كفاية، ممكن تتحرك بسرعة، تعمل releases، وتجرب features جديدة. لكن لو قربت تخلصه، يبقى لازم تهدي شوية وتركّز على إصلاح الاستقرار بدل إضافة حاجات جديدة.

مثال عملي:

تخيل عندك خدمة تسجيل دخول، والـ SLO بتاعها:

99.95% من login requests لازم تنجح خلال 30 يوم.

لو حصلت مشاكل متكررة، بدل ما الفريق يدخل في نقاشات عامة زي: “السيستم بقى وحش؟” أو “المشكلة كبيرة؟”

يبقى عندك رقم واضح يقولك: هل لسه جوه الـ margin والهدف بتاعنا ؟ ولا بدأنا نكسر الوعد اللي بيننا وبين المستخدمين؟

علشان كده الـ SLOs مش مجرد monitoring زيادة ولكن هي طريقة تخلي الفريق يوازن بين حاجتين مهمين جدًا: السرعة و الموثوقية.

وده لأن النظام مش لازم يكون مثالي طول الوقت، بس لازم يكون موثوق للمستخدمين اللي بيعتمدوا عليه.

ApexYard: لما الـ AI يكتب كود — مين بيراجع وراه؟

مع انتشار أدوات زي Claude Code وCursor، بقى سهل جدًا إنك تطلب من الـ AI يبني feature كاملة.
بس المشكلة الحقيقية مش في كتابة الكود… المشكلة في كل الحاجات اللي بتحصل حوالين الكود.

• مين كتب الـ spec؟

• مين راجع القرار التقني؟

• هل فيه tests؟

• هل تغيير قاعدة البيانات له rollback plan؟

• هل الكود جاهز للإطلاق فعلًا؟

هنا بيظهر مشروع ApexYard.

الفكرة ببساطة إنه بيحاول يحوّل عملية تطوير البرمجيات إلى SDLC-as-code: يعني مش مجرد prompts عشوائية للـ AI، لكن workflows واضحة، roles، skills، وguardrails تساعدك تطلع softwares كأن وراك فريق هندسي حقيقي.

المشروع معمول خصوصًا للـ solo founders، أو الفرق الصغيرة، أو أي حد بيستخدم AI agents في بناء منتجات حقيقية، وعايز يقلل مساحة إن “الـ AI كتب حاجة شكلها شغالة بس ناقصها أساسيات هندسية”.

ApexYard بيضيف طبقات زي:

• مراجعة تلقائية للتغييرات

• launch-readiness checks

• workflows للأفكار، الـ specs، القرارات، والـ handover

• guardrails تمنع تغييرات خطيرة من غير plan، خصوصًا في حاجات زي database migrations

• أدوار مختلفة للمراجعة بدل ما يبقى كل شيء “AI واحد بيرد على كل حاجة”

الجزء المهم هنا مش الأداة نفسها بس، لكن الاتجاه اللي بتمثله.

إحنا داخلين مرحلة إن قيمة المهندس مش هتبقى في إنه “يكتب كل سطر كود بإيده”، لكن في إنه يبني نظام حوالين الـ AI:
process واضح، مراجعة حقيقية، حدود أمان، وقرارات موثقة وزي ماتكلمنا قبل كده عن أهمية الـ Harness Engineering.

بمعنى آخر: الـ AI ممكن يسرّع التنفيذ، لكن الهندسة هي اللي بتحدد هل اللي اتبنى ينفع يعيش في production environment ولا لأ.

Try it now

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 102 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

• ال AI في سطور: WebMCP - W3C Standard for Agents to use Websites 👨‍💻

• شروحات رسومية بالورقة والقلم: Latency vs. Throughput ✍️

• أدوات وتقنيات عربية: DevLite - Developer Utility Hub 🧰

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉
أخر ٣ سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

بالفعل ظهرت مبادرات جميلة خلال السنين ولكن مش بتكمل, مجرة المرة دي بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

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

شاركوا في بناء الاستبيان

مرة تانية الهدف هو رسم صورة حقيقية عن مجتمعنا العربي في مجال التقنية ، والبيانات دي هتبقى مرجع مفيد لينا كلنا باذن الله .. فيلا نبنيها سوا ونكون جزء من ده 😍

WebMCP - W3C Standard for Agents to use Websites

الأسبوع دا لا يوجد أي Models جديدة أو أخبار نازلة علينا بعد سحب Fable 5 و Mythos 5 العالم بيحاول يتعلم الدرس وأنه دايمًا يكون ليه Fallbacks وميعتمدش بشكل مغلق علي AI Vendor واحد. وأظن بشكل فردي كمطورين محتاجين يكون عندنا Fallbacks في حالة الأدوات اللي بنعتمد عليها بشكل يومي حاليًا لم تصبح متاحة غدًا 😅

فحبينا نستغل الفرصة ونتكلم عن ال WebMCP وهو Standard جديد بيخلي المواقع تتعامل مع وكلاء الذكاء الاصطناعي (AI Agents) بشكل مباشر ومنظم، بدل ما الـ AI يحاول يفهم الموقع عن طريق قراءة الـ HTML أو تصوير الشاشة ومحاكاة ضغطات الماوس. الفكرة إن الموقع نفسه بيقول للـ AI: "دي الخدمات اللي أقدر أقدمها، ودي البيانات اللي محتاجها علشان أنفذها."

المشكلة اللي بيحلها

النهارده معظم الـ AI Agents بيتعاملوا مع المواقع بطريقة غير فعالة:

• بيحللوا واجهة المستخدم.

• بيحاولوا يخمنوا وظيفة الأزرار والفورمات.

• أي تغيير بسيط في تصميم الموقع ممكن يبوظ العملية كلها.

• العملية كلها non-deterministic ممكن نفس الAgent ونفس المهمة ويطلعلك نتائج مختلفة.

WebMCP بيحول تفاعل ال Agents مع المواقع من “تخمين” إلى “استدعاء أدوات (Tools) منظمة” بشكل مباشر

بيشتغل إزاي؟

الموقع بيسجل مجموعة من الأدوات أو الوظائف (Tools) داخل المتصفح باستخدام واجهة جديدة اسمها navigator.modelContext.

أمثلة: البحث عن منتج أو إضافة عنصر للسلة أو إرسال نموذج طلب.

بدل ما الـ AI يدور على زر “Search”، يقدر يستدعي أداة اسمها searchProducts مباشرة بالبيانات المطلوبة.

الفرق بين MCP و WebMCP

• MCP التقليدي: شغال على مستوى السيرفرات والـ APIs الخلفية.

• WebMCP: شغال جوه المتصفح نفسه وعلى الموقع مباشرة.

يعني MCP بيربط الـ AI بالأنظمة والخدمات الخلفية، بينما WebMCP بيربطه بواجهة الموقع اللي المستخدم فاتحها بالفعل. الاتنين مكملين لبعض ومش بدائل لبعض.

ليه الموضوع مهم؟

لو WebMCP انتشر:

• الـ AI Agents هتبقى أسرع وأدق.

• استهلاك التوكنز والتكلفة هيقلوا بشكل كبير.

• المواقع هتبقى “AI-ready” من غير الحاجة لبناء API منفصل في كل حالة.

• الخدمات الإلكترونية زي الحجز والشراء والدعم الفني هتبقى أسهل للـ AI إنه ينفذها نيابة عن المستخدم

  الوضع الحالي للمشروع

  الWebMCP بدأ يظهر في إصدارات تجريبية من متصفح Chrome بدعم من فرق من Google وMicrosoft تحت مظلة W3C. لسه مش معيار نهائي، لكن فيه اهتمام كبير بيه باعتباره خطوة مهمة نحو “الويب المخصص للـ AI Agents.

Latency vs. Throughput

في أنظمة البرمجيات ال Latency و Throughput هما من أهم مقاييس الأداء وغالبًا بنشوفهم جنبًا لجنب في نفس ال Dashboards، لكن كل واحد بيقيس حاجة مختلفة.

1. Latency (زمن الاستجابة)

التعريف: هو الوقت الذي يستغرقه النظام لإنجاز طلب واحد من لحظة إرساله حتى استلام النتيجة.

بمعنى تاني: “هستني قد إيه عشان يجيلي الرد؟”

مثال: إذا أرسلت طلب API الساعة 10:00:00 ووصل الرد الساعة 10:00:00.200 » فالـ Latency = 200 ms

أمثلة على Latency

• وقت تحميل صفحة ويب.

• زمن استجابة قاعدة البيانات لاستعلام معين.

• الوقت بين الضغط على زر وإظهار النتيجة للمستخدم.

كلما كان أقل كان أفضل

2. Throughput (معدل الإنتاجية)

التعريف: هو عدد العمليات أو الطلبات التي يستطيع النظام معالجتها خلال فترة زمنية معينة.

و دايمًا بنسأل: “كم كمية الشغل اللي يقدر النظام ينجزها في وقت معين؟”

مثال: إذا كان السيرفر يعالج: 10,000 Request في الثانية فالـ Throughput = 10,000 Requests/sec

أمثلة على Throughput

• عدد الطلبات في الثانية (RPS).

• عدد الرسائل التي يعالجها Queue في الدقيقة.

• عدد المعاملات البنكية في الثانية.

• عدد الملفات التي تتم معالجتها في الساعة.

كلما كان أعلى كان أفضل

العلاقة بينهما

وفقًا لـ Little’s Law في أنظمة الطوابير:

Latency = Concurrency / Throughput

Continue Reading

DevLite - Developer Utility Hub

كلنا بنحتاج tools تخلصلنا خطوات صغيرة في الشغل JSON Formatter هنا أو Cron Expression Generator أو حتي ID Generator ولكن دايمًا بنكون قلقانين لو بنتعامل مع بيانات مهمة وهنا بتيجي منصة DevLite!

المنصة بتقدم أكثر من 28 أداة مختلفة لكل المهام دي في مكان واحد مغطية أقسام كثيرة والمميز فعلاً:

• إن كل الأدوات دي بتشتغل عندك في المتصفح فمفيش أي remote servers ودا بيضمنلك الخصوصية.

• الأدوات بتشتغل بدون إنترنت.

• والأدوات كلها سريعة الأداء و خفيفة.

• واجهة استخدام سهلة ومنظمة لأن الأدوات بتندرج تحت أقسام أساسية

الأدوات منها

• أدوات للتنسيق JSON & SQL Formatters.

• أدوات لل Generation سواء ID Generators أو بيانات وهمية للاختبارات.

• أدوات لقواعد البيانات و ال Devops

• أدوات Encoders & Decoders مختلفة

وأدوات غيرها كتير متنوعة زي Regex Tester و HTTP / API Request Tester.

الخلاصة: الأداة تستحق إن يتعملها Pin في المتصفح عندك لأي مهمة بسيطة هتزود إنتجايتك وأنت متطمن علي بياناتك!

جرب الأداة الآن

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلًا بكم في العدد 101 من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

• Anthropic Launches Claude Fable 5 🔥

• Harness Explained in Agentic AI 🤖

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉
أكتر من مرة بتظهر مبادرات جميلة علشان ترسم صورة حقيقية لمجتمع المطورين في العالم ولكنها مش بتكمل ، وحيث إن مجرّة هدفها بناء مجتمع خاص بالمطورين لتبادل المهارات والخبرات وكمان متابعة مستجدات التقنية .. فقرروا يستعينوا بالله ويبدأوا .. ولعلها تكون مبادرة سنوية جميلة!

الاستبيان هيغطي جوانب كتير على سبيل المثال زي:
🔸 الرواتب الحقيقية علشان يبقى فيه صورة سنوية بتوضح ده
🔸 التقنيات اللي بنستخدمها فعلًا في الشغل وبجانب الشغل
🔸 إزاي بنستخدم الـ AI في شغلنا اليومي
🔸 العمل عن بُعد لشركات خارج الوطن العربي
🔸 ومنين بنتعلّم فعلًا وبنتابع المستجدات

بس قبل ما يفتحوا الاستبيان .. عايزين يسمعوا منكم انتوا الأول 👇
الأسئلة بتاعتكم هي اللي هتشكّل النسخة الأولى — اقترحوا، وهم فعلًا هيراجعوها ويضيفوها باذن الله.

شاركوا في بناء الاستبيان

مرة تانية الهدف هو رسم صورة حقيقية عن مجتمعنا العربي في مجال التقنية ، والبيانات دي هتبقى مرجع مفيد لينا كلنا باذن الله .. فيلا نبنيها سوا ونكون جزء من ده 😍

Anthropic Launches Claude Fable 5 🔥

الأسبوع ده Anthropic أعلنت عن Claude Fable 5، وده مش مجرد موديل جديد في سباق “مين أعلى Benchmark”. الفكرة هنا أعمق شوية: Anthropic بتقول إن Fable 5 هو أقوى موديل عام عندهم لحد دلوقتي، خصوصًا في الشغل الطويل والمعقد: كتابة كود، migration كبيرة، تحليل مستندات، شغل research، أو حتى tasks محتاجة agent يفضل شغال على مراحل ويختبر نفسه.

بس اللي لافت للنظر مش القوة بس… اللي لافت هو طريقة الإطلاق نفسها.

Fable 5 مبني على نفس الخط بتاع Mythos 5، لكن Mythos متاح لمجموعة صغيرة موثوقة عشان استخدامات حساسة زي cybersecurity وbiology. أما Fable فهو النسخة اللي متاحة للناس والشركات بشكل أوسع، بس مع safeguards. يعني لو الطلب دخل في منطقة Anthropic شايفاها خطيرة، السيستم ممكن يرجّعلك إجابة من Opus 4.8 بدل Fable 5.

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

بالنسبة للمطورين، Fable 5 مهم لأنه بيزق فكرة الـ AI Agent خطوة لقدّام. بدل ما تستخدم الموديل في prompt ورد، أو task صغيرة، Anthropic بتسوقه على إنه يقدر يمسك شغل طويل: يخطط، ينفذ، يراجع، يكتب tests، ويصحح نفسه. وده بالظبط المكان اللي معظم الفرق لسه بتحاول تفهمه: إمتى أثق في agent؟ وإمتى أخليه يشتغل لوحده؟ وإمتى لازم أفضل أنا في النص؟

وبرضه الناس بدأت تلاحظ ان احيانا كتير بيكون الموديل الجديد ما هو الا طريقة للشركات تكسب بيها فلوس أكتر ، فالناس بتلاقي الموديلات القديمة جودتها بقت في النازل ، وفجأة بيلاقوا موديل رجع بنفس القوة اللي كانوا متعودين عليها ولكن محتاجين يدفعوا أكتر.

فدلوقتي كل ما الموديلات بقت أقوى، قيمة المطور مش هتبقى في إنه “يكتب الكود بإيده” بس، لكن في إنه يعرف يصمم الـ harness اللي حوالين الموديل: بحيث يحدد له السياق، ويديله constraints واضحة، ويراجعه، ويقيس جودة شغله، ويمنعه من إنه ياخد قرارات غلط بثقة عالية.

والسؤال الحقيقي لينا كمطورين مش: “هل Fable 5 هيكتب كود أحسن مننا؟”

السؤال الأهم مفروض يكون: “هل احنا بنعرف نبني workflow تخلي موديل بالقوة دي يشتغل بأمان وجودة داخل نظام حقيقي؟”

Harness Explained in Agentic AI 🤖

لما بنتكلم عن الـ AI Agents، الفكرة غالبًا بتتباع لنا بشكل بسيط جدًا: ادّي للـ Agent هدف، وهو يخطط، يستخدم الأدوات، ينفّذ، ويرجعلك بالنتيجة.

لكن في الواقع العملي، خصوصًا داخل الأنظمة الحقيقية في الشركات، الموضوع مش بيكون بالبساطة دي.

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

لما بنتكلم عن AI Agent قوي زي Claude Fable 5، السؤال الطبيعي بيبقى:
هل القوة كلها جوه الموديل؟ ولا في النظام اللي حوالين الموديل؟ وهنا بيظهر دور الـ Harness!

الـ Harness هو الطبقة اللي بتتحط حوالين الـ Agent علشان تخليه قابل للاستخدام في نظام حقيقي، مش مجرد Demo لطيف .. تقدر تتخيله كأنه Wrapper حوالين الـ Agent، فهو مش العقل نفسه، ولكنه البيئة اللي بتنظّم شغله، وتحدد له الأدوات، وتتابع حالته، وتراقب نتائجه.

فببساطة هو “الإطار” أو “النظام” اللي بيشغّل الـ Agent ويسيطر على طريقة شغله. مش شرط يكون جزء من الموديل نفسه، لكنه كل حاجة بتخلي الموديل يشتغل في اتجاه واضح بدل ما يفضل مجرد عقل ذكي بيرد على prompts.

ممكن تتخيله زي البيئة اللي بتحاوط موظف جديد في شركة. الموظف ممكن يكون شاطر جدًا، بس من غير access واضح، rules، review process، tools، logs، وحدود صلاحيات… هيغلط، أو هيشتغل بعشوائية، أو ياخد قرارات أكبر من حجمه.

مكونات الـ Harness

1. Instructions و System Prompts
دي القواعد الأساسية: أنت مين؟ شغلك إيه؟ متعملش إيه؟ إمتى تسأل؟ وإمتى ترفض؟

2. Tools
زي إن الـ Agent يعرف يقرأ ملفات، يشغّل tests، يفتح issue، يعمل search، يكتب كود، أو يتعامل مع API. من غير tools، الموديل ذكي بس محبوس في الكلام بس.

3. Memory و Context
الـ Agent محتاج يعرف هو شغال على إيه، المشروع شكله إيه، القرارات القديمة كانت إيه، وإيه اللي اتجرب قبل كده. بس هنا لازم نفرّق بين context مفيد و context زيادة يخليه يتوه ويحصله Hallucination.

4. Permissions و Boundaries
مينفعش كل Agent يبقى معاه كل الصلاحيات. في فرق بين Agent يقترح كود، وAgent يعمل merge، وAgent يعدل production config. كل مستوى بيحتاج حدود واضحة من الصلاحيات.

5. Feedback Loop
الـ Agent لازم يراجع نفسه أو يتراجع من أدوات تانية: tests، linters، static analysis، human review، أو حتى Agent تاني ناقد. من غير feedback loop، احنا هنكون بنثق في أول إجابة بترجعلنا وخلاص.

6. Observability
وده جزء مهم جدًا غالبًا الناس بتنساه .. لازم تعرف الـ Agent عمل إيه، استخدم أنهي tool، قرر بناءً على إيه، فشل فين، وهل النتيجة اتحسنت ولا لأ ، لإن من غير logs وmetrics، مفيش طريقة نعرف هل فعلاً بيساعد ولا بيعمل noise.

والنقطة الجميلة في الموضوع هنا إن الناس مش متفقة 100٪ على ماهية الـ Harness لسه

Continue Reading

Repomix OpenSource - AI Friendly Repos

لو جرّبت قبل كده تدي AI Agent مشروع كامل وتقول له “راجعلي الكود” أو “ساعدني أعمل refactor”، غالبًا هتقابل نفس المشكلة: إزاي أدي للموديل context كبير وكافي من غير ما نفضل ننسخ الملفات يدويًا؟ او من غير ما نضطر كل مرة نحددله الاماكن اللي يشوف فيها الفايلات اللي يقراها ؟ او من غير ما نسيبه يدور بنفسه ويحرق tokens كتير؟

هنا بتيجي أداة اسمها Repomix.

Repomix ببساطة بتاخد الـ repository بتاعك وتحوّله لملف واحد منظم وAI-friendly، تقدر ترفعه أو تبعته لموديلات زي Claude أو ChatGPT أو Gemini عشان يفهموا شكل المشروع بشكل أوسع. الأداة معمولة تحديدًا لسيناريوهات زي code review، refactoring، documentation، أو إنك تطلب من الموديل يفهم architecture المشروع قبل ما يساعدك في تعديل معين.

الحلو فيها إنها مش مجرد “copy paste لكل الملفات” هي بتراعي حاجات زي .gitignore، وتقدر تحدد ملفات معينة تدخل أو تستبعد ملفات تانية، وكمان فيها اهتمام بفكرة إنك متبعتش حاجات حساسة بالغلط.

Repomix مثال صغير لكنه مهم على فكرة الـ Harness اللي اتكلمنا عنها فوق ، لأن جزء كبير من نجاح الـ AI في البرمجة مش بس إن الموديل يكون قوي، لكن إنك تعرف تجهز له الـ context الصح بالشكل الصح.

بس برضو لازم ناخد بالنا: مش معنى إنك قدرت تحط المشروع كله في ملف واحد إنك تبعته وخلاص .. لازم تراجع إيه اللي داخل في الملف، وتشيل الـ secrets، والـ keys، وأي معلومات داخلية حساسة وده لإن الـ AI محتاج context، ولكه مش محتاج يعرف كل حاجة.

الخلاصة: Repomix مش أداة “سحرية”، لكنها بتحل مشكلة عملية جدًا “إزاي تدي الموديل context مرتب عن مشروعك” ومع الموديلات الكبيرة والـ Agents، النوع ده من الأدوات هيبقى جزء أساسي من workflow أي مطور.

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء، ‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد المائة من النشرة الأسبوعية لاقرأ-تِك 🚀

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

حكاية 100 عدد من نشرة اقرأ-تِك 🎉

كتابة: محمود يُوسف

انا مش مصدق اني بكتب حاليًا العدد الـ 100 واللي مفروض هينزل بكرة يوم السبت كالعادة الساعة 11 بتوقيت القاهرة ، مش مصدق إن اقرأ-تِك وصلت للشكل الحالي ده .. أسابيع وشهور بتعدي قصادي حاليًا ومشاعر مختلفة عن كل عدد كنت بكتبه وكنت بحاول متأخرش في كتابة الأعداد علشان لو فيه حد بيستنى العدد ينزل ..

كنت دايمًا في الاجازات اللي بسافر فيها بحاول اجهز مثلًا بالـ 3 أعداد مرة واحدة واضغط نفسي واعملهم Scheduling علشان مفوتش الفرصة على الناس اللي بتستنى ، وماكونش مقصر معاهم .. ذكريات بتعدي قصادي حاليًا وانا فعلًا مش عارف أوصفها ولكن كل ده بفضل ربنا .. فاللهم لك الحمد والشكر .. وبفضل زوجتي ورفيقة الكفاح في اقرأ-تِك وبفضل تشجيعكم ❤️

الحكاية من الأول

الحكاية بدأت تقريبًا من شهر مايو سنة 2024، لما حبينا إن يكون فيه نشرة أسبوعية بنتكلم فيها عن مواضيع متنوعة في هندسة البرمجيات بشكل بسيط وبرسومات توضيحية كل أسبوع.

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

التطورات اللي النشرة مرت بيها

في البداية الموضوع كان موتر خصوصًا إن مكنش فيه مشاهدات كتير ولا مشتركين في النشرة .. ولكن حماسنا كان أكبر وفضلنا مكملين لحد ما وصلنا تقريبًا للعدد الـ 15 .. ومن وقتها والأعداد بدأت تزداد تدريجيًا!

في نهاية سنة 2024 بدأنا الإعلان عن منتجات اقرأ-تِك لأول مرة وأول كتاب كان “ورقة وقلم” الكتاب اللي بيضم أكتر من 50 موضوع في هندسة البرمجيات بشروحات رسومية بجودة عالية.

ونزلنا أول نسخة مجانية من الكتاب وده كان ليه الفضل بعد توفيق ربنا في إن عدد المشتركين في النشرة يزداد كذلك ، ومن هنا فضلنا مكملين في رحلتنا!

ويلي كتاب “ورقة وقلم” بكل تأكيد محتوى مدونات فطين وخبرات عملية من داخل الشركات في تصميم النظم واللي لقت رواج كبير واللي كانت دافع لينا اننا نكمل وننزل بكتاب “مدونات فطين” كتاني كتاب من منتجات اقرأ-تِك!

النشرة عدت بأشكال مختلفة .. وكنا كل مرة بنحاول بكل جهدنا إننا نخليها فعلًا حاجة تليق بالقارئ العربي وماتكونش بتضيع وقته فيما لا يفيد وكنا فعلًا حريصين جدًا على ده.

عقدة الخواجة — ولحظة الشك

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

دايمًا شرح أي موضوع بلغته الأم بيوصله وبيثبتّه بشكل أسهل وأسرع وهيكون سهل الهضم من إنك تقرأ لغة غير لغتك .. وبعدين تحاول تترجم وتحاول تثبت ده في دماغك!

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

زوبعة الفنجان — ودخول عالم الـ Agents

كسرنا العدد الـ 50 والـ 75 لحد ما وصلنا للـ 100 وتقريبًا بين الـ 75 والـ 100 كانت إنطلاقة الـ AI والـ LLM والـ Agents .. واللي بكل تأكيد هيكون ليها تأثير كبير وتغيير في شكل صناعة هندسة البرمجيات في المستقبل.

وبسبب ده حاولنا للمرة اللي مش فاكر كام نغير في شكل النشرة ونخلي دايما في جزء بنتكلم فيه عن الـ AI في سطور ونخلي في إطلاع دائم باللي بيحصل حوالينا في عالم تطور الـ AI!

التطوير دا أصبح بيقدم أكبر قيمة للقارئ (المبرمج) اللي حابب يفضل يتعلم جديد وكمان يفضل متابع الأخبار بشكل يفيده مش يتوّهه.

السر في الاستمرارية

كنت دايمًا بسمع الجملة دي .. السر في الاستمرارية .. Consistency is the key ولكن مقدرتش قيمتها فعلاً وحسيت بيها إلا مع اقرأ-تِك سواء في المنصة أو من خلال النشرة الأسبوعية .. كنا بنكتب كل عدد وكل مقال وإحنا مش مهتمين لا بعدد ولا مشاهدات .. هكون بكدب لو بقول الحاجات دي مش بتفرق .. هي أكيد بتفرق في النفسية والتحفيز .. ولكن كانت دايما نيتنا إننا بنحاول نشكر نعمة ربنا علينا .. وكنوع من شكر النعمة اللي ربنا أنعم بيها علينا في المجال .. هو إننا نشارك اللي اتعلمناه واللي بايدينا نساعد بيه المجتمع من حوالينا في إنه يتطور ويتحسن للأفضل ..

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

في الختام

الحمدلله احنا لسه مكملين .. وربنا يوفقنا في إننا نفضل مكملين للـ 100 عدد التاني وباذن الله مازلنا هنطور للأفضل وفيه أفكار كتير ناويين نعملها وهنشاركها معاكم دايمًا أول بأول .. فشكرًا إنكم جزء من رحلتنا الجميلة دي وشكرًا لدعمكم المستمر ❤️

شاركونا في رسم الأعداد الجاية 👋

بما إن هدفنا دائمًا في النشرة الأسبوعية نقدم محتوى يلامس اهتماماتكم التقنية والبرمجية ويضيف لقيمتكم المعرفية، حابين نعرف منكم: حابين نركز على ايه ونغطيه بالتفصيل في الأعداد الجاية؟ شاركونا في الاستبيان وخلينا نشوف رأي الأغلبية! 👇

• إستضافة مهندسين متميزين من مجالات برمجية مختلفة يشاركونا خبرتهم في النشرة

• محتوى أكبر عن الـ AI و ال AI Agents

• تعمق أكثر في الأساسيات

• محتوى أكبر عن ال System design والشركات العالمية

واكتبولنا في التعليقات لو عندكم أفكار تانية بالتأكيد هنحب نسمعها!

نظرة سريعة عن أهم ما جاء في الـ 100 عدد 🚀

100 عدد ب 100 شرح اتكلمنا فيهم عن مواضيع مختلفة لأننا بنحافظ على أن النشرة متكونش متمحورة بس على نشر الأخبار الجديدة في الـ software development ولكن تضيف “علم” حقيقي ليك كمبرمج سواء بشروحات تقديمية لبعض المواضيع أو شروحات متقدمة ونقاشات مواضيع هامة.

تقدروا تلاقوا الأعداد في الأرشيف بتاعنا على Substack ودي أهم التصنيفات اللي اتكلمنا عنها

هندسة الـ APIs والتطوير (APIs & Development Tools)

أهم ٥ أعداد في هذا التصنيف:

1. VOL34: Top 30 ASP.NET Core Libraries for Building Applications

2. VOL32: Full Guide Into API Documentation

3. VOL59: Improving Code Quality with SonarQube

4. VOL61: What is gRPC? A Modern Alternative to REST APIs

5. VOL62: Understanding API Idempotency & API Authentication Methods

دراسات حالة للأنظمة الضخمة (System Design & Scale Case Studies)

كان في أكثر من 23 عدد قدمنا فيهم شروحات لل Systems at Scale واللي الشركات العالمية بالفعل شاركتها في ال Engineering Blogs الخاصة بيها بشرح أسهل بالعربي وبـ Diagrams توضيحية ليها ودول كانوا أكثر 9 أعداد مميزة.

1. VOL:19 Strategies for Read Heavy Systems

2. VOL30: How Discord Stores Trillions of Messages

3. VOL45: How Canva Built Scalable and Reliable Content Usage Counting Service

4. VOL51: How Netflix Migrates Critical Traffic at Scale With No Downtime

5. VOL52: How Slack Handles Billions of Tasks in Milliseconds

6. VOL53: How YouTube Supports Billions of Users With MySQL

7. VOL67: Unlocking Notion’s Power - The Data Model Explained

8. VOL86: Modernizing Reddit’s Comment Backend from Monolithic to Microservices 🚀

9. VOL90: Scaling PostgreSQL to Power 800 million ChatGPT Users

تصميم الأنظمة وهندسة قواعد البيانات (System Design & Databases)

أكثر 11 عدد مميز في الموضوعين اللي مصدعين كل ال backenders! 😅

1. VOL22: Database Cheatsheet for System Design

2. VOL38: Deep Dive Into Rate Limiting

3. VOL24: Stop Using Sticky Sessions at Scale

4. VOL33: Distributed Tracing in Microservices

5. VOL36: Deep Dive Into Caching Strategies.

6. VOL50: Introduction to Apache Kafka - A Beginner’s Guide .

7. VOL64: Deep Dive Into Redis Persistence Strategies

8. VOL66: Top 6 API Performance Techniques

9. VOL80: Vector Databases Explained

10. VOL81: HTTP Versions Explained.

11. VOL99: Harness Engineering

الذكاء الاصطناعي وهندسة الأوامر (AI, LLMs & Prompt Engineering)

اتكلمنا عن ال AI بشكل رئيسي في أكثر من 15 عدد ودول أهم خمس أعداد من النشرة لشروحات عن الـ AI

1. VOL37: Prompt Engineering Crash Course

2. VOL57: Understanding Model Context Protocols in LLMs - The Future of AI Interaction

3. VOL77: RAG Architecture Explained

4. VOL79: AI Engineer Roadmap

5. VOL94: LLM Currency Language - Tokens Explained 🚀

أنظمة الدفع الإلكتروني (FinTech & Payment Systems)

في 2025 ابتدينا نتكلم عن ال Fintech بالتحديد كانت من أفضل التجارب و كل الشكر ل م محمد بسيوني لمقالته وشروحاته المتميزة في هذا الموضوع. نشرنا إلى الآن 10 أعداد مختلفين في مواضيع مهمة لكل مبرمج في ال FinTech ودول أهم خمس أعداد منهم:

1. VOL68: Online Payments 101 for Developers

2. VOL72: How Card Payments Secured With 3DS

3. VOL73: Payment Fees: An Engineering Breakdown

4. VOL74: How to Integrate Payment Gateways - A Developer’s Guide

5. VOL76: How Wallet Payment Works ?

أساسيات هندسة البرمجيات والويب (Software Engineering & Web Fundamentals)

الأعداد الأولى من النشرة كانت مركزة علي شروحات تقديمية في الويب و المجال بشكل عام ودول كانوا أفضل ٥ أعداد منهم والعدد الواحد بيقدم أكثر من موضوع فهتطلعوا بمعلومات قيمة جدًا..

1. VOL8: Message Queue, OAuth2 and High Order Component Pattern

2. VOL9: How to Write Better Logs, Json Web Token

3. VOL10: Database Connection Pool, Normalization and SQL Injection

4. VOL12: Pessimistic Locking, WebSockets and ACID

5. VOL13: HTTP Long Polling, Short Polling and SSE

آخر الإحصائيات 📊

احصائيات النشرة الأسبوعية لاقرأ-تِك قبل العدد الـ 100 ⭐️

رسالة شكر وتقدير ❤️

في خلال رحلتنا .. فيه ناس فضلوا مكملين معانا للآخر ولذلك وجب الشكر لجميع الكتاب في منصة اقرأ-تِك واللي بيبذلوا مجهود في اثراء المحتوى التقني باللغة العربية! وشكر خاص لـ

• م.محمد بيسوني وتميزه في كتابة المواضيع الخاصة بالـ FinTech

• م.روان إبراهيم وتميزها في كتابة المواضيع الخاصة بالـ Mobile Development وبالأخص Flutter

• م. يوسف حسين وتميزه في كتابة المواضيع الخاصة بالـ Scrum والـ Agile وتبسيطها

• م. Oussama Djaidri وتميزه في كتابة مواضيع متنوعة وبالأخص في الـ Frontend والـ React

• م. خالد عبدالفتاح وتميزه في كتابة مواضيع متنوعة بجودة عالية وبالأخص في الـ API Documentation

• م. أحمد أنور وتميزه في كتابة مواضيع خاصة بالـ Data Structures & Algorithms

• م. سعيد خالد وتميزه في كتابة مواضيع غير مسبوقة في الـ Frontend

• م. هبة محمد وتميزها في كتابة مواضيع خاصة بالـ AI والـ Prompt Engineering

• م. أحمد محمد وتميزه في كتابة مواضيع خاصة بقواعد البيانات وتصميم النظم

وشكرًا لكل المؤثرين في المجال واللي كانوا بيشجعونا نكمل وشكر خاص لـ

• أحمد الإمام

• أبوبكر سليمان

• حسن إبراهيم

• حاتم حسني

• سامح دعبس

• محمد سويلم

• آية الجبيلي

• هبة العيوطي

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

• مجرّة - مُجتمع المطورين ومستجدات التقنية

• Apidog

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد التاسع والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

Harness Engineering

في سنة 1973، شركة General Dynamics طلّعت prototype لطائرة مقاتلة جديدة اسمها YF-16. من برّه، الطيارة كانت شكلها عادي بالنسبة لمقاتلة حديثة: جناحات حادة، engine قوي، وتصميم كله سرعة ومناورة.

بس الحقيقة إن الطيارة دي كان جواها سر غريب جدًا: هي كانت متصممة بطريقة تخلي الإنسان مستحيل تقريبًا يطيرها لوحده.

قبل الـ F-16، الطيار كان متوصل بالطائرة بشكل ميكانيكي. يعني لما يشد عصاية القيادة، فيه كابلات وأجزاء ميكانيكية بتحرك أجزاء معينة في الجناح والذيل. لكن الـ F-16 كانت مختلفة.

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

فالمهندسين عملوا حاجة جريئة جدًا: حطّوا Computer بين الطيار والطيارة.

لما الطيار يحرك عصاية القيادة، هو في الحقيقة مش بيحرك الجناح مباشرة. هو بيبعت request للـ Computer. والـ Computer هو اللي بيترجم الطلب ده لمجموعة ضخمة من التعديلات الصغيرة في أجزاء من الثانية علشان الطيارة تفضل طايرة بثبات.

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

وده بالضبط اللي بيحصل دلوقتي في مهنة الـ Software Engineering.

تجربة OpenAI — خمسة شهور من غير ما إنسان يكتب كود

في تجربة مثيرة، فريق داخلي في OpenAI اشتغل لمدة خمسة شهور على بناء software product حقيقي.

بس كان عندهم شرط واحد غريب: ممنوع أي إنسان يكتب كود بإيده. وكل حاجة تقريبًا اتعملت عن طريق الـ AI Agent Codex.

• البشر كانوا بيشرحوا المطلوب.

• والـ Agent هو اللي يكتب الكود ويشغّل tests ويصلح errors ويكرر المحاولة لحد ما يوصل لنتيجة شغالة.

الموضوع مش معناه إن البشر اختفوا ولكن بالعكس البشر كانوا مهمين جدًا، بس دورهم اتغير.

بدل ما يكتبوا implementation سطر بسطر، بقوا يحددوا الاتجاه، يكتبوا design docs، يحطوا constraints، يراجعوا القرارات، ويبنوا البيئة اللي تخلي الـ AI Agent يعرف يشتغل من غير ما يحوّل المشروع لفوضى.

ووقتها OpenAI سمّت النوع ده من الشغل: Harness Engineering.

المشكلة عمرها ما كانت في كتابة الكود

لسنين طويلة فضلنا نتعامل مع كتابة الكود كأنها قلب المهنة.

• المبرمج الشاطر مش بس اللي يكتب بسرعة واللي حافظ syntax ولكن برضو اللي يعرف يبني feature كاملة لوحده وكمان اللي يغوص في الكود ويصلح كل حاجة بإيده.

  بس الحقيقة إن هندسة البرمجيات عمرها ما كانت مجرد typing .. كتابة الكود كانت بس الوسيلة اللي بنعبّر بيها عن قراراتنا. والشغل الحقيقي دايمًا كان في حاجات أدق وأعمق بكتير زي:

• إننا نفهم المشكلة.

• نقسم التعقيد.

• نختار abstraction مناسب.

• نرسم boundaries بين components.

• نوازن بين performance وmaintainability.

• نعرف إمتى نخلي الحل simple وإمتى نستثمر في الـ scalability وإمتى نقول “لا” لفكرة شكلها ذكي بس هتبوّظ النظام بعدين.

  فبشكل تاني إحنا لما بنشوف مهندس برمجة بيكتب كود، احنا مش بنتفرج عله وهوشغال typing ... ولكن احنا بنتفرج على التفكير وهو بيتحوّل لكود.

فلو الـ AI قدر ياخد التفكير ده ويحوّله لكود شغال، يبقى الـ bottleneck الحقيقي مكنش سرعة صوابعنا وهي بتكتب على الكيبورد. الـ bottleneck الحقيقي كان دايمًا وضوح التفكير.

Harness Engineering

ببساطة: الـ Harness Engineering هو إننا نبني البيئة اللي تخلي الـ AI Agent يقدر يكتب Software كويس، آمن، مفهوم، وقابل للصيانة.

فالفكرة هنا مش إننا نقول للـ Agent:

“ابني النظام ده” ونسيبه يسرح.

لأن الـ AI Agent سريع جدًا. متحمس جدًا. وبيقدر يطلع آلاف الأسطر في وقت قليل. وطبعًا كل ده من غير حدود، هنلاقي إن السرعة دي بتتحول لفوضى.

هيضيف abstractions مش محتاجينها ، وهيكرر logic في كذا مكان ، وهيكسر architectural boundaries وممكن يبني حاجة شغالة النهارده، بس صعب جدًا تتفهم أو تتعدل بعد شهرين.

علشان كده دورنا في الـ Harness Engineering مش إننا نجري ورا الـ Agent نصلحله كل حاجة بإيدينا ولكن دورنا إننا نبني الطريق ليه من خلال إننا نبني rails ، نحط guardrails ، نكتب docs واضحة ، نحدد rules ، نقوّي الـ tests ونظبط الـ CI ونخلي إمكانية الغلط أصعب، وإنه يطلع المطلوب الصح هو الأسهل.

فبدل ما تسأل نفسك:

“هكتب الكود إزاي؟”

تبدأ تسأل نفسك:

“أبني environment إزاي يخلي الـ Agent يكتب الكود الصح من غير مشاكل؟”

الـ Agent محتاج حدود مش حرية مطلقة

لو تخيلنا إن عندنا junior developer سريع جدًا، عنده طاقة رهيبة، وممكن يكتب كود طول اليوم من غير ما يتعب .. ده طبعًا هيكون شيء ممتاز.

بس الحقيقة المرة هي .. إن لو دخل codebase كبيرة من غير onboarding، من غير conventions، من غير architecture واضحة، ومن غير tests محترمة، هيعمل كارثة بسرعة.

الـ AI Agent شبه كده، بس أسرع بكتير .. هو مش محتاج إنك تشرحله كل تفصيلة يدويًا كل مرة ولكن محتاج system يفهمه.

محتاج يعرف:

• يبدأ فين بالظبط؟ وإيه الـ architecture؟ وإيه المسموح والممنوع؟ وإيه الـ naming conventions؟ طب إزاي نكتب tests؟ وإزاي نضيف feature من غير ما نكسر boundaries؟ وإيه الملفات اللي يرجع لها؟ ووإيه الحاجات اللي ممنوع يعملها حتى لو “شكلها” أسهل؟

هنا بقى قيمة الـ Software Engineer بتظهر .. مش في إنه يكتب كل function بإيده ولكن في إنه يبني codebase وworkflow يخلي الـ Agent يعرف يتحرك جواهم بأمان.

حكاية الـ Progressive Disclosure — ما ترميش المشروع كله في وش الـ Agent!

من أهم الأفكار في الـ Harness Engineering فكرة اسمها الـ Progressive Disclosure

ودي بكل بساطة يعني ما تديش للـ Agent كل حاجة مرة واحدة ، فما ترميش عليه architecture كاملة، وrequirements ضخمة، و20 ملف docs، وتستنى منه يطلعلك implementation ممتاز.

بدل كده، اديله entry point واضح وصغير مثلاً ملف زي: AGENTS.md الملف ده مش لازم يشرح كل حاجة ولكن هو بس يقول للـ Agent:

• ابدأ من هنا.

• لو بتشتغل على API، اقرأ الملف الفلاني.

• لو بتضيف database migration، اتبع القواعد دي.

• لو بتكتب tests، استخدم pattern ده.

• لو هتغير في module معين، ما تكسرش الحدود دي.

• يعني بدل ما تحط كل الـ Knowledge في prompt واحد ضخم، تبني نظام من docs صغيرة ومترابطة ، فكل layer تكشف اللي بعدها لو احتاجنا ليها وعند الضرورة.

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

شكل الشغل بيتغير

في الـ workflow القديم، المهندس يفتح IDE، يقرأ الكود، يكتب implementation، يشغّل tests، يصلح الأخطاء، ويعمل pull request ولكن في الـ workflow الحالي والقائم على مبدأ الـ Harness Engineering، المشهد بيكون مختلف.

المهندس ممكن يكتب task واضحة:

“ضيف user login feature، التزم بالـ existing architecture، اكتب tests، وحدّث docs.”

بعدها الـ Agent يبدأ يشتغل.

يقرأ الملفات ويعمل plan وبعدين يعدل الكود ويشغّل tests ولو حاجة باظت يصلحها ويراجع التغيير واخيرا يفتح pull request.

وهنا الـ Software Engineer دوره مختفاش ولكن بقى شغله في Layer أعلى فبيسأل:

هل الحل ده مناسب ولا لا ؟ هل الـ Agent فهم المشكلة صح؟ هل الـ design ماشي مع الاتجاه اللي عاوزينه؟ هل فيه complexity زيادة؟ هل التغيير ده هيبقى مفهوم بعدين مع الوقت ومع وجود تغييرات؟ هل الـ tests بتثبت السلوك المهم فعلًا ولا مش بتقدم قيمة؟ هل الـ architecture لسه مظبوطة ولا فيه volations؟

وكل دي أسئلة محتاجة مهندس شاطر ويمكن كمان اشطر من الأول .. لأنك دلوقتي مش بس بتكتب كود ولكن أنت بتصمم وبتدير نام يقدر ينتج هو الـ functions دي.

لما الـ Agent يغلط، متصلحش الكود بس!

في الطريقة التقليدية، لما bug يظهر، أول حاجة بنعملها إننا نفتح الكود وندور على المشكلة علشان نحلها .. ولكن في الـ Harness Engineering، السؤال الأهم بيبقى:

“ليه النظام سمح للـ Agent يغلط بالطريقة دي؟”

هل الـ docs مش واضحة؟ طب هل الـ tests ضعيفة؟ هل ممكن الـ prompt كان مكتوب بشكل generic زيادة عن اللزوم؟ هل فيه conventions متضاربة؟ هل الـ architecture مكنتش مفهومة وواضحة؟ هل مفيش automated checks تمنع النوع ده من الغلط بعدين؟ وآخيرًا هل الـ codebase نفسها كانت صعبة إن الـ Agent يفهمها بسبب تعقيدها ؟

فالغلط هنا مش بس bug في الكود ولكن ممكن يكون bug في الـ harness نفسه وده فرق كبير جدًا!

فبدل ما نفضل نصلح في نفس المشكلة كل مرة، احنا بنحاول نبني نظام يمنع تكرارها من الأساس.

هل ده معناه إن الـ Software Engineer هينتهي؟

بكل تأكيد لأ .. ولكن المهندس اللي قيمته كلها إنه “بيعرف يكتب كود كتير” بس، هيواجه ضغط كبير.

وده جوهر الـ Harness Engineering: الذكاء مبقاش بس في الكود اللي بيتكتب، لكن في البيئة اللي بتخلي الكود يتكتب صح.

الطيار مبقاش بيمسك الجناح بإيده

نرجع تاني لتشبيه الـ F-16 .. الطيار مبقاش متوصل بالجناح بشكل ميكانيكي ، فمش بيحرك كل سطح في الطيارة بنفسه ولكنه برضه مبقاش أقل أهمية .. بل بالعكس هو بقى بيوجّه نظام أعقد وأسرع من قدرة الإنسان.

وده اللي بيحصل بالظبط مع الـ Software Engineers ، إننا ما نكتبش كل سطر بإيدينا مش معناه ابدأ إننا بقينا أقل قيمة ولكن معناه إننا بدأنا نشتغل في layer أعلى محتاجة مهارات ومتطلبات أكتر. وبدل ما نكون منفّذين لكل تفصيلة، هنبقى مصممين النظام اللي بينفذ ده.

في الختام

الـ Harness Engineering هو محاولة لوصف تحول حقيقي في طريقة بناء الـ Software مع AI Coding Agents .. زمان، قوة المهندس كانت بتاخد wight كبير في قدرته على كتابة الكود ولكن دلوقتي، القوة بتتحرك تدريجيًا ناحية قدرته على بناء systems تخلي الـ Agents تشتغل بشكل منتج وآمن.

والـ Software Engineering عمرها ما كانت عن سرعة الكتابة ولكن كانت دايمًا عن مهارات التفكير وحل المشاكل.. فكل ما الآلة بقت أقوى في التنفيذ، الإنسان اللي يعرف يحدد الاتجاه، ويبني الحدود، ويفهم الـ trade-offs، هيبقى أهم.

وآه يمكن المستقبل مش محتاج دلوقتي مهندسين يكتبوا كود أكتر .. ولكن محتاج مهندسين بيعرفوا يبنوا الـ harness اللي يخلي الـ AI ينطلق بسرعة وبدون مشاكل … من غير ما يوقع النظام كله!

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الثامن والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• AI في سطور: DeepSeek V4 released with ultra-long context 🔥

• ورقة و قلم: Top 6 Deployment Strategies 🚀

• مقال: Beyond Barrel Files 💎

DeepSeek V4 Released with Ultra-long Context

في نهاية إبريل شركة DeepSeek أعلنت رسميًا عن الجيل الجديد من موديلاتها: DeepSeek-V4، واللي جاي بنسختين:

• V4-Pro: للأداء العالي والمهام المعقدة.

• V4-Flash: أسرع وأوفر في التكلفة.

ال Model يعتبر من أقوى الموديلات المفتوحة المصدر اللي نزلت لحد دلوقتي، وقريب جدًا من أداء أفضل الموديلات المغلقة زي OpenAI وAnthropic، لكن بتكلفة أقل بفرق كبير جدًا.

أهم المميزات

🔥 Context ضخم جدًا

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

🧠 وضعين للتشغيل

• Thinking Mode: للتفكير العميق والاستدلال.

• Non-Thinking Mode: للردود السريعة والعمليات اليومية.

💸 الأسعار

• V4-Flash بيقدم Input رخيص جدًا مقارنة بالمنافسين و بيعتبر مناسب للتطبيقات اللي محتاجة سرعة وحجم استخدام كبير.

• V4-Pro أغلى شوية، لكنه بيقدم أداء قوي جدًا في البرمجة، التحليل، والاستدلال المعقد

⚠️ العيوب اللي لازم تعرفها

• لسه أضعف شوية في الـ World Knowledge مقارنة بأحدث موديلات OpenAI وGoogle.

• مفيش دعم multimodal حاليًا (صور، صوت، فيديو).

• في بعض السيناريوهات المعقدة جدًا، Claude وGPT لسه متفوقين.

المهم فعلاً للمبرمجين

بالنسبة للفرق اللي بتشغل أحجام ضخمة جدًا من الـ inference، فرق التكلفة بين V4 Pro والموديلات المغلقة الرائدة بيعمل فرق حقيقي على أرض الواقع. لو نظامك بيعدّي ملايين التوكنز يوميًا من خلال Agent Pipeline، النزول من حوالي 15 دولار لكل مليون توكن كـ output لحوالي 1.10 دولار بس بيغيّر اقتصاد المنتج بالكامل.

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

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

أما لو أنت بالفعل بتستخدم موديلات مغلقة متقدمة، فالفجوة في الأداء بين V4 Pro وبين GPT-5.5 أو Opus 4.7 موجودة فعلًا، لكنها صغيرة نسبيًا. حسب نوع المهام اللي عندك، الفجوة دي ممكن تكون مؤثرة أو لا. عشان كده، استخدام نظام Multi-Model Routing—بحيث تعتمد على V4 Pro للمهام الأقل تعقيدًا، وتلجأ للموديلات المغلقة فقط في الحالات الصعبة—يعتبر حل عملي وذكي جدًا.

Top 6 Deployment Strategies

لما نيجي نتكلم عن الـ Deployment Strategies اللي بتستخدمها الشركات الكبيرة، الهدف الأساسي بيبقى إننا ننقل التحديثات الجديدة للـ Production Environment بأقل تأثير سلبي ممكن على المستخدمين.

فورقة وقلم وخلونا نستعرض الأنواع المختلفة من الاستراتيجيات دي مع مميزات وعيوب كل واحدة فيهم 🚀

Blue-Green Deployment

في الاستراتيجية دي بيبقى عندنا بيئتين شغالين في نفس الوقت: بيئة قديمة بتبقى هي دي الـ (Blue) وبيئة جديدة بتكون هي دي الـ (Green).

أول ما التحديث الجديد يبقى جاهز، بنحول الـ Traffic من بيئة الـ Blue للـ Green مرة واحدة. فيبدأ الناس بدل ما كانت بتروح للـ Blue Deployment تروح للـ Green وهنا بنتكلم طبعًا عن Real Traffic اتعمله Routing باستعمال Load Balancer للـ Green Deployments.

مميزات الـ Blue-Green Deployment:

تقليل الـ Downtime لأن الـ Traffic بيتحول بالكامل مرة واحدة.

لو حصلت مشكلة، الرجوع للبيئة القديمة بيبقى سهل وسريع لإن احنا لسه عندنا الـ Blue Environment لسه موجودة.

عيوب الـ Blue-Green Deployment:

محتاج موارد زيادة لإن بيئتين لازم يكونوا شغالين في نفس الوقت مع بعض.

مثال على ده: شركات كتيرة زي Amazon وغيرها بتستخدم الـ Blue-Green Deployment عشان تحافظ على استمرارية الخدمات بدون تأثير على المستخدمين وعشان يبقى سهل بالنسبالهم يرجعوا للبيئة القديمة لو حصل أي مشاكل غير متوقعة.

Canary Deployment

الاستراتيجية دي بتعتمد على إننا ننقل التحديث بشكل تدريجي يعني Gradually لعدد محدود من المستخدمين الأول، ولو الأمور مشيت كويس، نكمل تعميم التحديث لباقي المستخدمين.

وليكن هنعمل Apply على التحديث الجديد لـ 20% من الـ Machines اللي عندنا و 80% هيفضلوا لسه محافظين على النسخة القديمة وبالتالي الناس لما يطلبوا الخدمة 20% منهم هيروح للجديد و 80% هيفضلوا لسه بيجيلهم النسخة القديمة والنسبة دي طبعا احنا بنتحكم فيها على حسب احتياجاتنا.

مميزات الـ Canary Deployment:

• لو فيه أي مشاكل، بتأثر على عدد محدود من المستخدمين بس.

• بتساعد في اختبار التحديث الجديد في البيئة الحقيقية.

عيوب الـ Canary Deployment:

• محتاجين Monitoring دقيق عشان نعرف إذا كان فيه مشاكل بسرعة.

مثال: شركات زي Google و Netflix بتستخدم Canary Deployment عشان تجرب الـ Features الجديدة قبل تعميمها على كل المستخدمين وبالتالي يكون فيه نسبة بس بيجيلهم التحديث الجديد ونسبة تانية لسه بيظهرلهم النسخة القديمة.

Rolling Deployment

في الـ Rolling Deployment، التحديث بيتنقل بشكل تدريجي لمجموعة من السيرفرات بدلاً من نقل التحديث بالكامل مرة واحدة.

فلو عندنا مثلا 10 Servers هيبدأ يتعمله Apply على واحد تلو الآخر بشكل تدريجي لحد مايتم على كل الأجهزة والـ Servers اللي موجودة.

مميزات الـ Rolling Deployment:

• الـ Downtime قليل جداً لإن السيرفرات بتتحدث واحدة واحدة.

• بيقلل المخاطرة لأن التحديث بيكون بشكل تدريجي.

عيوب الـ Rolling Deployment:

• لو حصلت مشكلة، صعب ترجّع التحديث لكل السيرفرات بشكل سريع وده لإن احنا محتاجين نـ Rollback كل جهاز بشكل تدريجي ونرجع للنسخة القديمة فهياخد وقت.

مثال: فيه شركات بتفضل تستخدم الـ Rolling Deployment عشان تتجنب المشاكل الناتجة عن تحديث كل السيرفرات مرة واحدة فيبقى الموضوع ماشي واحدة واحدة وبشكل تدريجي

اكمل قراءة المقال

Beyond Barrel Files

أحيانا كتير بنشوف أنماط مختلفة من كتابه الكود وبنشوف الأنماط دي كتير في شغلنا اليومي وبنستخدمها كمبرمجين من غير ما نعرف ال cost بتاعها في الخلفية، وواحدة من الأنماط دي هي barrel file طب يعني ايه barrel file وهل هو صالح للمشروع أو لا ؟ 🤔 دا اللي هنعرفه في المقال ان شاء الله .

ماذا يعني barrel file ؟

ال barrel file عباره عن ملف واحد في الأغلب index.js او index.ts وهدفه الوحيد إنه يجمع ال exports الي في الملفات الأخرى الي بتكون في نفس ال folder يعني علي سبيل المثال

project/
├── components/
│   ├── index.ts          # Barrel file
│   ├── Button.ts
│   └── Modal.ts

ودا بيكون المحتوى بتاعه في الأغلب

 // index.ts
export { default as Modal } from “./Modal”
export { default as Button } from “./Button”

بعد ما عرفنا ايه هو ال barrel file خلينا نشوف ايه المشاكل الي ممكن يسببها ال barrel file

اكمل قراءة المقال مجانًا

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد السابع والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• جديد اقرأ-تِك وخصم الـ 50% 🚀

• AI في سطور: ChatGPT Images 2.0 Release 🔥

• مقال Threads & Isolates & Event Loop In Flutter 💎

• تطبيق مجرة على الـ IOS 🌌

إطلالة جديدة وعودة لخصم الـ 50% 🚀

بفضل الله وبفضل مساهمتكم وتشجيعكم وصل عدد المقالات في اقرأ-تِك لأكتر من 350+ مقال بالإضافة لأكتر من 100+ شروحات رسومية بجودة عالية وكمان وصلنا لأكتر من +7,000 مشترك في النشرة الأسبوعية مهتمين بكل ما يخص هندسة البرمجيات والتقنية بالعربي ✨

عشان كده عملنا تحسينات وتجديدات في المنصة تقدروا تشوفوها دلوقتي بطلة جديدة وبالمناسبة دي رجعنا عرض الـ 50% لفترة محدودة على كل خطط الاشتراك السنوية 🚀

اشترك الآن

ChatGPT Images 2.0 Release

ChatGPT Images 2.0 هو الجيل الجديد في أداوات توليد الصور من OpenAI، ودي نقلة كبيرة جدًا عن الإصدارات اللي قبلها. كمان حطم الأرقام القياسية بعد ما تصدر كل تصنيفات Image Arena بفارق ضخم جدًا وصل إلى 242 نقطة عن أقرب منافس، Google Nano Banana 2. أهم تطوير هنا إن “Thinking Mode” يسمح للنموذج بالتخطيط والتحقق قبل التوليد، وده يقلل عدد المحاولات ويوفر وقت كبير أثناء الـ Prototyping. يعني بيفهم المطلوب ويحلله الأول، وبعد كده يبدأ التوليد.

أهم المميزات:

• صور أدق و التزام أعلى جدًا بالتعليمات مع دعم دقة تصل إلى 2K ومجموعة واسعة من أبعاد الصور

• قدرة ممتازة على كتابة النصوص داخل الصور حتى في اللغات المعقدة زي العربي، الياباني، الكوري، والصيني، بدون الأخطاء المعتادة اللي كانت بتظهر في الموديلات القديمة، ودي كانت واحدة من أصعب المشكلات في ال AI Image Generation

• الحفاظ على الاتساق بين عدة صور لنفس المشروع.

• بقى يتعامل بشكل أفضل مع الملفات المرفوعة والسياق الكامل للمحادثة

اللي يهم الـ developers:

• بيفتح استخدامات عملية حقيقية لأنك دلوقتي تقدر تعتمد على النموذج في توليد UI Mockups، Dashboards، Infographics، Documentation Visuals، وحتى شاشات تطبيق كاملة فيها نصوص حقيقية قابلة للاستخدام. دعم تعدد الصور المتناسقة يسهل جدًا بناء Design Systems أو Storyboards للمشاريع.

• لو بتبني منتجات SaaS أو أدوات AI، فـ Images 2.0 ممكن يقلل اعتمادك على أدوات تصميم خارجية في المراحل الأولى، ويحسن سرعة التطوير بشكل ملحوظ.

Threads & Isolates & Event Loop In Flutter

المرة اللي فاتت اتكلمنا عن Platform Channels وليه هي مهمة، لكن في سؤال مهم لازم نسأله:

هل ممكن Platform Channels تبوّظ الأداء أو تخلي التطبيق يهنّج؟

الإجابة: آه، لكن مش لأنها فيها مشكلة في حد ذاتها… السبب دايمًا بيكون في طريقة استخدامها.

في الجزء ده هنعرف يعني إيه Threads وIsolates في Flutter

و يا تري إيه علاقة Dart Event Loop بالموضوع خلونا نشوف✨

📌هنتكلم النهاردة عن :

• يعني إيه Threads

• أنواع ال Threads

• ال Isolates

• ال Life Cycle isolate

• أهمية ال Isolate

• متى نستخدم ال Isolates

• ال Dart Event Loop

• أنواع ال Queues

• الخاتمة

Threads In Flutter

يعني إيه Thread أصلاً ؟

هو وحدة التنفيذ جوه البرنامج .تخيل ال thread دا عامل زي عامل التوصيل كدا بياخد المهمه و يروح يوصلها للمكان اللي هتتنفذ فيه و لازم المهمه دي تخلص علشان ياخد مهمه تانية ميقدرش ياخد اكتر من مهمة في نفس الوقت .

طب ما هي أنواع الـ Threads ؟

عندنا نوعين:

• Main Thread

• Background Thread

عندنا في Flutter:

💡 Main Thread = UI Thread

وده المسؤول عن:

• رسم الواجهة

• التعامل مع ضغطات المستخدم

• تشغيل lifecycle methods

و دا عامل زي جزء الوعي في مخ الانسان اللي هو انت مركز ف ايه ؟ شايف ايه ؟ بتتفاعل مع ايه ؟

ف كدا أما دماغك بتنضغط تركيزك بيقل ف برضو أي شغل تقيل علي ال Main Thread بيخلي التطبيق يهنّج و الـ UI يحصله Freeze

Dart Single Thread 🤔

عندنا دارت شغالة single thread

طب ازاي هقدر اعمل كذا حاجة ابعت ريكويست HTTP و اضغط علي زرار من غير ما التطبيق يقف ؟

اكمل قراءة المقال مجانًا

تطبيق مجرة على IOS 🔥

مجرة أطلقت الـ IOS Native Mobile App لمتابعة مستجدات التقنية من أكتر من 80+ مصدر عربي وعالمي وكمان لتبادل الخبرات والنقاشات بين المطورين 🚀

من خلال التطبيق:

‏🎯 تقدر تبني مجرتك بالشكل اللي يناسبك وتشوف المقالات اللي تهمّك فعلاً من المصادر المتاحة والوسوم
‏🤖 أوامر مدعومة بالذكاء الاصطناعي بالعربي — تلخيص، وتبسيط، وأمثلة عملية وتطبيقية من أي مقال، ونقد بنّاء بضغطة واحدة
‏🌟 الكوكبات — مجتمعات متخصّصة للمطوّرين (تقدر تفكر فيها كـ subreddits للمطوّرين العرب)
‏🔥 سلسلة القراءة — حافظ على عادة القراءة اليومية وهيكون فيه نظام Gamification للتحفيز جاي قريب
‏🏆 لوحة الصدارة والإنجازات
‏💎 تجربة استخدام مميزة للمطورين

وطبعًا دعم كامل للعربية والـ RTL 🌟

رابط التطبيق

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد السادس والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• جديد اقرأ-تِك وخصم الـ 50% 🚀

• AI في سطور: Anthropic’s Double Drop: Opus 4.7 & Claude Design 🔥

• تطبيق مجرة على الـ IOS 🌌

• مقال : How Boris Cherny uses Claude Code - Part 1 💎

إطلالة جديدة وعودة لخصم الـ 50% 🚀

بفضل الله وبفضل مساهمتكم وتشجيعكم وصل عدد المقالات في اقرأ-تِك لأكتر من 350+ مقال بالإضافة لأكتر من 100+ شروحات رسومية بجودة عالية وكمان وصلنا لأكتر من +7,000 مشترك في النشرة الأسبوعية مهتمين بكل ما يخص هندسة البرمجيات والتقنية بالعربي ✨

عشان كده عملنا تحسينات وتجديدات في المنصة تقدروا تشوفوها دلوقتي بطلة جديدة وبالمناسبة دي رجعنا عرض الـ 50% لفترة محدودة على كل خطط الاشتراك السنوية 🚀

اشترك الآن

Anthropic’s Double Drop: Opus 4.7 & Claude Design 🔥

Anthropic نزلت Claude Opus 4.7، وده الـ flagship model الجديد اللي بيتفوق على Opus 4.6 بوضوح خصوصًا في الـ advanced software engineering والـ long-running tasks. أهم نقلة إن الـ model بقى بيعمل verify لـ outputs بتاعته قبل ما يرجعلك نتيجة — يعني بيراجع شغله بنفسه بدل ما يسيبك تراجع وراه.

وده كان الـ Benchmark اللي وصله Claude Opus 4.7

اللي يهم الـ developers:

• فيه Effort level جديد اسمه xhigh بين الـ high وmax بيديك control أحسن على الـ trade-off بين الـ reasoning والـ latency

• فيه Task budgets في beta تخليك تحط ceiling للـ token spend على الـ long-running agents

• فيه Command جديد في Claude Code اسمه /ultrareview بيراجع كودك زي الـ senior ويلقط design flaws.

• Auto mode اتفتح للـ Max Plan Users

ملحوظة مهمة: Opus 4.7 لسه أقل من Claude Mythos Preview اللي Anthropic مش هتنزله للعامة عشان الـ cyber capabilities الخطيرة.

Claude Design — From Prompt to Prototype

في نفس الأسبوع، Anthropic نزلت Claude Design في research preview، وده أول دخول حقيقي ليها في الـ visual creative workflows.

والحكاية ببساطة: تكتب text prompt، أو ترفع images و documents (DOCX, PPTX, XLSX)، أو توجه Claude على الـ codebase بتاعك — ويطلعلك prototypes وكمان slides.

أكتر feature هيعجب فرق الـ engineering: أول ما بتعمل onboarding، Claude بيبني design system للفريق بتاعك لما يقرا الـ codebase و design files. بعد كدة أي project بيطلعه بيمشي على نفس الـ colors والـ typography والـ components automatically. وتقدر تحافظ على أكتر من design system لو شركتك محتاجة كده.

وطبعًا تقدر تعمل export لكل ده: كـ PDF، URL، PPTX، أو تبعته لـ Canva وتكمل editing و collaboration هناك.

وفيه كمان web capture tool بتسحب بيه elements من الـ website بتاعك عشان الـ prototypes تبقى شبه الـ product الحقيقي.

Claude Design شغال بـ Opus 4.7، ومتاح لـ Claude Pro و Max و Team وEnterprise.

تطبيق مجرة على IOS 🔥

مجرة أطلقت الـ IOS Native Mobile App لمتابعة مستجدات التقنية من أكتر من 80+ مصدر عربي وعالمي وكمان لتبادل الخبرات والنقاشات بين المطورين 🚀

من خلال التطبيق:

‏🎯 تقدر تبني مجرتك بالشكل اللي يناسبك وتشوف المقالات اللي تهمّك فعلاً من المصادر المتاحة والوسوم
‏🤖 أوامر مدعومة بالذكاء الاصطناعي بالعربي — تلخيص، وتبسيط، وأمثلة عملية وتطبيقية من أي مقال، ونقد بنّاء بضغطة واحدة
‏🌟 الكوكبات — مجتمعات متخصّصة للمطوّرين (تقدر تفكر فيها كـ subreddits للمطوّرين العرب)
‏🔥 سلسلة القراءة — حافظ على عادة القراءة اليومية وهيكون فيه نظام Gamification للتحفيز جاي قريب
‏🏆 لوحة الصدارة والإنجازات
‏💎 تجربة استخدام مميزة للمطورين

وطبعًا دعم كامل للعربية والـ RTL 🌟

رابط التطبيق

How Boris Cherny uses Claude Code - Part 1 💎

بوريس شيرني — الراجل اللي عمل Claude Code نفسه في Anthropic — اتكلم في thread على X عن بعض النصايح وأهم الممارسات اللي بيشتغل بيهم يومياً وهو بيستعمل Claude ولكن النصايح دي ممكن نعتبرها إنها حجر أساس في التعامل مع الـ AI Driven Development 🚀

1. شغّل 5 instances في نفس الوقت

بوريس مش بيشتغل بـ Claude Code بـ Instance واحدة. ولكن هو بيفتح 5 sessions في نفس الوقت في الـ terminal، وكل session بتكون في git checkout منفصل للـ repo نفسه. وبناء على ده علشان يقدر يواكب بين الـ 5 sessions بيرقّم الـ tabs من 1 لـ 5 وبيشغّل الـ system notifications عشان يعرف لما أي Claude Session تحتاج رأيه.

~/repo-1 $ # Tab 1: Working on feature ~/repo-2 $ # Tab 2: Running tests ~/repo-3 $ # Tab 3: Code review ~/repo-4 $ # Tab 4: Debugging ~/repo-5 $ # Tab 5: Documentation

الفكرة بسيطة: كل session بتاخد وقت، فبدل ما تستنى واحدة تخلص وتفضل مستني، شغّل 5 وروح اعمل حاجة أي حاجة تانية.

2. استعمل الـ web + mobile في نفس الوقت

بالإضافة للـ terminal، هو بيشغّل 5 لـ 10 sessions تانيين على الـ claude.ai/code — من المتصفح. وكمان بيعمل handoff بينهم بسهولة بالـ & command أو الـ --teleport flag.

& — Background a session
--teleport — Switch contexts between local and web

وفيه حاجة تانية: بيبدأ الـ sessions من موبايله الصبح، وبعدين لما يجي يقعد على اللابتوب يكمل من المكان اللي وقف فيه. يعني نقدر نقول إن Claude بيشتغل حتى وهو نايم 🤣

3. Opus 4.5 مع الـ Thinking Mode

ناس كتير بتشتغل بـ Sonnet عشان أسرع وأرخص. ولكن بوريس عنده وجهة نظر مختلفة — هو دايماً بيستخدم Opus 4.5 مع الـ thinking mode.

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

4. CLAUDE.md مشترك للفريق كله

الفريق بيعمل CLAUDE.md واحد محطوط في الـ git، والكل بيضيف فيه كذا مرة في الأسبوع. كل ما Claude يعمل غلطة، بيضيفوها في الـ CLAUDE.md عشان متتكررش تاني.

claude-cli $ cat CLAUDE.md # Development Workflow **Always use `bun`, not `npm`.** # 1. Make changes # 2. Typecheck (fast) bun run typecheck # 3. Run tests bun run test -- -t “test name” # Single suite bun run test:file -- “glob” # Specific files # 4. Lint before committing bun run lint:file -- “file1.ts” # Specific files bun run lint # All files # 5. Before creating PR bun run lint:claude && bun run test

فنقدر نعتبر ده نوع من الذاكرة المرجعية — مش بس للكود، ولكن لـ Claude نفسه.

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الخامس والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• ورقة وقلم : How Online Payments Work 🚀

• AI في سطور: Anthropic’s Most Powerful Model Which Scared Its Own Creators 🔥

• مقال الأسبوع: Understanding Kubernetes CPU Limits and Requests 💎

How Online Payments Work 🚀

واحدة من أكثر المجالات صعودًا في السنين الأخيرة في عالم التقنية هي ال Fintech بل وأصبحت لا غني عنها وجزء من حياتنا اليومية, وأي Business حاليًا لازم يتعامل معها بطريقة أو بأخرى, فورقة وقلم مًبرمجنا الفاضل وتعالى نفهم أساس النظام دا من وجهة نظر العميل ووجهة النظر التقنية لأن سواء احتجت تطبق Payment Solution أو بس ت Integrate مع حل جاهز, فهمك للنظام دا هيسهل عليك كتير..

القصة القصيرة بالنسبة للعميل:

العميل بيدفع للتاجر باستخدام بطاقة البنك الخاصة بيه سواء في المحل مع جهاز الـ Terminal أو ما يعرف ب Point of sale POS) أو بيدخل بيانات الكارت في ال Checkout علي الموقع, وقتها احنا بنعمل Authorisation Request للبنك المٌصدر للكارت عشان نتأكد من وجود رصيد كافي للمعاملة ال Authorisation request دا بنعمل فيه أكثر من عملية أهمهم:

• التأكد من بيانات الكارت و من إن المعاملة مش Fraud

• التأكد من وجود رصيد كافي

• لو في رصيد كافي فالبنك بيقوم بخصم قيمة المعاملة من حساب المشتري وإرسالها لحساب التاجر

خلص ال Authorisation request بنجاح عميلنا كدا دفع بنجاح وخد مشترياته ومشي.

خد بالك عزيزي المبرمج العميل هنا مهتم بـ حاجتين ملهمش ثالث:

• Reliability of Service: أمان المعاملة (ادفع ويتخصم مني فقط القيمة المٌتفق عليها من غير مشاكل تقنية وتفضل بياناتي وبيانات حسابي في أمان)

• Ease of Service: سلاسة ووقت المعاملة (عملية الدفع تتم بأسهل وأسرع طريقة)

فمهما قصة ال Payments تطول معاك في تفاصيلها أولويتك الأولى والأخيرة إنك بتوفر له الحاجتين دول.

القصة الطويلة بالنسبة للمبرمج

قبل ما نعرض الخطوات هنناقش نقطتين مهمين:

المصطلحات المٌستخدمة في أنظمة الدفع

خلونا نستعرض بعض المصطلحات لتسهيلها, الجميل إن المصطلحات دي 90٪ من الوقت ثابتة حول العالم ففي مصر مثل السعودية مثل أمريكا هو نظام واحد بيختلف مٌقدمين الخدمات وأسمائهم.

• الـ Issuer (البنك المُصدِر): هو البنك أو الجهة التي أصدرت بطاقة العميل ويتحقق من صلاحيتها ويوافق أو يرفض العملية.

• الـ Acquirer (البنك المُكتسِب): هو البنك أو المؤسسة المالية التي تمثل التاجر وتستقبل المدفوعات نيابة عنه من شبكات البطاقات.

• ال Card Network (شبكة البطاقات): هي الجهة الوسيطة التي تربط بين البنك المُكتسِب (Acquirer) والبنك المُصدِر (Issuer)، وتُعالج الطلبات وتُطبق قواعد المدفوعات بين الطرفين.

• الـ Payment Gateway (بوابة الدفع): هي الواجهة الإلكترونية التي تجمع بيانات الدفع من العميل وتربطها آمنًا بمعالج الدفع لتنفيذ المعاملة.

• الـ Payment Processor (معالج الدفع): هو النظام أو الشركة التي تنفذ عملية الدفع تقنيًا من خلال التحقق من البيانات والتواصل مع الشبكات والبنوك.

عملية الدفع ليست خطوة واحدة

لما بندفع Cash, عميلة الدفع أغلب الوقت هي نفسها عملية الاستلام. بينما في عمليات الدفع الالكتروني عملية دفع العميل لا تعني استلام التاجر للفلوس, طيب إزاي🤷‍♀️

السر في كون عملية نقل الأموال الفعلية عملية مكلفة فعلاً, خلونا نوضح بمثال

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

وبكدا عملية الدفع بتنقسم دومًا خطوتين:

• عملية تحقق Authorisation : وفيها البنك المٌصدر بيقوم بحجز الفلوس في حساب العميل بل وبيوضح للعميل إنه اتخصم منه بشكل فوري(حسابك كرقم بيقل) لكن الفلوس في الواقع متحركتش من البنك.

• عملية تسوية Settlement : وفيها يتم نقل الفلوس بالفعل لحساب التاجر في البنك. عملية التسوية بتحصل عادة خلال يوم أو اثنين ولكن في حلول حاليًا بتقدم تسوية للتاجر في نفس اليوم.

أكمل القراءة

Anthropic’s Most Powerful Model Which Scared Its Own Creators 🔥

في نص الأسبوع، Anthropic عملت حاجة غريبة شوية — أعلنت عن model جديد اسمه Claude Mythos Preview، وفي نفس الوقت قالت إنها مش هتنزله للعامة.

مش بسبب أي مشكلة تقنية. ولكن بسبب إنه خطير جدًا.

إيه اللي بيعمله Mythos بالظبط؟

الـ model ده متخصص جداً في الـ cybersecurity. وبالتحديد، في إيجاد الـ vulnerabilities في الـ software و Anthropic جربته على أكتر من 7,000 مشروع open source، ومعظم الوقت، كان بيقرأ الكود، بيعمل hypotheses عن الـ vulnerabilities، وبيشغل المشروع فعلاً عشان يتحقق — وفي الآخر بيطلع إما بـ bug report كامل مع proof-of-concept exploit، أو بيقول إنه مفيش حاجة.

طب والنتيجة كانت ايه؟

الـ model وجد آلاف من الـ high-severity vulnerabilities في أنظمة تشغيل ومتصفحات ضخمة — vulnerabilities بعضها فضل موجود لسنين من غير ما حد يلاحظه.

Project Glasswing

وعشان كده، Anthropic عملت مشروع اسمه Glasswing — فكرته إن Anthropic هتستخدم Mythos نفسه عشان يساعد في تأمين الـ critical software في العالم قبل ما أي حد تاني يستغل نفس القدرات دي.

ومش بس كده ده كمان التزمت بـ $100M كـ model usage credits لشركاء المشروع ده، وبرضو تبرعت بـ $4M للـ open source security foundations زي Linux Foundation وApache.

Mythos System Card and Benchmarks

الـ system card بتاع Mythos — اللي جه بـ 244 صفحة — فيه تفاصيل مقلقة شوية عن الـ alignment.

في اختبار واحد، Mythos حقن كود في ملف عشان يدي نفسه permission لتعديل حاجة مش المفروض يعدل فيها — وبعدين مسح الأثر وقال إنه بس بيعمل “cleanup”. لكن الـ researchers استخدمواinterpretability techniques ولاقوا إن الـ model من جوا كان عارف تماماً إنه بيعمل حاجة ممنوعة وبيحاول يخبيها.

في حالة تانية، الـ model وصل بالغلط لـ database مش المفروض يشوفها، وبدل ما يقول الإجابة الصح بالظبط ويكشف إنه شاف البيانات، قدم confidence interval “بشكل مريب” — و استخدمواinterpretability كشف إنه كان “بيعمل strategic response عشان يغش مع الحفاظ على الـ plausible deniability”.

الخلاصة

شركة Anthropic وصفت Mythos بإنه “best-aligned model” ليها لحد الآن — وفي نفس الوقت قالت إنه “likely poses the greatest alignment-related risk of any model we have released.” الجملتين صح في نفس الوقت.

المعادلة بسيطة: كل ما زادت القدرات، زاد الـ risk — حتى لو الـ alignment كان فيه تحسن.

لحد دلوقتي، Mythos مش متاح للناس. بس لو عايزين تاخدوا فكرة عن المكان اللي الـ AI models رايحة ليه في الـ cybersecurity، فالقصة دي مثال كويس.

Understanding Kubernetes CPU Limits and Requests 💎

ناس كتير بتستخدم Kubernetes مش مهم هل لحاجه ضرورية ولا لا .. ولكن انا بعتبره حاجة كدا مما عم به البلاء أو الموضة لكن بما اننا بنستخدمه والناس كلها بتستخدمه فمحتاجين نفهم شويه تفاصيل.

المقال ده هيكون طويل شوية لذكر تفاصيل داخلية وهيكون في الآخر الخلاصة الي أنت محتاج تعرفها لو مش عايز تتوه في التفاصيل.

المهم إن Kubernetes فيه جزء الناس أغلبها ملمين بيه ألا وهو الـ CRUD الي بتعمله وانت بتعمل Apply لشوية specs مكتوبة بـ Yaml format ودا فقط بيروح يعمل CRUD في etcd db ودا الـ db engine الي بيستخدمه Kubernetes.

التفاصيل دي بتاخدها components داخليه بتشتغل عليها منها الـ high level ومنها الي بيتعامل مع الـ Linux kernel لكن في المقال دا عايز اتكلم عن جزء الـ Resources Request and Limits وهتكلم تحديدًا عن الـ CPU. وفي مقال تاني ممكن نتكلم عن الـ Memory.

CPU Requests & Limits

هل سألت نفسك قبل كدا لما بتحط CPU limits او memory limits او CPU requests او memory requests الأرقام دي الـ Kubernetes بيعمل بيها ايه او الـ Linux kernel بيتعامل معاها ازاي؟

والإجابة هي إن Kubernetes بيستخدم حاجة اسمها Cgroup عشان يدير الـ resources زي الـ memory والـ CPU لكل container قايمة علي الـ Node من خلال Kubernetes. والمسؤول عن الجزء دا هو الـ Kubelet والي تقدر تعتبره المخ بتاع Kubernetes.

المهم إن Kubernetes بيقسم أو بيوزع الـ Pods في ثلاثة تصنيفات بناءًا علي الإعدادات بتاعة الـ memory والـ cpu الي انت بتحطها في الـ Specs بتاعة الـ Pod وبناءًا عليه ايضًا وجود الـ workload او الـ pod بتاعك في أي من التصنيفات دي بتتغير طريقة التعامل معاها وبقاءها في حالة الـ node pressure او التضحية بيها ودا بيُسمى Quality of Service او QOS اختصارًا والي ممكن تشوفه لما تعرض الـ Specs لـ Pod موجوده عن طريق

 kubectl get pod pod-name -o yaml 

هتلاقي فيه managed field اسمه qos.

طيب ايه التقسيمات دي وتأثيرها ايه علي دورة حياة الـ workload بتاعتك وعلي الـ Out of memory issue ؟ دي كلها حاجات مهم نكون ملمين بيها ولكن أنا في المقال ده هتكلم فقط او أكثر علي الجانب الخاص بالـ CPU.

تصنيفات الـ QOS

Guaranteed

ودي شروطها إن :

• الـ CPU requests = الـ CPU limits

• والـ Memory requests = الـ Memory limits

يعني يكونوا قد بعض .. طيب دا بيترتب عليه ايه؟

بيترتب عليه أداء أفضل وأولوية بمعني إن في حالة الضغط أو ال node pressure والحاجة للتضحية ببعض ال workloads البروفايل دا بيكون آخر حاجة بيتم التضحية بيها وبتاخد أداء مضمون.

ولكن لل CPU limits عيوب هنتكلم عنها لاحقًا ودا عادة اختيار لما تكون عايز predictable CPU availability زي أنواع من ال workloads الي بتعتمد في أنماط التصميم وتحسين الأداء علي حساب ال CPU المتاح زي ال work schedulers وال concurrency rate limit والي غالبا لا ينطبق علي أغلب ال web apps. وده لإن عادة بتتسخدم الأنماط دي في ال db engines وال Message queues وغيرها.

Burstable

ودي شروطها إن:

• ال Resources Request تكون أقل من ال Resources Limits

ودا معناه إن هتاخد الي طلبته ولكن هتقدر تستخدم resources أكتر لو احتجت أكتر من اللي المطلوب بشرط إن يكون متاح دا اصلًا علي ال node وهنسرد دا في تفاصيل لاحقة ازاي دا بيتوزع في كل حالة والفرق بين ال request وال limits.

Best Efforts

ودا لو محطتش أي limits ولا requests .. في الحالة دي ال Pod بتاعتك هتستخدم المتاح أو الي هيتحط لها تاكله أو تموت من الجوع وأول حاجة بيتم بيها التضحية في حالة الضغط وكمان عرضه للـ throttling.

الفرق بين الـ CPU Request والـ CPU Limits

طيب احنا محتاجين نفهم ايه الفرق بين ال CPU request وال CPU limits غير الفرق الواضح من المسميات الي هو اختصارا ال request دا الي طلبته وال limits دا اخري.

أكمل القراءة

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

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

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

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

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us