نحن نقف عند نقطة تحول في تطوير البرمجيات. وغالباً ما يدور النقاش حول أي ما إذا كان الذكاء الاصطناعي يكتب أفضل رمز برمجي (Claude مقابل ChatGPT) أو أين لكن هذا ليس بالسؤال الصحيح.
إذا تبنينا الذكاء الاصطناعي باعتبارنا "مبرمجي الأجواء" (Vibe Coders) – حيث نحدد النية ويتولى الذكاء الاصطناعي التنفيذ – فإننا ننشئ تدفقاً هائلاً من البرمجيات الجديدة. يمكن لسرب من وكلاء الذكاء الاصطناعي توليد كود برمجي في دقيقة واحدة أكثر مما يمكن لمطور متمرس مراجعته في أسبوع. لقد أصبح العنصر البشري هو عنق الزجاجة.
الحل ليس أكثر البشر. الحل هو سلطة تصميم الذكاء الاصطناعي.
تقليدياً، تعتبر "سلطة التصميم" مجموعة من المهندسين المعماريين الذين يجتمعون مرة في الأسبوع أو الشهر للموافقة على تصميم ما أو رفضه. وفي عالم تطوير الذكاء الاصطناعي عالي السرعة هذا النموذج عفا عليه الزمن تماماً. فهو بطيء جداً وتفاعلي للغاية.
إذا انتقلنا إلى "البرمجيات القابلة للتخلص منها" – وهي برمجيات لا نقوم بإعادة هيكلتها بلا نهاية، بل نتخلص منها ونعيد توليدها عندما تتغير المتطلبات – فإن دورنا يتغير بشكل جوري. لم نعد بناة نضع حجراً فوق حجر. بل أصبحنا مهندسي المصنع الذي يطبع الجدران.
ولكن من يتحقق مما إذا كانت هذه الجدران مستقيمة؟
سلطة تصميم الذكاء الاصطناعي ليست شخصاً، بل هي خط أنابيب. إنها بمثابة حلبة صراع يجب على كل سطر من الكود المُتولّد أن يشق طريقه عبرها ليصل إلى مرحلة الإنتاج. هذه العملية لا تحل محل مراجعة الكود البشرية بـ لاشيء، بل بشيء أفضل.
وهي تعمل على ثلاث طبقات:
1. السلطة التنفيذية (التوليد)
نحن لا نطلب من نموذج ذكاء اصطناعي واحد إيجاد حل، بل نطلب ذلك من ثلاثة نماذج. فنحن نترك نماذج Gemini 3 وGPT-5 ونموذجاً مفتوح المصدر (مثل Llama) تعمل بشكل متوازٍ لحل نفس المشكلة. هذا يمنع الرؤية النفقية ويكسر "الكسل" الذي تعاني منه نماذج اللغات الكبيرة أحياناً. هذا النهج مدعوم بحثياً وعلمياً ويثبت أنه يمكنك منع هلوسة الذكاء الاصطناعي وبناء سلاسل طويلة جداً دون أخطاء
2. الفلتر الصارم (القانون)
هنا لا مجال للنقاش. يجب أن يتم تجميع الكود (Compile). ويجب ألا تشتكي أدوات التدقيق (Linters). والأمر الأهم، هو أن اختبارات الصندوق الأسود يجب أن تنجح. نحن لا نختبر ما إذا كانت الوظيفة تعمل داخلياً (فهذا يمكن للذكاء الاصطناعي التلاعب به)، بل نختبر ما إذا كان النظام يؤدي من الخارج ما يُفترض به القيام به. هل فشل الاختبار؟ إذن يُرمى مباشرة في سلة المهملات.
3. المرشح الناعم (لجنة تحكيم الذكاء الاصطناعي)
هذا هو الابتكار الحقيقي. يتم عرض الحلول المتبقية على "ذكاء اصطناعي للتصويت" مُخصص. هذا الوكيل لا يكتب الكود، بل يقرأ الشفرة البرمجية. لقد تم تدريب النموذج على مبادئ الهندسة المعمارية الخاصة بنا، ومتطلبات الأمان (OWASP، ISO) وقواعد الامتثال (قانون الذكاء الاصطناعي للاتحاد الأوروبي).
وهو يصوت: "الحل (أ) أسرع، لكن الحل (ب) أكثر أماناً ويتوافق بشكل أفضل مع هندسة الخدمات المصغرة (Microservices) الخاصة بنا."
الفائز ينتقل إلى مرحلة الإنتاج.
يفرض هذا النموذج فصلاً بين السلطات تفتقر إليه العديد من الفرق.
project-description.md, rules.md, skills.md en principles.md), المتطلبات الصارمة. يحدد المهندس المعماري ماذا نحن نبني، من يبنى، كيف و لماذا.إنه يحررنا من طغيان أخطاء بناء الجملة (Syntax) ويتركنا نركز على ما نجيد القيام به: التفكير النظامي. البحث عن الحقيقة. الهيكل واتخاذ القرار.
السؤال ليس ما إذا كان الذكاء الاصطناعي قادراً على كتابة شفراتنا البرمجية. لقد حُسم هذا الموضوع بالفعل. أصبحت البرمجة إلى حد كبير منتجاً يمكن التخلص منه.
السؤال هو: هل تجرؤ على التخلي عن السيطرة على الشفرة البرمجية لكي تستعيد من خلال ذلك السيطرة على الجودة ؟
أخبرني بذلك