Microsoft Build 2026 والتحول الهادئ إلى التطوير agent-native

spinny:~/writing $ vim microsoft-build-2026-agent-native-development.md

1~
2كان لدى Microsoft Build 2026 رسالة جانبية واضحة جدا: المرحلة التالية من وكلاء البرمجيات ليست صندوق دردشة أجمل. الفكرة أن نعطي الوكيل مكتبا، وقائمة تحقق، وsandbox، وشخصا مسؤولا عنه.
3~
4الإشارات الرسمية جاءت من [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)، ومن مقال Microsoft [AI alone won't change your business. The system running it will](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)، ومن إعلان GitHub عن [GitHub Copilot app](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/). عند قراءتها معا، تظهر نفس الفكرة: الوكلاء يدخلون نظام التطوير نفسه، لا يبقون إضافة بجانب المحرر.
5~
6## الجزء المفيد ممل، وهذا جيد
7~
8وكيل يكتب patch شيء مثير. لكن الوكيل الذي يعمل داخل worktree معزول، يشغل checks، يحتفظ بtrace واضح، يفتح pull request، ويتوقف عند بوابة الموافقة الصحيحة، هو الأكثر فائدة.
9~
10هذا هو التحول الذي أراه في Build 2026. سحر أقل. نموذج تشغيل أكثر.
11~
12تبدو GitHub Copilot app كغرفة تحكم لعمل الوكلاء: sessions، repositories، issues، pull requests، ومهام متوازية في مكان واحد. التفصيل الذي يعجبني هو worktrees. كل محاولة تعيش في مساحة خاصة، ويمكن مقارنتها أو حذفها أو ترقيتها من دون إفساد ملفاتك.
13~
14## Sandboxes ليست تفصيلا جانبيا
15~
16إذا كان الوكيل يستطيع تشغيل الكود، فهو يحتاج مكانا آمنا لكي يخطئ. هنا تظهر أهمية sandboxes، سواء محلية أو في السحابة. يمكنه التجربة من دون تحويل جهازك أو production إلى مختبر.
17~
18هذا ليس براقا، لكنه الفرق بين demo وworkflow. الوكيل الجيد يشغل tests، يقرأ failures، يحاول مرة أخرى، ويعرض ما تغير. وفي الوقت نفسه يجب أن يكون محدودا بما يكفي حتى تبقى الأخطاء صغيرة.
19~
20## Foundry وAgent Framework يتحدثان لغة الإنتاج
21~
22تحديثات Foundry وMicrosoft Agent Framework هي النسخة المؤسسية من القصة نفسها. Hosted agents، toolboxes، tracing، evaluation، memory، middleware وagent controls تبدو كلمات بنية تحتية. هي كذلك. ولذلك هي مهمة.
23~
24عندما تبني الشركة عددا كبيرا من الوكلاء، لا يعود السؤال هل نستطيع بناء واحد. يصبح السؤال: من يملكه، ماذا يستطيع الوصول إليه، كيف نقيمه، كيف نعرف أنه يتحسن، وكيف نوقفه؟
25~
26## المراجعة تصبح عنق الزجاجة
27~
28فخ agentic development هو الاعتقاد أن المزيد من الوكلاء يعني تلقائيا المزيد من العمل المنشور. قد يعني فقط المزيد من pull requests أمام مراجعين مرهقين.
29~
30سأقيس التبني بثلاثة أشياء: هل يوفر وقت المراجعين أم يستهلكه، كم مرة تمر التغييرات generated checks من دون رعاية، وهل يشرح trace المنطق بما يكفي للثقة في diff.
31~
32إذا كان على reviewer إعادة بناء كل شيء من الصفر، فالworkflow لم يكتمل. العبء انتقل فقط.
33~
34## من أين أبدأ
35~
36أبدأ بمهام مملة ومحدودة: تحديث dependencies، إصلاح tests، refactors صغيرة، متابعة تعليقات review، release notes، وmigrations لديها tests قوية.
37~
38لكل مهمة أريد isolation، checks، trace، وقرار merge بشري. الوكيل يقوم بالعمل المتكرر. الفريق يظل مالك النتيجة.
39~
40## قراءتي
41~
42Build 2026 جعل agent-native development يبدو أقل كشعار وأكثر كمشكلة تشغيل. الفرق الأفضل لن تكون التي تترك كل شيء للوكلاء، بل التي تصمم نظاما يسمح لهم بالتقدم من دون إخفاء الأثر.
43~
44## المصادر
45~
46- [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)
47- [Microsoft: AI alone won't change your business](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)
48- [GitHub: Copilot app, the agent-native desktop experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/)
49~

NORMAL · microsoft-build-2026-agent-native-development.md [readonly]49 lines · :q to close

2كان لدى Microsoft Build 2026 رسالة جانبية واضحة جدا: المرحلة التالية من وكلاء البرمجيات ليست صندوق دردشة أجمل. الفكرة أن نعطي الوكيل مكتبا، وقائمة تحقق، وsandbox، وشخصا مسؤولا عنه.

4الإشارات الرسمية جاءت من [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)، ومن مقال Microsoft [AI alone won't change your business. The system running it will](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)، ومن إعلان GitHub عن [GitHub Copilot app](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/). عند قراءتها معا، تظهر نفس الفكرة: الوكلاء يدخلون نظام التطوير نفسه، لا يبقون إضافة بجانب المحرر.

6## الجزء المفيد ممل، وهذا جيد

8وكيل يكتب patch شيء مثير. لكن الوكيل الذي يعمل داخل worktree معزول، يشغل checks، يحتفظ بtrace واضح، يفتح pull request، ويتوقف عند بوابة الموافقة الصحيحة، هو الأكثر فائدة.

10هذا هو التحول الذي أراه في Build 2026. سحر أقل. نموذج تشغيل أكثر.

11~

12تبدو GitHub Copilot app كغرفة تحكم لعمل الوكلاء: sessions، repositories، issues، pull requests، ومهام متوازية في مكان واحد. التفصيل الذي يعجبني هو worktrees. كل محاولة تعيش في مساحة خاصة، ويمكن مقارنتها أو حذفها أو ترقيتها من دون إفساد ملفاتك.

13~

14## Sandboxes ليست تفصيلا جانبيا

15~

16إذا كان الوكيل يستطيع تشغيل الكود، فهو يحتاج مكانا آمنا لكي يخطئ. هنا تظهر أهمية sandboxes، سواء محلية أو في السحابة. يمكنه التجربة من دون تحويل جهازك أو production إلى مختبر.

17~

18هذا ليس براقا، لكنه الفرق بين demo وworkflow. الوكيل الجيد يشغل tests، يقرأ failures، يحاول مرة أخرى، ويعرض ما تغير. وفي الوقت نفسه يجب أن يكون محدودا بما يكفي حتى تبقى الأخطاء صغيرة.

19~

20## Foundry وAgent Framework يتحدثان لغة الإنتاج

21~

22تحديثات Foundry وMicrosoft Agent Framework هي النسخة المؤسسية من القصة نفسها. Hosted agents، toolboxes، tracing، evaluation، memory، middleware وagent controls تبدو كلمات بنية تحتية. هي كذلك. ولذلك هي مهمة.

23~

24عندما تبني الشركة عددا كبيرا من الوكلاء، لا يعود السؤال هل نستطيع بناء واحد. يصبح السؤال: من يملكه، ماذا يستطيع الوصول إليه، كيف نقيمه، كيف نعرف أنه يتحسن، وكيف نوقفه؟

25~

26## المراجعة تصبح عنق الزجاجة

27~

28فخ agentic development هو الاعتقاد أن المزيد من الوكلاء يعني تلقائيا المزيد من العمل المنشور. قد يعني فقط المزيد من pull requests أمام مراجعين مرهقين.

29~

30سأقيس التبني بثلاثة أشياء: هل يوفر وقت المراجعين أم يستهلكه، كم مرة تمر التغييرات generated checks من دون رعاية، وهل يشرح trace المنطق بما يكفي للثقة في diff.

31~

32إذا كان على reviewer إعادة بناء كل شيء من الصفر، فالworkflow لم يكتمل. العبء انتقل فقط.

33~

34## من أين أبدأ

35~

36أبدأ بمهام مملة ومحدودة: تحديث dependencies، إصلاح tests، refactors صغيرة، متابعة تعليقات review، release notes، وmigrations لديها tests قوية.

37~

38لكل مهمة أريد isolation، checks، trace، وقرار merge بشري. الوكيل يقوم بالعمل المتكرر. الفريق يظل مالك النتيجة.

39~

40## قراءتي

41~

42Build 2026 جعل agent-native development يبدو أقل كشعار وأكثر كمشكلة تشغيل. الفرق الأفضل لن تكون التي تترك كل شيء للوكلاء، بل التي تصمم نظاما يسمح لهم بالتقدم من دون إخفاء الأثر.

43~

44## المصادر

45~

46- [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)

47- [Microsoft: AI alone won't change your business](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)

48- [GitHub: Copilot app, the agent-native desktop experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/)

49~