لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩
أهلًا وسهلًا بكم في العدد 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 حاجتين مهمين:
Skills فيها workflows وbest practices وknowledge متخصصة في AWS وطبعًا up-to-date.
و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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
