في المرة الأولى التي يقوم فيها وكيل ترميز بإصلاح خطأ لك، يكون رد الفعل هو نفسه دائمًا تقريبًا: مزيج من الحماس والشك. لطيف، بالتأكيد. ولكن بعد ذلك تنظر إلى الفرق وتسأل نفسك: "حسنًا، ولكن ما الذي لمسه بالضبط؟ هل يمكنني الوثوق به؟ هل سيفعل ذلك مرة أخرى بنفس الطريقة غدًا؟".

هذا هو المكان الذي أعتقد أن الجزء المثير للاهتمام يبدأ فيه. ليس عندما يكتب الوكيل وظيفة، ولكن عندما يصبح قادرًا بما يكفي لتولي أجزاء كاملة من العمل: اقرأ المستودع، وأنشئ تصحيحًا، وقم بإجراء الاختبارات، وافتح العلاقات العامة، ثم ارجع بعد تعليق المراجعة. يتحرك Codex على وجه التحديد في هذا الاتجاه: العمل في الخلفية، وأشجار العمل المنفصلة، ​​والمتصفح المتكامل، والأتمتة، والمكونات الإضافية، والذاكرة، وضوابط الأذونات الأكثر وضوحًا.

لا يتعلق الأمر بتخيل مستقبل لا يقرأ فيه أحد التعليمات البرمجية بعد الآن. سيكون المستقبل رهيبًا، وساذجًا أيضًا. الهدف هو معرفة كيفية العمل مع الوكلاء الذين يمكنهم فعل الكثير دون السماح لهم بفعل كل شيء.

تغيير العادة

مع الإكمال التلقائي التقليدي، كنت دائمًا خلف عجلة القيادة. اقترح الذكاء الاصطناعي سطرًا، أنت من قررت ذلك. ومع ذلك، تتغير العلاقة مع الوكيل: فأنت تعطيه هدفًا ويمر بخطوات متعددة بمفرده.

وهذا أمر قوي، لكنه يغير المشكلة. لم يعد السؤال مجرد "هل يمكن للبرنامج النموذجي؟". ويصبح السؤال:

• هل أعطيته نطاقًا صغيرًا بما يكفي؟
• هل تعرف كيفية التحقق من النتيجة؟
• هل أعمل في بيئة معزولة؟
• هل المراجعة النهائية لا تزال إنسانية ودقيقة؟

يبدو سير العمل الصحي أشبه بهذا من كونه عصا سحرية:

يبدو الأمر أقل رومانسية من عبارة "الوكيل يبني كل شيء"، لكنه يعمل بشكل أفضل بكثير. وهي أيضًا الطريقة التي تعمل بها الفرق التي تجيد التعامل مع البشر: مهام واضحة، وردود فعل سريعة، ومساءلة صريحة.

إن المطالبة الجيدة تكاد تكون تذكرة جيدة

المطالبة الأكثر خطورة هي تلك الغامضة ولكن الواثقة: "إصلاح صفحة الفواتير"، "تحسين البنية"، "تنظيف وحدة المصادقة". هذه هي الطلبات التي تبدو منتجة وتولد اختلافات كبيرة. ولكن بعد ذلك تجد نفسك تقوم بعلم الآثار.

المطالبة المفيدة أكثر مملة. على سبيل المثال: تنفيذ تصدير CSV لصفحة الفواتير، مع العلم أن الجدول موجود في app/(dashboard)/invoices/page.tsx، والاستعلامات موجودة في src/server/invoices.ts ويوجد بالفعل نمط مشابه في app/(dashboard)/reports.

ثم أضف قيودًا واضحة: لا تغير مخطط قاعدة البيانات، ولا تضف تبعيات إذا كانت الأداة المساعدة الصغيرة كافية، واحتفظ بنمط واجهة المستخدم الحالي. وأغلق التحقق: npm test -- invoices وnpm run build.

