IBS تشرح كيف تغيّر الشبكات العصبية تصميم البرمجيات ولماذا لن تحل محل المعماري

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

والاهتمام بالموضوع مفهوم. فمعماري البرمجيات لا يتعامل مع الشيفرة وحدها، بل مع قيود أيضًا: المواعيد النهائية والميزانية والأنظمة القديمة (legacy) وعمليات التكامل ومتطلبات الموثوقية والهيكل التنظيمي للفريق. وهنا تحديدًا يبدو الذكاء الاصطناعي التوليدي مغريًا على نحو خاص. فبدلًا من ساعات تُقضى في إعداد الخيارات، يمكن الحصول خلال دقائق على عدة مقاربات: النظام المتجانس (monolith) مقابل الخدمات المصغّرة، والتكامل المتزامن مقابل ناقل الأحداث، وPostgreSQL مقابل مخازن البيانات المتخصصة. ويستطيع النموذج أن يضع بسرعة قائمة بالإيجابيات والسلبيات، وأن يقترح أنماطًا مثل CQRS وevent-driven وhexagonal architecture، بل أن يرسم أساسًا لمخطط C4. ويتجلى ذلك خصوصًا في المشاريع التي تتطلب حساب عدة سيناريوهات لتطور النظام بسرعة، ومعرفة مسبقة بما سينتج عن كل خيار للفريق وللبنية التحتية.

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

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

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

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