تخيل أن فريقك ينتج كودًا أكثر من أي وقت مضى، لكن بموظفين أقل. هذا ليس سيناريو خياليًا، بل واقع تعيشه صناعة البرمجيات اليوم بفضل أدوات الذكاء الاصطناعي التوليدية. السؤال الأهم: أين ذهبت الجودة؟ في مؤتمر AI Dev 26 x San Francisco، طرح Paul Everitt من JetBrains هذه المعضلة بوضوح، مشيرًا إلى أن الصناعة تسير في نهم لإنتاج المزيد من الكود دون الاهتمام الكافي بجودته، ودعا إلى تبني ما يسميه «الهندسة الوكيلة» (Agentic Engineering) عبر إحياء الدروس القديمة وتكييفها.
ما هي الهندسة الوكيلة بالضبط؟
المصطلح قد يبدو معقدًا، لكنه ببساطة يعني استخدام وكلاء ذكاء اصطناعي مستقلين لأتمتة أجزاء من دورة حياة تطوير البرمجيات — بدءًا من كتابة الكود، مرورًا باختباره، وصولًا إلى نشره. الفرق بينها وبين الأدوات المساعدة التقليدية أن الوكيل يمكنه التخطيط واتخاذ قرارات متعددة الخطوات دون تدخل بشري مباشر. لكن مع هذه القوة تأتي مسؤولية: إذا لم تُحكم الممارسات المهنية، يتحول تسريع الإنتاج إلى كارثة جودة.
رسالة Paul Everitt: الدروس القديمة لا تزال صالحة
ما أثار الانتباه في كلمة Everitt هو تأكيده أن المشكلات التي نراها اليوم — كود غير قابل للصيانة، اختبارات مفقودة، تصميم هش — ليست جديدة. في التسعينيات، واجه المطورون تحديات مماثلة مع ظهور لغات عالية المستوى وأطر العمل السريعة. الحل وقتها كان بناء ممارسات مهنية صارمة: مراجعة الكود، الاختبار الآلي، توثيق القرارات، وفصل الاهتمامات. الآن، مع الهندسة الوكيلة، نحتاج إلى تكييف هذه الممارسات لبيئة الوكلاء.
على سبيل المثال، بدلًا من أن يراجع المطور كود زميله، يمكنه مراجعة «خطة الوكيل» قبل تنفيذها. بدلًا من كتابة اختبارات يدويًا، يمكن للوكيل توليدها لكن بضوابط تحدد معايير الجودة مسبقًا. الهدف ليس استبدال المطور، بل رفع دوره إلى مستوى «مهندس وكيل» يشرف على سير العمل بدلًا من كتابة كل سطر بنفسه.
أثر ذلك على المطور العربي
في العالم العربي، حيث تنتشر مشاريع البرمجيات الصغيرة والمتوسطة، قد تكون الهندسة الوكيلة فرصة ذهبية لتقليل الفجوة مع الفرق الكبيرة. لكن الخطر يكمن في الاندفاع نحو استخدام وكلاء جاهزين دون فهم تداعيات الجودة. Everitt حذر من أن الصناعة حاليًا «في حالة سُكر» (on a bender) بالإنتاج دون النظر إلى الجودة. لذلك، على المطور العربي أن يتبنى مبدأ «الجودة أولًا» حتى مع وجود وكلاء أذكياء.
من الناحية العملية، يمكن البدء بتجربة أدوات مثل JetBrains AI Assistant التي تدمج الوكلاء في بيئة التطوير، ولكن مع وضع سياسات صارمة: لا تقبل كودًا غير مصحوب باختبارات، طالب الوكيل بتوثيق قراراته، واستخدم مراجعة يدوية للخطط بدلًا من النتائج فقط. هذه الخطوات البسيطة تحمي مشروعك من التحول إلى «فوضى وكيلة».
ما التالي؟ دروس قابلة للتطبيق الآن
المؤتمر لم يقدم حلًا سحريًا، لكنه أعاد التأكيد على أن القواعد الأساسية لهندسة البرمجيات لا تموت. سواء كنت تستخدم GitHub Copilot أو Cursor أو JetBrains، الأهم هو امتلاك عقلية نقدية تجاه ما ينتجه الوكيل. الخلاصة العملية: ابدأ الآن بتوثيق معايير الجودة في فريقك، وحدد بوضوح ما يُسمح للوكيل بفعله وما يتطلب موافقة بشرية. تذكر أن الوكيل يسرع تنفيذ الأخطاء بنفس سرعة تنفيذ الكود الصحيح، إن لم يكن أسرع.
في النهاية، يمثل نقاش Paul Everitt في AI Dev 26 تذكيرًا مهمًا: التكنولوجيا تتغير، لكن الجودة تبقى مسؤولية الإنسان. لا تدع السرعة تخدعك — جودة البرمجيات هي ما يبني السمعة ويجنبك الديون التقنية التي تدفع ثمنها لسنوات.
مصدر المقطع
نشر المقطع على قناة DeepLearningAI في YouTube، وتم اختياره لأنه حديث ومرتبط بموضوعات عليها طلب في الذكاء الاصطناعي.