الحوكمة الهندسية في عصر الذكاء الاصطناعي الوكيلي (Agentic AI): المهندس التأسيسي | كبسولات حوسبية احترافية

مرحبا بكم فى كبسولات “ألف محترف حوسبي” حيث نقدم مقدمة مبسطة لأهم ممارسات هندسة البرمجيات والحوسبة السحابية.

لماذا هذه الكبسولات؟

سوف تساعدك هذه الكبسولات من “ألف محترف حوسبي” على التعرف على العديد من الممارسات والأدوات والمفاهيم التقنية الحديثة بأسلوب مبسط.

هذه الكبسولة هي نسخة مكتوبة من محاضرتي في مؤتمر DevOpsDays Cairo 2026 التي قُدّمت يوم 26 سبتمبر 2026، ونُشرت نسختها الإنجليزية على مدونة swac.blog. يمكنك مشاهدة تسجيل إنجليزي لنفس المحاضرة على يوتيوب من خلال هذا الرابط. ستجد أهم الشرائح مضمّنة في هذه الكبسولة على هيئة أشكال.

قدّمتُ مؤخرًا محاضرة في مؤتمر DevOpsDays Cairo 2026 بعنوان “The Foundational Engineer: Engineering Governance and Anti-Burnout in the Era of Agentic AI Co-Workers” (المهندس التأسيسي: الحوكمة الهندسية ومقاومة الاحتراق الوظيفي في عصر زملاء العمل من وكلاء الذكاء الاصطناعي). كانت المحاضرة موجهة لمهندسي البرمجيات ومهندسي DevOps على جميع المستويات، من المهندسين الأقدم إلى قادة الفرق والمهندسين الرئيسيين (Staff). الفكرة الأساسية بسيطة: عندما تكتب وكلاء الذكاء الاصطناعي القوية جزءًا كبيرًا من الكود، تصبح الحوكمة الهندسية (Engineering Governance) هي ما يُبقي الفرق ممسكة بزمام الأمور، وهي أيضًا ما يحمي أفرادها من الاحتراق الوظيفي (Burnout). وكما فعلت في كبسولة التطوير الموجه بالمواصفات مع Kiro، أحوّل هنا الجلسة المباشرة إلى محتوى مكتوب يمكنك قراءته على مهل.

أولًا: قصة من عام 1969

بدأتُ بصورة من عام 1969: شابة تقف بجوار كومة من الأوراق المطبوعة يكاد ارتفاعها يساوي ارتفاعها هي. إنها مارغريت هاميلتون (Margaret Hamilton) التي قادت فريق البرمجيات الخاص بحاسوب التوجيه في مهمة أبولو، والكومة هي كود لغة التجميع (Assembly) المطبوع الذي ساعد في إيصال رائدي فضاء إلى القمر وإعادتهما. ويُنسب إليها أيضًا تعميم مصطلح “هندسة البرمجيات” (انظر تقرير MIT News الذي تعود إليه الصورة).

شكل 1: مارغريت هاميلتون وكود أبولو المطبوع (1969). الصورة: Draper Laboratory / MIT Museum، ملكية عامة.

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

ثانيًا: هل هذا جديد؟ نعم ولا

ليس جديدًا لأننا بنينا طبقات تجريد من قبل. المترجمات (Compilers) سمحت لنا بكتابة لغة C بدلًا من Assembly. أطر CSS مثل Bootstrap وTailwind حوّلت CSS الخام إلى أنظمة تصميم قابلة لإعادة الاستخدام. وأطر React وVue وAngular نظّمت JavaScript الخام، كما فعلت Node.js وLaravel وSymfony وSpring في الخلفية (Backend). وفي كل مرة كنا نعمل على مستوى أعلى ونثق في الطبقة التي تحتنا لتتولى التفاصيل.

لكنه جديد في نقطة مهمة: الطبقة التي تحتنا لم تعد حتمية (Deterministic). إذا أعطيتها المدخل نفسه مرتين فقد لا تحصل على المخرج نفسه. وبدون الضوابط المناسبة نفقد السيطرة ونجد أنفسنا أمام معادلة “مدخلات سيئة تعطي مخرجات سيئة” (garbage in, garbage out)، وهو طريق مباشر إلى الإحباط والاحتراق الوظيفي.

ثالثًا: الحوكمة الهندسية لها نتيجة بشرية

يقول روبرت سي. مارتن (Robert C. Martin) المعروف بـ Uncle Bob: احكم عملك بنفسك وإلا حُكم عليك. فإن لم نحدد نحن الانضباطات والمعايير والأخلاقيات الخاصة بمهنتنا، فستكون “مفروضة علينا ممن لا يعرفوننا.” وهذه الفكرة تتردد في كتابه Clean Craftsmanship: Disciplines, Standards, and Ethics.

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

