1~
2في المرة الأولى التي يقوم فيها وكيل ترميز بإصلاح خطأ لك، يكون رد الفعل هو نفسه دائمًا تقريبًا: مزيج من الحماس والشك. لطيف، بالتأكيد. ولكن بعد ذلك تنظر إلى الفرق وتسأل نفسك: "حسنًا، ولكن ما الذي لمسه بالضبط؟ هل يمكنني الوثوق به؟ هل سيفعل ذلك مرة أخرى بنفس الطريقة غدًا؟".
3~
4هذا هو المكان الذي أعتقد أن الجزء المثير للاهتمام يبدأ فيه. ليس عندما يكتب الوكيل وظيفة، ولكن عندما يصبح قادرًا بما يكفي لتولي أجزاء كاملة من العمل: اقرأ المستودع، وأنشئ تصحيحًا، وقم بإجراء الاختبارات، وافتح العلاقات العامة، ثم ارجع بعد تعليق المراجعة. يتحرك Codex على وجه التحديد في هذا الاتجاه: العمل في الخلفية، وأشجار العمل المنفصلة، ​​والمتصفح المتكامل، والأتمتة، والمكونات الإضافية، والذاكرة، وضوابط الأذونات الأكثر وضوحًا.
5~
6لا يتعلق الأمر بتخيل مستقبل لا يقرأ فيه أحد التعليمات البرمجية بعد الآن. سيكون المستقبل رهيبًا، وساذجًا أيضًا. الهدف هو معرفة كيفية العمل مع الوكلاء الذين يمكنهم فعل الكثير دون السماح لهم بفعل كل شيء.
7~
8## تغيير العادة
9~
10مع الإكمال التلقائي التقليدي، كنت دائمًا خلف عجلة القيادة. اقترح الذكاء الاصطناعي سطرًا، أنت من قررت ذلك. ومع ذلك، تتغير العلاقة مع الوكيل: فأنت تعطيه هدفًا ويمر بخطوات متعددة بمفرده.
11~
12وهذا أمر قوي، لكنه يغير المشكلة. لم يعد السؤال مجرد "هل يمكن للبرنامج النموذجي؟". ويصبح السؤال:
13~
14- هل أعطيته نطاقًا صغيرًا بما يكفي؟
15- هل تعرف كيفية التحقق من النتيجة؟
16- هل أعمل في بيئة معزولة؟
17- هل المراجعة النهائية لا تزال إنسانية ودقيقة؟
18~
19يبدو سير العمل الصحي أشبه بهذا من كونه عصا سحرية:
20~
21```mermaid
22flowchart LR
23    Idea[مهمة إنسانية] --> Scope[غرض صغير يمكن التحقق منه]
24    Scope --> Agent[عامل في شجرة العمل معزولة]
25    Agent --> Checks[اختبار، لينت، بناء، متصفح]
26    Checks --> Review[مراجعة بشرية]
27    Review --> Merge[دمج أو تكرار جديد]
28    Review --> Iterate[تعليقات دقيقة على الفرق]
29    Iterate --> Agent
30```
31~
32يبدو الأمر أقل رومانسية من عبارة "الوكيل يبني كل شيء"، لكنه يعمل بشكل أفضل بكثير. وهي أيضًا الطريقة التي تعمل بها الفرق التي تجيد التعامل مع البشر: مهام واضحة، وردود فعل سريعة، ومساءلة صريحة.
33~
34## إن المطالبة الجيدة تكاد تكون تذكرة جيدة
35~
36المطالبة الأكثر خطورة هي تلك الغامضة ولكن الواثقة: "إصلاح صفحة الفواتير"، "تحسين البنية"، "تنظيف وحدة المصادقة". هذه هي الطلبات التي تبدو منتجة وتولد اختلافات كبيرة. ولكن بعد ذلك تجد نفسك تقوم بعلم الآثار.
37~
38المطالبة المفيدة أكثر مملة. على سبيل المثال: تنفيذ تصدير CSV لصفحة الفواتير، مع العلم أن الجدول موجود في `app/(dashboard)/invoices/page.tsx`، والاستعلامات موجودة في `src/server/invoices.ts` ويوجد بالفعل نمط مشابه في `app/(dashboard)/reports`.
39~
40ثم أضف قيودًا واضحة: لا تغير مخطط قاعدة البيانات، ولا تضف تبعيات إذا كانت الأداة المساعدة الصغيرة كافية، واحتفظ بنمط واجهة المستخدم الحالي. وأغلق التحقق: `npm test -- invoices` و`npm run build`.
41~
42هذا النوع من الموجز ليس "لشرح أفضل للذكاء الاصطناعي". إنه يخدم قبل كل شيء لتوضيح ما تقوم بتفويضه لك. إذا لم تتمكن من تدوينها بشكل ملموس، فربما لم تكن المهمة جاهزة للوكيل بعد.
43~
44## ثلاث وظائف أفوضها عن طيب خاطر
45~
46الأول هو عمل متكرر ولكن يمكن التحقق منه: إضافة الاختبارات، وترحيل الاستدعاءات إلى واجهة برمجة تطبيقات داخلية جديدة، وتحديث الواردات، واستبدال المكونات المهملة، وإصلاح أخطاء TypeScript. هنا يمكن للوكيل توفير ساعات ويمكن السيطرة على المخاطر.
47~
48والثاني هو العمل الاستكشافي: "ابحث عن مكان حساب هذا الإجمالي"، "اشرح لي سبب هشاشة هذا الاختبار"، "أعد إنتاج الخطأ وأخبرني بالملفات التي يبدو أنها متأثرة". وحتى عندما لا تنتج رقعة على الفور، يمكنها القيام باستطلاع مفيد.
49~
50والثالث هو أعمال الصيانة المتكررة: تحديثات التبعية الصغيرة، وتنظيف علامات الميزات القديمة، وملخص العلاقات العامة المحظورة، والتحقق من المهام المنسية. إنه ليس براقًا، لكنه بالضبط نوع العمل الذي يميل إلى التراكم.
51~
52## ثلاث وظائف أحتفظ بها كإنسان
53~
54تظل قرارات المنتج بشرية. إذا أدى التغيير إلى تغيير طريقة دفع المستخدم، أو حذف البيانات، أو الاطلاع على الأسعار، أو فهم الإذن، فأنا أريد شخصًا مسؤولاً.
55~
56تستحق الحدود الأمنية أيضًا اهتمامًا إنسانيًا: المصادقة، والأدوار، والرموز المميزة، وتسجيل البيانات الحساسة، وترحيل قاعدة البيانات. يمكن للوكيل المساعدة في التنفيذ، ولكن ليس من الضروري أن يكون صانع القرار الوحيد.
57~
58وأخيراً أحافظ على كل ما يتطلب الذوق المعماري الإنساني. يمكن للوكيل أن يقترح إعادة البناء، لكن فهم ما إذا كان التجريد ضروريًا حقًا أو ما إذا كنا نقوم فقط بتلميع مشكلة غير موجودة يظل مهمة.
59~
60## المراجعة ليست اختيارية
61~
62الإغراء، عندما يكون الوكيل جيدًا، هو الوثوق باللون الأخضر لـ CI. إنه أمر مفهوم. إنه أيضًا عندما تبدأ المشاكل.
63~
64أنظر دائمًا إلى خمسة أشياء على الأقل:
65~
661. هل التصحيح يحل المهمة المطلوبة فقط؟
672. هل لمس ملفات لا علاقة لها بها؟
683. هل تغطي الاختبارات سلوكًا جديدًا أم مجرد فرصة سعيدة؟
694. هل يتبع الكود الأنماط المحلية؟
705. هل يتم التعامل مع الأخطاء كما هو الحال في بقية المشروع؟
71~
72عندما يكون هناك خطأ ما، يجب أن تكون ردود الفعل محددة. "إصلاحه" كسول. الأفضل: تقوم هذه الأداة بتكرار `parseMoney` إلى `src/lib/money.ts`؛ أعد استخدام هذه الوظيفة، وأضف اختبارًا لحالة EUR ولا تقم بتغيير واجهة برمجة التطبيقات العامة لوحدة الفوترة.
73~
74يستجيب الوكلاء بشكل أفضل للتعليقات الصغيرة التي يمكن التحقق منها. ومن الغريب أن الناس كذلك.
75~
76## الدرابزين يستحق هذا الجهد
77~
78إذا كان الوكيل قادرًا على قراءة الملفات وكتابة التعليمات البرمجية وتنفيذ الأوامر، فيجب التعامل معها على أنها عملية قوية. ليست هناك حاجة لجنون العظمة، أنت بحاجة إلى النظافة.
79~
80استخدم أشجار عمل أو فروع منفصلة. لذا يمكنك مقارنة الاختلافات، والتخلص من التجارب الفاشلة، وعدم الخلط بين عمل الوكيل وما كنت تفعله.
81~
82الحد من الأذونات. أوامر مثل `rg`، `git diff`، `npm test` و`npm run build` يمكن أن تكون مجانية تمامًا. يجب أن تظل عمليات النشر وترحيل قاعدة البيانات والوصول إلى الأسرار والأوامر المدمرة صريحة.
83~
84تقليل الوصول إلى الشبكة عندما لا تحتاج إليها. بالنسبة للعديد من المهام، تعد الوثائق الرسمية وتسجيل الحزم والخدمات الداخلية المحددة كافية. مساحة سطح أقل، مفاجآت أقل.
85~
86تتبع الإجراءات. عندما يصل التصحيح إلى المراجعة، يجب أن تكون قادرًا على إعادة بناء المطالبات والأوامر المنفذة والاختبارات التي تم اجتيازها وتعديل الملفات. ليس لخلق البيروقراطية، ولكن لتكون قادرًا على فهم ما حدث إذا حدث خطأ ما.
87~
88## طريقة سهلة للبدء كفريق
89~
90إذا كنت سأقدم عملاء إلى فريق صغير، سأبدأ بدون ثورات كبيرة.
91~
92سأقوم بإنشاء علامة `agent-ready` للمشكلات ذات النطاق الواضح. أود إضافة قالب يحتوي على السياق والقيود وأوامر التحقق. أود أن أطلب علاقات عامة صغيرة، ومن الأفضل أن تكون أقل من بضع مئات من الأسطر. سأطلب اختبارًا أو لقطات شاشة للتغييرات المرئية. وقبل كل شيء سأبقي شخصًا مسؤولاً عن الدمج.
93~
94بعد أسبوعين، كنت ألقي نظرة على البيانات: ما هي المهام التي تم تسريعها بالفعل، وما هي المراجعات التي كانت ثقيلة، وما هي المطالبات التي كانت مربكة، وما هي أجزاء قاعدة التعليمات البرمجية الهشة للغاية بحيث لا يمكن تفويضها.
95~
96إنها طريقة أقل إثارة من عبارة "بدءًا من اليوم سنفعل كل شيء مع الوكلاء"، ولكنها الطريقة التي تسمح لك بالوصول إلى الأسبوع الثالث دون أي ندم.
97~
98## الجزء الأكثر إنسانية
99~
100والأمر المضحك هو أنه كلما أصبح العملاء أكثر استقلالية، زادت أهمية المهارات الكلاسيكية مرة أخرى: كتابة تذكرة جيدة، وإجراء تخفيضات صغيرة، وإنشاء الاختبارات، وقراءة الفروق، وتوصيل المقايضات. يقوم الوكيل بتسريع أولئك الذين يعرفون بالفعل كيفية العمل بشكل جيد. كما أنه يزيد من فوضى أولئك الذين يفوضون بشكل سيئ.
101~
102لذلك لا، لا أرى أن سير العمل متعدد الوكلاء هو اختصار للتوقف عن القيام بالأعمال الهندسية. أراها وسيلة لتحويل المزيد من الطاقة إلى الأجزاء المهمة: تحديد ما سيتم بناؤه، والتأكد من أنه يعمل، وإبقاء النظام مفهومًا.
103~
104يمكن للوكلاء تكوين زملاء غير متزامنين رائعين. لكن الزميل غير المتزامن، لكي يكون مفيدًا، يحتاج إلى سياق وحدود ومراجعة. تماما مثل أي شخص آخر.
105~
106## مصادر مفيدة
107~
108- [المخطوطة لكل شيء (تقريبًا) - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [تشغيل Codex بأمان في OpenAI](https://openai.com/index/running-codex-safely/)
110- [تقديم الدستور الغذائي - OpenAI](https://openai.com/index/introducing-codex/)
111- [ما الجديد في وكيل ترميز GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~