https://boat.dev/

https://www.brangus.io/survival-llm

این مقاله‌ی Addy Osmani درباره‌ی اینه که تیم Claude Code چطور کد ریویو می‌کنه، در حالی که حدود ۹۰٪ کدشون رو خود Claude می‌نویسه. حرف اصلیش اینه که ریویو رو کنار نذاشتن. بیشترِ خوندن کد رو خودکار کردن و وقت آدم‌ها رو فقط برای جاهای پرریسک نگه داشتن. نتیجه هم این شد که از ژوئن تا سپتامبر تعداد PRهای merge‌شده بیشتر از دو برابر شد و نرخ revert بیش از ۴۰٪ پایین اومد. ایده‌ی اصلی: سؤال «کسی کد رو خونده یا نه؟» معیار خوبی نیست. سؤال درست اینه که این تغییر چه خرابی‌ای ممکنه بیاره و کدوم چک، چه خودکار و چه انسانی، باید اونو بگیره. ریویو هم دیگه یه مرحله‌ی آخر کار نیست و مثل اسپل‌چک وسط خود نوشتن انجام می‌شه. هفت لایه‌ای که هر تغییر ازشون رد می‌شه: 1. قبل از PR: از Claude می‌خوان کارش رو ثابت کنه، یعنی تست بزنه، بیلد کنه یا اسکرین‌شات رو با دیزاین مقایسه کنه، نه اینکه فقط بگه «تموم شد». بعد یه ایجنت دیگه با context تازه diff رو ریویو می‌کنه. به گفته‌ی Boris Cherny، داشتن فرایند verification کیفیت خروجی رو دو تا سه برابر می‌کنه. 2. ریویوی AI روی هر PR: چند ایجنت موازی دنبال باگ می‌گردن و بعد رأی می‌دن که هر یافته واقعیه یا false positive. کامنت‌های صرفاً استایلی فیلتر می‌شن. 3. ریویوی امنیتی: تا وقتی یه یافته‌ی باز هست، PR مرج نمی‌شه. 4. چک‌های استاندارد: lint، type check، تست و بیلد. 5. تأیید انسانی بر اساس ریسک: ریسک رو خود تغییر تعیین می‌کنه، نه اینکه نویسنده‌اش کیه. مثلاً اصلاح داکیومنت با تغییر auto-updater فرق داره. تأیید بات هیچ‌وقت جای تأیید آدم رو نمی‌گیره، و با هر کامیت جدید تأیید قبلی باطل می‌شه. 6. Merge queue، فیچر فلگ و rollout مرحله‌ای: اول خود کارمندای Anthropic استفاده می‌کنن. 7. برگردوندن سریع: اگه چیزی خراب از همه‌ی لایه‌ها رد شد، چند دقیقه‌ای revert می‌شه. یه نکته‌ی جالب: ایجنت نویسنده و ایجنت ریویوور می‌تونن تا ابد با هم کلنجار برن. یه PR یه شب بیش از ۵۰ دور رفت و برگشت خورد. برای همین بعد از سه دور از نویسنده می‌خوان کل رویکرد رو دوباره بررسی کنه، دورهای بعدی فقط diff جدید رو ریویو می‌کنن، و مشکلی که قبلاً گزارش شده دوباره گزارش نمی‌شه. کارهایی که هنوز با آدمه: اینکه اصلاً این چیز ساخته بشه یا نه، کدهای حساس مثل billing و CI، تصمیم‌های معماری، و اینکه مسئولیت هر تغییر با یه آدم مشخصه. قانونشون هم اینه که «هرکی مرج کرد، صاحبشه»، ولی بدون مقصرتراشی. یاد گرفتن کدبیس: وقتی ریویو رو ماشین انجام می‌ده، آدم‌ها کد رو از کجا یاد بگیرن؟ جوابشون اینه که هر وقت لازم شد، از Claude یه توضیح درباره‌ی همون تیکه‌ی کد می‌گیرن که همیشه به‌روزه. چیزایی که می‌گه از فردا خودت هم می‌تونی انجام بدی: - یه فایل CLAUDE.md کوتاه بنویس که checklist چک‌ها توش باشه. - یه فایل REVIEW.md بساز که بگه تو هر بخش از کد چی مهمه. - قبل از PR دستورهای /code-review و /security-review رو اجرا کن. - به قالب PR سه بخش «تست، ریسک، چطور revert کنیم» اضافه کن. - تعداد دورهای ریویو رو محدود کن. - مسیرهای حساس رو با CODEOWNERS ببند. برای پروژه‌ی خودت (flux-saas-runtime) هم که با Claude کار می‌کنی، به نظرم ساختن همون CLAUDE.md و REVIEW.md کم‌هزینه‌ترین و پربازده‌ترین قدمه. اگه بخوای، کمکت می‌کنم یه نسخه‌ی اولیه‌شون رو بنویسیم. [لینک پست](https://x.com/addyosmani/status/2114604912520921136) https://x.com/addyosmani/status/2114604912520921136