تصور کنید برنامهنویسی هستید که پیش از این یک درخواست تغییر (Pull Request) ۴۰۰ خطی میفرستاد، اما حالا با کمک دستیارهای کدنویسی هوش مصنوعی، پنج درخواست ۸۰ خطی ارسال میکند. این تغییر رفتار که در گزارش ۱۳ سپتامبر ۲۰۲۶ وبسایت dev.to بررسی شده، بحرانی در حجم دادهها ایجاد کرده است؛ جایی که سطح کلی کد تغییر نکرده، اما هزینهی اداری برای بازبینهای انسانی چندین برابر شده است. این پدیده در واقع تداوم همان چالشی است که در بررسیهای پیشین دربارهی عمیقتر شدن گلوگاه بازبینی به دلیل سرعت بالای عاملهای هوش مصنوعی به آن پرداختیم.
بسیاری از تیمهای مهندسی به اشتباه سعی میکنند این مشکل را با افزایش سرعت بازبینی هر درخواست حل کنند. اما گلوگاه اصلی، سرعت خواندن نیست، بلکه هزینهی ثابتِ «بارگذاری زمینه» (Context Loading) و پیمایش تفاوتها (Diff Navigation) برای هر درخواست است. این وضعیت شبیه به یک باجه عوارضی است که خودروها در آن کوچکتر شدهاند اما تعدادشان ۱۰ برابر شده است؛ در نتیجه ترافیک فارغ از اینکه باجه با چه سرعتی باز شود، تغییری نمیکند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اتکای مطلق به سرعت تولید بدون در نظر گرفتن زیرساختهای نظارتی، منجر به شکست عملیاتی میشود. برای مقیاسپذیری، تیمها باید سیستمی برای مسیریابی (Routing) پیاده کنند که درخواستها را پیش از آنکه هر انسانی آنها را ببیند، در سه دستهی مجزا فیلتر کند:
چارچوب مسیریابی
- نویزهای استایل و قراردادها: هوش مصنوعی اغلب کدی تولید میکند که از نظر داخلی سازگار است اما استانداردهای خاص تیم را نقض میکند. این موارد باید توسط ابزارهایی که قراردادهای تیم را به عنوان ورودی مستقیم میگیرند، بهطور خودکار علامتگذاری شوند.
- صحت محلی: مشکلاتی مثل نبودِ بررسیهای مقدار تهی (Null Checks) یا فراخوانهای شکسته (Broken Callers) را میتوان با ترکیب تحلیلگرهای ایستا (Static Analyzers) و مدلهایی که زمینه اطراف را میفهمند، شناسایی کرد.
- قصد طراحی (Design Intent): این تنها دستهای است که به قضاوت انسانی نیاز دارد. در اینجا سوال این است که آیا انتزاعِ API درست است یا تغییرات با تاریخچه محصول همخوانی دارد؛ سوالاتی که پاسخ آنها خارج از متنِ تفاوتهای کد (Diff Text) قرار دارد.
به نقل از تحلیل dev.to، هدف یک ابزار بازبینی هوش مصنوعی این نیست که در هر خط کد حق با او باشد. در عوض، این ابزار باید بتواند بهطور قابلاعتمادی روی موارد بدیهی — که انسانها هم در حالت عادی بدون دقت تایید (Rubber-stamp) میکردند — سختگیر باشد تا انرژی انسانها فقط صرف تصمیمات سطح بالا و نیازمند قضاوت شود.
برای تیمهایی که ابزارهای جدید را ارزیابی میکنند، معیار موفقیت «توان عملیاتی» (Throughput) نیست، بلکه نسبتِ «خطاهای شناساییشده و ارجاع داده شده» به «نویزهای تحمیلشده به انسان» است. ابزاری که هر باگی را میگیرد اما روزانه ۱۰۰ کامنت حاشیهای برای بازبین میفرستد، در واقع مشکل حجم را وخیمتر میکند.
این منطق مسیریابی فارغ از اینکه تیم از GitLab، Azure DevOps یا Bitbucket استفاده کند، صادق است؛ زیرا فیلترینگ پیش از آنکه کاربر حتی به رابط کاربری (UI) این پلتفرمها دسترسی پیدا کند، رخ میدهد.
گام بعدی شما
برای پیادهسازی این رویکرد، ابتدا یک مجموعه ارزیابی کوچک از درخواستهای بازبینیشدهی قبلی بسازید. سپس آنها را به سه برچسب «تایید خودکار» (Auto-pass)، «علامتگذاری خودکار» (Auto-flag) و «ارجاع به انسان» (Escalate) تقسیم کنید تا بتوانید بسنجید ابزار مورد نظر با چه دقتی نویزهای خاص کدبیس شما را مسیریابی میکند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو