كيفية توحيد توليد الكود بالذكاء الاصطناعي على مستوى فريق التطوير لديك 

هذه المشكلات ليست مجرد مخاوف افتراضية، بل أصبحت واقع تطوير البرمجيات المدعوم بالذكاء الاصطناعي في عام 2026، وفقًا لأبحاث حديثة أجريت على الفرق الهندسية القائمة على الذكاء الاصطناعي. ¹

فالمشكلة لا تكمن في أن الذكاء الاصطناعي ينتج كودًا رديئًا. بل تكمن في أنه، من دون توحيد للمعايير، سيتخذ وكيل الذكاء الاصطناعي الخاص بكل مطوّر قرارات مختلفة. فمثلًا، قد يستخدم أحد الوكلاء إطار Jest للاختبار، بينما يستخدم وكيل آخر إطار Mocha. وقد يتبع أحدهم نمط معالجة الأخطاء المعتمد في فريقك، بينما يبتكر آخر نمطًا جديدًا بالكامل. ورغم أن الكود سيعمل بالفعل، إلا أن فهم قاعدة الأكواد وصيانتها سيصبحان أكثر صعوبة بمرور الوقت.

ولا يتمثل الحل في تقليل حجم الكود المُولَّد بالذكاء الاصطناعي. بل يكمن في تزويد وكلاء الذكاء الاصطناعي بنفس المعايير والأعراف التي كان سيلتزم بها المطورون البشر، وذلك من خلال ما نُطلق عليه "القواعد على مستوى المشروع". 

ويعمل وكلاء البرمجة بالذكاء الاصطناعي بالاعتماد على النماذج اللغوية الكبيرة (LLMs)، والتي تولّد استجاباتها بناءً على أنماط تعلمتها من بيانات التدريب. ورغم امتلاك هذه النماذج لمعرفة واسعة بلغات البرمجة وأطر العمل وأفضل الممارسات، فإنها تفتقر إلى الوعي بالمتطلبات الخاصة بكل مشروع، مثل أنماط معالجة الأخطاء التي يفضلها فريقك، أو الأغلفة المساعدة الداخلية (utility wrappers)، أو أعراف الاختبار المتبعة.

ومن دون إرشادات صريحة، سيتطلب كل تفاعل مع وكيل ذكاء اصطناعي تحديد التفضيلات يدويًا، مما يخلق احتكاكًا في سير العمل ويؤدي إلى عدم الاتساق. فعندما يطلب أحد المطورين من وكيله كتابة دالة برمجية، قد يستخدم الوكيل نمط async/await. وعندما يطلب مطور آخر وظيفة مشابهة، قد يستخدم وكيله نمط الوعود (promises). ورغم أن كلا الأسلوبين سيعملان، إلا أن قاعدة الأكواد ستفقد تماسكها.

ويتفاقم هذا التباين بمرور الوقت. فتصبح مراجعات الأكواد أكثر صعوبة، لأن المراجعين لا يقيمون فقط ما إذا كان الكود يعمل، بل عليهم أيضًا التأكد من توافقه مع أعراف الفريق التي لم تُنقل أصلًا بوضوح إلى الذكاء الاصطناعي. كما لن يتمكن أعضاء الفريق الجدد من تعلم الأنماط المعتمدة من خلال قاعدة الأكواد نفسها، لأن هذه الأنماط لا تُطبَّق بصورة متسقة. ونتيجة لذلك، لا تتشكل أبدًا تلك المعرفة الضمنية (القبلية) التي كانت تنشأ عادةً من خلال مراجعات الأكواد وجلسات البرمجة الثنائية.

وتظهر تكلفة ذلك في ثلاثة أشكال: 