رابعًا: أربع ركائز للحوكمة الهندسية، وهدف واحد

تغطي المحاضرة أربع ركائز للحوكمة الهندسية. ثلاث منها أسس هندسية قديمة لا ترتبط بأداة بعينها، والأخيرة فقط هي الخاصة بعصر الذكاء الاصطناعي:

1. التطوير الموجه بالاختبارات (TDD): أثبت أنه يعمل وفق حدود تغطية متفق عليها. الأثر على الاحتراق: توقف عن السهر قلقًا من أن الكود لا يعمل.
2. التطوير الموجه بالمواصفات (SDD): اعرف ماذا تبني ولماذا قبل أن تبنيه. الأثر على الاحتراق: توقف عن إعادة بناء الشيء نفسه مرات.
3. التطوير القائم على الجذع (TBD): اجتز اختبار الدمج المستمر الذي وضعه جيز همبل (Jez Humble). الأثر على الاحتراق: لا مزيد من رهبة الدمج في نهاية السبرنت.
4. سير العمل الحديث في عصر الذكاء الاصطناعي: لا يجوز أن يكون أي نموذج هو الحكم الوحيد على مخرجاته. الأثر على الاحتراق: قم بحوكمة الوكلاء ولا تتعامل معهم كأطفال يحتاجون إلى مراقبة دائمة.

شكل 2: الركائز الأربع، لكل منها هدف في الحوكمة وأثر على الاحتراق الوظيفي.

خامسًا: الركيزة الأولى: التطوير الموجه بالاختبارات (TDD)

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

شكل 3: التطوير الموجه بالاختبارات ودورة أحمر – أخضر – إعادة هيكلة.

وهذا اعتراف صريح مني: أنا عادةً لا أمارس TDD بشكله الصارم. فالـ TDD يعني كتابة الاختبار أولًا، بينما أكتب أنا الاختبارات عادةً بعد التنفيذ، لأن الاختبار أولًا غير بديهي لدى كثير من الفرق. لكن ما لا أتنازل عنه هو التغطية الآلية للاختبارات (Test Coverage) وبوابات الجودة (Quality Gates) على كل ما يُسلَّم. فهدف الحوكمة الهندسية ليس الطقوس، بل الثقة بأن التغييرات التي ينتجها الذكاء الاصطناعي تخضع فعلًا للتحقق، وأن لدينا شبكة أمان تتيح لنا تغيير الكود متى شئنا.

أدوات التغطية تساعد كثيرًا هنا. فالتقارير في الطرفية تُظهر الفروع غير المغطاة، والأدوات على الويب مثل Codecov تمنح كل أفراد الفريق الرؤية نفسها. ومن الأدوات المرافقة الجميلة Git Truck التي تعرض المستودع على شكل مخطط فقاعات أو خريطة شجرية أو أقسام بحسب حجم الملفات وعدد الـ commits والأسطر المتغيرة وأكثر المساهمين وآخر تعديل، فيحافظ البشر على صورة واضحة لقاعدة الكود.

شكل 4: أداة Git Truck، مرافق لتغطية الاختبارات لفهم قاعدة الكود.

سادسًا: الركيزة الثانية: التطوير الموجه بالمواصفات (SDD)

في التطوير الموجه بالمواصفات تُكتب المواصفات ويُتفق عليها قبل بدء التنفيذ، وتصبح المصدر الوحيد للحقيقة لما يجب بناؤه (وهذا ما يقوله أيضًا تعريف IBM). عمليًا هي سلسلة بسيطة: المتطلبات، ثم التصميم، ثم المهام، وتسمى أحيانًا PRD ثم SPEC ثم PLAN. وكل هذا موجود قبل أن يلمس أي وكيل ذكاء اصطناعي الكود.

شكل 5: المتطلبات، التصميم، المهام: سلسلة التطوير الموجه بالمواصفات.

النقطة المهمة أن SDD انضباط وليس منتجًا. وإذا فهمت ذلك أصبحت مستقلًا عن الأدوات. فمن الأدوات مفتوحة المصدر أداة Spec Kit من GitHub وأداة OpenSpec ومنهجية BMAD التي تغطي دورة Agile كاملة. أما Kiro من AWS فهي خيار مغلق المصدر. وأنا لا أروّج لأي منها، ويمكنك ممارسة SDD دون أي أداة، فهو انضباط من انضباطات الحوكمة الهندسية وليس منتجًا تشتريه.

سابعًا: الركيزة الثالثة: التطوير القائم على الجذع (Trunk-Based Development)

