واحدة من أكثر المشاكل شيوعًا مع كود السحابة المولد بالذكاء الاصطناعي هي أنه يبدو معقولاً بينما لا يزال متأخراً قليلاً عن الواقع.
الكود يترجم. الدالة تنشر. النموذج يبدو جيدًا.
ثم تلاحظ التفاصيل:
- نماذج برمجية قديمة
- أسرار مشفرة في المشروع
- خيارات توسع ضعيفة
- عدم وجود تصميم قائم على الهوية أولاً
- نقص التحقق قبل النشر
لهذا السبب تبدو azure-functions-skills مفيدة لي.
المعاينة ليست مجرد مساعد بناء آخر. إنها تحاول حل مشكلة أكثر أهمية بكثير: جعل وكلاء البرمجة ينتجون حلول Azure Functions حالية وآمنة افتراضيًا بدلاً من مسودات أولية لائقة المظهر لكنها متقادمة تشغيليًا.
المقال المصدر صريح بشكل منعش حول نمط الفشل
جزء واحد من المقال الأصلي يعجبني حقًا هو مدى صراحته بشأن المشكلة.
يقول إن الوكلاء العامين غالبًا ما “يتركون مفاتيح مشفرة وسلاسل اتصال وأسرار أخرى في دالتك لتنظيفها لاحقًا”.
هذا هو بالضبط نوع الجملة التي أريدها في مقال كهذا.
لأنه يسمي المشكلة الحقيقية بدلاً من التظاهر بأن الفجوة صغيرة.
هذا ليس حول ما إذا كان الوكلاء يمكنهم كتابة كود على الإطلاق. يمكنهم.
إنه حول ما إذا كان يمكنهم كتابة كود Azure سليم للإنتاج.
هذا معيار مختلف.
القيمة الحقيقية هي تعليم الوكيل عادات أفضل
ما لفت انتباهي ليس مجرد أمر التثبيت أو كتالوج المهارات.
إنها فكرة أن الإضافة تعطي الوكيل:
- أنماط Azure Functions الحالية
- إعدادات افتراضية للهوية المدارة
- إرشادات Flex Consumption
- تكامل قالب Azure MCP
- مهارات النشر والتحقق
- فحص “doctor” قبل الشحن
هذا مهم لأن الكثير من إخفاقات برمجة AI تحدث في الفجوة بين توليد الكود العام و الصحة الخاصة بالمنصة.
وتلك الفجوة هي حيث تخسر الفرق الوقت.
لماذا هذا التوقيت مناسب
مع استخدام المزيد من الفرق لـ GitHub Copilot CLI و Claude Code و VS Code وتدفقات مماثلة لبناء تطبيقات سحابية، القطعة المفقودة غالبًا ليست توليد الكود الخام.
إنه السياق.
بشكل أكثر تحديدًا:
- ما هو نموذج الاستضافة الحالي؟
- ما هي قصة المصادقة المفضلة؟
- ما الأنماط التي تتوسع على هذه المنصة؟
- ما الذي يجب التحقق منه قبل النشر؟
هذه هي بالضبط المجالات التي تبدأ فيها “مهارات الوكيل” بمعنى أكثر من مجرد رمي نموذج أكبر على المشكلة.
فكرة doctor ذكية بشكل خاص
إذا كان علي اختيار شيء واحد من الإعلان أعتقد أن الفرق ستقدره أكثر، فمن المحتمل أن يكون أمر doctor.
المقال المصدر يقول إن عيوب الكود وسوء التكوين تمثل “حوالي 53%” من حوادث دعم Azure Functions في تحليلهم الداخلي.
هذا الرقم مهم.
لأنه يعني أن فريق المنصة لا يخمن فقط أين يكمن الألم. إنهم يبنون حول نمط فشل ملموس جدًا.
وبصراحة، هذا هو نوع التفكير المنتج الذي أثق به أكثر:
- حدد أغلى الأخطاء المتكررة
- إكتشفها قبل النشر
- اجعل المسار الجيد أسهل من المسار السيء
هكذا تحسن تجربة المطور بطريقة هادفة.
ما زلت سأكون حذرًا بشأنه
على الرغم من أنني أحب الاتجاه كثيرًا، إلا أنني سأستمر في معاملة هذا كطبقة إنتاجية، وليس بديلاً عن الحكم الهندسي.
سأريد بالتأكيد من الفرق مراجعة:
- إعداد الهوية المولد
- أي افتراضات بنية تحتية
- خيارات الربط
- نموذج الأمان حول التخزين والطوابق والأسرار
- استخدام CI للتحقق من نمط
--deep
الخبر السار هو أن الأداة تبدو مصممة مع أخذ هذا الواقع في الاعتبار. إنها لا تخفي التحقق أو تدّعي أن الوكيل يعرف كل شيء. إنها تحاول إنشاء مسار آمن وموجه.
هذه نقطة بداية أفضل.
رأيي
هذا هو بالضبط نوع طبقة الأدوات التي أتوقع أن تصبح أكثر شيوعًا.
ليس لأن الوكلاء بحاجة إلى مزيد من الضجة، ولكن لأنهم بحاجة إلى قضبان أفضل عندما يستهدفون منصات حقيقية مثل Azure Functions.
أذكى جزء في هذه المعاينة هو أنها لا تساعد الوكلاء فقط في كتابة الكود. إنها تساعدهم في كتابة كود حالي، واعٍ بـ Azure، واعٍ بالهوية، واعٍ بالنشر.
هذا طموح أكثر فائدة بكثير.
وبالنسبة للفرق التي تبني أعباء عمل بدون خادم أو مدعومة بالوكلاء على Azure، هذا يجعل المعاينة تستحق المتابعة عن كثب.
المقال الأصلي: Introducing azure-functions-skills: An AI-Era Workspace for Azure Functions (Preview)
