الكود مكتوب والبنية المعمارية ميتة: الثمن الخفي لتطوير البرمجيات بالذكاء الاصطناعي

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

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

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

أما مراجعة الكود (code review) التقليدية، التي ظلت لعقود المرشّح الرئيسي للجودة، فتبدو في الظروف الجديدة غير كافية. فالمراجِع معتاد على فحص كود كتبه زميل، أي إنسان يمكن إعادة بناء منطقه ومناقشة قراراته. أما الكود الصادر عن LLM فيبدو مقنعًا ويجتاز أدوات linter والاختبارات، لكن لا يقف وراءه تصوّر معماري واعٍ. فيرى المراجِع أسطرًا صحيحة ويمرّرها دون أن يطرح السؤال الأهم: هل ينبغي أصلًا أن يكون النظام مبنيًا على هذا النحو؟ وبحسب دراسات حديثة، يميل المطوّرون إلى الوثوق بالكود المولَّد بالذكاء الاصطناعي أكثر مما ينبغي، خصوصًا عندما «يعمل ببساطة» وتغطيه الاختبارات.

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

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

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