تمت ترجمة هذه المقالة تلقائيًا. للنسخة الأصلية، انقر هنا.
أعتقد أن أحد أكثر التحولات فائدة في تبني Copilot هو الابتعاد عن الهوس بالميزات.
ولهذا السبب ينجح هذا الدليل الجديد الخاص بـ GitHub Copilot لمطوري .NET بهذه الصورة.
الفكرة الكبرى بسيطة: توقف عن السؤال عن وضع Copilot الأكثر إثارة، وابدأ بسؤال أي واجهة تناسب المهمة.
هذا هو النموذج الذهني الصحيح
في معظم أعمال .NET الحقيقية، السؤال ليس:
- دردشة أم وكيل؟
- Visual Studio أم CLI؟
- مضمّن أم سحابي؟
السؤال الأفضل هو:
- هل أحاول فهم الشيفرة؟
- هل أخطط لإعادة هيكلة؟
- هل أُحدث الاختبارات؟
- هل أصلح build مكسورًا؟
- هل أنسّق تغييرًا يمتد عبر عدة ملفات؟
هذه طريقة أكثر إنتاجية للعمل مع Copilot.
الجملة الأكثر فائدة في المقال الأصلي
السطر الذي كنت سأبرزه من المنشور الأصلي هو هذا:
“السؤال ليس أيّها هو الأكثر تقدمًا. السؤال الأفضل هو: أيّها يناسب المهمة التي أقوم بها الآن؟”
هذه بالضبط النصيحة التي كنت سأعطيها أيضًا.
لأن كثيرًا من ارتباك أدوات الذكاء الاصطناعي يأتي من التعامل مع الواجهات كأنها هويات، لا أدوات.
Visual Studio وVS Code وCLI والوكلاء الخلفيون كلٌّ منها يناسب لحظات مختلفة.
وما إن تتقبل ذلك، تصبح التجربة كلها أكثر عملية.
لماذا هذا مهم لفرق .NET تحديدًا
عمل .NET غالبًا ما يتوزع عبر عدة أنواع من المهام في اليوم الواحد:
- فهم خدمة قديمة
- تخطيط إعادة هيكلة
- توليد اختبارات
- إصلاح build معطّل
- التعامل مع الشيفرة والإعدادات والتوثيق والبنية التحتية معًا
هذا يعني أنه لا توجد واجهة Copilot واحدة ستكون الأفضل في كل شيء.
لذلك فالنصيحة في هذا الدليل جيدة لأنها تعكس كيف يحدث العمل فعليًا.
رأيي
هذا الدليل مفيد لأنه يعامل Copilot كجزء من حلقة تطوير .NET الفعلية بدلًا من كونه طبقة novelty فوقها.
وهذا يجعله ذا صلة.
وبصراحة، كان يمكن أن تتحسن كثير من إرشادات الذكاء الاصطناعي لو تبنت هذا التحول نفسه نحو التفكير القائم على المهمة أولًا.
المنشور الأصلي: Doing More with GitHub Copilot as a .NET Developer
