Oossa

Anthropic روند بازبینی کد با Claude را تشریح کرد

هدف تیم این است که بیشتر تغییرات با حضور حداکثر یک بازبین انسانی ادغام شوند؛ هرچند خطرهای حل‌نشده و نبود برخی سازوکارهای حفاظتی را هم می‌پذیرد.

نویسنده: منتشرشده توسط Oossa: 2 دقیقه مطالعه

Ilya Pavlov · Unsplash

Anthropic می‌گوید Claude Code اکنون حدود 90% از کد خودش را می‌نویسد و تیم در حال تغییر شیوه بازبینی این کدهاست. در مطلبی از Addy Osmani، Morgan Westlee Lunt و Qing Wang، تیم هدفش را این‌طور توضیح می‌دهد: بیشتر درخواست‌های ادغام باید با حضور حداکثر یک انسان ادغام شوند؛ این فرد می‌تواند همان نویسنده تغییر باشد، بی‌آنکه تعداد بازگشت تغییرات یا رخدادهای ناخواسته افزایش پیدا کند.

به گفته تیم، بازبین‌ها لازم نیست درک کاملی از Claude Code داشته باشند؛ کافی است از Claude بخواهند بخش موردنیاز از کد را برایشان توضیح دهد. این رویکرد در بحثی در Hacker News انتقادهایی برانگیخت: برخی کاربران پرسیدند اگر درک مدل اشتباه باشد، تکیه بر توضیحات هوش مصنوعی باعث نمی‌شود دیگر کسی نتواند علت خرابی را پیدا کند؟

سازوکار مراحل بازبینی

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

خود فرایند بازبینی هم می‌تواند دچار مشکل شود: عامل‌ها به بازخوردهایی عمل می‌کنند که شاید یک انسان نادیده بگیرد. Anthropic از یک درخواست ادغام می‌گوید که یک‌شبه بیش از 50 دور بازبینی و اصلاح را پشت سر گذاشت، تا اینکه نویسنده آن را متوقف کرد. تیم می‌گوید پس از آنکه دریافت اجرای دورهای بیشتر بازبینی اوضاع را بدتر می‌کند، سقفی برای تعداد دورها تعیین کرده است. همچنین متوجه شده که حدود 59% از کدی که در دورهای بعدی علامت‌گذاری شده بود، از همان بررسی نخست بازبین در کد وجود داشت.

آنچه هنوز روشن نیست

نمونه‌ای جداگانه از مخزن عمومی Claude Code محدودیت توضیحات تولیدشده را نشان می‌دهد. در ماه August، پاسخی که Claude تولید کرده بود می‌گفت بعضی مسئله‌ها به‌دلیل بی‌اطلاعاتی لازم برای بازتولید مشکل، به‌علت غیرفعال بودن بسته شده‌اند. اما طبق قواعد مخزن، مسئله‌ها پس از 14 روز با برچسب «راکد» و 14 روز دیگر بسته می‌شوند؛ مگر آنکه دست‌کم 10 رأی مثبت داشته باشند. یک توسعه‌دهنده بیش از 6,000 مسئله را شمرد که برچسب داشتن مراحل بازتولید داشتند، اما با وضعیت غیرفعال بسته شده بودند. پیشنهاد پاسخ برای بازگشایی مسئله با ثبت نظر هم با این روند روبه‌رو شد که مسئله‌های بسته‌شده پس از هفت روز قفل می‌شوند.

Anthropic می‌گوید هنوز سازوکار قطع اضطراری ندارد تا اگر معیارهای بازبینی بدتر شدند، الزامات تأیید را سخت‌گیرانه‌تر کند. محصول Code Review به‌طور عمومی در طرح‌های Team و Enterprise در دسترس است. GitHub Action بازبینی امنیتی متن‌باز است، اما README آن هشدار می‌دهد که در برابر تزریق دستورالعمل مقاوم‌سازی نشده و باید فقط برای بازبینی درخواست‌های ادغام مورداعتماد به کار رود.

چرا مهم است

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

آیا این مقاله مفید بود؟
اشتراک‌گذاری

بیشتر بخوانید

Oossa · خبرنامه

هفتهٔ هوش مصنوعی، به زبان ساده

هر دوشنبه: خبرهایی که ارزش دانستن دارند، به زبان ساده. رایگان و بدون هرزنامه.