تُظهر هذه التجارب أن أدوات الذكاء الاصطناعي للبرمجة يمكنها تسريع العمل، لكنها تتطلب من المطورين توفير السياق، والتحقق من النتائج، وحماية قابلية الصيانة، والبقاء مسؤولين عن المنتج النهائي.
كيف يساهم GitHub Copilot في زيادة الإنتاجية؟
فلاد ميهالشا (Vlad Mihalcea)
قال فلاد ميهالشا إنه استخدم GitHub Copilot لتحليل وتصميم وتنفيذ ميزات مختلفة في كل من Hypersistence Utils و Hypersistence Optimizer. وأضاف أن مهمة تطوير تطبيق ويب لتاريخ أحداث Optimizer، والتي كانت ستستغرق أسابيع، استغرقت يومين فقط بفضل Copilot. وقال إنه يستخدم GitHub Copilot في IntelliJ IDEA لسهولة تشغيله أثناء مراجعة الكود أو جلسات التصحيح. وأوضح أنه لا يزال يراجع الخطط والكود الذي يولده الذكاء الاصطناعي، لأن الهدف هو تحسين إنتاجيته وليس استبداله بالكامل. وقال إنه طور مهارات تساعد الذكاء الاصطناعي على محاكاة ممارسات الكود الحالية. ونصح بتغيير نوع النموذج بناءً على نوع العملية، باستخدام Opus للمهام المعقدة ونماذج أخف للمهام البسيطة.
باتريك بومغارتنر (Patrick Baumgartner)
قال باتريك بومغارتنر إن الكثير من عمله يحدث بينما تستمر الأعمال العادية. وأكد أن الجزء المهم بالنسبة له هو العمل مع الفريق واتخاذ القرارات معًا، وعدم جعل الفريق يعتمد عليه. وأضاف أن أدوات الذكاء الاصطناعي الجديدة توفر أداة قوية أخرى لذلك. وذكر أن هجرة 900 شريحة تعليمية من Reveal.js إلى Marp كانت ستستغرق أسبوعًا أو أكثر يدويًا، لكنها استغرقت ثماني إلى عشر ساعات باستخدام Copilot. وأوضح أنه ظل مسؤولاً عن المحتوى والهدف التعليمي، بينما ساعد Copilot في الإصلاحات والتغييرات. وقال إن هذه التجربة عززت مبدأ "تفويض التنفيذ، لا المسؤولية".
وذكر بومغارتنر أنه استخدم Copilot لتحويل ملاحظات المستخدمين حول مشكلة في تطبيق واجهة المستخدم الطرفية (Tamboui) إلى اختبارات واجهة مستخدم قابلة للتكرار. وأشار إلى أنه طلب من Copilot مساعدته في إعادة تصميم طريقة تمثيل الاختبارات، حيث اقترح Copilot ترميزًا أكثر إيجازًا باستخدام الأسهم. كما ذكر أنه بحث مع Copilot في أساليب التعلم لتطوير تطبيق تعليمي للرياضيات، وأشار إلى أن Copilot تحدى أحد افتراضاته الأصلية خلال البحث، مما أدى إلى التركيز على سويسرا أولاً وجعل التطبيق متاحًا بأربع لغات. وقال إن هذه التجربة أظهرت له جانبًا آخر من Copilot: استخدامه كشريك للمناقشة لتوسيع وتحدي مساحة الحلول قبل البدء في البناء.
وأوضح بومغارتنر أنه لم يعد يستخدم تجربة الإكمال التلقائي الكلاسيكية لـ Copilot، وقال إن عمله انتقل بالكامل تقريبًا نحو سير العمل القائم على الوكلاء. وذكر أنه تمكن من توجيه الوكيل من هاتفه أثناء رحلة استغرقت أربع ساعات لإنشاء مكون إضافي لـ Maven، وعند وصوله، كان لديه مكون إضافي لـ Maven يعمل بالكامل.
فرانك ديلبورت (Frank Delporte)
ووصف GitHub Copilot بأنه رفيق مثالي لتقييم طلبات السحب والتحقيق في تقارير الأخطاء. وذكر أنه في فبراير 2026، أصدروا الإصدار V4 من مكتبة Pi4J، وأشار إلى أن مستخدمًا أبلغ عن مشكلة في الإصدار V4 حيث لا يعمل الزر الخامس من أصل خمسة أزرار إدخال كما هو متوقع. وقال إنه خصص المشكلة لوكيل Copilot للبرمجة، وبعد حوالي نصف ساعة، كان هناك طلب سحب مع تفسير غير متوقع.
وأوضح ديلبورت أن Copilot اكتشف أن المشكلة تكمن في أن كل مدخل يشغل مراقب أحداث يحظر في استدعاء poll() الأصلي، وأن سلاسل المحادثات الافتراضية التي تحظر داخل استدعاء أصلي لا يمكن فصلها عن سلاسل الناقل الخاصة بها. نظرًا لأن Raspberry Pi 4 يحتوي على أربع نوى، فإن جدولة السلاسل الافتراضية لديها أربع سلاسل ناقلة، وعند تسجيل أربعة مدخلات، يتم إيقاف جميع الناقلات الأربعة في poll() إلى الأبد، ولا يتم جدولة المراقب الخامس أبدًا. وقال إنه ترك تعليقًا يطلب من Copilot شرح ذلك بمزيد من التفصيل، وأشار إلى أن Copilot ربط استخدام Raspberry Pi ذي الأربع نوى بالمشكلة المقترحة وقدم حلاً بسيطًا.
ما هي أفضل الممارسات لاستخدام أدوات الذكاء الاصطناعي للبرمجة؟
يقدم الخبراء النصائح التالية:
- التوقف عن التوجيهات الفردية: أوصى باتريك بومغارتنر بالتوقف عن استخدام التوجيهات الفردية (one-shot prompting) للمهام غير البسيطة، وقال إنه غالبًا ما يطلب من الوكيل إجراء مقابلة معه أولاً للكشف عن الافتراضات والتوقعات الضمنية. وأشار إلى أن الدرس المستفاد هو أن "الالتفافات مكلفة. احصل على المتطلبات الصحيحة قبل التسريع."
- تحديد بوابات التحقق: المبدأ الثاني هو تحديد بوابات تحقق خاصة بالمهمة. وأوضح بومغارتنر أن "الانتهاء" لا يعني أن النموذج يقول إنه انتهى، بل يجب أن يكون الوكيل قادرًا على تقديم دليل على أن العمل يفي بتعريف الإنجاز.
- تحويل الدروس إلى مهارات قابلة لإعادة الاستخدام: المبدأ الثالث هو تحويل الدروس إلى مهارات قابلة لإعادة الاستخدام.
- وضع أدوات هندسية حتمية حول النموذج الاحتمالي: المبدأ الرابع هو وضع أدوات هندسية حتمية حول النموذج الاحتمالي. وذكر بومغارتنر أنه يستخدم أدوات فحص الجودة مثل Checkstyle و PMD لإنتاج تقرير موحد يمكن للوكيل استهلاكه. وقال إنه تعلم أن طلب كل شيء دفعة واحدة لأن "الذكاء الاصطناعي يمكنه فعل ذلك" عادة ما يكون فكرة سيئة.
وقال إنه يريد دائمًا الحفاظ على الكود قابلاً للقراءة والصيانة.
يرى باتريك بومغارتنر أن المطورين بحاجة إلى التحدث أكثر عن كيفية استخدامهم لهذه الأدوات، وأكد أن الملاحظات البشرية وفهم المنتج والسياق الواقعي تظل ضرورية. وقال إنه لا يعتقد أن طلاب هندسة البرمجيات يجب أن يطمحوا في المقام الأول ليصبحوا آلات لإنتاج الكود، بل يجب أن يصبحوا حلّالين أقوياء للمشكلات. وأوضح أنه يريد أن يظل مسؤولاً عن تشكيل الحل ويترك للوكيل تولي المزيد من التنفيذ. ويرى أن الذكاء الاصطناعي يعيد "الهندسة" إلى هندسة البرمجيات.
