Code Review با هوش مصنوعی؛ چه چیزهایی را می‌توان به AI سپرد؟

صف انتظار Review طولانی است؛ نویسنده‌ها از Agent برای تولید PR استفاده می‌کنند و حجم Diff بالا می‌رود. وسوسه این است که «خود AI هم Review کند و تمام.» بخشی از این وسوسه درست است: مدل در یافتن الگوهای تکراری، ناهماهنگی سبک، و بعضی کلاس‌های باگ سریع است. بخش خطرناکش این است که Approve نهایی و فهم دامنه را هم به همان مدل بدهید که کد را نوشته یا حتی ندیده.

مستندات GitHub Copilot code review می‌گوید سیستم PR را بررسی و اصلاح پیشنهاد می‌کند، از چند زاویه بازخورد می‌دهد، و قابلیت‌های agentic برای جمع‌آوری زمینه دارد—اما همهٔ مسائل را پیدا نمی‌کند و باید با دقت اعتبارسنجی و با Review انسانی تکمیل شود. این مقاله همان خط را به تقسیم کار عملی تبدیل می‌کند.

پاسخ کوتاه

به AI بسپارید: مرور اولیه برای باگهای رایج، ناهماهنگی سبک، پیشنهاد تست جاافتاده، یادآوری قراردادهای نوشته‌شده در instructions، و بازخورد زودهنگام روی Draft. به انسان بسپارید: صحت منطق کسب‌وکار، معماری و مرز سرویس، پذیرش ریسک امنیتی، خوانایی برای نگهداری بلندمدت، و Approve نهایی مسیرهای حساس. AI لایهٔ اول است؛ جایگزین Reviewer مسئول نیست.

Review خوب یعنی کاهش ریسک Merge—نه فقط کامنت بیشتر.

Code Review قرار است چه مسئله‌ای را حل کند؟

هدف نمایش دانش نیست؛ هدف جلوگیری از ورود نقص به شاخهٔ مشترک است: صحت، امنیت، نگهداری، دانش تیمی. AI می‌تواند بخشی از بازرسی مکانیکی را ارزان کند تا انسان روی قضاوت بماند. اگر AI را طوری به کار ببرید که انسان کمتر Diff را بخواند، فقط نمایش پیشرفت ساخته‌اید.

جدول تقسیم کار

چه چیزهایی را خوب می‌توان به AI سپرد؟

بازخورد زودهنگام روی Draft

GitHub امکان Review خودکار روی Draft یا اولین Open را می‌دهد تا نویسنده قبل از درگیر کردن انسان، مسائل سطحی را جمع کند. این صف انسان را سبک می‌کند—به شرطی که Draft تبدیل به «Approve مصنوعی» نشود.

پیدا کردن الگوهای تکراری و ناهماهنگی

تکرار منطق، import بلااستفاده، کپی پیست بین ماژول‌ها، نام‌های متناقض. مدل با زمینهٔ مخزن (و در Copilot با custom instructions و skills) دقیق‌تر می‌شود.

پیشنهاد اصلاح قابل‌اعمال

پیشنهادهای کوچک با یک کلیک یا سپردن به cloud agent برای PR اصلاحی—مفید وقتی پیشنهاد را فهمیده‌اید. اعمال کور همهٔ پیشنهادها همان Improper Output Handling است.

یادآوری سیاست نوشته‌شده

اگر در `.github/copilot-instructions.md` یا Rules نوشته‌اید «لاگ PII ممنوع» یا «از این ORM فلان API را استفاده کن»، AI Review می‌تواند تخطی آشکار را پرچم کند. سیاست نانوشته را کشف نمی‌کند.

چه چیزهایی را نباید فقط به AI سپرد؟

• Approve نهایی برای auth، پرداخت، مهاجرت داده، و حذف رکورد.
• قضاوت دربارهٔ اینکه آیا تغییر با هدف Issue واقعاً می‌خواند.
• پذیرش ریسک امنیتی یا استثنای موقت کنترل.
• Review طراحی که آیندهٔ نگهداری را تعیین می‌کند.
• تأیید اینکه تست‌ها رفتار درست را قفل کرده‌اند نه پیاده‌سازی غلط.

اگر سازمان قابلیت «Copilot approvals» را آزمایش می‌کند، آن را با سیاست جدا و دامنهٔ محدود تعریف کنید؛ پیش‌فرض امن این است که Approve مدل به‌تنهایی کافی برای Merge مسیر حساس نباشد.

چگونه کیفیت AI Review را بالا ببریم؟

1. Custom instructions مخزن: استاندارد تست، امنیت، و معماری به زبان کوتاه.
2. دستورهای مسیر‌محور برای پوشه‌های حساس.
3. توضیح خوب در بدنهٔ PR: هدف، ریسک، نحوهٔ تست—زمینه به مدل و انسان کمک می‌کند.
4. انتخاب سطح تلاش: در Copilot، Lite برای تغییرات روتین و Balanced برای منطق پیچیده یا امنیت‌حساس (با هزینهٔ بیشتر).
5. MCP و skills فقط با حداقل لازم؛ ابزار باز = نویز و ریسک.
6. انسان همیشه پیشنهادها را روی Diff واقعی چک کند.

