الناس يستمرون في السؤال عن كيفية إدارة وكلاء البرمجة. إليك النظام الفعلي. النقطة الأساسية: جلسة برمجة ذكاء اصطناعي طويلة واحدة هشة. يجمع السياق، ويهلوس، ويتوقف عن العمل. لذا بدلا من ماراثون واحد، أجري العديد من السباقات السريعة. كل جلسة وكيل تبدأ من جديد وتستأنف من حيث انتهت الجلسة السابقة عبر سجل git وحالة الملف. يسمى هذا "حلقة رالف". يقوم سكريبت التغليف بتشغيل وكيل ترميز بنفس التعليمات مرارا حتى يتم الانتهاء من العمل. إذا توقفت أو تعطل — لا مشكلة. النسخة التالية تبدأ نظيفة بدون أي أعباء. أستخدم Opus 4.6 للتخطيط — كتابة PRDs، تحليل البنية، تحديد مواصفات المهام. ثم يتولى Codex 5.3 تنفيذ البرمجة الفعلي. وجدنا أن هذا التقسيم ينتج أكثر الكود موثوقية وجودة مع أقل مشاكل في إصلاح الأخطاء أو المتابعة. أكتب PRD كقائمة تحقق للتخفيض. تتحقق الحلقة من صحة الإكمال من خلال التحقق مما إذا كانت جميع المربعات قد تم تحديدها. الوكيل يدعي أن الأمر تم لكن تبقى 12 من أصل 47 مهمة؟ أعدت التشغيل. لا تفاوض مع نموذج مشوش. الوكلاء يركضون في جلسات TMUX حتى ينجوا من إعادة التشغيل. أراقبها على نبض قلب — إذا مات أحدهم، أعيد تشغيله تلقائيا. إذا توقف أحدهم (نفس النتيجة لفحصين متتاليين)، أوقف اللعبة وأعد التشغيل. كل جلسة tmux تتضمن خطاف استيقاظ في النهاية: عندما ينتهي الوكيل، يطلق حدثا يرسلني فورا. لا إكمال صامت. أعرف اللحظة التي ينتهي فيها العمل، سواء كنت أراقب أم لا. في الأيام الجيدة أشغل 3-4 وكلاء بالتوازي في مشاريع منفصلة، كل منها في شجرة عمل git خاصة به. الأسبوع الماضي قمت بتنفيذ 108 مهام عبر 3 مشاريع في نفس الوقت خلال حوالي 4 ساعات. المفتاح الآخر: المحفزات المعتمدة على الاختبار. أطلب من الوكيل كتابة اختبارات فاشلة أولا، ثم تنفيذها. الاختبارات هي معايير قبول حتمية للعامل غير الحتمي. يقلل بشكل كبير من الفشل بعد الدمج. ليس سحرا. إنها هندسة عمليات مطبقة على العمل بالذكاء الاصطناعي. مسح المواصفات، التحقق التلقائي، إعادة التشغيل عند العالق، التحقق من المخرجات. هذا أحد أكثر الأسئلة شيوعا التي أتلقاها، لذا سأكتب هذا بشكل صحيح وأضيفه كفصل جديد في كتاب "كيفية توظيف ذكاء اصطناعي". كل من اشترى بالفعل سيحصل على النسخة المحدثة.