• أولًا، تراكم الدين المعرفي بوتيرة أسرع. فعندما يُولِّد وكلاء الذكاء الاصطناعي أكوادًا دون فهم لأعراف المشروع، تتسع الفجوة مع كل عملية إيداع (commit) بين ما يفعله الكود فعليًا وما يفهمه الفريق عنه. فقد كانت كتابة الكود هي الطريقة التي يبني بها المهندسون حدسهم وفهمهم العميق للنظام. فأثناء الكتابة، كنت تكتشف الحالات الحدّية (edge cases)، وتشعر بين يديك باحتكاك التجريد البرمجي السيئ. أما عندما يتولى الوكلاء مهمة الكتابة، فلا يتشكل هذا الفهم بنفس الطريقة.
• ثانيًا، تذبذب الجودة وعدم اتساقها. فمن دون قواعد واضحة، قد يتحول كل تفاعل مع الذكاء الاصطناعي إلى انحراف محتمل عن معايير الفريق. فقد يولّد أحد الوكلاء معالجة شاملة للأخطاء، بينما يتجاوزها وكيل آخر بالكامل. وقد يكتب أحدهم اختبارات للوحدات (unit tests)، بينما لا يفعل الآخر ذلك. وهذا التباين ليس عشوائيًا. بل يعكس اختلاف الطرق التي يصوغ بها المطورون موجّهاتهم (prompts) للوكلاء؛ لكن النتيجة النهائية هي قاعدة أكواد تبدو وكأن عشرات الأشخاص قد كتبوها بمعايير مختلفة.
• ثالثًا، تصبح تهيئة الأعضاء الجدد مستحيلة. فقد اعتاد المطورون الجدد تعلم الأعراف المتبعة من خلال قراءة الأكواد الحالية وتلقي الملاحظات أثناء مراجعات الكود. ولكن عندما يكون الكود نفسه غير متسق، فلن يجدوا شيئًا واضحًا ليتعلموا منه. وعندها لا تظل هذه الأعراف موجودة إلا في أذهان كبار المطورين الذين يتذكرون "كيف كنا ننجز الأمور سابقًا".

لقد تبنّت الفرق الهندسية وكلاء البرمجة بالذكاء الاصطناعي بوتيرة سريعة، لكن العمليات التنظيمية لم تواكب هذا التحول بنفس السرعة. وتكشف البيانات عن صورة واضحة ومقلقة:

فعلى الرغم من أن 48% من الكود بات يُولَّد الآن بالذكاء الاصطناعي، فإن استطلاعًا شمل 219 من قادة الهندسة وجد أن العمليات التنظيمية لم تتحرك إلا بقدر ضئيل للغاية؛ إذ لم تغيّر سوى 19 مؤسسة تعريفات الأدوار رسميًا، ولم تغيّر سوى 15 مؤسسة عمليات تهيئة الأعضاء الجدد، بينما لم تغيّر سوى 32 مؤسسة طريقة قياسها للإنتاجية..²

كما أن المهارات التي يصرح القادة بأنهم يقدّرونها أكثر من غيرها - كتقييم الكود المُولَّد بالذكاء الاصطناعي، وتنسيق عمل الوكلاء، والتفكير المنهجي - لا تنعكس فعليًا في التوصيفات الوظيفية، أو دورات المقابلات الشخصية، أو مسارات التدرج المهني. فمعايير التوظيف قد تغيرت بالفعل، لكن الهياكل التنظيمية المحيطة بها ظلت ثابتة لم تتغير.

وهذا يخلق فجوة خطيرة. فالمهندسون يعبّرون عن مخاوفهم من أن تصبح مهاراتهم أقل أهمية؛ إذ يفيد 63% من القادة بأنهم يسمعون هذه المخاوف، وترتفع النسبة إلى 89% في المؤسسات الكبيرة. ومع ذلك، فإن معظم المديرين يستمعون إلى هذه الحوارات ثم لا يتخذون أي إجراء. فالمواصفات والتوصيفات الوظيفية ومسارات التدرج المهني، وهي الأشياء التي توضّح للبشر والوكلاء شكل العمل "الجيد"، ما زالت مكتوبة في معظمها لعالم قديم لم يعد قائمًا كما كان.

وتكون النتيجة ما يطلق عليه الباحثون "دين النوايا" (intent debt): وهو دين يتراكم حين لا تُوثَّق الأهداف والقيود التي ينبغي أن توجّه النظام توثيقًا كافيًا، أو لا تُصان على النحو المطلوب. وصحيح أن عمليات مراجعة الكود تخضع حاليًا لإعادة الصياغة (حيث غيّرتها 57 مؤسسة رسميًا)، إلا أن السياق التنظيمي الأوسع الذي يمنح هذه المراجعات معناها لم يتغير بعد.

