أنا أكثر تفاؤلاً بشأن الهندسة باستخدام الـ agents ممّا كنت في أيّ وقت مضى. الـ agents جيدة فعلاً، تتحسّن كل شهر، وفي أسبوع عادي أنجز الآن أشياء لم أكن لأحاول إنجازها في الوقت نفسه قبل عام. هذه المقالة خريطة لأين انتقل العمل المثير، لأنه انتقل فعلاً، ومعظم الفِرَق لم تلحق بعد بالمكان الجديد.
الصدفة السعيدة التي انكسرت
كانت الـ code review تعمل بفضل صدفة سعيدة تتعلّق بالسرعة النسبية. كان المهندس الأقدم يستطيع قراءة الكود أسرع ممّا يكتبه المبتدئ، فبقيت الـ review مواكبة دون أن يصمّمها أحد لذلك، وامتصّ الفريق فهم كيف يتماسك النظام كأثر جانبي لقراءة اثنان من الـ diffs لبعضهم البعض. كثير من ذلك لم يكن مقصوداً. نتج عن حقيقة واحدة: كتابة الكود كانت الجزء البطيء المكلف، وقراءته كانت رخيصة وسريعة.
تلك الحقيقة لم تعد صحيحة. الـ agent ينتج ألف سطر من الكود الجيد المنسَّق غالباً في وقت أقلّ ممّا يستغرقني قراءة هذه الفقرة، بينما سرعة القراءة البشرية لم تتغيّر منذ اليوم الذي بدأنا فيه التحديق في الشاشات تقريباً. فانتقل القيد إلى أسفل الخطّ، إلى الخطوة الوحيدة التي لم تصبح أسرع: أن يكون شخص واثقاً أن التغيير صحيح. لا أعتقد أن ذلك خسارة. إنه المكان الأعلى رافعة في البرمجيات الآن، وهو المكان الذي وضعت فيه معظم انتباهي هذا العام.
هناك مفارقة سعيدة تشكّل بقية هذه المقالة. الأدوات نفسها التي تولّد كل هذا الكود الإضافي هي أيضاً أفضل ما لديّ لمواكبته. في مشاريعي الخاصة، بما فيها المشاريع مفتوحة المصدر الشائعة، أوجّه الآن Claude Code أو Codex إلى دفعة من اثنان من الـ PRs الواردة وأطلب منهم فرز الطابور نيابة عنّي، وهذا غيّر فعلاً كيف أقضي وقتي. لذا هذه ليست حجّة ضدّ الذكاء الاصطناعي، وسأعود إلى كيفية استخدامي له بالضبط.
وهي أيضاً ليست تفريغاً للبيانات، ولا جولة أخرى حول ما إذا كان ترك نموذج يكتب الكود أمراً رائعاً أو نهاية الحرفة، لأن هذا الإطار عديم الفائدة. الإجابة الوحيدة التي تصمد أمام codebase حقيقي هي أن الأمر يعتمد كلياً على من أنت. مطوّر يمارس الـ vibe-coding على مشروع جانبي سيستخدمه عشرة أشخاص على الأكثر، وفريق يبقي نظاماً مؤسسياً عمره عشر سنوات حيّاً لربع آخر، لا يتشاركان تقريباً أيّ قيود تستحقّ الذكر، ومعظم النصائح المتداولة هي في الحقيقة أحد هذين الشخصين يخبر الآخر كيف يعيش.
ما تُظهره بيانات 2026 فعلاً
مكاسب الإنتاجية من الذكاء الاصطناعي حقيقية، لكن الناتج الخام يبالغ فيها: نحو أربعة أضعاف الكود مقابل عُشر واحد من القيمة المُضافة الفعلية. الفجوة بين هذين الرقمين هي عمل الـ review، وهذا بالضبط لماذا الـ review هي المكان الذي تتركّز فيه الرافعة الآن.
لعامين كان هذا مجرّد حكايات وجدال. الآن هو مقاس على نطاق واسع، من مؤسسات لا تتشارك أيّ أجندة وفي عدّة حالات لها مصالح تجارية متنافسة، والقياسات تشير باستمرار في الاتجاه نفسه: الذكاء الاصطناعي يدفع الناتج للأعلى بحدّة، ويدفع كلّاً من الجودة وقابلية المراجعة للأسفل.
رصدت Faros AI أداء 22,000 مطوّر عبر 4,000 فريق وتتبّعت ما حدث مع انتقال الفِرَق من اعتماد منخفض إلى عالٍ على الذكاء الاصطناعي. هذه بيانات مارس 2026، بأحدث ما يمكن. الجانب الإيجابي حقيقي ويستحقّ الذكر بوضوح: المطوّرون يدمجون عدداً أكبر بكثير من اثنان من الـ PRs وينجزون عملاً أكثر، والإنتاجية لكل مهندس ترتفع. ثم بقية التقرير:
- معدّل إعادة العمل على الكود ارتفع 861%
- نسبة الحوادث إلى اثنان من الـ PRs ارتفعت 242.7%
- معدّل الأخطاء لكل مطوّر ارتفع من 9% إلى 54%
- متوسط مدّة الـ review ارتفع 441.5%، مع تضاعف تقريبي لوقت أوّل review ومتوسط وقت الـ review
- اثنان من الـ PRs المدمَجة بدون أيّ review ارتفعت 31.3%
الرقم الأخير هو الأصعب في تجاهله، لأن لا أحد اختاره. لم يكن هناك قرار بالتوقّف عن المراجعة. المراجعون ببساطة لم يستطيعوا مواكبة الحجم، فبدأ الكود يُدمَج دون قراءة، وأصبح ذلك طبيعياً. التفصيل الذي أعود إليه دائماً هو أن الفِرَق ذات الممارسات الهندسية الناضجة والمنضبطة تأثّرت بنفس القدر. العمليات الجيدة لم تحمِهم، لأن الحجم وصل أسرع ممّا صُمِّمت أيّ عملية لاستيعابه.
تحفّظ يجب إبقاؤه حاضراً: كلّ من CodeRabbit وFaros يبيعان في هذا السوق، لذا إطارهما ليس محايداً. هذا لا يجعل الأرقام خاطئة — أحجام التأثير كبيرة ومتّسقة عبر مصادر غير مترابطة — لكن أبحاث البائعين تستحقّ أن تُقرأ مع وضع ذلك في الاعتبار.
درست CodeRabbit عدداً من اثنان من الـ PRs مفتوحة المصدر (470 في ديسمبر 2025، منها 320 بمشاركة الذكاء الاصطناعي و150 بشرية فقط) ووجدت أن التغييرات بالذكاء الاصطناعي حملت نحو 1.7 ضعف من المشاكل: مشاكل المنطق والصحّة ارتفعت نحو 75%، مشاكل الأمان أكثر شيوعاً بـ 1.5 إلى ضعفين، ومشاكل سهولة القراءة تضاعفت أكثر من ثلاث مرّات. وصف مدير الذكاء الاصطناعي لديهم David Loker هذه بأنها «نقاط ضعف متوقّعة وقابلة للقياس يجب على المؤسسات التخفيف منها بفعالية». متوقّعة هي الكلمة المفتاحية. هذه نقاط ضعف معروفة وقابلة للتحديد، وهذا خبر جيد: يعني أن عملية review، بشرية أو آلية، يمكن توجيهها مباشرة إليها.
لدى GitClear بيانات مثيرة هنا أيضاً. في بيانات إنتاجيتهم حتى 2025، المستخدمون اليوميون للذكاء الاصطناعي ينتجون نحو أربعة أضعاف الناتج الخام مقارنة بغير المستخدمين، لكن مقاساً مقابل ناتجهم هم قبل عام، المكسب الحقيقي في الإنتاجية هو نحو 12% فقط. أنت تولّد نحو أربعة أضعاف الكود مقابل شيء كعُشر القيمة المُضافة الفعلية، وإنسان لا يزال عليه مراجعة الأضعاف الأربعة كلّها. لصالح GitClear، Bill Harding صريح بأن بعض حتى ذلك الـ 12% هو تحيّز اختيار، لأن المطوّرين الأقوى تركّزوا في مجموعة الذكاء الاصطناعي. الفجوة بين أربعة أضعاف الكود وعُشر القيمة الإضافية هي مشكلة الـ review ملخَّصة في سطر واحد.
تقول GitHub إن Copilot review أجرت الآن أكثر من 60 مليون review، بزيادة عشرة أضعاف في أقلّ من عام، وأكثر من واحدة من كل خمسة عمليات review على المنصة تشارك فيها agent. لم يعد هذا ممارسة هامشية. هذه هي الطريقة التي يُصنَع بها الكود.
أربع مجموعات بيانات، أربع منهجيات، استنتاج واحد. صببنا ناتجاً بسرعة الآلة في نظام بُني لعمل بسرعة البشر. عنق الزجاجة لم يختفِ — انتقل إلى التحقّق، والـ review هي المكان الذي تُستحَقّ فيه الفاتورة.
كلّ شخص يحلّ مشكلة مختلفة
مقدار الـ review الذي يحتاجه تغيير ما يعتمد بشكل شبه كامل على الـ blast radius، ومعظم النصائح التي تقرأها كتبها شخص يعمل عند blast radius مختلف جداً.
تقريباً كل البيانات المقلقة أعلاه تأتي من بيانات المؤسسات الكبيرة ومن مشرفي المشاريع مفتوحة المصدر المغمورين بالعمل. هي حقيقية تماماً إن كان هذا وضعك. إن كنت شخصاً واحداً تشحن شيئاً سيستخدمه حفنة من الناس على الأكثر، كثير منها ببساطة لا ينطبق عليك، ولا ينبغي أن تُشعَر بخلاف ذلك.
ثلاثة متغيّرات تحدّد أين تقف:
- الـ blast radius: ماذا يحدث عندما ينكسر. لا شيء، أو مستخدمون غاضبون وأموال وبيانات شخصية على المحكّ.
- كم يعيش الكود: prototype قابل للرمي قد تعيد كتابته الأسبوع القادم، أو codebase ستصونه لسنوات.
- كم شخصاً يحتاج لفهمه: أنت وحدك تحمل كل شيء في رأسك، أو فريق يجب أن يتشارك المسؤولية مع الوقت.
مرّر نفس الـ diff عبر هذه الثلاثة و«الـ review الجيدة» تعني أشياء مختلفة فعلاً.
إن كنت تعمل وحدك على مشروع جديد بلا مستخدمين، فالوظيفة الثانية للـ review — توزيع المعرفة عبر الفريق — غير موجودة لديك. أنت الفريق. الخطوة المعقولة هي الاعتماد بقوّة على الاختبارات والأتمتة، ومراجعة الأجزاء التي تهمّ فعلاً، وقبول لمسة أخفّ على الباقي. التكرار وإعادة العمل يكلّفان أقلّ بكثير عندما قد لا يكون الكود موجوداً بعد شهر ولا أحد يُوقَظ الساعة الثالثة فجراً عندما ينكسر. المحذور — ويتعلّمه الناس بألم — هو أن هذا لا يعمل إلا إذا كانت الاختبارات حقيقية. تخطّي الـ review بدون شبكة أمان لا يزيل العمل، بل يؤجّله بثمن أعلى، والمعايير تنزلق عندما لا يكون هناك أحد ليدفع للخلف. لا مستخدمين هو إذن لتأجيل الـ review. وليس إذناً لتخطّي التحقّق.
ثم يحصل المشروع على مستخدمين. هذه هي المنطقة الوسطى الخطرة، ونادراً ما يُلاحَظ العبور في حينه. دور الـ review في اصطياد الأخطاء يصبح مهمّاً فجأة، لأن الأخطاء الآن تؤذي الناس، ودورها في مشاركة المعرفة ينشط، لأنك لم تعد وحدك. تحتفظ الفِرَق بعادات مرحلة العمل الفردي لبضعة أشهر أطول ممّا ينبغي، ثم يكون هناك تقرير ما بعد الحادثة وأرقام Faros تتوقّف عن كونها رسماً بيانياً وتصبح لوحة التحكّم الخاصة بك.
في الطرف الأبعد تقف المؤسسة الكبيرة ذات الـ codebase القديم والمستخدمين الكثر. هنا كل رقم مقلق يصل بكامل قوّته. تغيير لم يفهمه أحد هو دَين فهم يصبح حادثة ليلية لشخص ما. الـ review تقوم بعدّة وظائف في وقت واحد، وحجم ناتج الـ agent يكسرها كلّها بهدوء. نتيجة Faros عن الفِرَق الناضجة موجَّهة مباشرة هنا.
فالنقطة ليست «المؤسسات يجب أن تحذر والمطوّرون المستقلّون يمكنهم الاسترخاء». بل إن غرض الـ review يتغيّر مع موقعك، لذا القواعد يجب أن تتغيّر معه. ركّب pipeline مؤسسة مقفلة ومتعدّدة اثنان من الـ agents وتتطلّب أدلّة على prototype من شخصين وستكون قد أضفت احتكاكاً بلا فائدة. شغّل «الاختبارات تمرّ، اشحن» على نظام مدفوعات وستكون قد بنيت مولّد حوادث بعلامة خضراء فوقه. معظم النصائح السيئة في هذا المجال هي موقف واحد على ذلك الطيف يفرض وصفته على الآخر.
ما الذي تخدمه الـ review فعلاً الآن
بُنيت الـ review للتحقّق من تفكير المؤلف واصطياد الأخطاء، بالإضافة إلى مشاركة المعرفة مع الفريق. الـ agent يفكّر فعلاً، لكن ذلك التفكير عادةً يُرمى بدل أن يُرفَق بالكود، فيضطر المراجع لإعادة بناء مبرّر لم يصل أصلاً إلى الـ diff. الخبر الجيد: هذه مشكلة أدوات، والتقاط التفكير يجعل الـ review أسهل بشكل كبير.
هذا هو الجزء الذي تغيّر فعلاً، وأعتقد أنه لا يحظى بالتقدير الكافي.
عندما يكتب إنسان الكود، يأتي القصد مجاناً. التفكير والبدائل التي وُزنت وأُقصيت عاشت في رأس المؤلف، وكانت الـ review هي أنت تتحقّق من ذلك التفكير. اثنان من الـ agents الحديثة تفكّر فعلاً، غالباً بشكل مرئي، تنتج آثار تفكير وتزن خيارات وتشرح نفسها وهي تعمل. المحذور هو أن هذا التفكير عادةً يُتخلَّص منه لحظة إنتاج الـ diff. نادراً ما يُلتقَط، نادراً ما يُرفَق بالـ PR، وعلى أيّ حال هو تفكير الـ agent حول كيفية تنفيذ المهمّة، وليس حكم إنسان حول ما إذا كانت المهمّة الصحيحة من الأساس. فتتحوّل الـ review من التحقّق من تفكير أمامك إلى إعادة بناء قصد لم يُكتَب أبداً، وهو أصعب وأبطأ، ونستمرّ في الاستغراب أنه يستغرق 441% أطول.
ورقة بحثية في 2026، AI Slop and the Software Commons، حلّلت 1,154 منشوراً عبر 15 سلسلة نقاش في Reddit وHacker News حيث ناقش المطوّرون «AI slop». سطر من مطوّر لفت نظري: مراجعة PR من agent جعلته «أوّل إنسان يضع عينيه على هذا الكود على الإطلاق».
هذا يشير مباشرة إلى الحلّ. في الـ review العادية كان المؤلف يفهم التغيير مسبقاً وأنت كنت تتحقّق من عمله. مع PR من agent، لم يعِد أحد بناء لماذا بعد. المراجع هو أوّل من يحاول.
كما تقول الورقة، الـ review «لم تُبنَ لاستعادة قصد مفقود». الجزء المشجّع هو أن القصد المفقود قابل للاستعادة: التفكير كان موجوداً، فقط تخلّصنا منه. اطلب من الـ agent أن يذكر ما كان يحاول فعله وما استبعده، والتقط ذلك كسجلّ قرارات على الـ PR، وجزء كبير من تكلفة إعادة البناء يختفي. هذه مشكلة أدوات، ومشاكل الأدوات تُحَلّ.
لا شيء من هذا يجعل «دع الذكاء الاصطناعي يراجع الذكاء الاصطناعي» إجابة كاملة بمفردها. نموذج ثانٍ بافتراضات مختلفة يلتقط أخطاء حقيقية فعلاً، ويلتقط كثيراً منها، ولهذا يجب أن تشغّل واحداً. ما لا يقدّمه هو الحكم البشري حول ما إذا كان هذا هو التغيير الصحيح لبنائه من الأساس. ذلك الحكم يبقى مع إنسان، ويصادف أنه الجزء الأكثر إثارة في العمل — الجزء الذي يستحقّ الاحتفاظ به.
الأدوات جيدة — استخدم اثنتين تختلفان
أدوات الـ AI review الحالية جيدة فعلاً، وأحياناً لا تُعلِّم نفس الأسطر، فالخطوة الصحيحة ليست اختيار الأفضل بل تشغيل اثنتين بُنيتا بشكل مختلف.
أدوات الـ AI review المخصّصة جيدة الآن، وأعتقد أنه يجب أن تشغّل على الأقلّ الـ coding agent الرئيسي، إن لم يكن agent review مخصّص، على كل شيء — بما في ذلك المشاريع الجانبية.
CodeRabbit هي الأكثر انتشاراً وتصدّرت معيار Martian المستقلّ (يناير إلى فبراير 2026) على F1، بدقّة نحو 49% مع أفضل recall في المجال. Greptile تتبادل الدقّة مقابل الـ recall: نحو 82% معدّل اصطياد أخطاء مقابل 44% لـ CodeRabbit في معيار واحد، بتكلفة المزيد من الإنذارات الكاذبة. تقرير Code Review من Anthropic يذكر أقلّ من 1% من ملاحظاته وُصِفت بالخاطئة من مهندسيهم، والرقم الذي سأعرضه فعلاً على مدير: رفع نسبة اثنان من الـ PRs التي تتلقّى review جوهرية داخلياً من 16% إلى 54%. الذيل الطويل من التغييرات التي كانت تحصل على نظرة سريعة وموافقة أصبحت الآن تُقرأ من شيء ما.
أكثر نتيجة مفيدة رأيتها هذا العام ليست من بائع. مهندس شغّل أربع أدوات review بالتوازي — CodeRabbit وSentry Seer وGreptile وCursor BugBot — عبر 146 PR حقيقية و679 ملاحظة على مدى ثلاثة أسابيع ونصف:
من 617 موقعاً مميَّزاً مختلفاً، 93.4% التقطتها أداة واحدة فقط من الأربع. 6% التقطتها اثنتان. تقريباً لا شيء بثلاث. لا شيء على الإطلاق بالأربع.
الأدوات الأربع لم تُعلِّم نفس السطر ولا مرّة واحدة. كلّ واحدة كانت قوية في صنف مختلف من المشاكل: Greptile بإنذارات كاذبة قريبة من الصفر في الصحّة والهندسة المعمارية، CodeRabbit بأوسع شبكة وإصلاحات بنقرة واحدة، Seer الأفضل في خطورة أعطال production. هذه هي حجّة الـ review المتعدّدة المصادر مُثبَتة على codebase حقيقي وليس في ورقة بحثية. التنوّع هو الهدف بالكامل. أربع نسخ من نموذج واحد هي مراجع واحد بفاتورة أكبر، بينما أربعة مراجعين مختلفين فعلاً يكشفون مجموعة أخطاء لا يستطيع أيّ عضو واحد إيجادها وحده — بما في ذلك الإنسان.
عملياً: لا تقلق بشأن الأداة الوحيدة الأفضل — لا توجد. في الطرف عالي المخاطر، شغّل اثنتين بشخصيات مختلفة عمداً. إن كنت مستقلّاً، أداة review جيدة واحدة مع اختبارات حقيقية تكفي. ومهما قال التسويق، قِسها على الكود الخاصّ بك، لأن كل واحدة من هذه النتائج كانت خاصّة بـ codebase معيّن، وكودك سيكون كذلك.
هل ندع الذكاء الاصطناعي يراجع أكثر؟
الآلة تراجع بالفعل من الكود أكثر ممّا تراجع أنت. القرار الحقيقي الوحيد المتبقّي هو ما إذا كنت تفعل ذلك بشكل مقصود، ومقدار البشري الذي تحتفظ به يجب أن يتناسب مع الـ blast radius.
أسمع باستمرار سؤالاً كان سيُعتبَر هرطقة قبل عام، الآن من مهندسين ذوي خبرة: هل يجب أن تقوم الآلة بمزيد من المراجعة، ربما معظمها؟ لم أعد أعتقد أن هذا سؤال أحمق.
الجزء غير المريح هو أن الـ AI review تعمل. أقلّ من 1% من ملاحظات Anthropic تُعلَّم كخاطئة، والأدوات تلتقط أخطاء يمرّ عليها البشر مرور الكرام، ولا تتعب في الـ PR الثلاثين في اليوم — وهو بالضبط الوقت الذي يكون فيه الإنسان أقلّ موثوقية. في المقابل البشر لا يواكبون بشكل واضح: عمليات الـ merge بدون review ارتفعت 31% وأوقات الـ review ارتفعت بأرقام من ثلاث خانات. بمعنى حقيقي الآلة تراجع بالفعل من الكود أكثر ممّا نفعل نحن. الإطار الصادق ليس «هل ندع الذكاء الاصطناعي يراجع أكثر» بل «الذكاء الاصطناعي يفعل ذلك بالفعل — هل سنكون مقصودين في ذلك، أم نتركه يحدث تلقائياً بينما نتظاهر أن البشر لا يزالون يقرؤون كل شيء؟»
هندسة الحلقات توضّح هذا أكثر
فرضية الحلقة هي أنك تتوقّف عن كونك الشخص الذي يعطي prompt للـ agent وبدلاً من ذلك تبني نظاماً يعطيه prompt، وجزء مركزي من ذلك النظام هو حَكَم: agent يقرّر ما إذا كان العمل قد أُنجِز قبل الانتقال. المراجع هو الدور التالي الذي يُصمَّم خارج الحلقة الداخلية، عمداً. قضينا عاماً نؤتمت الكتابة، والحلقات الآن تؤتمت التحقّق، والإنسان يستمرّ في الدفع للأعلى والخارج. «أين يبقى الإنسان؟» ليس سؤال ندوة — إنه شيء تقرّره كل مرّة تبني فيها حلقة، سواء أدركت أنك تقرّره أم لا.
أين أقف حالياً: الإجابة قد لا تكون «إنسان يقرأ كل سطر». ذلك انتهى. لكنها أيضاً ليست «دع الحلقة تراجع نفسها وامشِ». عندما يكتب agent الكود وآخر يراجعه وثالث يحكم عليه، لديك حلقة مغلقة من النماذج بنقاط عمياء مترابطة بشكل عامّ، خاصّة عندما تأتي من نفس العائلة، تتّفق بثقة في نفس الأماكن. «يبدو جيداً» بثقة بلا أيّ إنسان في أيّ مكان هي ثقة مستعارة: يقين النظام يصبح يقينك، ولا أحد فهم شيئاً فعلاً. الحلقة يمكن أن تكون واثقة جداً ومخطئة جداً، بلا إنسان متبقٍّ ليميّز الفرق.
فالإنسان لا يغادر — الإنسان يصعد مستوى. تتوقّف عن مراجعة كل diff وتبدأ في امتلاك الأجزاء التي لا تنتقل إلى نموذج:
- الحكم على ما إذا كان هذا حتى التغيير الصحيح لبنائه — بخلاف ما إذا كان الكود صحيحاً.
- البوّابات ذات الـ blast radius العالي حيث يكون الخطأ مكلفاً.
- السلوك الذي لم يحدّده أحد — لأن النموذج يراجع الكود الموجود ونادراً ما يُعلِّم المتطلَّب الذي لم يفكّر أحد في كتابته، وهذه فجوة بشكلة إنساني لا أتوقّع إغلاقها قريباً.
إنسان في الحلقة يصبح إنساناً فوق الحلقة: يأخذ عيّنات ويدقّق ويراجع النظام بدلاً من قراءة كل PR، ويصرف انتباهه المحدود حيث يكون الخطأ مؤلماً فعلاً.
كيف أستخدم هذا فعلاً
هذه هي الطريقة التي أعمل بها بالفعل على مشاريعي الخاصة، بما فيها مشاريع open source التي تستقبل الآن عدداً من اثنان من الـ PRs في اليوم أكثر ممّا أستطيع قراءته بعناية في مساء.
أوجّه Claude Code أو Codex إلى دفعة من اثنان من الـ PRs الواردة وأطلب تمريرة أولى: قراءة عالية المستوى لما يبدو آمناً للدمج، وما يحتاج مزيداً من العمل، وما هو عالي المخاطر فعلاً. لا أدمج تلقائياً بناءً على النتيجة، ولا أدمج بكسل كل ما يوافق عليه. ما يعطيني إيّاه هو طريقة لتوزيع الانتباه.
أستطيع قضاء بضع دقائق في تأكيد التغييرات التي يعتبرها منخفضة المخاطر، وأضع وقتاً حقيقياً متأنّياً في التي يُعلِّمها كخطيرة. التفصيل المهمّ هو أن هذه ليست ساعة المراجعة القديمة أسرع قليلاً. إنها ساعة بشكل مختلف، وبالحجم الذي أتعامل معه الآن، هي السبب الرئيسي في بقاء الطابور قابلاً للنجاة أصلاً.
نسخة أكثر تطرّفاً من نفس الخطوة هي Kun Chen، مهندس سابق في Meta بمستوى L8 يشحن الآن نحو 40 PR في اليوم كمطوّر مستقلّ. يشغّل من 20 إلى 30 agent بالتوازي ونقل جهده إلى الخطة: يكتب خططاً مفصّلة مسبقاً، اثنان من الـ agents تعمل لساعات وفقها، ويقول إن جودة الخطة تحدّد كم يمكنها العمل بدون إشراف. يستحقّ أن نكون دقيقين في ما حدث فعلاً، لأنه لم يتوقّف عن التحقّق. القصد لم يختفِ — كتبه بنفسه في الخطة، فمشكلة «أوّل إنسان يضع عينيه على هذا» نصف محلولة. ولم يعمل بدون شبكة أمان: بنى بوّابة review آلية تتحقّق من الكود قبل الدمج، ويبقى جاهزاً للتصعيد عندما يعلق agent. الإنسان يقوم بالتفكير المكلف قبل أن يوجد الكود والآلة تقوم بالمراجعة سطراً بسطر بعدها.
لكنه مطوّر مستقلّ بلا فريق كبير ولا نظام عمره عشر سنوات مليء بالألغام تحته. الشروط بالضبط التي تجعل 40 PR في اليوم بدون review منطقية له هي شروط لا يملكها معظم القرّاء. انسخ سير عمله على فريق يشحن لمستخدمين كثر وستعيد إنتاج أرقام Faros على لوحة التحكّم الخاصة بك. ليس مخطئاً — هو بعيد جداً على طرف محدّد من الطيف.
ماذا تفعل فعلاً
الفكرة المنظِّمة هي مطابقة جهد الـ review مع تكلفة الخطأ، ودفع العمل الحتمي الرخيص مبكراً قدر الإمكان، وحفظ الانتباه البشري لما لا يستطيع إلا البشر فعله.
صنِّف حسب المخاطر، لا حسب المؤلف. تغيير في config يستحقّ linter ونظرة. تعديل على مسار منطق الأعمال الأساسي يستحقّ الحزمة الكاملة: types واختبارات واثنان من أدوات الـ AI review المختلفة وإنسان يملك ذلك النظام وتمريرة أمنية. لا تصرف review ثقيلة على boilerplate، ولا تمرّر تغييراً كبيراً لأن الاختبارات خضراء.
أفشل بسرعة في الذيل المكلف. دراسة يناير 2026 على 33,707 PR كتبتها اثنان من الـ agents وجدت أن اثنان من الـ agents جيدة في التغييرات الصغيرة المحدّدة — نحو 28% تُدمَج فوراً تقريباً — لكنها تميل للـ «اختفاء» لحظة تلقّي ملاحظات ذاتية، فتتخلّى عن الذهاب والإياب الذي هو الـ review فعلاً. افرز اثنان من الـ PRs من اثنان من الـ agents مقدَّماً، سرّع التافهة منها، ولا تدع شخصاً يغرق ساعة في تغيير ممتدّ سيتخلّى عنه الـ agent بمجرّد أن تدفع للخلف.
ارفع الحدّ الأدنى لما ستراجعه أصلاً. الحلّ لكونك مدفوناً ليس إغلاق الـ repository — بل رفض مراجعة التغييرات التي تصل بدون دليل. اطلب قبل الـ review: بياناً بالغرض من التغيير، وdiff ليس 3,500 سطر بدون تعليقات، وناتج الاختبارات، ودليلاً على أنها شُغِّلت فعلاً. ادفع عمل إعادة بناء القصد إلى من أرسله، حيث هو رخيص.
اجعل اثنان من الـ PRs صغيرة، عمداً. اثنان من الـ PRs من اثنان من الـ agents أكبر بـ 51% في المتوسط في بيانات Faros، وتفاعل المراجع هو أحد أقوى المؤشرات على أن PR ستُدمَج أصلاً. الـ diff الذي يستطيع إنسان قراءته فعلاً هو الآن قيد تصميم، وليس مجاملة.
اقرأ تغييرات الاختبارات بعناية أكبر من الكود. هذا هو نمط فشل الـ agent الذي يجب مراقبته. الـ agent يغيّر السلوك، ثم «يصلح» الاختبار بإعادة كتابة الـ assertion ليطابق السلوك الجديد المعطوب. علامة خضراء فوق 200 اختبار معدَّل لا تعني شيئاً حتى تتأكّد أن التعديلات صحيحة. الـ mutation testing يكسب مكانه هنا: الـ coverage يخبرك أن السطر عمل، الـ mutation testing يخبرك ما إذا كان الاختبار سيلاحظ لو كان ذلك السطر خاطئاً.
عامل الـ CI كجدار لا يتحرّك. راقب الاختبارات المحذوفة، والـ lint المتخطّى، وعتبات الـ coverage المخفَّضة، والـ helpers المكرّرة، والمدخلات غير الموثوقة التي تتدفّق إلى prompt. النقطة الأخيرة تستحقّ التأكيد — الـ features التي تبنيها اثنان من الـ agents هي مصدر جديد للـ prompt injection. اثنان من الـ agents ستُضعف أيضاً الـ CI لتمرّر نفسها، ليس بخبث، فقط تجد أرخص طريق إلى الأخضر. البوّابات الحتمية هي الجزء الوحيد من الـ pipeline الذي لا يمكن إقناعه بالتراجع عن حكمه بفقرة واثقة.
إنسان يملك الـ merge. النموذج لا يمكن إيقاظه ولا تحميله مسؤولية ما شحنه، فمن ينقر merge يملكه. عامل كل AI review كمستشعر، لا كحكم: بيانات، لا قرار.
ماذا يعني هذا إن كنت تدير فريقاً
القيد الحاكم على الشحن لم يعد مدى سرعة كتابتك للكود. بل مدى سرعة ثقة إنسان موثوق بأن التغيير صحيح. أيّ خطة تعامل التوليد كعنق الزجاجة والـ review كمجانية ستتوقّف بهدوء، مع بقاء لوحة تحكّم السرعة خضراء طوال الطريق.
تقرير Faros مباشر في هذا: عمل ضمان الجودة والـ review يرتفع حتى مع ارتفاع الناتج، لذا تقليل عدد المهندسين لأن «الذكاء الاصطناعي جعلنا أسرع» خطير ما لم تكن قد سددت فجوة الـ review أوّلاً. ضريبة المهندس الأقدم — وقت الـ review مرتفع بأرقام من ثلاث خانات — يقع بأشدّ قوّة على الأشخاص الذين لا تستطيع تحمّل جعلهم عنق زجاجة، وهو غير مرئي لأيّ مقياس يعدّ فقط اثنان من الـ PRs المدمَجة.
مشرفو المشاريع مفتوحة المصدر اصطدموا بهذا الجدار أوّلاً وبأقوى شكل. التدفّق المستمرّ من المساهمات المعقولة لكن الجوفاء يكلّف وقت فرز حقيقياً حتى عندما يكون حسن النيّة، وهذا هو إنذار الكناري. الشركات هي التالية. التي تتعامل مع الأمر جيداً تعامل سعة الـ review كمورد حقيقي يُقاس ويُحمى ويُصرَف بقصد — وليس كفراغ حرّره الذكاء الاصطناعي.
الخلاصة
الـ code review لم تصبح أقلّ أهمية عندما وصلت اثنان من الـ agents. أصبحت النشاط المركزي. كتابة الكود أصبحت محلولة بشكل متزايد وتصبح أرخص كل شهر — الميزة الدائمة هي النظام الذي يتيح لك الثقة بما كُتِب.
لا تأخذ الإجابة الموحَّدة في أيّ اتجاه. إن كنت مستقلّاً بلا مستخدمين، قصص الرعب المؤسسية عن إعادة العمل والتكرار هي خطر مستقبلي وليست حريق اليوم — فاعتمد على اختباراتك، وراجع ما يهمّ، وكن صادقاً أن العمل المؤجَّل لا يزال مستحَقّاً. إن كنت تصون شيئاً كبيراً لأشخاص كثر، كل رقم مقلق هنا يتحدّث عنك، والشيء الوحيد الذي يصمد هو عملية review متدرّجة تتطلّب أدلّة ومتنوّعة عمداً مع إنسان يملك الـ merge.
الثابت عبر كل الطيف هو الاقتصاد الأساسي. جعلنا الكتابة رخيصة، والفهم بقي بالضبط بنفس التكلفة التي كان عليها دائماً. الفِرَق التي ستنجح في السنوات القادمة لن تكون تلك التي تولّد أكثر الكود — بل تلك التي بنت نظام review تثق به فعلاً، ولم تخلط أبداً بين «الاختبارات مرّت» و«شخص يفهم ما يفعله هذا ولماذا».
فهم النظام بما يكفي لتقف خلفه هو أكثر مهارة دائمة وأكثرها إثارة في البرمجيات، ولم يكن هناك وقت أفضل من الآن لتصبح ممتازاً فيها بشكل استثنائي.