گردش‌کار پیشنهادی تیم

1. نویسنده با Agent/Assistant PR کوچک می‌سازد.
2. AI Review خودکار روی Draft یا Open اولیه.
3. نویسنده پیشنهادهای معقول را اعمال و بقیه را رد می‌کند با دلیل.
4. Reviewer انسان روی منطق، امنیت، و نگهداری تمرکز می‌کند—نه روی ویرگول.
5. CI (تست، lint، SCA، secret scan) دروازهٔ Merge است.
6. برای مسیر قرمز، Review دوم یا checklist امنیتی.

این ترتیب با روح MEASURE/MANAGE در NIST سازگار است: لایهٔ خودکار اندازه می‌گیرد و انسان مدیریت ریسک می‌کند.

محدودیت‌ها و شکست‌های رایج

• False positive زیاد → خستگی و نادیده گرفتن همهٔ کامنت‌ها.
• False negative روی باگ دامنه → حس امنیت کاذب.
• حجم PR بزرگ → هم AI هم انسان سطحی می‌شوند.
• نبود instructions → بازخورد عمومی و کم‌ارزش.
• نویسنده همان مدل Review را «تأیید نهایی» می‌داند چون لحن قاطع دارد.

OWASP Misinformation و Improper Output Handling اینجا هم‌زمان‌اند: بازخورد غلط می‌تواند نویسنده را به مسیر ناامن بکشاند اگر بدون اعتبارسنجی اعمال شود.

AI Review در برابر ابزارهای کلاسیک

Linter، typechecker، CodeQL/SAST، و secret scanning قطعی‌تر و قابل تکرارترند. AI مکمل است برای آنچه قواعد سخت به سختی می‌گیرند: نیت، خوانایی، و بعضی الگوهای منطقی. هیچ‌کدام را به خاطر دیگری خاموش نکنید. GitHub جداگانه Code Quality را کنار Copilot code review مطرح می‌کند—نشانهٔ اینکه لایهٔ قواعد همچنان لازم است.

متریک‌های سالم

• زمان تا اولین بازخورد (AI می‌تواند کم کند).
• نرخ کامنت‌های AI که نویسنده می‌پذیرد و بعداً در Review انسانی رد نمی‌شود.
• نقص‌های یافت‌شده پس از Merge در مسیرهای AI-reviewed.
• زمان Review انسان روی منطق—باید بالا بماند نه قربانی سرعت ظاهری.

سوالات متداول

آیا Junior می‌تواند فقط با AI Review Merge کند؟

خیر برای Production. AI برای یادگیری و پاکسازی اولیه خوب است؛ Merge نیاز به Reviewer با مالکیت دارد.

اگر AI و انسان خلاف هم بگویند؟

انسان با دلیل و تست تصمیم می‌گیرد. ثبت اختلاف در کامنت PR برای یادگیری تیم مفید است.

Cursor هم Review می‌کند؟

می‌توانید از Agent/Ask بخواهید Diff را نقد کند؛ محصول تخصصی «reviewer درخواستی روی PR» مثل Copilot code review را با گردش GitHub یکسان ندانید. اصل یکی است: پیشنهاد را اعتبارسنجی کنید.

خلاصه

به AI سپردنِ مرور اولیه، سبک، سرنخ باگ و یادآوری سیاست عاقلانه است؛ سپردن Approve نهایی، منطق دامنه و پذیرش ریسک نیست. با instructions، PR کوچک، CI قطعی و Reviewer انسان، صف را کوتاه و کیفیت را نگه می‌دارید.

طراحی Rubric مشترک انسان و AI

Rubric کوتاه روی شش محور: صحت در برابر AC، امنیت داده/دسترسی، سازگاری قرارداد، آزمون‌پذیری، خوانایی، و شعاع Diff. از AI بخواهید روی همین محورها کامنت بدهد؛ از انسان بخواهید فقط روی محورهایی که امتیاز پایین یا عدم اطمینان دارد وقت بگذارد. این کار از پراکندگی کامنت‌های سلیقه‌ای کم می‌کند.

Rubric را در instructions مخزن هم خلاصه کنید تا AI Review با زبان تیم حرف بزند.

Review کد تولیدشده توسط همان اکوسیستم AI

وقتی نویسنده Agent و بازبین هم Copilot code review است، خطر هم‌بستگی خطا وجود دارد: هر دو ممکن است الگوی رایج اما غلط را «طبیعی» ببینند. برای مسیرهای حساس، Reviewer انسانی که در نوشتن آن Diff مشارکت نداشته و ترجیحاً ابزار متفاوت یا دیدگاه دامنه دارد، ضروری است.

تکنیک: یک چک‌لیست «فرض‌های خطرناک»—مثل خوش‌بینی به ورودی، نادیده‌گرفتن timezone، بلعیدن exception—را انسان همیشه دستی ببیند حتی اگر AI چیزی نگفت.

مدیریت حجم کامنت AI

