المصنع المُظلم: برمجيات لا يكتبها إنسان ولا يراجعها إنسان

مقدمة

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

يستعير المفهوم من عالم التصنيع. “المصنع المُظلم” هو منشأة إنتاجية تعمل بلا إضاءة لأنه لا يوجد بشر على أرضية الإنتاج. تبني الروبوتات المنتجات. تتولى أجهزة الاستشعار ضبط الجودة. يُصمّم البشر المنتجات ويضعون المعايير، لكن أرضية المصنع تعمل باستقلالية تامة. طبّقت StrongDM هذا النموذج على البرمجيات. والنتائج ليست نظرية — فمخزن السياق الخاص بهم المعروف بـ CXDB يعمل في الإنتاج منذ أشهر، وقد بُني بالكامل بواسطة هذا المصنع.

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

المستويات الخمسة للبرمجة بالذكاء الاصطناعي

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

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

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

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

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

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

الإطار مهم لأنه يوفر خارطة واقعية للمشهد. أغلب المنظمات تقع بين المستوى الأول والثالث. أغلبها تعتقد أنها أبعد مما هي عليه فعلًا. والفجوات بين المستويات ليست تدريجية — بل معمارية.

السيناريوهات مقابل الاختبارات: التمييز الأهم الذي لا يتحدث عنه أحد

لا يستخدم نظام ضمان الجودة في المصنع المُظلم الاختبارات التقليدية. بل يستخدم ما تسميه StrongDM “السيناريوهات.” قد يبدو هذا التمييز لفظيًا. إلا أنه جوهري.

السيناريو يصف السلوك المتوقع من منظور خارجي. يبدو كمعيار قبول مكتوب في شكل قصة: “إذا أنشأ مستخدم موردًا وأجاز المشرف ذلك، يجب أن يتمكن المستخدم من الوصول إلى هذا المورد.” السيناريو يلتقط ما يجب أن تفعله البرمجيات من وجهة نظر من يستخدمها.

الاختبار هو كود يُمارس الوظائف الداخلية مباشرة. تحقق من أن الدالة X تُرجع Y عند إدخال Z. الاختبار يتحقق من الآليات الداخلية للتنفيذ.

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

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

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

عالم التوأم الرقمي

الركيزة الثانية للمصنع المُظلم هي ما تسميه StrongDM “عالم التوأم الرقمي” — نسخ سلوكية مطابقة لكل خدمة خارجية تتفاعل معها البرمجيات. Okta محاكى. Jira محاكى. Slack وGoogle Docs وGoogle Drive وGoogle Sheets محاكاة. يطوّر وكلاء الذكاء الاصطناعي في مواجهة هذه التوائم الرقمية، مُجرين سيناريوهات اختبار التكامل الكاملة دون أن يلمسوا أنظمة إنتاج حقيقية أو واجهات برمجية حقيقية أو بيانات حقيقية.

هذه ليست بيئة تدريج قياسية. إنها عالم مُحاكى مُصمَّم خصيصًا للتطوير البرمجي المستقل. لا تكتفي التوائم الرقمية بمحاكاة استجابات API — بل تُحاكي أنماط السلوك الواقعية وحالات الخطأ وحدود معدل الطلبات والحالات الحافة التي تُظهرها خدمات الإنتاج. يعمل وكلاء الذكاء الاصطناعي داخل هذا العالم المُحاكى كما لو كانوا يعملون في مواجهة أنظمة حقيقية، والسيناريوهات تتحقق من السلوك عبر تلك التكاملات المُحاكاة.

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

الحلقة الذاتية المرجعية

المصنع المُظلم ليس حكرًا على StrongDM. أبرز أمثلة التطوير البرمجي المستقل تحدث في شركات الذكاء الاصطناعي نفسها.

أفصحت Anthropic عن أن نحو 90% من قاعدة كود Claude Code كتبها Claude Code بنفسه. الوكيل كتب الوكيل. منتج Codex من OpenAI يُشحن بميزات بُنيت بالكامل من قِبل وكلاء Codex — النظام يبني نفسه. هذه ليست ادعاءات تسويقية. إنها حقائق تشغيلية أكدها مهندسون متعددون في كلتا الشركتين.

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

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

مشكلة الأرض البنية

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

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

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

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

لماذا كتابة المواصفات أصعب من كتابة الكود

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

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

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

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

هذا هو العنق الزجاجي الحقيقي للمصنع المُظلم. ليس قدرة الذكاء الاصطناعي. ليس البنية التحتية. بل جودة المواصفات. وهي مهارة لم تطورها الصناعة بعد على نطاق واسع.

الانعكاسات التنظيمية

فريق المصنع المُظلم في StrongDM مؤلف من ثلاثة أشخاص. ثلاثة فقط. لا مدير هندسي — لا شيء يُدار. لا Scrum Master — لا سبرينتات تُنسَّق. لا قائد تقني يُجري مراجعات الكود — لا يراجع إنسان الكود. لا فريق ضمان جودة — بنية السيناريوهات تتولى الجودة باستقلالية.

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

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

تنتقل قيمة مدير الهندسة من “تنسيق الفريق لبناء الميزة” إلى “تعريف المواصفة بدقة كافية لبناء الوكلاء للميزة.” تنتقل قيمة مدير الإصدار من “تنسيق النشر عبر الفرق” إلى “تصميم معايير التقييم التي تحدد ما إذا كانت مخرجات الوكيل تُشحن.” يصعب تبرير دور Scrum Master حين لا توجد سبرينتات. طبقات التنسيق الموجودة لإدارة مئات المهندسين الذين يبنون منتجًا يمكن حذفها حين تتولى الوكلاء الهندسة.

المصادر والقراءات الإضافية

• مدونة StrongDM الهندسية — إطار Ben Shapiro وخمسة مستويات البرمجة بالذكاء الاصطناعي
• Anthropic — أفضل ممارسات Claude Code: قاعدة الكود المكتوبة بنسبة 90% بواسطة Claude Code
• دراسة METR — أدوات الذكاء الاصطناعي وإنتاجية المطورين
• OpenAI Codex — منصة التطوير البرمجي المستقل
• The Mythical Man-Month — Brooks, F. P. (1975): الكتاب الكلاسيكي في هندسة البرمجيات
• Stack Overflow 2025 — مسح المطورين: تبني أدوات الذكاء الاصطناعي