وتكتسب هذه المسألة أهمية لأن وكلاء الذكاء الاصطناعي لا يكتفون بالتعليمات التقنية فحسب، بل يحتاجون أيضًا إلى السياق التنظيمي. فهم لا يحتاجون إلى معرفة كيفية كتابة دالة برمجية فقط، بل يحتاجون كذلك إلى فهم أسباب تفضيل الفريق لأنماط معينة، وطبيعة المقايضات المقبولة، ومعايير الجودة التي يجب الالتزام بها. وبدون هذا السياق، سيوجه الوكلاء جهودهم نحو تحسين الجوانب الخاطئة.

وتُعرّف "القواعد على مستوى المشروع" بأنها إرشادات ومعايير برمجة وأعراف محددة توضّح كيفية إنجاز العمل داخل مشروع بعينه. وفي سياق وكلاء البرمجة بالذكاء الاصطناعي، تعمل هذه القواعد كتعليمات مستمرة توجّه عملية اتخاذ القرار لدى الوكيل، وتنسيق مخرجاته، وتوليد الكود، من دون أن يضطر المطوّرون إلى تكرار التوجيهات في كل تفاعل.

وعلى عكس الموجّهات (prompts) التي تُستخدم لمرة واحدة، تظل القواعد على مستوى المشروع نشطة طوال دورة حياة المشروع، مما يضمن الاتساق ويحافظ على توافق فرق التطوير حول معايير الجودة. وعند تهيئتها بشكل صحيح، تُحوّل هذه القواعد وكيل البرمجة بالذكاء الاصطناعي من مجرد مساعد عام الأغراض إلى عضو متخصص في الفريق، يفهم أعراف المشروع الخاصة ويلتزم بها. 

وتعمل القواعد على مستوى المشروع كجسر تشغيلي يربط بين نية المؤسسة وواقع التنفيذ الفعلي. فبينما تحدد السياسات العليا الأهداف الاستراتيجية، تتولى القواعد على مستوى المشروع تحديد الكيفية التي تنجز بها الفرق عملها. وهذه العلاقة موثقة جيدًا في أبحاث حوكمة المشاريع؛ إذ تحدد الحوكمة من يملك حق اتخاذ القرار وتحت أي سلطة، بينما تحدد القواعد على مستوى المشروع الطريقة الفعلية المسموح بها لسير العمل.³

وفي تطوير البرمجيات، تظهر هذه المسألة في الفجوة بين عبارة مثل "نحن نولي جودة الكود أهمية كبيرة" (بوصفها نية استراتيجية)، وعبارة مثل "يجب أن تتضمن جميع الدوال العامة اختبارات وحدات" (بوصفها قاعدة تشغيلية). فالعبارة الأولى تمثل طموحًا عامًا، في حين تمثل الثانية إجراءً عمليًا قابلاً للتطبيق. ولا يقتصر دور القواعد على مستوى المشروع على التوحيد القياسي فحسب، بل إنها تسهم بفاعلية في تشكيل التنسيق والتعلم والامتثال والقدرة على التكيف، وذلك من خلال تدوين الفهم المشترك لدى الفريق للأعراف والقرارات المعمارية والمنطق الكامن وراءها، بدلًا من أن تظل هذه المعرفة حبيسة أذهان الأشخاص فقط.

وتمتد القواعد على مستوى المشروع لتشمل أبعادًا متعددة في عملية تطوير البرمجيات، ومنها: 

• معايير البرمجة: وتشمل أعراف التسمية، والأنماط البنيوية، ومتطلبات إتاحة الوصول، وتفضيلات المسافات البادئة والتنسيق
• متطلبات التوثيق: وتتضمن أنماط التعليقات، وتنسيقات توثيق واجهات برمجة التطبيقات (API)، ومعايير التوثيق داخل الكود
• منهجيات الاختبار: وتشمل أطر عمل الاختبار، وتنظيم الاختبارات، ومتطلبات التغطية، وأعراف تسمية الاختبارات
• عمليات سير العمل: وتتضمن أعراف Git، وتسمية الفروع، وصيغ رسائل الإيداع (commit)، ومعايير مراجعة الكود
• الأعراف الخاصة بالفريق: وتشمل المكتبات الداخلية، وأنماط معالجة الأخطاء، ومعايير تسجيل الأحداث (Logging)، ومخططات التسمية للمفاهيم الخاصة بالمشروع

