‏بحران کد ریویو در عصر ایجنت‌های هوش مصنوعی

فرایند کد ریویو که در پروژه‌های اوپن‌سورس دهه ۹۰ شکل گرفت و بعدها توسط گوگل و گیت‌هاب جهانی شد، یک مکانیزم ساده برای همکاری در محیط‌های کم‌اعتماد بود. یک انسان تغییری ایجاد می‌کرد، انسان دیگری آن را بررسی می‌کرد و بعد از چند رفت‌و‌برگشت، به شاخه اصلی ادغام می‌شد. این فرایند باگ‌ها رو شکار نمی‌کرد، ولی مدل ذهنی مشترکی از کدبیس می‌ساخت و نرم‌های تیمی رو منتقل می‌کرد.

حالا ایجنت‌های هوش مصنوعی این معادله رو کاملاً خراب کردن. اگر بخوای ایجنت رو به فرایند قدیمی اضافه کنی، حجم ریویو دو برابر می‌شه؛ یه بار انسان خودش کد ایجنت رو بررسی می‌کنه، یه بار هم همتاش. از اون طرف چون ایجنت‌ها بهره‌وری رو بالا می‌برن، تعداد کل تغییرات هم بیشتر می‌شه. نتیجه؟ قبل از اینکه بتونی از ایجنت‌ها ارزشی بگیری، پهنای باند ریویوت تموم می‌شه.

اما کسی اصلاً این مسیر «آرمانی» رو طی نمی‌کنه. آنچه در واقعیت اتفاق می‌افته اینه که مشارکت‌کننده کد رو سطحی چک می‌کنه، پول ریکوئست باز می‌کنه، کامنت‌های ریویوئر رو مستقیم به ایجنت می‌فرسته و منتظر می‌مونه تا تأیید بگیره. این دقیقاً همون چیزیه که اقتصاددان‌ها بهش «مشکل نماینده-اصیل» (principal-agent problem) می‌گن: ریویوئر نمی‌تونه بفهمه آیا طرف مقابل واقعاً فکر کرده یا نه، چون سیگنال «تلاش» از بین رفته. این پدیده داره اوپن‌سورس رو می‌کشه و با اسم «slop PR» شناخته می‌شه.

تیم‌های کوچک پر‌اعتماد می‌تونن از یه فرایند ساده‌تر استفاده کنن: انسان به ایجنت دستور می‌ده، خودش کد رو ریویو می‌کنه و تأیید می‌کنه، بعد مستقیم دیپلوی می‌کنه. دیگه خبری از ریویو بین همتایان نیست. مهم‌ترین مزیتش اینه که مسئولیت دیپلوی با همون کسیه که ایجنت رو هدایت کرده، پس انگیزه داره کار رو درست انجام بده. البته این مسیر نیاز داره تیم خیلی بیشتر روی تست‌های یکپارچه‌سازی، تست‌های end-to-end و ورک‌فلوهای خودکار تحلیل کامیت سرمایه‌گذاری کنه.

در شرکت‌های بزرگ این راه‌حل عملی نیست. وقتی اعتماد پایینه، هیچ‌کس حاضر نیست مسئولیت یه تغییر گسترده رو بدون پشتوانه ریویو قبول کنه. تا زمانی که کسی فرایند مناسبی برای محیط‌های کم‌اعتماد طراحی نکرده، تیم‌های کوچک یه مزیت چند برابری دارن که شرکت‌های بزرگ ازش محروم‌ان.

نویسنده برای نمونه‌های تاریخی به مایکروسافت دهه ۹۰ اشاره می‌کنه که بدون فرایند اجباری ریویو-قبل-از-کامیت کار می‌کرد و تیم‌های مستقل توسط فرایندهای QA با هم هماهنگ می‌شدن. این همون سبکی بود که چیزهایی مثل win32 API رو تولید کرد که هنوز پابرجاست.

نکات کلیدی:

• فرایند سنتی کد ریویو برای دنیای پیش از ایجنت‌ها طراحی شده و دیگه کافی نیست
• ایجنت‌ها باعث می‌شن بار ریویو دو برابر بشه، در حالی که تعداد تغییرات هم بیشتر می‌شه
• مشکل اصلی «principal-agent problem» است: وقتی ریویوئر نمی‌تونه تلاش واقعی مشارکت‌کننده رو بسنجه
• تیم‌های کوچک با حذف peer review و سپردن مسئولیت دیپلوی به هدایت‌کننده ایجنت می‌تونن این بحران رو دور بزنن
• این راه‌حل به تست‌های بیشتر و ارتباط آگاهانه‌تر نیاز داره
• شرکت‌های بزرگ هنوز فرایند مناسبی برای این چالش ندارن