أدوات البرمجة بالذكاء الاصطناعي تُنشئ نمط إخفاق يتعرف عليه المهندسون ذوو الخبرة فوراً ويكتشفه المبتدؤون بألم: الوكيل يُبرمج بثقة وبسرعة وبشكل خاطئ.
ليس خاطئاً لأن النموذج سيئ. خاطئاً لأنه لم يُجبر على توضيح افتراضاته قبل البدء. خاطئاً لأنه اختار مساراً معقداً حين كان بسيط موجوداً. خاطئاً لأنه لمس ملفات خارج النطاق المحدد، وحوّل تغييراً في ملفين إلى تغيير في اثني عشر ملفاً، وجعل المراجعة مستحيلة بثقة. خاطئاً لأنه سلّم كوداً اعتقد أنه صحيح دون تأكيد موافقة مجموعة الاختبارات.
الحل ليس نموذجاً أفضل. إنه انضباط هندسي، مُطبَّق على الوكلاء بنفس صرامة تطبيقه على المهندسين البشريين.
نمط الإخفاق الذي لا أحد يذكره
هناك موازٍ في تاريخ كل فريق هندسي: المهندس الجديد الذي يشحن بسرعة بتخطي التحقق ولمس كل شيء قريب. الكود يعمل بشكل معزول. الـ PR ضخم. مراجعة الكود تستغرق ساعتين ولا تزال تفوت شيئاً. الخطأ يظهر بعد أسبوعين في مكان لم يتوقعه أحد، لأن التغيير كان واسعاً جداً للتتبع.
وكلاء البرمجة بالذكاء الاصطناعي يُظهرون هذا الإخفاق على نطاق أوسع وبسرعة أكبر. الوكيل ليس خبيثاً. لا يقطع الزوايا. يفعل ما قيل له، بالطريقة التي بدت له أكثر اكتمالاً، بدون قيود كانت ستُحدد حجم العمل.
الضوابط هي تلك القيود. ليست قيوداً على القدرة. إنها الشروط التي تجعل سرعة الوكيل قابلة للاستخدام.
التفكير قبل البرمجة
الضابط الأول: يجب على الوكيل كشف افتراضاته قبل كتابة الكود.
طلب فيه غموض يستدعي سؤالاً، لا تفسيراً مُدمَجاً بصمت في أول commit. نهجان معقولان يستدعيان اقتراحاً صريحاً بالأبسط منهما مع طلب تأكيد. حل مباشر، حين يوجد، يُذكر قبل بناء حل معقد.
التطبيق هو تعليمة واحدة في CLAUDE.md: لأي تغيير غير تافه، اذكر التفسير، اقترح النهج، واطلب التأكيد قبل أول كتلة كود.
ما يمنعه واضح: ساعات عمل مبنية على متطلب خُطئ في قراءته كان من الممكن توضيحه في ثلاثين ثانية. كل مهندس أول مرّ بهذه المحادثة في نهاية سبرينت. الضابط ينقلها إلى البداية.
المواز الهندسي ينطبق. المهندسون الكبار لا يبدأون الكتابة فوراً حين يُوصف الإشكاليه. يُعيدون صياغة المشكلة ويسألون عن القيود ويؤكدون معايير النجاح. هذا السلوك ليس بطئاً. إنه انضباط يجعل العمل اللاحق أسرع.
البساطة أولاً
الضابط الثاني: الوكيل يكتب الحد الأدنى الذي يحل المشكلة.
لا مرونة غير مستخدمة. لا تجريدات أحادية الاستخدام. لا كود دفاعي لسيناريوهات خارج النطاق. لا إعادة هيكلة للكود المجاور غير المطلوب في الطلب. وصف المهمة هو حد، والوكيل يبقى داخله.
الصيغة الدقيقة لهذا المبدأ: أي إضافة تتجاوز النطاق المُحدد تستلزم طلباً صريحاً. الوكيل الذي يضيف مرونة غير مطلوبة ليس مفيداً. إنه يتخذ قرارات تعود للإنسان. القرارات المعمارية، بشكل خاص، لا ينبغي أن يتخذها الوكيل لأنها بدت معقولة في اللحظة.
ما يمنعه هو زحف الميزات من وكيل البرمجة. كود صحيح تقنياً لكن منتفخ معمارياً. أنظمة تنمو في اتجاهات لم يقررها أحد، لأن الوكيل كان شاملاً.
يجب أن يكون تعريف الإتمام صريحاً في مواصفة المهمة. “نفّذ نقطة نهاية تسجيل الدخول” ليس تعريفاً للإتمام. “نفّذ نقطة نهاية تسجيل الدخول، تُعيد 401 عند بيانات اعتماد غير صالحة، و200 عند النجاح، مع اختبار لكلتا الحالتين” هو تعريف إتمام.
التغييرات الجراحية
الضابط الثالث: الوكيل يلمس فقط الملفات والأسطر المطلوبة.
نمط الإخفاق محدد: الوكيل يُغيّر ترتيب الاستيراد، يُعيد تسمية المتغيرات، يضبط التنسيق، يضيف تعليقات على كود خارج النطاق المُحدد، كل ذلك في نفس الـ commit. الفرق يصبح غير قابل للقراءة. مراجعة الكود تصبح تمرين إعادة بناء. تعارضات الدمج تظهر عبر أعمال غير مترابطة.
اختبار التغيير النظيف مباشر: كل سطر مُعدَّل في الفرق له رابط سببي بالمتطلب المُحدد. إذا تغيّر سطر ولا يمكنك تفسير لماذا كان ضرورياً، فلا يجب أن يكون في الـ commit.
عزل الـ worktree يُطبّق هذا بنيوياً. حين يعمل الوكيل في فرعه الخاص، لا على main، يكون الفرق مرئياً قبل أي مراجعة بشرية. نطاق التغيير قابل للتدقيق قبل قبوله. هذه ليست راحة في المراجعة. إنها خاصية أمان في الإنتاج.
سطح مراجعة الكود تكلفة حقيقية. تغيير بمائتي سطر يلمس المائتي سطر الصحيحة يستغرق وقتاً أقل للمراجعة من تغيير بخمسين سطراً يلمس خمسين سطراً إضافةً إلى مائتي سطر من التنظيف غير المترابط. التغييرات الجراحية ليست تفضيلاً أسلوبياً. إنها متطلب إنتاجية.
التنفيذ المُوجَّه بالهدف
الضابط الرابع: الوكيل يحوّل الطلب إلى معيار قابل للتحقق ويتوقف حين يُحقق ذلك المعيار.
ليس “حاول إصلاح الخطأ.” بل “استنسخ الخطأ، نفّذ الإصلاح، شغّل مجموعة الاختبارات ذات الصلة، أكّد نجاح الاختبار، توقف.”
الفارق مهم لأن الوكلاء الذين لا يملكون شروط خروج صريحة يواصلون تحسين الأشياء خارج النطاق، أو يسلمون كوداً يعتقدون أنه صحيح دون تأكيد موافقة مجموعة الاختبارات. كلاهما مُكلف بطرق مختلفة.
للأخطاء: استنسخ أولاً. إصلاح بدون استنساخ هو تخمين. الوكيل الذي لا يستطيع استنساخ الخطأ يجب أن يقول ذلك قبل تنفيذ أي شيء.
للميزات: عرّف اختبار القبول قبل أول سطر كود. الاختبار يُعرّف ما يعنيه الإتمام. الوكيل يتجه نحو نجاح الاختبار، لا نحو إحساس داخلي بالاكتمال.
مراقبة حالة الخروج هي مهمة الإنسان. سؤال المراجعة ليس “هل يبدو هذا الكود صحيحاً؟” بل “هل تتطابق حالة خروج الوكيل مع المعيار المتفق عليه؟” هذان سؤالان مختلفان بإجابات مختلفة.
كيفية ترميز هذه الضوابط في مشروعك
جميع الضوابط الأربعة لها تطبيقات ملموسة. لا أيٌّ منها يتطلب أدوات مخصصة.
ملف CLAUDE.md بقواعد سلوك صريحة يعالج معظمها: اشترط التفسير + النهج + التأكيد قبل التغييرات غير التافهة؛ اشترط طلباً صريحاً للنطاق لأي إضافات خارج النطاق؛ اشترط أن يكون كل سطر مُعدَّل ضرورياً سببياً؛ اشترط أن تتضمن كل مهمة شرط خروج قابلاً للتحقق.
المهارات، وهي أوامر مائلة قابلة لإعادة الاستخدام مُدمَجة في المشروع، تُعزز الضوابط دون الاعتماد على تذكر المطور لها جلسة بعد جلسة. مهارة scope-check تطلب من الوكيل إدراج كل ملف يخطط للمسه قبل لمس أي منها. مهارة verify-before-commit تشغّل مجموعة الاختبارات وتُبلّغ بالنتيجة قبل كتابة رسالة الـ commit. قالب تعريف الإتمام يُجبر المطور على كتابة اختبار القبول قبل تعيين المهمة للوكيل.
التأثير المركب قابل للقياس. مشروع يُرمّز هذه الضوابط يتطور أسرع من مشروع بدونها، لأن إعادة العمل تنخفض مع ازدياد الثقة في مخرجات الوكيل. الجلسة الأولى مع الضوابط قد تبدو أبطأ. بحلول الأسبوع الثالث، الفرق في الديون المتراكمة يصبح واضحاً.
هناك أيضاً ديناميكية فريق تستحق الذكر. الضوابط تجعل مراجعة الكود قابلة للتنفيذ. حين يكون الفرق جراحياً ومعيار الخروج صريحاً، يعرف المراجعون ما يبحثون عنه. وقت المراجعة ينخفض. كمون الدمج ينخفض. التأثير المركب على وقت الدورة أكبر مما تُنتجه أي ضابطة منفردة بذاتها.
النمط التنظيمي الذي ينجح: أدخل الضوابط الأربع في السبرينت الأول، لا واحدة في كل مرة. الضوابط تتفاعل. تنفيذ مُوجَّه بالهدف بدون بساطة أولاً لا يزال ينتج انتفاخاً. تغييرات جراحية بدون التفكير أولاً لا تزال تُنتج الشيء الخاطئ بدقة. جميع الأربعة معاً يُنشئون حلقة مغلقة حيث يبقى الوكيل في النطاق ويؤكد تفسيره ويُجري تغييرات دنيا ويتوقف عند معيار قابل للقياس.
هذه الضوابط ليست قيوداً على الوكيل. إنها الشروط التي تجعل سرعة الوكيل أصلاً لا التزاماً. السرعة بدون انضباط تتراكم أسرع مما تُشحن. السرعة ضمن الضوابط تُشحن.
ملف CLAUDE.md في مستودعك هو آلية التطبيق. إذا كان لا يُحدد ما يجب على الوكيل فعله قبل كتابة الكود، سيتخذ الوكيل ذلك القرار بنفسه.
ذات صلة: Claude Code ليس مساعد برمجي. إنه نظام تسليم. والبرمجة بالتحسس استراتيجية نماذج أولية، لا استراتيجية إنتاج