ويعكس اتساع ما يمكن لهذه القواعد تحديده دورها بوصفها ترجمة تشغيلية للنية الاستراتيجية. فقاعدة تشترط "إضافة تعليقات JSDoc إلى جميع الدوال العامة" تحوّل هدف إنتاج كود قابل للصيانة وموثق جيدًا إلى ممارسة تشغيلية ملموسة. كما أن قاعدة تفرض استخدام "Jest كإطار عمل للاختبار" تترجم مبدأ اتساق ممارسات الاختبار إلى إرشادات عملية قابلة للتنفيذ بواسطة وكيل الذكاء الاصطناعي.

وقد كانت الأساليب التقليدية للحفاظ على جودة الأكواد تعتمد على استيعاب المطورين البشر لأعراف المشروع من خلال التوثيق، ومراجعات الكود، والمعرفة الضمنية المتداولة داخل الفريق. أما وكلاء الذكاء الاصطناعي، فيحتاجون إلى شيء أكثر وضوحًا: تعليمات قابلة للقراءة آليًا، لا تقتصر على توضيح ما ينبغي أن يفعله الكود فحسب، بل توضح أيضًا كيفية كتابته واختباره وتوثيقه وفقًا لمعايير فريقك.

ومن دون قواعد مُهيأة على نحو صحيح، يتحول وكلاء الذكاء الاصطناعي إلى أعضاء غير موثوقين في الفريق، يحتاجون إلى إشراف مستمر. أما بوجود هذه القواعد، فإنها تطبق معايير المشروع باتساق ودون رقابة يدوية، مما يجعل "القواعد على مستوى المشروع" بنية تحتية أساسية لعمليات التطوير المدفوعة بالذكاء الاصطناعي.

ومن خلال تحويل الأعراف والقرارات المعمارية ومنطقها إلى قواعد صريحة، تستطيع الفرق الحفاظ على المعرفة المؤسسية حتى مع تطور قواعد الكود وتغيّر أعضاء الفريق. ويخلق النظام حلقة تحسين مستمرة: تكتشف الفرق الحالات الحدّية، وتصقل فهمها، ثم تحدّث القواعد، فيطبق الوكيل فورًا هذه المعرفة المنقّحة على كل الأعمال المستقبلية. وتمنع هذه الحلقة تآكل الفهم الشامل لقاعدة الأكواد، وهو تحدٍ تشير إليه العديد من الفرق الهندسية مع تزايد حجم الأكواد التي يولدها الذكاء الاصطناعي.

وتوازن أنظمة القواعد الفعّالة بين الاتساق المؤسسي والمرونة الخاصة بكل مشروع، وذلك من خلال بنية هرمية واضحة: 

1. القواعد العامة: وهي تُطبّق تلقائيًا على جميع المشاريع، وتُخزَّن في دليل خاص بالمستخدم أو المؤسسة 
2. قواعد مساحة العمل: وهي تُطبّق حصرًا داخل دليل المشروع الحالي

وداخل كل نطاق، تُحمَّل القواعد الخاصة بوضع معين (والتي تستهدف سياقات تطوير محددة مثل البرمجة، أو التخطيط، أو مسارات العمل المخصصة) قبل القواعد العامة، مما يتيح قدرًا أكبر من الدقة دون الحاجة إلى إضافة طبقة تهيئة منفصلة. 

وتفرض القواعد العامة المعايير الأساسية مثل ممارسات الأمان والمكتبات المعتمدة، في حين تتولى قواعد مساحة العمل إدارة المتطلبات الخاصة بالمشروع، مثل أطر عمل الاختبار وأعراف واجهات برمجة التطبيقات (API). وعندما تتعارض القواعد، تكون الأولوية لقواعد مساحة العمل على القواعد العامة، بما يعكس الطريقة التي تعمل بها الحوكمة فعليًا داخل المؤسسات.

