حين نشر Robert C. Martin — المعروف بـ"Uncle Bob" — أنه لا يقرأ الكود الذي يولّده الذكاء الاصطناعي، ردّ عليه آلاف المطورين في غضون أربع وعشرين ساعة. منطقه بسيط وحاسم في آنٍ معاً: "لا أراجع الكود للسبب ذاته الذي يجعلني لا أراجع الكود الثنائي الذي يولّده المترجم. تعلّمتُ أن أثق، ضمن حدود معيّنة، بمخرجات الذكاء الاصطناعي المقيّد بالشكل الصحيح."
هذا ليس إهمالاً. إنه موقف هندسي مبني على مبادئ تشكّل عبر أشهر من العمل مع وكلاء البرمجة بالذكاء الاصطناعي — ويأتي مصحوباً بمنهجية صارمة تُعرف بـالهندسة الوكيلية المنضبطة (DAE).
قياس المترجم
في أواخر السبعينيات، اضطر Uncle Bob إلى كتابة مرشّح تصحيح لمترجم معيب — مراجعاً مخرجات الأسمبلي سطراً سطراً. وعبر العقود، بنت الصناعة ثقة كافية في المترجمات حتى توقفنا عن قراءة الكود الثنائي. اكتسبنا هذه الثقة عبر الاختبارات والتحقق الرسمي والأدلة المتراكمة.
مولّدات الكود بالذكاء الاصطناعي اليوم تقف في المكان ذاته الذي وقفت فيه المترجمات عام 1979. لا ينبغي الثقة العمياء بها — لكن لا ينبغي أيضاً فحص كل دالة تنتجها يدوياً. المسار إلى الأمام هو ذاته: بناء حاجز اختبارات يُغني عن المراجعة اليدوية.
يقول Uncle Bob صراحةً: "حين بدأت استخدام الذكاء الاصطناعي كنت أفحص الكود بعناية شديدة. لكن مع مرور الأسابيع والأشهر، تعلّمت الوثوق به ضمن حدود معيّنة. تعرّفت على الظروف التي يمكن الثقة به فيها، وتلك التي تستوجب قيوداً إضافية. اللحن نفسه. يوم مختلف."
مساران من الاختبارات
أساس DAE هو مساران مستقلان من الاختبارات، يُكتبان قبل أي كود إنتاجي:
المسار الأول — اختبارات القبول (Gherkin) يُكتب بالتعاون بين المهندس والذكاء الاصطناعي، باستخدام صياغة Given/When/Then. هذه الاختبارات تُشكّل العقد السلوكي للنظام بلغة الأعمال. لا يُسمح للذكاء الاصطناعي بتعديلها دون إذن صريح.
المسار الثاني — اختبارات الوحدة يكتبها الذكاء الاصطناعي بالكامل. تتحقق من السلوك الداخلي وتفاصيل التنفيذ.
لماذا مساران؟ لأن إرضاء منظورين مستقلين يمنع النموذج من كتابة كود يجتاز فقط الاختبارات التي يتذكر كتابتها. المساران يدفعان الذكاء الاصطناعي إلى التفكير بعمق أكبر في بنية الكود.
خط أنابيب النقاط الثماني
فرماليزت المجتمع البرمجي نهج Uncle Bob في خط أنابيب من ثماني خطوات:
النقطة 0 — الميثاق وتأسيس المشروع. تحديد القواعد غير القابلة للتفاوض: أسلوب الكتابة، الأنماط المحظورة، متطلبات الأمان. الميثاق عقد للقراءة فقط لا يستطيع الذكاء الاصطناعي تعديله.
النقطة 1.5 — نطاق الميزة ومستوى الاستقلالية. كل ميزة تحصل على إعداد استقلالية واضح، من ضيّق (يراجع المهندس كل قرار) إلى فضفاض (يمضي الذكاء الاصطناعي باستقلالية). المسارات الحساسة أمنياً تُعيَّن افتراضياً على الوضع الضيّق.
النقطة 2 — اكتشاف معايير القبول. يتعاون المهندس والذكاء الاصطناعي في استقصاء الحالات الطرفية ومواطن الفشل وقواعد العمل. المخرج: قائمة منظّمة من المعايير القابلة للاختبار.
النقطة 3 — مواصفة Gherkin. تتحول المعايير إلى سيناريوهات Given/When/Then. تُطبَّق هنا قاعدة حرجة تُسمى منع تسرّب التنفيذ: يجب أن تستخدم المواصفات لغة المجال فقط. كتابة "POST to /api/users" مرفوضة، والأصح "user registers with email". هذا يمنع تفاصيل التنفيذ من تلويث طبقة المواصفات.
النقطة 4 — تخطيط البنية المعمارية. يقترح الذكاء الاصطناعي تصميماً يُتحقق منه بالميثاق. يراجع المهندسون البنية المعمارية، لا الكود.
النقطة 5 — التنفيذ. يكتب الذكاء الاصطناعي الكود الإنتاجي واختبارات الوحدة في آنٍ واحد مقابل سيناريوهات Gherkin. يجب أن ينجح كلا المساران قبل المتابعة.
النقطة 6 — المراجعة ثلاثية الأبعاد. فحوصات آلية لفرص إعادة الاستخدام ومعايير جودة الكود والكفاءة. لا تدخّل بشرياً في التنفيذ ما لم يفشل أحد الأبعاد.
النقطة 7 — ملاءمة البنية وتحليل مخاطر التغيير. هل انحرف التنفيذ عن التصميم المتفق عليه؟ هل أدخل ترابطاً غير متوقع؟
النقطة 8 — اختبار الطفرات التفاضلي. الابتكار الجوهري: يُعيد اختبار الطفرات فقط للدوال التي تغيّر كودها أو اختباراتها أو عوامل الطفرة منذ آخر تشغيل. هذا يجعل اختبار الطفرات سريعاً بما يكفي للتشغيل عند كل إيداع.
لماذا تغيّر اختبارات الطفرات كل شيء
تغطية الكود تخبرك أي أسطر نُفّذت. اختبارات الطفرات تخبرك ما إذا كانت اختباراتك تستطيع اكتشاف الأخطاء فعلاً.
الطفرة هي تعديل صغير في الكود الإنتاجي — قلب عامل مقارنة، حذف فحص null، تغيير قيمة إرجاع. إذا لم تكتشف مجموعة الاختبارات الطفرة، فالاختبارات لا تتحقق من ذلك السلوك.
حين لا تقرأ الكود الذي يولّده الذكاء الاصطناعي، تصبح اختبارات الطفرات إشارة الجودة الأولى لديك. يستخدم خط أنابيب DAE الطفرات التفاضلية — يخزّن النتائج عبر التشغيلات ويُعيد الاختبار فقط لما تغيّر — مما يُبقي حلقة التغذية الراجعة في حدود ثلاثين ثانية لمعظم قواعد الكود.
متى تقرأ الكود الاصطناعي؟
لقاعدة "لا تقرأ" حدود واضحة:
- في بداية سياق جديد، قبل اكتساب الثقة
- المسارات الحساسة أمنياً (راجعها يدوياً دائماً)
- حين يفشل اختبار بطريقة لا يمكن تشخيصها من مخرجات الاختبار وحدها
- حين تعمل مع أنظمة ذات عواقب واقعية (تحكم في الأجهزة، المعاملات المالية)
القاعدة: ثقة مكتسبة عبر القيود، تُسحب حين تفشل القيود.
خطوات عملية لتبني DAE
ابدأ بـ Gherkin. قبل أن تطلب من الذكاء الاصطناعي كتابة أي شيء، اكتب ثلاثة إلى خمسة سيناريوهات Gherkin للميزة. استخدم مجلد features/ ومشغّل Cucumber بسيطاً.
احظر تفاصيل التنفيذ في المواصفات. راجع كل معيار قبول: إذا ذكر اسم جدول قاعدة بيانات أو مسار endpoint أو اسم كلاس، احذفه. يجب أن تُقرأ المواصفة كمتطلب منتج، لا كتصميم تقني.
أضف اختبار الطفرات. لـ JavaScript/TypeScript استخدم Stryker؛ لـ Python استخدم mutmut. ابدأ بوحدة واحدة وتوسّع. تتبّع نقاط الطفرات كمقياس في عملية البناء.
حدّد ميثاقك. ملف نصي يُدرج ما يمكن وما لا يمكن للذكاء الاصطناعي فعله — تبعيات لا يضيفها، أنماط يلتزم بها، ملفات لا يُعدّلها. ارجع إليه في بداية كل جلسة.
حدّد مستويات الاستقلالية صراحةً. قبل كل ميزة، قرّر: ضيّق (تراجع البنية) أو متوسط (تراجع الاختبارات) أو فضفاض (الذكاء الاصطناعي يمضي حتى النهاية). أعلن ذلك للذكاء الاصطناعي في بداية الجلسة.
مستودع disciplined-agentic-engineering على GitHub يُرسمن هذه النقاط في سير عمل متوافق مع Claude Code مع سكريبتات hook ومدققي نقاط.
الصورة الأكبر
حقبة "البرمجة بالمزاج" أدخلت الملايين من المطورين إلى البرمجة بمساعدة الذكاء الاصطناعي. DAE هي التصحيح: ليس عودةً إلى المراجعة اليدوية الشاملة، بل إطاراً منظّماً يمتلك فيه المهندسون طبقة المواصفات بينما يمتلك الذكاء الاصطناعي طبقة التنفيذ.
قياس Uncle Bob بالمترجم دقيق تاريخياً. استغرقت الصناعة ثلاثين سنة لتتعلم الثقة بالمترجمات. ستستغرق وقتاً أقل بكثير لتتعلم الثقة بالذكاء الاصطناعي، لأننا نعرف بالفعل كيف يبدو حاجز الاختبارات.
السؤال ليس: هل تقرأ الكود الذي يولّده الذكاء الاصطناعي؟ السؤال هو: هل اختباراتك جيدة بما يكفي حتى لا تحتاج إلى ذلك؟