مراجعة العمل الذي كتبه الذكاء الاصطناعي

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

ويستحق الأمر فصله عن جاره. مراجعة التغييرات هي فعل القبول أو الرفض لحظة بلحظة لكل تعديل يقترحه Claude. أمّا هذه الصفحة فهي السؤال الأكبر الذي يأتي بعده: صار بين يديك عمل مكتمل، وتحتاج إلى سبب وجيه يجعلك تصدّق أنه صحيح.

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

ثم اصرف انتباهك بشكل غير متساوٍ، لأن الانتباه المتساوي هو الطريقة التي يضيع بها المهم. الأجزاء التي تستحق قراءة بشرية بطيئة هي تلك التي يكلّف الخطأ فيها كثيرًا — كل ما يمسّ المال أو البيانات الشخصية أو الـ permissions أو الحذف أو أي شيء يصعب عكسه. أمّا الباقي الروتيني فهو بالضبط ما يجيده المراجع الآلي: /review يقرأ الـ diff ويشير إلى الـ bugs والحواف الخشنة، أمّا cloud review فيرسل التغيير كاملًا إلى أسطول من الـ agents يصطادون عيوبًا حقيقية بالتوازي بينما تفعل أنت شيئًا آخر.

وملاحظة عن النطاق، حتى لا يفاجئك شيء فيما يلي. /review و/pr-comments و/autofix-pr أدوات موجّهة للمطوّرين ومبنية حول الـ pull requests — مفيدة فعلًا إن كان ذلك أسلوب عملك، وغير ذات صلة إن لم يكن. والحكم الموصوف أعلاه يبقى صالحًا في الحالتين، وكذلك حجّة الأمان الكامنة تحته: المراجعة بثقة أسهل بكثير حين لا تكلّفك الإجابة السيئة سوى أمر git واحد للتراجع.