هذا النوع من الموجز ليس "لشرح أفضل للذكاء الاصطناعي". إنه يخدم قبل كل شيء لتوضيح ما تقوم بتفويضه لك. إذا لم تتمكن من تدوينها بشكل ملموس، فربما لم تكن المهمة جاهزة للوكيل بعد.

ثلاث وظائف أفوضها عن طيب خاطر

الأول هو عمل متكرر ولكن يمكن التحقق منه: إضافة الاختبارات، وترحيل الاستدعاءات إلى واجهة برمجة تطبيقات داخلية جديدة، وتحديث الواردات، واستبدال المكونات المهملة، وإصلاح أخطاء TypeScript. هنا يمكن للوكيل توفير ساعات ويمكن السيطرة على المخاطر.

والثاني هو العمل الاستكشافي: "ابحث عن مكان حساب هذا الإجمالي"، "اشرح لي سبب هشاشة هذا الاختبار"، "أعد إنتاج الخطأ وأخبرني بالملفات التي يبدو أنها متأثرة". وحتى عندما لا تنتج رقعة على الفور، يمكنها القيام باستطلاع مفيد.

والثالث هو أعمال الصيانة المتكررة: تحديثات التبعية الصغيرة، وتنظيف علامات الميزات القديمة، وملخص العلاقات العامة المحظورة، والتحقق من المهام المنسية. إنه ليس براقًا، لكنه بالضبط نوع العمل الذي يميل إلى التراكم.

ثلاث وظائف أحتفظ بها كإنسان

تظل قرارات المنتج بشرية. إذا أدى التغيير إلى تغيير طريقة دفع المستخدم، أو حذف البيانات، أو الاطلاع على الأسعار، أو فهم الإذن، فأنا أريد شخصًا مسؤولاً.

تستحق الحدود الأمنية أيضًا اهتمامًا إنسانيًا: المصادقة، والأدوار، والرموز المميزة، وتسجيل البيانات الحساسة، وترحيل قاعدة البيانات. يمكن للوكيل المساعدة في التنفيذ، ولكن ليس من الضروري أن يكون صانع القرار الوحيد.

وأخيراً أحافظ على كل ما يتطلب الذوق المعماري الإنساني. يمكن للوكيل أن يقترح إعادة البناء، لكن فهم ما إذا كان التجريد ضروريًا حقًا أو ما إذا كنا نقوم فقط بتلميع مشكلة غير موجودة يظل مهمة.

المراجعة ليست اختيارية

الإغراء، عندما يكون الوكيل جيدًا، هو الوثوق باللون الأخضر لـ CI. إنه أمر مفهوم. إنه أيضًا عندما تبدأ المشاكل.

أنظر دائمًا إلى خمسة أشياء على الأقل:

1. هل التصحيح يحل المهمة المطلوبة فقط؟
2. هل لمس ملفات لا علاقة لها بها؟
3. هل تغطي الاختبارات سلوكًا جديدًا أم مجرد فرصة سعيدة؟
4. هل يتبع الكود الأنماط المحلية؟
5. هل يتم التعامل مع الأخطاء كما هو الحال في بقية المشروع؟

عندما يكون هناك خطأ ما، يجب أن تكون ردود الفعل محددة. "إصلاحه" كسول. الأفضل: تقوم هذه الأداة بتكرار parseMoney إلى src/lib/money.ts؛ أعد استخدام هذه الوظيفة، وأضف اختبارًا لحالة EUR ولا تقم بتغيير واجهة برمجة التطبيقات العامة لوحدة الفوترة.

يستجيب الوكلاء بشكل أفضل للتعليقات الصغيرة التي يمكن التحقق منها. ومن الغريب أن الناس كذلك.

الدرابزين يستحق هذا الجهد

إذا كان الوكيل قادرًا على قراءة الملفات وكتابة التعليمات البرمجية وتنفيذ الأوامر، فيجب التعامل معها على أنها عملية قوية. ليست هناك حاجة لجنون العظمة، أنت بحاجة إلى النظافة.

