عند العبث مؤخرًا بأدوات LLM CLI (مثل Codex / Claude Code / Gemini CLI)، اكتشفت أن “التنفيذ التلقائي” لا ينبغي أن يكون خيارين فقط: إمّا تسأل في كل خطوة، أو تترك الأمور على هواها. خذ Codex مثالًا: فهو يقسّم الأتمتة إلى وضعين أكثر عملية:
1) أتمتة مُتحكَّم بها: --full-auto (تلقائي لكن بحدود)
الفكرة الأساسية هي “فتح داخل المشروع، والفرملة عند تجاوز الحدود”:
- داخل مساحة العمل يمكنه تعديل الملفات وتشغيل الأوامر تلقائيًا، ما يقلّل التأكيدات المتكررة
- عند التعامل مع ملفات خارج مساحة العمل (مثل
~/.zshrcو/etc/hosts) أو عند الوصول إلى الشبكة، سيتوقف ليطلب منك التأكيد
مناسب لجهاز التطوير اليومي الأساسي: كفاءة عالية مع بقاء نقاط المخاطر الحرجة تحت السيطرة.
2) أتمتة قصوى: --dangerously-bypass-approvals-and-sandbox (--yolo)
الفكرة الأساسية هي “تجاوز الموافقات + إيقاف العزل (sandbox)”:
- بلا سؤال، بلا اعتراض، شبه فتح كامل
- الخطر ليس فقط أن يخرّب الكود (وهذا يمكن التراجع عنه)، بل في إعدادات النظام، تثبيت البرامج، جلب الاعتماديات عبر الشبكة… وهي أفعال لا يستطيع Git ضبطها
لا يُنصح به إلا داخل Docker/آلة افتراضية/بيئة مؤقتة لاستخدام قصير، ثم تُتلف بعد الانتهاء؛ ولا تُفعِّله على جهازك الأساسي أو بيئة الإنتاج.
إضافة: تقليل النوافذ المنبثقة لا يعني إيقاف العزل
إن كنت فقط منزعجًا من كثرة التأكيدات، يمكنك الإبقاء على عزل مساحة العمل (workspace sandbox)، وتعديل سياسة الموافقات فقط (مثلًا: تقليل الأسئلة داخل المشروع، مع استمرار المنع عند تجاوز الحدود).
خلاصة بجملة واحدة
استخدم “الأتمتة المُتحكَّم بها” يوميًا، و“YOLO” للتجارب فقط؛ إذا أمكن تفعيل العزل فلا تُطفئه، وإذا أمكن الإبقاء على الموافقات فلا تُلغِها.
النص الأصلي: https://www.einverne.info/post/806.html