مصنع البرمجيات: التطوير بالذكاء الاصطناعي دون مراجعة بشرية للكود
المصدر: Software Factory بقلم Simon Willison (٧ فبراير ٢٠٢٦)
يغطي Simon Willison كيف نفّذ فريق الذكاء الاصطناعي في StrongDM ما يسميه Dan Shapiro مستوى "Dark Factory" في تبني الذكاء الاصطناعي — حيث لا يكتب أي إنسان أو حتى يراجع الكود الذي تنتجه coding agents. تقريرهم الكامل: Software Factories and the Agentic Moment.
المبادئ الأساسية
يعمل فريق الذكاء الاصطناعي في StrongDM (تأسس في يوليو ٢٠٢٥، ٣ أشخاص فقط) تحت قيود جذرية:
- الكود يجب ألا يُكتب بواسطة البشر
- الكود يجب ألا يُراجع بواسطة البشر
- إذا لم تنفق على الأقل ١٬٠٠٠ دولار يومياً على tokens لكل مهندس، فإن مصنع البرمجيات لديك لا يزال قابلاً للتحسين
المحفز: مع Claude 3.5 Sonnet المراجعة الثانية (أكتوبر ٢٠٢٤)، بدأت سير عمل البرمجة الوكيلية طويلة المدى في تراكم الصحة بدلاً من تراكم الأخطاء. نقطة التحول في نوفمبر ٢٠٢٥ (Claude Opus 4.5، GPT 5.2) حسّنت الموثوقية بشكل أكبر.
الابتكار الرئيسي #١: اختبارات السيناريوهات كمجموعات محجوبة
المشكلة: إذا كتبت الـ agents كلاً من التنفيذ والاختبارات، يمكنها الغش (assert true). كيف تثبت أن البرمجيات التي أنتجتها agents تعمل فعلاً؟
الحل: الاقتباس من التعلم الآلي — معاملة سيناريوهات الاختبار مثل المجموعات المحجوبة (holdout sets) في تدريب النماذج:
- قصص مستخدم شاملة مخزنة خارج قاعدة الكود، غير مرئية لـ coding agents
- الانتقال من نجاح/فشل ثنائي إلى رضا احتمالي: "من جميع المسارات الملاحظة عبر جميع السيناريوهات، ما النسبة التي من المرجح أن تُرضي المستخدم؟"
- تكرار فعال لاختبارات QA الخارجية المكثفة — مكلفة تاريخياً لكنها فعالة للغاية
لماذا يهم هذا للمطورين: هذا يعيد صياغة فلسفة الاختبار من "هل يفعل هذا الكود ما طلبته منه" نحو "هل يُرضي هذا النظام المستخدمين عبر سيناريوهات واقعية." إنه تحول في التفكير من صحة اختبارات الوحدة إلى التحقق السلوكي.
الابتكار الرئيسي #٢: Digital Twin Universe (DTU)
المشكلة: لا يمكنك تشغيل آلاف اختبارات التكامل في الساعة ضد واجهات SaaS API حقيقية (حدود المعدل، التكاليف، كشف إساءة الاستخدام).
الحل: جعل coding agents تبني نسخاً سلوكية من خدمات الطرف الثالث:
- بنوا twins لـ Okta وJira وSlack وGoogle Docs وGoogle Drive وGoogle Sheets
- نسخ واجهات API الخاصة بها وحالاتها الحدية وسلوكياتها الملاحظة
- إدخال وثائق API العامة الكاملة في harness الـ agent لإنتاج ملفات Go ثنائية مستقلة
- وضع واجهات مستخدم مبسطة فوقها للمحاكاة الكاملة
النقلة النوعية: إنشاء نسخ عالية الدقة من تطبيقات SaaS كان دائماً ممكناً لكنه لم يكن أبداً مجدياً اقتصادياً. LLM agents تخفض تكلفة بناء هذه النسخ بشكل كبير. الآن يمكنك:
- التحقق بأحجام تتجاوز حدود الإنتاج
- اختبار أوضاع الفشل التي ستكون خطرة ضد الخدمات الحية
- تشغيل آلاف السيناريوهات في الساعة دون حدود معدل أو تكاليف API
لماذا يهم هذا للمطورين: حتى لو لم تكن تبني "مصنع برمجيات" كاملاً، فإن مفهوم DTU قابل للتطبيق مباشرة. أي فريق يجري اختبارات تكامل ضد واجهات API خارجية يمكنه الاستفادة من service mocks المولدة بواسطة agents والتي تتجاوز بكثير الـ stubs المكتوبة يدوياً.
الابتكار الرئيسي #٣: تقنيات Agents قابلة لإعادة الاستخدام
نشرت StrongDM عدة أنماط مسماة على صفحة التقنيات الخاصة بها:
| التقنية | الوصف | التطبيق للمطورين |
|---|---|---|
| Gene Transfusion | تستخرج الـ Agents أنماطاً من الأنظمة الحالية وتعيد استخدامها في أماكن أخرى | ترحيل الأنماط المعمارية بين الخدمات تلقائياً |
| Semports | نقل مباشر للكود من لغة إلى أخرى | عمليات ترحيل عبر اللغات (مثلاً خدمة Python إلى Go) |
| Pyramid Summaries | مستويات ملخصات متعددة — تعدد الـ agents الملخصات القصيرة أولاً، ثم تتعمق في التفاصيل حسب الحاجة | إدارة قواعد الكود الكبيرة مع agents؛ تحميل السياق التدريجي |
الابتكار الرئيسي #٤: برمجيات Agents مدفوعة بالمواصفات (Attractor)
أصدرت StrongDM أداة Attractor — coding agent غير تفاعلي — كمستودع يحتوي على صفر كود. فقط ثلاثة ملفات markdown تصف المواصفات بتفصيل دقيق، مع تعليمات لإدخالها في coding agent من اختيارك.
هذا يمثل تحولاً حيث المواصفات هي توزيع البرمجيات. الافتراض: أي coding agent كفء يمكنه التنفيذ من مواصفات جيدة بما فيه الكفاية.
خلاصات عملية
-
فصل كتابة الاختبارات عن كتابة الكود: حتى دون الذهاب إلى "dark factory" الكاملة، الاحتفاظ بتعريفات السيناريوهات خارج السياق المرئي للـ agent يمنع التلاعب.
-
الاستثمار في محاكاة البيئة: service mocks/twins المولدة بواسطة agents أصبحت الآن مجدية اقتصادياً وتحسن إنتاجية الاختبار بشكل كبير.
-
التحقق الاحتمالي بدلاً من الاختبارات الثنائية: فكر في قياس "معدلات الرضا" عبر مسارات السيناريوهات بدلاً من مجرد مجموعات اختبار نجاح/فشل.
-
إدارة السياق التدريجية: تساعد Pyramid Summaries الـ agents على التنقل في قواعد الكود الكبيرة دون تجاوز نافذة السياق.
-
التطوير بالمواصفات أولاً: المواصفات المكتوبة جيداً تصبح المنتج الأساسي؛ التنفيذ يصبح قابلاً للاستبدال.
فحص واقعية التكاليف
هدف ١٬٠٠٠ دولار/يوم لكل مهندس (٢٠٬٠٠٠ دولار/شهر) يطرح تساؤلات جدية حول الجدوى الاقتصادية. يشير Willison إلى أن هذا يجعل النهج "أقل إثارة للاهتمام بكثير" عند هذا المستوى السعري — يصبح تمريناً في نموذج الأعمال وليس تقنية عالمية. بالإضافة إلى ذلك، يمكن للمنافسين نظرياً استنساخ الميزات بساعات قليلة من عمل agents، مما يتحدى الخنادق البرمجية التقليدية.
بالنسبة للمطورين الأفراد والفرق الأصغر، الأنماط المفاهيمية (اختبار المجموعات المحجوبة، DTU، Pyramid Summaries) قيّمة حتى عند مستويات إنفاق أقل بكثير مثل خطة Claude Max بـ ٢٠٠ دولار/شهر.