يا جماعة الخير، السلام عليكم ورحمة الله.
بتذكر قبل سنتين تقريباً، كنا شغالين على مشروع ضخم، نظام إدارة متكامل لشركة كبيرة. المشروع كان فيه كمية هائلة من “النماذج” (Models) و”وحدات التحكم” (Controllers) وواجهات برمجة التطبيقات (APIs). الوضع كان إنه كل يوم الصبح، بنفتح مهمات اليوم وبنلاقي قائمة طويلة من المهام المتشابهة بشكل قاتل: “إنشاء واجهة برمجة تطبيقات لإضافة منتج”، “إنشاء واجهة برمجة تطبيقات لتعديل منتج”، “إنشاء واجهة برمجة تطبيقات لحذف منتج”… وهكذا مع العملاء، الفواتير، والمستخدمين.
كنت أحس حالي أنا والفريق زي اللي بنسخ وبيلصق طول اليوم. بنفتح ملف قديم، بننسخ الكود، بنغير اسم المتغيرات، وبنعدل كم شغلة بسيطة. الشغل كان ممل لدرجة إنه الإبداع صار كلمة بنسمعها بس في الاجتماعات. بصراحة، كنا غرقانين في وحل الكود المتكرر، والتركيز على الصورة الكبيرة، على بنية النظام وجودته، كان شبه معدوم. كنا بنكتب كود، بس ما كنا “بنبني” برمجيات بالمعنى الحقيقي.
لحد ما يوم، واحد من الشباب في الفريق، شب صغير لسا متخرج جديد، حكالنا عن أداة اسمها GitHub Copilot. في البداية، كنت متشكك. أنا مبرمج من أيام “زمان”، وشايف كثير أدوات بتيجي وبتروح. قلت في بالي: “شو يعني؟ كمان أداة بتكمل الكود؟ زي الـ IntelliSense بس على أذكى شوي؟”. بس يا جماعة، لما جربته… كانت هاي هي اللحظة اللي تغير فيها كل شيء.
ما هو الـ Copilot، وكيف “بفهم” علينا؟
قبل ما ندخل في التفاصيل، خلوني أبسط الموضوع للي ما سمع عنه. الـ GitHub Copilot هو عبارة عن “مبرمج مساعد” يعتمد على الذكاء الاصطناعي، تم تطويره بالتعاون بين GitHub و OpenAI. هو مش مجرد أداة بتكمل اسم دالة (function) كتبتها غلط، لا أبداً.
تخيل معي إنه عندك زميل في الفريق، بس هالزميل قرأ تقريباً كل الكود المفتوح المصدر على كوكب الأرض. لما تيجي تكتب كود، هو بيكون قاعد جنبك، شايف شاشتك، وبفهم السياق اللي بتشتغل فيه. مجرد ما تكتب تعليق (comment) يوصف اللي بدك تعمله، أو تبدأ بكتابة اسم دالة، هو بيقترح عليك الكود كامل! مش بس سطر، ممكن يقترح دالة كاملة أو حتى كلاس (class) بأكمله.
هو “بفهم” علينا لأنه تدرب على مليارات الأسطر من الكود، وتعلم الأنماط (patterns) الشائعة في البرمجة. تعلم كيف المبرمجين بيكتبوا واجهات برمجة التطبيقات، وكيف بيتعاملوا مع قواعد البيانات، وكيف ببنوا واجهات المستخدم. باختصار، هو استخلص خبرة ملايين المبرمجين وحطها بين إيديك.
من التكرار الممل إلى الإبداع المحلّق: وقائع من الميدان
طيب، حكينا كثير نظري. خلونا نرجع للواقع ونشوف كيف هاي الأداة فعلاً غيرت طريقة شغلنا. هاي بعض الأمثلة الحقيقية من تجربتي وتجربة فريقي.
1. كتابة الكود النمطي (Boilerplate) في دقائق بدل ساعات
تتذكروا مشكلة الـ APIs المتكررة اللي حكيت عنها في البداية؟ هاي كانت أول شغلة الـ Copilot حلّها. صرنا بدل ما ننسخ ونلصق، نفتح ملف جديد ونكتب تعليق بسيط باللغة الإنجليزية:
// Express route to get a product by its ID from MongoDB
وبدون أي مبالغة، بمجرد الضغط على Enter، كان الـ Copilot يقترح الكود التالي كاملاً:
app.get('/api/products/:id', async (req, res) => {
try {
const product = await Product.findById(req.params.id);
if (!product) {
return res.status(404).json({ message: 'Product not found' });
}
res.status(200).json(product);
} catch (error) {
res.status(500).json({ message: 'Server error', error: error.message });
}
});
الكود مش بس صحيح، بل كان بيشمل معالجة الأخطاء (error handling) وحالات عدم وجود المنتج (not found case). شغلة كانت تاخد منا 10-15 دقيقة من النسخ والتعديل والتركيز، صارت تاخد 10 ثواني ومراجعة سريعة. تخيلوا كمية الوقت اللي توفرت لما يكون عندك 50 API endpoint بدك تبنيهم!
2. استكشاف التقنيات الجديدة والتعلم الفوري
من فترة، كان لازم نستخدم مكتبة جديدة لإنشاء الرسوم البيانية في واجهة المستخدم اسمها `Chart.js`. بدل ما أروح أفتح التوثيق الرسمي (Documentation) وأقعد أقرأ فيه ساعة زمن لأعرف كيف أبدأ، عملت إشي بسيط جداً. في ملف الجافاسكريبت الخاص بالمكون (component)، كتبت التعليق التالي:
// Create a bar chart using Chart.js with labels for months and data for sales
الـ Copilot أعطاني الهيكل الأساسي للكود مع بيانات وهمية. كل اللي عملته هو إني استبدلت البيانات الوهمية بالبيانات الحقيقية اللي جاياني من الـ API. خلال دقائق، كان الرسم البياني شغال قدامي. الأداة تحولت من مجرد مساعد كتابة إلى معلم شخصي وسريع.
3. كتابة الاختبارات (Tests) بلمح البصر
أغلب المبرمجين، وأنا منهم أحياناً، “بستثقلوا دم” كتابة الاختبارات الوحدوية (Unit Tests). مع إنها مهمة جداً لجودة الكود، بس بتضل عملية مكررة ومملة. هنا الـ Copilot عبقري.
لنفترض عندك دالة بسيطة زي هاي:
function calculateTotalPrice(items) {
if (!items || items.length === 0) {
return 0;
}
return items.reduce((total, item) => total + (item.price * item.quantity), 0);
}
كل اللي بعمله هو إني بروح على ملف الاختبار وبكتب تعليق:
// write unit tests for the calculateTotalPrice function
// test with an empty array
// test with a single item
// test with multiple items
الـ Copilot بيقوم بتوليد ملف الاختبار كاملاً باستخدام أي إطار عمل بتستخدمه (سواء Jest, Mocha, 등). بيغطي كل الحالات اللي طلبتها وأحياناً بيقترح حالات ما خطرت في بالي.
نصائح أبو عمر الذهبية لاستخدام الـ Copilot
بعد فترة طويلة من الاستخدام اليومي، صار عندي شوية قواعد ومبادئ للتعامل مع هاي الأداة عشان تطلع منها بأفضل نتيجة ممكنة. خذوها مني:
1. كن واضحاً في طلبك (اكتب تعليقات كأنك تتحدث لزميل)
جودة الكود اللي بيعطيك إياه الـ Copilot بتعتمد بشكل مباشر على جودة “طلبك”. كل ما كان تعليقك أو اسم الدالة اللي كتبتها أوضح وأكثر تفصيلاً، كل ما كان الاقتراح اللي رح يوصلك أدق وأفضل. لا تكتب `// get data`، بل اكتب `// fetch user profile data from the /users/profile endpoint`. الفرق شاسع.
2. لا تثق ثقة عمياء: أنت القبطان!
“Copilot is your copilot, not the pilot.”
هاي الجملة لازم تضل في بالك. المساعد هو “مساعد طيار”، لكن أنت القبطان المسؤول عن الطائرة (الكود). لازم دائماً تراجع الكود اللي بيقترحه. أحياناً ممكن يقترح كود قديم، أو كود فيه ثغرة أمنية، أو كود غير فعال (inefficient). أنت الخبير، وهو الأداة. مسؤوليتك تفهم الكود وتتأكد من جودته قبل اعتماده.
3. استخدمه كأداة للإلهام وليس كعكاز
أكبر خطر في استخدام هاي الأدوات هو إنها تخليك مبرمج “كسول” فكرياً. لا تسمح لهذا يصير. استخدم الوقت اللي بتوفره من كتابة الكود المكرر في التفكير. فكر في بنية النظام (Architecture)، في تجربة المستخدم (UX)، في تحسين الأداء (Performance). الـ Copilot حرر أيدينا من الكتابة، عشان يحرر عقولنا للإبداع وحل المشاكل الصعبة.
الخلاصة: هل سيأخذ الذكاء الاصطناعي مكاننا؟ 🤔
من الآخر يا جماعة، السؤال هذا غلط. السؤال الصح هو: “كيف رح نستخدم الذكاء الاصطناعي عشان نكون مبرمجين أفضل؟”.
الـ Copilot والأدوات الشبيهة فيه ما رح تاخذ مكان المبرمج الشاطر، لكن المبرمج اللي بيستخدم هاي الأدوات بفعالية، هو اللي رح ياخذ مكان المبرمج اللي رافض يتعلم ويتطور.
تجربتنا كانت انتقال من عالم كنا فيه “كتبة كود” إلى عالم صرنا فيه “مهندسي حلول”. صرنا نقضي وقتنا في الحوار والنقاش والتصميم، بدل ما نقضيه في النسخ واللصق. تحول تركيزنا من “كيف نكتب هاي الشغلة؟” إلى “هل هاي هي الشغلة الصح اللي لازم نكتبها أصلاً؟”. وهذا هو جوهر الإبداع الهندسي.
نصيحتي الأخيرة لكل مبرمج، سواء كنت مبتدئ أو خبير: جربوا هاي الأدوات. تعاملوا معها بعقلية نقدية، تعلموا منها، وخلوها تخدمكم في التركيز على ما هو مهم حقاً: بناء برمجيات عظيمة تحل مشاكل حقيقية.
يلا، روحوا جربوه وخبروني شو بصير معكم! 😉
