Microsoft Build 2026 والتحول الهادئ إلى التطوير agent-native
· 2 min read · Filippo Spinella · AI, GitHub Copilot, Microsoft Build, Developer Tools
كان لدى Microsoft Build 2026 رسالة جانبية واضحة جدا: المرحلة التالية من وكلاء البرمجيات ليست صندوق دردشة أجمل. الفكرة أن نعطي الوكيل مكتبا، وقائمة تحقق، وsandbox، وشخصا مسؤولا عنه.
الإشارات الرسمية جاءت من Microsoft Build 2026 live blog، ومن مقال Microsoft AI alone won't change your business. The system running it will، ومن إعلان GitHub عن GitHub Copilot app. عند قراءتها معا، تظهر نفس الفكرة: الوكلاء يدخلون نظام التطوير نفسه، لا يبقون إضافة بجانب المحرر.
الجزء المفيد ممل، وهذا جيد
وكيل يكتب patch شيء مثير. لكن الوكيل الذي يعمل داخل worktree معزول، يشغل checks، يحتفظ بtrace واضح، يفتح pull request، ويتوقف عند بوابة الموافقة الصحيحة، هو الأكثر فائدة.
هذا هو التحول الذي أراه في Build 2026. سحر أقل. نموذج تشغيل أكثر.
تبدو GitHub Copilot app كغرفة تحكم لعمل الوكلاء: sessions، repositories، issues، pull requests، ومهام متوازية في مكان واحد. التفصيل الذي يعجبني هو worktrees. كل محاولة تعيش في مساحة خاصة، ويمكن مقارنتها أو حذفها أو ترقيتها من دون إفساد ملفاتك.
Sandboxes ليست تفصيلا جانبيا
إذا كان الوكيل يستطيع تشغيل الكود، فهو يحتاج مكانا آمنا لكي يخطئ. هنا تظهر أهمية sandboxes، سواء محلية أو في السحابة. يمكنه التجربة من دون تحويل جهازك أو production إلى مختبر.
هذا ليس براقا، لكنه الفرق بين demo وworkflow. الوكيل الجيد يشغل tests، يقرأ failures، يحاول مرة أخرى، ويعرض ما تغير. وفي الوقت نفسه يجب أن يكون محدودا بما يكفي حتى تبقى الأخطاء صغيرة.
Foundry وAgent Framework يتحدثان لغة الإنتاج
تحديثات Foundry وMicrosoft Agent Framework هي النسخة المؤسسية من القصة نفسها. Hosted agents، toolboxes، tracing، evaluation، memory، middleware وagent controls تبدو كلمات بنية تحتية. هي كذلك. ولذلك هي مهمة.
عندما تبني الشركة عددا كبيرا من الوكلاء، لا يعود السؤال هل نستطيع بناء واحد. يصبح السؤال: من يملكه، ماذا يستطيع الوصول إليه، كيف نقيمه، كيف نعرف أنه يتحسن، وكيف نوقفه؟
المراجعة تصبح عنق الزجاجة
فخ agentic development هو الاعتقاد أن المزيد من الوكلاء يعني تلقائيا المزيد من العمل المنشور. قد يعني فقط المزيد من pull requests أمام مراجعين مرهقين.
سأقيس التبني بثلاثة أشياء: هل يوفر وقت المراجعين أم يستهلكه، كم مرة تمر التغييرات generated checks من دون رعاية، وهل يشرح trace المنطق بما يكفي للثقة في diff.
إذا كان على reviewer إعادة بناء كل شيء من الصفر، فالworkflow لم يكتمل. العبء انتقل فقط.
من أين أبدأ
أبدأ بمهام مملة ومحدودة: تحديث dependencies، إصلاح tests، refactors صغيرة، متابعة تعليقات review، release notes، وmigrations لديها tests قوية.
لكل مهمة أريد isolation، checks، trace، وقرار merge بشري. الوكيل يقوم بالعمل المتكرر. الفريق يظل مالك النتيجة.
قراءتي
Build 2026 جعل agent-native development يبدو أقل كشعار وأكثر كمشكلة تشغيل. الفرق الأفضل لن تكون التي تترك كل شيء للوكلاء، بل التي تصمم نظاما يسمح لهم بالتقدم من دون إخفاء الأثر.