كيفية توسيع وكلاء البرمجة الذكية عبر فريق التطوير

مطور واحد مع وكيل برمجة هو قصة إنتاجية. من السهل سردها، وتظهر بشكل جيد، وهي صحيحة حقًا.

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

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

ما الذي يتعطل أولاً: السياق المشترك

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

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

الإصلاح ممل وهو الشيء الأكثر تأثيرًا في هذه الصفحة. ضع الاتفاقيات في ملف، والتزم بالملف.

CLAUDE.md لوكيل Claude Code، AGENTS.md لوكيل Codex ومعظم وكلاء CLI الآخرين، وفي الممارسة العملية، يحتفظ العديد من الفرق بملف سياق محمول واحد بدلاً من الحفاظ على اثنين يتباعدان. الآلية أهم من اسم الملف: التعليمات تعيش في المستودع، لذا تصل مع git pull بدلاً من الوصول من خلال من كان في الغرفة.

ما يجب أن يتواجد فيه:

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

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

اختبار مفيد قبل إضافة سطر: إذا قام زميل بسحب هذا، هل يساعدهم أم يكسرهم؟

ما الذي يتعطل ثانيًا: وكيلان، ملف واحد

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

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

هناك آليتان لإصلاح ذلك، وتريد كلاهما.

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

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

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

ما الذي يتعطل ثالثًا: المراجعة

كل شيء يتعلق بالمراجعة على نطاق الفريق يتبع رقمًا واحدًا: كم من التغييرات تصل في الساعة.

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

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

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

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

ما الذي يتعطل رابعًا: التكلفة، والمحادثة حول التكلفة

توقف إنفاق الرموز عن كونه تفصيلًا شخصيًا في اللحظة التي يظهر فيها على فاتورة الفريق.

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

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

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

ما الذي يتغير فعليًا في طقوس الفريق

ثلاثة أشياء، في تجربتنا وفي ما تقوله الفرق.

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

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

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

الإعداد الذي يستمر

مكثف، بالترتيب الذي يهم:

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

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

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