طوال عام كامل، كان فريق صغير من المطورين يكتب سكربتات shell تلفّ Claude Code و Codex داخل حلقات while. أطلقوا على هذا النمط اسم "Ralph" — وجّه الوكيل نحو هدف، واتركه ينفّذ ويختبر ويراجع ويكرّر حتى يكتمل. حلٌ ملعون لكنه فعّال.
هذا الأسبوع، أطلق كلٌ من Codex CLI و Claude Code الفكرة ذاتها بشكل مدمج. الأمر اسمه /goal، وهو يحوّل وكلاء البرمجة من شركاء محادثة إلى عمّال يقيّمون أنفسهم ويتوقفون فقط عندما تكتمل المهمة بشكل قابل للتحقق.
إن كنت لا تزال تكتب موجّهاً واحداً في كل مرة وتراقب الرموز تتدفق على الشاشة، فهذه هي النقلة التي فاتتك.
من الحوار إلى النتيجة
النموذج الذهني الافتراضي للبرمجة بالذكاء الاصطناعي كان حوارياً: تكتب موجّهاً، يكتب الوكيل بعض الكود، تقرأ الفرق، تصحح، تكرّر. أندريه كارباثي يسمّي هذا "البرمجة بالحدس" — سريعة وبديهية ولكنها هشّة بعد حدٍ معين من التعقيد.
الوكلاء الموجّهون بالهدف يقلبون الحلقة. أنت تُعلن النتيجة ومعايير النجاح. والوكيل يتولّى التكرار:
- التخطيط — تقسيم الهدف إلى مهام فرعية قابلة للتحقق
- التنفيذ — تنفيذ المهمة الفرعية التالية (تعديل كود، تشغيل سكربت، استدعاء أداة)
- الاختبار — تشغيل فحوصات مقابل معايير النجاح
- المراجعة — مقارنة المخرج مع الهدف
- التكرار — اختيار المهمة الفرعية التالية أو التوقف عند الاكتمال
هذه هي حلقة Ralph في خمسة أسطر. أمر /goal في Codex وما يقابله في Claude Code يشغّلان هذه الحلقة دون رقابة بشرية مستمرة.
الإعداد في Codex CLI
وصل الأمر إلى Codex CLI ابتداءً من الإصدار 0.128. لتفعيله، عدّل ملف ~/.codex/config.toml:
[features]
goals = true
[goal]
max_iterations = 40
auto_mode = true
require_tests = trueأعد تشغيل الـ CLI ثم أعطِ هدفاً:
codex
> /goal أضف تدوير رموز JWT للتحديث إلى خدمة المصادقة. يجب أن تنجح الاختبارات الحالية في tests/auth. أضف اختباراً جديداً يتحقق من أن الرمز المُدوَّر يُلغي الرمز السابق.يخطّط Codex للعمل ويعدّل الملفات ويشغّل مجموعة الاختبارات ويقرأ الإخفاقات ويعدّل مرة أخرى ويتوقف حين تصبح معايير النجاح خضراء. ضغطة Shift+Tab تدخل الوضع التلقائي لكي لا يتوقف الوكيل لطلب الإذن بين الخطوات.
Claude Code يستخدم واجهة شبه مطابقة. توافقت الأداتان على الشكل نفسه خلال أسابيع قليلة — إشارة قوية إلى أن هندسة الأهداف هي الافتراضي الجديد وليست نمطاً جانبياً.
كتابة هدف يكتمل فعلاً
أكبر سبب لإخفاق الحلقات الذاتية هو الأهداف الغامضة. سيدور الوكيل إلى الأبد أو يتوقف باكراً إن كان معنى "اكتمل" غير واضح.
الهدف الجيد يتكوّن من ثلاثة أجزاء:
الهدف: <جملة واحدة تصف النتيجة>
القيود: <ملفات، مكتبات، حدود الأداء>
النجاح: <فحوصات قابلة للتحقق>
قارن بين:
# سيئ
/goal اجعل البحث أسرع.
# جيد
/goal خفّض P95 لزمن استجابة GET /search من 480ms إلى أقل من 200ms.
القيود: لا تغيّر الـ API العام، ولا تضف اعتمادية جديدة.
النجاح: إضافة benchmark في tests/perf/search_bench.ts ينجح بالتأكيد على P95 تحت 200ms عبر 1000 طلب على البيانات الأولية.النسخة الجيدة نظام مغلق. يستطيع الوكيل كتابة الـ benchmark وتشغيله ورؤية الرقم والتوقف فقط حين يصبح أخضر. هذا ما يجعل الحلقة قابلة للإنهاء.
أين تتفوّق حلقة Ralph
ثلاث فئات من العمل تتطابق بشكل نظيف مع الوكلاء الموجّهين بالهدف:
- عمليات إعادة الهيكلة الميكانيكية. إعادة تسمية وحدة، الانتقال من ORM إلى آخر، استبدال عميل HTTP عبر ثلاثين ملفاً. معيار النجاح هو "الاختبارات لا تزال تنجح"، وهو شيء تستطيع الحلقة التحقق منه بثمن بخس.
- إصلاح الأخطاء مع إخفاق قابل للتكرار. سلّم للوكيل اختباراً فاشلاً أو stack trace. تدور الحلقة حتى يصبح الأحمر أخضر.
- ضبط الأداء. عرّف benchmark، اضبط هدفاً، اترك الوكيل يجرّب ويقيس ويكرّر. البشر سيّئون في هذا النوع من البحث بالقوة الغاشمة. الوكلاء ليسوا كذلك.
الخيط المشترك: فحص رخيص وحتمي يفصل بين "اكتمل" و"لم يكتمل". بدون ذلك، لن توفّر لك أي حلقة ذاتية الوقت.
أين تنهار
تفشل الوكلاء الموجّهة بالهدف بشكل متوقع في ثلاثة أنماط:
- القرارات التصميمية. "ابنِ نظام إشعارات" يحتمل إجابات صحيحة كثيرة جداً. ستختار الحلقة واحدة وتمضي قُدُماً، وفي الغالب الإجابة الخاطئة.
- التغييرات عبر الأنظمة دون اختبارات محلية. إذا كان التحقق من النجاح يتطلب الوصول إلى بيئة staging أو API مدفوع، فلن يستطيع الوكيل إغلاق الحلقة.
- الاختبارات غير المستقرة. اختبار يفشل مرة من كل خمس مرات سيخدع الوكيل ويدفعه للاعتقاد بأنه أفسد شيئاً لم يفسده. ثم "يصلح" كوداً سليماً.
علاج الأنماط الثلاثة واحد: أبقِ البشر في خطوة التخطيط ودع الوكيل يتولّى التنفيذ. اكتب المواصفة، اكتب اختبار القبول، ثم سلّم الهدف.
السلامة وشروط التوقف
الحلقة الذاتية مع الوضع التلقائي هي بحكم تصميمها وكيل قادر على إحداث ضرر كبير بين لحظة تشغيله ولحظة عودتك. اضبط الحدود قبل أن تضغط Enter:
[goal.safety]
allowed_paths = ["src/**", "tests/**"]
denied_commands = ["rm -rf", "git push", "npm publish"]
require_clean_git = true
max_runtime_minutes = 30
require_human_approval_for = ["migrations", "package.json"]تعامل مع إعدادات الهدف وكأنها سياسة CI. الوكيل أصبح مساهماً يفتح commits دون أن تشاهده — أعطه نفس نطاق التأثير الذي تعطيه لمهندس مبتدئ في أسبوعه الأول.
ما الذي يتغيّر لفرق الهندسة
تتغيّر الاقتصاديات بشكل ملموس. أمر /goal يعمل لأربعين دقيقة على نموذج بسعر 0.10$ لكل مليون رمز يحرق نقوداً حقيقية، وإن أطلقت عشراً منها بالتوازي ستخبرك فاتورتك الشهرية. على فرق منطقة الشرق الأوسط وشمال أفريقيا التي تستخدم بالفعل Claude Code أو Codex على كود إنتاجي أن تخصّص ميزانية لذلك — العمل الموجّه بالهدف أرخص لكل نتيجة من الموجِّهات الحوارية، لكن الإنفاق المطلق لكل مطوّر يرتفع لأن المزيد من العمل يُحاوَل تنفيذه.
التحوّل الآخر هو المراجعة. إن أرسل مطوّر عشرة PRs مدفوعة بالهدف في يوم واحد، يصبح المراجعون عنق الزجاجة. الشركات الأسرع تكيّفاً تربط /goal بقوالب PR أكثر صرامة، وملخصات diff مولّدة آلياً، واختبارات قبول مطلوبة داخل وصف الـ PR. الوكيل يقوم بالكتابة؛ والبشر يحرسون المواصفة والـ diff.
كيف تبدأ غداً
اختر مهمة واحدة في sprint الحالي ذات نتيجة قابلة للتحقق بوضوح. مثالياً خطأ مع اختبار فاشل، أو إعادة هيكلة تغطّيها الاختبارات الموجودة. اكتب الهدف بالشكل الثلاثي أعلاه. شغّله مرة بـ /goal و auto_mode = false لتراقب ما تفعله الحلقة. وفي المهمة التالية، فعّل الوضع التلقائي وابتعد.
أول مرة تعود فيها إلى مجموعة اختبارات خضراء و diff نظيف لم تكتب أنت أيّاً منه، يذوب النموذج الذهني الحواري من تلقاء نفسه. لن تعود إلى الوراء.
حلقة Ralph لم تعد سكربت shell ملعوناً. صارت الافتراضي. السؤال لم يعد هل تستخدمها، بل كم تجيد كتابة الهدف.