العمارة ككود: كيف تُسرّع نماذج اللغة الكبيرة تصميم الأنظمة

التوثيق المعماري في الشركات الكبرى يكاد يكون دائماً مصدر عناء. أسابيع من الموافقات، وتعديلات لا تنتهي على المخططات في Draw.io، وإدارة نسخ عبر Confluence تشبه أعمال التنقيب الأثري أكثر مما تشبه عملية هندسية. قرر فريق قسم الذكاء الاصطناعي في مجموعة شركات BCS أن الوقت قد حان لوضع حد لذلك، وأظهر كيف يمكن لنهج Architecture as Code، بالاقتران مع مساعدات LLM، أن يغيّر قواعد اللعبة جذرياً.

وصف أليكسي برونسكي، المسؤول عن العمارة في قسم الذكاء الاصطناعي في BCS، مشكلة يعرفها كل مهندس معماري في المؤسسات. يبني فريقه أنظمة وكيلية (agentic)، ومساعدات ذكاء اصطناعي، وحلول OCR، وتحليلات الكلام، ونماذج ML كلاسيكية. ويقف وراء كل مشروع من هذه المشاريع قرار معماري، أي وثيقة يجب أن تمر بموافقات متعددة المراحل مع الأعمال، والعمارة المؤسسية، وإدارة أمن المعلومات، وأصحاب الأنظمة المجاورة. وفي المتوسط، يستغرق المسار من استلام المتطلبات التجارية إلى الاعتماد النهائي من أسبوعين إلى ثلاثة أسابيع. وفي قطاع تحدد فيه سرعة التكرار القدرة التنافسية، تُعدّ هذه المدة طويلة إلى حد لا يمكن قبوله.

جوهر النهج المقترح هو نقل التوثيق المعماري من المحررات المرئية وأنظمة الويكي إلى الكود. اختار فريق BCS أداة Structurizr التي تتيح وصف عمارة الأنظمة البرمجية بلغة DSL مخصصة. وبدلاً من سحب المكوّنات يدوياً على لوحة Draw.io، يصف المهندس المعماري المكوّنات والعلاقات والسياقات نصاً. ويمنح ذلك كل المزايا التي يحصل عليها المطورون منذ زمن من نهج Infrastructure as Code: إدارة النسخ عبر Git، ومراجعة الكود، والتوليد الآلي للمخططات، والأهم من ذلك إمكانية ربط مساعد LLM.

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

من المهم فهم السياق الذي ظهرت فيه هذه الممارسة. فـ Architecture as Code ليست فكرة جديدة. أدوات مثل Structurizr وPlantUML وMermaid موجودة منذ زمن طويل. غير أنه قبل ظهور النماذج اللغوية القوية ظل الوصف النصي للعمارة نهجاً محدود الانتشار: عتبة الدخول مرتفعة، والمكسب مقارنة بالمحررات المرئية غير واضح. وقد غيّرت نماذج LLM هذه المعادلة. فالنموذج الذي يتعامل بطلاقة مع النصوص والكود يحوّل Architecture as Code من ممارسة أنيقة لكنها مرهقة إلى سير عمل فعال حقاً. يصوغ المهندس المعماري المتطلبات، ويولّد المساعد مسودة بلغة DSL، ويراجعها الإنسان ويصحّحها، فتنكمش الدورة من أسابيع إلى أيام.

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

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