استخدم أشجار عمل أو فروع منفصلة. لذا يمكنك مقارنة الاختلافات، والتخلص من التجارب الفاشلة، وعدم الخلط بين عمل الوكيل وما كنت تفعله.

الحد من الأذونات. أوامر مثل rg، git diff، npm test وnpm run build يمكن أن تكون مجانية تمامًا. يجب أن تظل عمليات النشر وترحيل قاعدة البيانات والوصول إلى الأسرار والأوامر المدمرة صريحة.

تقليل الوصول إلى الشبكة عندما لا تحتاج إليها. بالنسبة للعديد من المهام، تعد الوثائق الرسمية وتسجيل الحزم والخدمات الداخلية المحددة كافية. مساحة سطح أقل، مفاجآت أقل.

تتبع الإجراءات. عندما يصل التصحيح إلى المراجعة، يجب أن تكون قادرًا على إعادة بناء المطالبات والأوامر المنفذة والاختبارات التي تم اجتيازها وتعديل الملفات. ليس لخلق البيروقراطية، ولكن لتكون قادرًا على فهم ما حدث إذا حدث خطأ ما.

طريقة سهلة للبدء كفريق

إذا كنت سأقدم عملاء إلى فريق صغير، سأبدأ بدون ثورات كبيرة.

سأقوم بإنشاء علامة agent-ready للمشكلات ذات النطاق الواضح. أود إضافة قالب يحتوي على السياق والقيود وأوامر التحقق. أود أن أطلب علاقات عامة صغيرة، ومن الأفضل أن تكون أقل من بضع مئات من الأسطر. سأطلب اختبارًا أو لقطات شاشة للتغييرات المرئية. وقبل كل شيء سأبقي شخصًا مسؤولاً عن الدمج.

بعد أسبوعين، كنت ألقي نظرة على البيانات: ما هي المهام التي تم تسريعها بالفعل، وما هي المراجعات التي كانت ثقيلة، وما هي المطالبات التي كانت مربكة، وما هي أجزاء قاعدة التعليمات البرمجية الهشة للغاية بحيث لا يمكن تفويضها.

إنها طريقة أقل إثارة من عبارة "بدءًا من اليوم سنفعل كل شيء مع الوكلاء"، ولكنها الطريقة التي تسمح لك بالوصول إلى الأسبوع الثالث دون أي ندم.

الجزء الأكثر إنسانية

والأمر المضحك هو أنه كلما أصبح العملاء أكثر استقلالية، زادت أهمية المهارات الكلاسيكية مرة أخرى: كتابة تذكرة جيدة، وإجراء تخفيضات صغيرة، وإنشاء الاختبارات، وقراءة الفروق، وتوصيل المقايضات. يقوم الوكيل بتسريع أولئك الذين يعرفون بالفعل كيفية العمل بشكل جيد. كما أنه يزيد من فوضى أولئك الذين يفوضون بشكل سيئ.

لذلك لا، لا أرى أن سير العمل متعدد الوكلاء هو اختصار للتوقف عن القيام بالأعمال الهندسية. أراها وسيلة لتحويل المزيد من الطاقة إلى الأجزاء المهمة: تحديد ما سيتم بناؤه، والتأكد من أنه يعمل، وإبقاء النظام مفهومًا.

يمكن للوكلاء تكوين زملاء غير متزامنين رائعين. لكن الزميل غير المتزامن، لكي يكون مفيدًا، يحتاج إلى سياق وحدود ومراجعة. تماما مثل أي شخص آخر.

مصادر مفيدة

• المخطوطة لكل شيء (تقريبًا) - OpenAI
• تشغيل Codex بأمان في OpenAI
• تقديم الدستور الغذائي - OpenAI
• ما الجديد في وكيل ترميز GitHub Copilot