يبدأ معظم مطوّري البرمجيات وقادة الفرق التقنية ومهندسي DevOps مسيرتهم بنّائين.

يبنون الأنظمة والتطبيقات والمكوّنات والقوالب والأنماط والوحدات وخطوط الإنتاج. يحسّنون التخطيطات، ويعالجون الحالات الحدّية، ويحافظون على التوافق، ويدفعون الأنظمة إلى الأمام التزامًا بعد التزام (commit). العمل دقيق وعملي وتقني حتى النخاع.

لكن في لحظة ما، يتغيّر شيء.

أفضل الممارسين لا يتوقفون عن البناء، لكنهم يبدؤون التفكير بعقلية الأنظمة.

من البنّاء إلى مفكّر الأنظمة

التحوّل: من المُخرَجات إلى القواعد

حين تكون بنّاءً، ينصبّ تركيزك على المُخرَجات: المكوّنات والقوالب والصفحات والميزات والمكتبات والتطبيقات.

وحين تصبح مفكّر أنظمة، يتحوّل التركيز إلى القواعد: القيود والتفاعلات وحلقات التغذية الراجعة.

بدلًا من أن يسأل «كيف يبدو هذا المكوّن؟»، يطرح مفكّرو الأنظمة أسئلة مختلفة: ما القواعد التي تحكم هذا المكوّن؟ وما الذي يُسمح له بالتفاعل معه؟ وكيف يتصرّف عند التغيير؟ وكيف تبقى النيّة حيّة مع مرور الزمن؟

وهذا التحوّل يقود بطبيعته نحو الأنظمة الوكيلية (agentic systems).

حين يكفّ التصميم عن كونه ساكنًا

أنظمة التصميم الحديثة تحمل المنطق في داخلها أصلًا: الرموز (tokens) تحدّد القيود، والمكوّنات تحدّد البنية، والأنماط تحدّد السلوك.

ومع ذلك، ما زالت معظم الأنظمة تعتمد على تنسيق بشري كثيف.

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

هنا يتطوّر التصميم من وثائق مكتوبة إلى منطق قابل للتنفيذ.

إلى أين يتجه هذا كله

التركيز الآن على تطبيق هذه الأفكار في أنظمة حقيقية تعمل فعلًا، لا كتجارب عابرة بل كأساسات.

1. تكامل أعمق لوكلاء الذكاء الاصطناعي مع أدوات التصميم (Figma)

نحو أنظمة تصميم وكيلية

لا ينبغي أن تكون أدوات التصميم لوحات سلبية.

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

بهذا ينتقل التصميم إلى أعلى المسار، حيث تُحفظ النيّة كما هي بدل أن تُستنتج لاحقًا.

2. إدارة قابلة للتوسّع لوكلاء الذكاء الاصطناعي

الهدف: 150 وكيلًا، وكيل لكل مكوّن

بدلًا من ذكاء اصطناعي واحد عام الغرض، تتجه الفرق نحو وكلاء متخصصين كثيرين.

يحصل كل مكوّن على وكيله الخاص، بمسؤوليات محددة وحدود واضحة ووعي بالمكوّنات المرتبطة به.

وهذا يشبه الطريقة التي تتوسّع بها الأنظمة السليمة: بالتخصص والتنسيق والعقود الواضحة.

3. وكلاء بمهارات وأدوات وإضافات حقيقية

يجب أن يكون الوكلاء قادرين على الفعل.

ويعني هذا تزويدهم بمهارات (التفكير في إمكانية الوصول، والتحقق من التصميم، والوعي بالأداء)، وأدوات (أدوات فحص الشيفرة، ومشغّلات الاختبار، وواجهات برمجة التصميم)، وإضافات (Storybook وDrupal وخطوط CI وتكاملات Figma).

وكيل بلا أدوات يبقى نظريًا. أما الوكيل المزوَّد بالأدوات فيصبح جزءًا من النظام نفسه.

4. اختبار قبول وظيفي آلي أذكى

مدفوع بالذكاء الاصطناعي وواعٍ بالنيّة

الاختبار التقليدي يفحص المُخرَجات. أما الاختبار الذي يقوده الوكلاء فيفهم السلوك.

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

يصبح الاختبار طبقة أخرى من ذكاء النظام.

TDD وBDD في عصر الذكاء الاصطناعي: لماذا يتطلب وكلاء الذكاء الاصطناعي تطويرًا يبدأ بالاختبار بنسبة 100% أكثر

لماذا يهمّ هذا

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

في هذا العالم، لا يتوسّع التحكّم اليدوي. أما القواعد المحددة جيدًا فتتوسّع.

على المصمّمين والمطوّرين ووكلاء الذكاء الاصطناعي أن يعملوا ضمن إطار منطقي واحد، نظام مشترك واحد من القيود والنيّة.

الانتقال من البنّاء إلى مفكّر الأنظمة لا يعني التخلّي عن التنفيذ. بل يعني أن ترى الأنظمة أكثر من مجرد مجموعة أجزاء.

الخطوة التالية هي تصميم القواعد التي تتيح للأنظمة أن تستدلّ وتتكيّف وتتطوّر.

مطوّرو البرمجيات وقادة الفرق التقنية ومهندسو DevOps الذين يخطون هذه الخطوة لا يبنون فحسب، بل يبنون الظروف التي تجعل الأنظمة تبني نفسها بنفسها.