الكود مكتوب، والبنية المعمارية ميتة: التكلفة الخفية للتطوير بمساعدة AI

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

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

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

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

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

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

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