هل يجب عليك مراجعة كود وكيل الذكاء الاصطناعي الخاص بك؟

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

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

الحجة للشحن دون قراءة كل سطر

ابدأ بأقوى نسخة من الحجة المتفائلة، لأنها أقوى مما يعترف به معظم المراجعين.

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

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

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

الحجة للحفاظ على إنسان على الاختلاف

الآن الجانب الآخر، الذي هو أيضًا أقوى مما يعترف به المتحمسون.

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

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

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

النقاش مؤطر بشكل خاطئ

إليك إعادة الإطار التي تنهي الاجتماع.

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

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

لذا فإن الجواب ليس "راجع كل شيء" ولا "ثق في الوكيل". إنه:

تتوقف عن مراجعة الأسطر. تبدأ في مراجعة المخاطر.

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

كيف يبدو "الوكيل أخطأ" فعليًا

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

1. تغيرت الاختبارات في نفس الالتزام مع الكود الذي تغطيه. تم إنشاء الأخضر، وليس ملاحظًا. هذه هي العلامة ذات الإشارة الأعلى في القائمة، وهي العلامة التي يجب التحقق منها أولاً.
2. تم إضعاف تأكيد أو تم تعطيل اختبار. skip، only، تم توسيع تأكيد ليقبل ما يحدث أن يعيده الكود الجديد، try/catch الذي يبتلع الخطأ الذي كان من المفترض أن يكشفه الاختبار.
3. الاختلاف أكبر من المهمة. تم لمس ملفات لم يطلبها أحد. الزحف في النطاق في وكيل ليس حماسًا، إنه علامة على أن الوكيل أعاد تفسير الهدف في مكان ما على طول الطريق.
4. سطح مخترع. طريقة واجهة برمجة التطبيقات، خيار تكوين أو مسار غير موجود. يتم تجميعه في رأس الوكيل ولا يوجد في أي مكان آخر.
5. تم إصلاح البيئة بدلاً من الكود. مسار مطلق مشفر، قيمة محددة لجهاز، رمز شخصي، اسم مستخدم. اختفى العرض على جهاز الوكيل وانتقل إلى أجهزة الآخرين.
6. ظهرت تبعية دون أن يُطلب منها. سلسلة إمداد جديدة، ترخيص جديد، سطح صيانة جديد، تم اتخاذه بواسطة شيء لن يقوم بصيانته.
7. تكرار بدلاً من إعادة الاستخدام. أعاد تنفيذ مساعد كان موجودًا بالفعل على بعد عشرين سطرًا. هذه هي الآلية وراء الدين المقاس: يبدو أن كل تغيير معقول محليًا ويكتسب قاعدة الكود بهدوء طريقة ثالثة للقيام بنفس الشيء.
8. الملخص لا يتطابق مع الاختلاف. "تم الإصلاح والاختبار" عندما لم يتم تشغيل أي اختبار. يتم إنشاء السرد بنفس الثقة سواء حدث العمل أم لا، لذا اعتبره ادعاءً للتحقق منه، وليس تقريرًا.
9. توقفت التعليمات عن المتابعة. التقاليد الصغيرة التي تم إسقاطها بصمت هي كيف تتدهور جلسة قبل أن تبدأ في الهلوسة بشكل واضح. إذا كنت تستخدم كناري في ملف السياق الخاص بك، فهذا هو بالضبط ما تم تصميمه لالتقاطه.
10. تم لمس أرض حساسة بشكل عابر. قراءة .env، مكالمة شبكة جديدة صادرة، سطر سجل جديد يحمل بيانات المستخدم، ترحيل مضمن في التزام ميزة.

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

كم من المراجعة يستحقه التغيير؟

يقرر نطاق الانفجار، وليس حجم الاختلاف. الجدول الذي يمكن لفريقك اعتماده هذا بعد الظهر:

حجم الاختلاف يخبرك بمدة المراجعة. نطاق الانفجار يخبرك ما إذا كان اختياريًا.

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

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

ماذا يتغير عندما يعمل خمسة وكلاء في وقت واحد

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

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

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

لا شيء من هذا يحل محل الحكم. إنه يزيل الأعذار لعدم ممارسته.

اجعل الآلة تمتلك الأسطر

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

اختبارات لم يكتبها الوكيل في نفس نفس الكود. كُتبت أولاً، أو كتبها وكيل مختلف، أو على الأقل تمت مراجعتها كتغيير خاص بهم. في اللحظة التي يأتي فيها الكود واختباراته من نفس الجيل، يتوقفان عن كونهما دليلين مستقلين.

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

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

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

إذن، هل لا تزال تراجع؟

نعم، وأقل مما تفعله اليوم.

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

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

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

الأسئلة المتكررة

هل يجب عليك مراجعة كود الذكاء الاصطناعي الذي تم إنشاؤه؟

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

هل يمكن لوكيل الذكاء الاصطناعي مراجعة كود وكيل ذكاء اصطناعي آخر؟

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

كيف تعرف إذا كان وكيل الذكاء الاصطناعي قد ارتكب خطأ؟

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

هل ستحل وكلاء الذكاء الاصطناعي محل مراجعي الكود البشريين؟

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

هل تحتاج إلى مراجعة كود الذكاء الاصطناعي سطرًا بسطر؟

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

ما الذي يجب ألا يتم دمجه أبدًا دون مراجعة بشرية؟

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