ويعمل هذا التسلسل الهرمي على منع نمطين شائعين من الإخفاق: 

1. الإفراط في المركزية: ويحدث عندما تكون القواعد المؤسسية شديدة الصرامة بحيث لا تتناسب مع الواقع المحلي لكل مشروع. فلا ينبغي أن يخضع نظام إنتاج عالي المخاطر ونموذج أولي استكشافي لنفس القواعد تمامًا.
2. ضعف التحديد: عندما تكون الأهداف العليا موجودة، لكن المشاريع تبتكر ممارسات غير متسقة بشكل ارتجالي. فبدون معايير أساسية مشتركة، يتحول كل مشروع إلى حالة خاصة قائمة بذاتها. 

ولذلك، استخدم القواعد العامة لضبط المعايير الشاملة التي تنطبق على جميع مشاريعك، مثل:  

• ممارسات الأمان  
• المكتبات وأطر العمل المعتمدة  
• معايير البرمجة المطبقة على مستوى المؤسسة  
• متطلبات التوثيق

في المقابل، استخدم قواعد مساحة العمل لتلبية المتطلبات الخاصة بكل مشروع، مثل:  

• أطر عمل الاختبار الخاصة بهذا المشروع تحديدًا  
• أعراف واجهات برمجة التطبيقات (API) الخاصة بهذه الخدمة  
• مخططات التسمية الخاصة بالمشروع  
• أنماط التكامل مع الخدمات الأخرى

وبهذا التوازن الدقيق، يمكن تجنب الإفراط في المركزية (التي تفرض قواعد صارمة لا تلائم جميع السياقات)، وكذلك تجنب ضعف التحديد (الذي يعني غياب المعايير الأساسية بالكلية). 

ولذلك، يجب التعامل مع القواعد بوصفها توثيقًا حيًا يتطور باستمرار، وليس كعناصر ثابتة وجامدة: 

• المراجعة الدورية: حيث يُنصح بجدولة مراجعات ربع سنوية لقواعدك
• إزالة الإرشادات المتقادمة: وذلك بحذف القواعد التي لم تعد صالحة للتطبيق
• دمج القواعد المتكررة: من خلال توحيد القواعد المتشابهة لتقليل التعقيد
• تنقيح التعليمات الغامضة: عبر تحديث القواعد بناءً على ملاحظات الفريق والحالات الحدّية التي تُكتشف أثناء التطبيق العملي
• إخضاع كل شيء للتحكم في الإصدارات: لتتبّع التغييرات وفهم كيفية تطور المعايير بمرور الوقت 

ومن خلال تحويل الأعراف والقرارات المعمارية ومنطقها إلى قواعد صريحة، تستطيع الفرق الحفاظ على المعرفة المؤسسية حتى مع تطور قواعد الكود وتغيّر أعضاء الفريق. ويخلق النظام حلقة تحسين مستمرة: تكتشف الفرق الحالات الحدّية، وتصقل فهمها، ثم تحدّث القواعد، فيطبق الوكيل فورًا هذه المعرفة المنقّحة على كل الأعمال المستقبلية. وتمنع هذه الحلقة تآكل الفهم الشامل لقاعدة الأكواد، وهو تحدٍ تشير إليه العديد من الفرق الهندسية مع تزايد حجم الأكواد التي يولدها الذكاء الاصطناعي.

وعند تنفيذ القواعد على مستوى المشروع تنفيذًا صحيحًا، فإنها تحقق فوائد ملموسة وقابلة للقياس، من بينها:

