ابزارهای بازبینی کد با هوش مصنوعی گلوگاه را جابه‌جا کردند، نه حذف
ابزارهای بازبینی کد با هوش مصنوعی قرار بود زمان بین باز کردن یک Pull Request و merge کردن آن را فروبریزند. برای مجموعه‌ای محدود از بررسی‌ها، این اتفاق افتاده. اما برای وظیفه اصلی یک بازبین — تشخیص اینکه آیا تغییر واقعاً درست و امن است — اکثر تیم‌هایی که این ابزارها را در مقیاس بزرگ اجرا می‌کنند گزارش می‌دهند که یک گلوگاه را با گلوگاهی دیگر معامله کرده‌اند: زمانی که قبلاً صرف خواندن diff می‌شد، اکنون صرف تصمیم‌گیری درباره اینکه کدام نظرات بات ارزش خواندن دارند می‌شود.
پذیرش از شواهد اثربخشی پیشی گرفته
نظرسنجی ۲۰۲۵ Stack Overflow نشان داد ۴۷٪ از توسعه‌دهندگان حرفه‌ای در سال گذشته از بازبینی کد با کمک هوش مصنوعی استفاده کرده‌اند. نظرسنجی JetBrains در همان دوره این رقم را ۴۴٪ گزارش کرد. این اعداد سریع رشد کردند — هر دو نظرسنجی تقریباً دو برابر شدن نسبت به دو سال قبل را نشان دادند. پذیرش، به عبارت دیگر، دیگر سؤال جالبی نیست. اینکه آیا این ابزارها واقعاً باگ‌های مهم را بدون غرق کردن آن‌ها در نویز می‌گیرند یا نه، سؤال است.
مشکل مثبت کاذب واقعی است، و باید به اعداد فروشندگان با تردید نگاه کرد
یک بنچمارک مارس ۲۰۲۶ از Signal65، که پنج ابزار بازبینی تجاری را در برابر باگ‌های تاریخی واقعی در شش مخزن متن‌باز آزمایش کرد، به CodeRabbit دقت ۹۵.۸۸٪ نسبت داد. این رقم از مطالعه‌ای سفارشی‌شده توسط فروشنده می‌آید و باید متناسب با آن وزن‌دهی شود — اعداد دقت از بنچمارک‌هایی که حول نقاط قوت یک اسپانسر طراحی شده‌اند به‌ندرت در تماس با یک کدبیس نامرتبط دوام می‌آورند.
گزارش‌های نوشته‌شده توسط توسعه‌دهندگان داستانی پیچیده‌تر را روایت می‌کنند. یادداشت‌های مستقل در میان تیم‌های مهندسی نشان می‌دهند ابزارهای بازبینی هوش مصنوعی پیکربندی‌نشده نرخ مثبت کاذب در بازه ۱۵ تا ۲۵ درصد روی Pull Requestهای معمولی تولید می‌کنند، که تنها پس از هفته‌ها تنظیم ابزار برای کدبیس، راهنمای سبک و الگوهای امن‌شناخته‌شده خاص تیم به حدود ۷ تا ۱۲ درصد می‌رسد. آن هزینه تنظیم همان چیزی است که معمولاً از معرفی‌های فروشندگان حذف می‌شود.
جایی که این ابزارها واقعاً کار می‌کنند
واضح‌ترین پیروزی‌ها محدود و مکانیکی هستند: علامت‌گذاری رمزهای عبور hardcode شده، گرفتن الگوهای SQL injection، اجرای راهنمای سبک، و تشخیص دسته خاصی از خطاهای null-pointer و off-by-one که به‌طور مداوم در diff ها ظاهر می‌شوند. این‌ها مسائل تطبیق الگو هستند، و ابزارهای مبتنی بر LLM در تطبیق الگو در سراسر زمینه کامل یک diff به شیوه‌ای که یک linter نیست، خوب عمل می‌کنند.
واضح‌ترین شکست‌ها در قضاوت‌ها است — اینکه آیا تغییری واقعاً باگ زیربنایی را رفع می‌کند یا فقط علامتی را پوشش می‌دهد، آیا یک وابستگی جدید معامله معقولی است، آیا یک refactor رفتاری را که توسط تست‌ها پوشش داده نشده حفظ می‌کند. این‌ها نیاز به درک قصد دارند، و قصد دقیقاً چیزی است که یک diff، جدا از گفتگویی که آن را تولید کرده، به‌طور قابل‌اعتماد به یک مدل منتقل نمی‌کند، همان‌طور که به یک انسانی که خیلی سریع نگاه می‌کند هم منتقل نمی‌شود.
چه چیزی واقعاً گلوگاه را کاهش می‌دهد
تیم‌هایی که صرفه‌جویی زمانی خالص گزارش می‌کنند، نه فقط جابه‌جایی، چند عمل مشترک دارند. اول، آن‌ها بازبین هوش مصنوعی را به دسته‌ای ثابت از بررسی‌ها محدود می‌کنند — الگوهای امنیتی، سبک و دسته‌های باگ شناخته‌شده — به‌جای درخواست بررسی گسترده صحت از آن. دوم، آن‌ها ماه اول استقرار را به‌عنوان دوره تنظیم در نظر می‌گیرند، با بازخورد مثبت‌های کاذب تا نرخ نویز کاهش یابد، به‌جای انتظار دقت out-of-the-box. سوم، و پرتکرارترین مورد ذکرشده، آن‌ها یک انسان را به‌عنوان تصویب‌کننده نهایی برای هر چیزی که به احراز هویت، پرداخت‌ها یا حذف داده مربوط می‌شود نگه می‌دارند، بدون توجه به آنچه بازبین هوش مصنوعی می‌گوید، زیرا این دسته‌هایی هستند که یک منفی کاذب در آن‌ها به اندازه‌ای پرهزینه است که هزینه غربال‌گری اضافی ارزش پرداخت را دارد.
الگو در هر سه عمل یکسان است: بازبینی کد با هوش مصنوعی به‌عنوان فیلتری عمل می‌کند که آنچه یک انسان باید با دقت به آن نگاه کند را محدود می‌کند، نه به‌عنوان جایگزینی برای آن نگاه نهایی. تیم‌هایی که آن را با انتظار دومی مستقر کردند اکنون همان‌هایی هستند که گزارش می‌دهند بازبینی به‌اندازه قبل طول می‌کشد — زمان فقط از خواندن کد به خواندن بات منتقل شده است.