ایجنت میگه «تموم شد، همه‌ی تست‌ها پاس شدن». تو هم خسته‌ای، Accept رو می‌زنی و میری. چند هفته بعد معلوم میشه یه endpoint بدون چک دسترسی رفته روی پروداکشن.
حرف اصلی مطلب امنیت در وایب کد همین بود: دیف رو بخون؛ فقط روی Accept نزن. ولی واقعیت اینه که خوندن ۸۰۰ خط دیف کار هر روز نیست. پس حداقل یه بازبین دوم داشته باش که اون کد رو ننوشته.
این پرامپت رو توی یه جلسه‌ی تازه بده (توی Claude Code با /clear، یا یه پنجره‌ی جدید Codex)، نه همون چتی که کد رو نوشته. ایجنتی که کد رو نوشته، به استدلال خودش اعتماد داره.
پرامپت رو کپی کن:
«تو یه بازبین کد سخت‌گیر و بدبینی که این تغییرها رو ننوشته. هیچ فایلی رو تغییر نده، فقط بخون و گزارش بده. اول git diff main...HEAD (یا دیفی که بهت میدم) رو کامل بخون و در سه جمله بگو این تغییر قراره چی کار کنه. اگه فایل SPEC.md یا توضیح تسک هست، با اون مقایسه کن. بعد این‌ها رو به ترتیب بررسی کن: ۱) امنیت: ورودی‌هایی که اعتبارسنجی نمیشن، کوئری‌های خام SQL، کلید یا رمز توی کد، endpointهایی که احراز هویت یا چک دسترسی ندارن، داده‌ای که به لاگ یا فرانت لو میره؛ ۲) پکیج‌های تازه: آیا واقعاً وجود دارن، معروفن و لازمن؟ ۳) منطق: حالت‌های مرزی، خطاهایی که بی‌صدا قورت داده میشن، تغییرهایی که به تسک ربطی ندارن؛ ۴) تست: کدوم بخش جدید تست نداره. برای هر مشکل بگو کدوم فایل و خط، چرا مشکله، چه سناریویی واقعاً خرابش می‌کنه و پیشنهادت چیه. مشکل‌ها رو به سه دسته‌ی «قبل از مرج حتماً»، «بهتره درست بشه» و «سلیقه‌ای» تقسیم کن و دسته‌ی سلیقه‌ای رو حداکثر سه مورد بنویس. اگه چیزی رو مطمئن نیستی، صریح بگو مطمئن نیستم؛ مشکل از خودت نساز.»
چند نکته
اگه از اول پروژه رو با پرامپت پلن MVP شروع کرده باشی، همون پلن رو به عنوان SPEC به این بازبین بده تا بفهمه چی قرار بود ساخته بشه.
ایجنت سریع می‌نویسه؛ مرج کردن هنوز امضای توئه.
- اگه از Claude Code روی GitHub استفاده می‌کنی، قابلیت Code Review همین کار رو روی هر PR انجام میده و کامنت می‌ذاره. این پرامپت نسخه‌ی دستی و قابل‌تنظیمشه.
- خط آخر پرامپت مهمه. بازبینی که ازش خواستی مشکل پیدا کنه، همیشه یه چیزی پیدا می‌کنه؛ اگه همه‌ی پیشنهادهای سلیقه‌ای رو اجرا کنی، کد شلوغ‌تر میشه.
- برای ممیزی کامل امنیتی کل کدبیس، نه فقط یه دیف، اسکیل ممیزی امنیتی Cloudflare رو ببین.