تميل الفرق غالبًا إلى الفروع طويلة العمر والدمج في النهاية: كل مطوّر يعمل على فرعه الخاص ويدمجه في الفرع الرئيسي في نهاية السبرنت. أما التطوير القائم على الجذع فيفعل العكس، ويدمج بأجزاء صغيرة ودون انقطاع. وتاريخ ذلك يمتد من Git flow إلى GitHub flow ثم TBD. ويقول مارتن فاولر (Martin Fowler) في مقاله عن شهادة الدمج المستمر إنه لا يُعد دمجًا مستمرًا إلا إذا كان يجري على “خط رئيسي مشترك يلتزم به الناس كل يوم.”

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

شكل 6: التكامل منخفض التكرار يقود إلى الانفجار الكبير. المصدر: مارتن فاولر.

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

شكل 7: التكامل عالي التكرار. المصدر: مارتن فاولر.

هل يأتي هذا دون ثمن في الحوكمة الهندسية؟ لا. فالالتزام عدة مرات في اليوم يعني الالتزام بكود لست مستعدًا لإطلاقه. والحل هو مفاتيح الميزات (Feature Toggles): نقطة تبديل في الكود وموجّه (Router) يقرران هل يعمل الكود القديم أم الجديد. أبسط صورها شرط يُرجع الدالة القديمة أو المحسّنة. الأنظمة الحقيقية أكثر حرصًا من ذلك، لكن الفكرة قائمة. ومن الأدوات مفتوحة المصدر لذلك Flagsmith.

شكل 8: مفاتيح الميزات تتيح الالتزام بعمل غير مكتمل على الجذع بأمان.

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

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

ثامنًا: الركيزة الرابعة: سير العمل الحديث في عصر الذكاء الاصطناعي

هنا يأتي الذكاء الاصطناعي، وهو يحصل على وقت أقل من الركائز الثلاث الأخرى مجتمعة. لأكثر من عام جرّبتُ الوكلاء (Agents) وأطر التشغيل (Harnesses) والنماذج مفتوحة الأوزان ومغلقتها، وخلصتُ إلى أن الاعتماد على نموذج واحد ليس في مصلحة المشروع. فبدأت أستخدم نموذجين بالتوازي: مبرمج ومراجع. كان المبرمج يعمل في Cursor على Claude Opus، والمراجع في OpenCode على GPT Codex، أي أداتان ومزوّدان مختلفان عن قصد. وكانا يتواصلان عبر ملفات، وأنا الإنسان في الحلقة (Human in the Loop). ثم أضفت دورًا ثالثًا هو المدقق (Auditor) ليتحقق بشكل مستقل. والمبدأ هو أن لا يكون أي نموذج هو الحكم الوحيد على مخرجاته.

شكل 9: مبرمج ومراجع من مزودين مختلفين، مع إنسان يحكم الحلقة.

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

فبدأتُ ثلاث نماذج أولية (Proofs of Concept): عميل وخادم MCP، ثم وكيل فوق هذا العميل، ثم عدة وكلاء يتحدثون عبر بروتوكول A2A، وبنيتُهم باستخدام ADK من Google. ومن دمجها وُلدت فكرة OrchestrAI، وهي منسق (Orchestrator) أصيل للطرفية يدير فريقًا من الوكلاء المصممين لغرض محدد عبر دورة حياة البرمجيات (مثل وكلاء التخطيط والتطوير ومراجعة الكود والاختبار والتوثيق وDevOps والأمان). فيه واجهة طرفية مع نقاط موافقة بشرية (Human-in-the-Loop)، وهو مصمم للعمل مع عدة مزودي نماذج لغوية. بنيناه في هاكاثون DevOpsDays Cairo 2026 وقدمناه للجنة التحكيم وتقدمنا إلى الجولة التالية. وهو متاح على npm. وقدّمته كدراسة حالة في الحوكمة وليس كعرض لمنتج، أي مثال واحد على النمط.

شكل 10: OrchestrAI، منسق أصيل للطرفية لفريق من الوكلاء المتخصصين.

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

تاسعًا: أربع ركائز، ونتيجة مستدامة واحدة

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

شكل 11: من الركائز الأربع إلى الحوكمة الهندسية إلى فرق أكثر استدامة.

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

عاشرًا: أهم الخلاصات

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

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

اذا اردت قراءة المزيد فيمكنك قراءة هذه الكبسولة عن بناء تطبيق ويب بدون خادم على AWS، وإذا كنت تستعد لشهادات AWS فاطلع على كبسولة خدمات AWS للمطورين، كما يمكنك قراءة النسخة الإنجليزية من هذا المقال على مدونة swac.blog.

اذا اعجبتكم هذه الكبسولة فسارعوا بالاشتراك فى قائمة ألف محترف حوسبي البريدية ليصلكم كل جديد – نقوم بنشر كبسولة جديدة كل فترة قصيرة على أمل أن نساعدكم فى تطوير مهاراتكم التقنية.

كذلك تابعونا على منصات التواصل الاجتماعى لتصلكم عروضنا الجديدة و كوبونات توفير ألف محترف سحابي.