• تحقيق الاتساق بين أعضاء الفريق. فعندما يلتزم وكيل الذكاء الاصطناعي الخاص بكل مطور بنفس القواعد، تصبح مراجعات الكود أسرع، كما يتوافق الكود الجديد تلقائيًا مع الأنماط المعتمدة بالفعل. وبذلك تحافظ قاعدة الكود على تماسكها، حتى مع تعدد المطورين المساهمين فيها.
• تقليل العبء المعرفي. إذ لم يعد المطورون بحاجة إلى تحديد تفضيلات المشروع في كل تفاعل مع الذكاء الاصطناعي، وهو ما يحررهم للتركيز على حل المشكلات بدلًا من الانشغال بإدارة مخرجات الذكاء الاصطناعي.
• الحفاظ على المعرفة المؤسسية. حيث تُدوّن القواعد أعراف الفريق وقراراته المعمارية داخل ملفات خاضعة للتحكم في الإصدارات، مما يحافظ على فهم قاعدة الكود حتى مع تطور الفرق وقواعد الكود. وبهذا لا تظل المعرفة حبيسة أذهان الأفراد وحدهم.
• فرض الجودة آليًا. فالقواعد تُضمّن معايير الجودة التي كانت ستتطلب، لولا ذلك، مراجعة يدوية، مثل اشتراط اختبارات وحدات لكل الدوال العامة، أو فرض أنماط محددة لمعالجة الأخطاء.
• تسريع تهيئة الأعضاء الجدد. إذ يستفيد أعضاء الفريق الجدد فورًا من وكيل ذكاء اصطناعي يفهم أعراف المشروع ويطبقها بالفعل. ولذلك يمكنهم الوصول إلى الإنتاجية المطلوبة بسرعة أكبر، لأن الذكاء الاصطناعي يساعدهم على الالتزام بمعايير الفريق منذ اليوم الأول.
• إرساء معايير قابلة للتدقيق. فالقواعد الخاضعة للتحكم في الإصدارات تنشئ سجلًا تاريخيًا يوضح كيفية تطور معايير المشروع، مما يضمن عمل جميع أعضاء الفريق انطلاقًا من الأساس نفسه، ويسهل فهم أسباب اتخاذ قرارات بعينها.

ومع تزايد نسبة كود الإنتاج الذي يكتبه وكلاء الذكاء الاصطناعي، لن تكون الفرق الناجحة هي تلك التي تولّد أكبر قدر من الكود، بل هي الفرق التي تحافظ على أكبر قدر من الفهم. فالقواعد على مستوى المشروع هي الآلية التي تُمكّن الفرق من تدوين معرفتها في صيغة يستطيع كل من البشر ووكلاء الذكاء الاصطناعي الرجوع إليها وتطبيقها.

أما البديل، فهو دين معرفي يتراكم مع كل عملية إيداع (commit): كود أكثر يُكتب، وكود أقل يُفهم، إلى أن يتعطل شيء ما ولا يستطيع أحد تتبّع السبب. وتؤكد الأرقام ذلك؛ إذ يشير أكثر من نصف قادة الهندسة بالفعل إلى هذه المشكلة باعتبارها مصدر قلق حقيقي، بينما يقول ما يقرب من اثنين من كل خمسة قادة إنها تؤثر على ثقتهم فيما يطرحونه في بيئة الإنتاج.

وليس الوقت المناسب لوضع هذه المعايير هو بعد أن تصبح قاعدة الأكواد غير قابلة للفهم؛ بل الوقت هو الآن، طالما أن لديكم فهمًا مشتركًا يمكن تدوينه. فالمؤسسات التي تتحرك مبكرًا هي التي ستحافظ على ميزتها التنافسية. أما المؤسسات التي تنتظر، فستجد نفسها تدير قواعد أكواد لا يفهمها أحد فهمًا كاملًا، كتَبها وكلاء ذكاء اصطناعي لم يوجههم أحد كما ينبغي.

وتُحوّل "القواعد على مستوى المشروع" وكلاء البرمجة بالذكاء الاصطناعي من مساعدين عامّي الأغراض إلى أعضاء متخصصين في الفريق، يفهمون الأعراف الخاصة بكل مشروع. كما تعمل هذه القواعد كجسر تشغيلي بين النية الاستراتيجية وواقع التنفيذ، حيث تترجم الأهداف العليا إلى قيود قابلة للتنفيذ تُشكّل كل تفاعل. وعندما تكون الأعراف محفوظة في ملفات خاضعة للتحكم في الإصدارات، بدلًا من بقائها في أذهان الأشخاص فقط، تستطيع الفرق الحفاظ على معرفتها المؤسسية حتى مع نمو قواعد الأكواد وتغير أعضاء الفريق.