اگر AI بیست کامنت سبکی بدهد، نویسنده یا همه را کور قبول می‌کند یا همه را نادیده. تنظیمات: سطح تلاش مناسب، محدود کردن فایل‌های تولیدشده، و قوانین «فقط مسائل با شدت متوسط به بالا». انسان می‌تواند از مدل بخواهد کامنت‌ها را در سه سطل Must / Should / Nit دسته‌بندی کند و فقط Must را جدی بگیرد.

نیت‌ها را در قالب پیشنهاد patch کوچک نگه دارید؛ بازنویسی کل فایل در Review معمولاً خارج از محدوده است مگر نویسنده موافق باشد.

آموزش Reviewerها در عصر Agent

مهارت جدید Reviewer: تشخیص بوی کد AI—نام‌گذاری کلی، کامنت‌های بدیهی، تست‌های سطحی، وابستگی تازه بدون دلیل. این بوها ناقص بودن را ثابت نمی‌کنند اما محل تمرکز را نشان می‌دهند. کارگاه ماهانه روی یک PR واقعی Agent-heavy مؤثرتر از اسلاید ابزار است.

Reviewer باید اجازه داشته باشد PR را به دلیل «غیرقابل Review بودن» برگرداند؛ این با سیاست ۱۲۹ هم‌راستاست.

پیوند به GitHub و کیفیت کلاسیک

Branch protection، required reviewers، و CodeQL را خاموش نکنید چون AI Review آمده است. مقالهٔ ۲۰۹ دربارهٔ Review روی GitHub و ۲۲۰ دربارهٔ Branch protection مکمل اجرایی این متن‌اند. AI لایهٔ کمکی است روی همان زیربنا.

نمونهٔ پیام Review برای نویسندهٔ Agent-heavy

به‌جای «این را AI نوشته؛ رد» بنویسید: «Diff بزرگ‌تر از شعاع Issue است؛ لطفاً تغییر لاگ و تغییر API را دو PR کنید. تست نقش کاربر عادی نیست. پیشنهاد Copilot دربارهٔ null-check خوب است—اعمال کنید. دربارهٔ حذف شرط مجوز مخالفم مگر توضیح دامنه بدهید.» این لحن هم سرعت می‌دهد هم استاندارد را نگه می‌دارد.

نویسندگان را تشویق کنید قبل از درخواست Review انسان، AI Review Draft را مصرف کنند تا صف با nitهای سطحی پر نشود.

کجا AI Review را خاموش یا محدود کنیم؟

• مخازن فوق‌سری با سیاست دادهٔ سخت—تا ارزیابی حقوقی/امنیتی تمام شود.
• PRهای فقطdocs کوچک اگر نویز ایجاد می‌کند—اختیاری.
• وقتی مدل مرتب false positive روی DSL داخلی می‌دهد—اول instructions را درست کنید، بعد دوباره روشن کنید.

خاموشی دائمی به‌خاطر یک تجربهٔ بد معمولاً اشتباه است؛ تنظیم instructions و سطح تلاش ارزان‌تر است.

ارتباط Review با تست و Agent

Reviewer باید ببیند آیا تست‌ها oracle مستقل دارند (مقاله ۱۳۱) و آیا Agent خارج از فایل‌های مجاز رفته است (مقاله ۱۲۸). سه مقاله ۱۲۸–۱۳۱ یک زنجیره‌اند: قابلیت، ممنوعیت Ship بدون ناظر، و تقسیم کار Review/Test.

اگر فقط یکی را پیاده کنید، ضعیف‌ترین حلقه می‌شکند. حداقلViable: PR کوچک + AI Review Draft + یک انسان + CI.

خلاصهٔ عملی برای شروع این اسپرینت

1. Auto review روی Draft را برای یک مخزن پایلوت روشن کنید.
2. دستورالعمل مخزن دویست کلمه‌ای بنویسید.
3. Rubric شش‌محوره را در قالب PR بگذارید.
4. مسیرهای قرمز را از Approve-only-AI صریح مستثنی کنید.
5. پس از دو هفته، نرخ پذیرش کامنت AI و نقص گریزی را مرور کنید.

خط آخر برای مدیر مهندسی

بودجهٔ Copilot یا Cursor را با بودجهٔ زمان Reviewer اشتباه نگیرید. اگر ابزار خریدید اما ظرفیت Review انسان را کم کردید، فقط سرعت ورود نقص را خریده‌اید. شاخص سلامت: زمان Review منطق بالا بماند، صف nit پایین بیاید، و نقص تولیدی مسیرهای AI-reviewed افزایش نیابد.

منابع و مراجع

• About GitHub Copilot code review — https://docs.github.com/en/copilot/concepts/agents/code-review
• GitHub Copilot cloud agent (applying review suggestions) — https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
• Cursor Agent overview — https://cursor.com/docs/agent/overview
• OWASP GenAI LLM Top 10 2026 — https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
• NIST AI RMF — https://www.nist.gov/itl/ai-risk-management-framework
• NIST AI 600-1 — https://doi.org/10.6028/NIST.AI.600-1