سلطة تصميم الذكاء الاصطناعي

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

المشكلة الحقيقية ليست في الجيل الكود. المشكلة الحقيقية هي التحقق تطبيقه.

عندما نتبنى الذكاء الاصطناعي كـ "مُبرمجي النوايا" (Vibe Coders) - حيث نحدد النية ويتولى الذكاء الاصطناعي التنفيذ - فإننا نخلق تدفقًا هائلاً من البرامج الجديدة. يمكن لسرب من وكلاء الذكاء الاصطناعي توليد كود برمجي أكثر في دقيقة واحدة مما يمكن لمطور خبير مراجعته في أسبوع. لقد أصبح الإنسان هو عنق الزجاجة.

الحل ليس المزيد البشر. الحل هو سلطة تصميم الذكاء الاصطناعي.

من الحرفي إلى مدير المصنع

تقليديًا، "سلطة التصميم" (Design Authority) هي مجموعة صغيرة من المهندسين المعماريين تجتمع مرة واحدة في الأسبوع أو الشهر للموافقة على تصميم أو رفضه. في عالم من تطوير الذكاء الاصطناعي عالي السرعة أصبح هذا النموذج قديمًا بشكل ميؤوس منه. إنه بطيء للغاية ويتسم برد الفعل المتأخر.

عندما نتحول إلى "الكود القابل للتصرف" (Disposable Code) - وهو برنامج لا نقوم بإعادة هيكلته إلى ما لا نهاية، بل نرميه ونعيد إنشاؤه عندما تتغير المتطلبات - فإن دورنا يتغير بشكل جذري. لم نعد بناة يضعون حجرًا فوق حجر. نحن مهندسو المصنع الذي يطبع الجدران.

ولكن من يضمن أن هذه الجدران مستقيمة؟

تحدي "القفاز": اختبار حريق مؤتمت

سلطة تصميم الذكاء الاصطناعي (AI Design Authority) ليست شخصًا، بل هي مسار عمل (Pipelne). "تحدي" (Gauntlet) يجب أن تجتاز كل سطر من التعليمات البرمجية المولّدة هذا المسار لتصل إلى مرحلة الإنتاج. هذه العملية لا تستبدل المراجعة البشرية للتعليمات البرمجية بـ لا شيء، بل بشيء أفضل.

يعمل هذا النظام في ثلاث طبقات:

1. السلطة التنفيذية (التوليد)
نحن لا نطلب من ذكاء اصطناعي واحد تقديم الحل، بل نطلب ثلاثة. نجعل Gemini 3 و GPT-5 ونموذج مفتوح المصدر (مثل Llama) يعملون بالتوازي على نفس المشكلة. هذا يمنع الرؤية النفقية ويكسر "الكسل" الذي تعاني منه نماذج اللغة الكبيرة أحيانًا. هذا النهج أيضًا تم فحصه علميًا ويُظهر أنه يمكنك منع هلوسة الذكاء الاصطناعي وبناء سلاسل طويلة جدًا دون أخطاء

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

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

يفوز الحل المتجه إلى الإنتاج.

فصل السلطات الثلاث للبرمجيات

يفرض هذا النموذج فصلًا للسلطات تفتقر إليه العديد من الفرق.

• السلطة التشريعية (المهندس المعماري): يكتب المهندس المعماري "الدستور". الأوامر (Prompts)، ووثائق البنية المعمارية (project-description.md, rules.md en principles.md)، والمتطلبات الصارمة. يحدد المهندس المعماري ماذا ما نبنيه و لماذا.
• السلطة التنفيذية (وكلاء البرمجة): إنهم ينفذون. بسرعة، وبتكلفة منخفضة، وتحت إشراف المطورين البشريين.
• السلطة القضائية (سلطة التصميم): طبقة ذكاء اصطناعي مستقلة تلتزم بالقانون.

الخلاصة: الدور الجديد للمهندس المعماري

إنه يحررنا من طغيان أخطاء بناء الجملة ويسمح لنا بالتركيز على ما نبرع فيه: التفكير المنظومي. استقصاء الحقائق. الهيكلة واتخاذ القرار.

السؤال ليس ما إذا كان الذكاء الاصطناعي يستطيع كتابة الشفرة البرمجية الخاصة بنا. لقد تم البت في ذلك بالفعل. تصبح الشفرة البرمجية قابلة للتصرف إلى حد كبير.
السؤال هو: هل تجرؤ على التخلي عن السيطرة على التنفيذ حتى تتمكن من استعادة السيطرة على الجودة ؟