AI Agent در یک پروژه نرم‌افزاری چه کارهایی می‌تواند انجام دهد؟
10 دقیقه مطالعه
نقش عملی Agent در مسیر Issue→کد→تست→Review→Deploy، مثال Cursor و Copilot cloud agent، و محدودیت‌های رسمی و تیمی.
سؤال درست این نیست که «آیا Agent می‌تواند جایگزین تیم شود؟»؛ سؤال این است که در کدام ایستگاه‌های مسیر Issue تا Production ارزش می‌آفریند، و کجا باید متوقفش کنید. بدون این نقشه، یا Agent را روی کارهای نمایشی هدر می‌دهید یا بدون ناظر به Deploy نزدیک می‌کنید.
این مقاله جریان کلاسیک Issue → کد → تست → Review → Deploy را می‌شکافد و برای هر مرحله نقش واقع‌بینانهٔ Agent، نمونهٔ محصولی، و محدودیت را می‌نویسد. مبنای محصولی: مستندات GitHub Copilot cloud agent و Cursor Agent/Plan؛ مبنای ریسکی: OWASP Excessive Agency و نظارت انسانی در NIST AI RMF.
پاسخ کوتاه
Agent می‌تواند Issue را بخواند و طرح بدهد، کد را در شاخهٔ جدا تغییر دهد، تست و lint را اجرا کند، پیش‌نویس PR بسازد و پیشنهادهای Review را اعمال کند—به شرطی که هدف، محیط و مجوز محدود باشد. نمی‌تواند به‌تنهایی مالک نیاز کسب‌وکار، تصمیم معماری پرمخاطره، پذیرش ریسک امنیتی، یا Deploy بدون دروازهٔ انسانی/خودکار قابل‌اعتماد باشد. مسیر سالم: Agent پیش‌نویس می‌سازد؛ انسان و CI تصمیم Merge و انتشار را می‌گیرند.
Agent را در حلقهٔ تحویل بگذارید، نه به‌جای حلقهٔ مسئولیت.
نقشهٔ ایستگاه‌ها
| ایستگاه | کار مفید Agent | کار غیرمجاز / پرریسک | ناظر انسانی |
|---|---|---|---|
| Issue / نیاز | خلاصه‌سازی، شکستن به زیرکار، طرح اولیه | تعیین اولویت کسب‌وکار بدون مالک محصول | PO / Tech Lead |
| طراحی | گزینه‌ها و trade-off، Plan Mode | انتخاب نهایی معماری حیاتی | معمار / Lead |
| پیاده‌سازی | ویرایش چندفایلی محدود، boilerplate | بازنویسی هستهٔ auth در یک نشست | نویسندهٔ PR |
| تست | تولید/اجرای unit، رفع شکست ساده | اعلام «پوشش کافی» بدون معیار | QA / نویسنده |
| Review | یافتن الگوی تکراری، پیشنهاد اصلاح | Approve نهایی مسیر حساس | Reviewer انسان |
| Deploy | آماده‌سازی changelog، اسکریپت با Review | Push مستقیم به Production | Release owner + CI |
۱) از Issue تا طرح
GitHub می‌گوید Copilot cloud agent می‌تواند مخزن را تحقیق کند، برنامهٔ پیاده‌سازی بسازد و قبل از باز کردن PR روی شاخه کار کند. Cursor Plan Mode هم قبل از نوشتن کد، طرح قابل‌بازبینی می‌سازد و سؤال شفاف‌ساز می‌پرسد. ارزش این مرحله: کاهش «شروع کدنویسی از روی ابهام».
محدودیت: Agent اولویت backlog، ارزش مشتری، یا وابستگی قانونی را «نمی‌فهمد» مگر شما در Issue نوشته باشید. اگر Acceptance Criteria خالی باشد، طرح زیبا اما بی‌هدف می‌سازد. قانون: Issue بدون معیار Done وارد Agent نشود.
۲) پیاده‌سازی کد
در IDE، Cursor Agent می‌تواند جست‌وجوی کدبیس، ویرایش چند فایل، اجرای فرمان ترمینال و حتی کنترل مرورگر برای بررسی UI را انجام دهد. Copilot agent mode محلی روی محیط شما ویرایش می‌کند؛ cloud agent در محیط موقت Actions کار می‌کند—شفافیت commit و لاگ برای تیم بیشتر است.
- مناسب: رفع باگ با بازتولید، افزودن endpoint هم‌سبک، به‌روزرسانی مستند هم‌راستا با کد، افزایش پوشش تست برای ماژول مشخص.
- نامناسب بدون کنترل: مهاجرت دیتابیس Production، تغییر مدل مجوز، حذف داده، یا کار همزمان روی چند مخزن (cloud agent رسماً فقط یک مخزن در هر اجرا).
محدودیت رسمی cloud agent شامل سقف زمانی نشست (۵۹ دقیقه)، یک شاخه و یک PR به ازای هر وظیفه، و وابستگی به سازگاری با branch protection است. کار بزرگ را بشکنید.
۳) تست
Agent در محیط خودش می‌تواند تست و linter را اجرا کند و روی شکست‌ها تکرار کند—همین حلقهٔ مشاهده است که Agent را از چت جدا می‌کند. اما سبز شدن تست‌های موجود به معنی درست بودن رفتار جدید نیست؛ اگر تست را هم خودش نوشته باشد، خطر «تست تأیید تعارف‌آمیز» بالاست.
نقش درست: بخواهید caseهای مرزی و منفی را پیشنهاد دهد؛ شما تصمیم بگیرید کدام باید قفل رفتار باشد. جزئیات بیشتر در مقالهٔ ۱۳۱.
۴) Review
Copilot code review می‌تواند PR را از چند زاویه بررسی و اصلاح پیشنهاد دهد؛ قابلیت‌های agentic برای جمع‌آوری زمینهٔ پروژه دارد و می‌توان پیشنهادها را به cloud agent سپرد تا PR اصلاحی بسازد. با این حال اسناد GitHub صریح است: همهٔ مسائل را پیدا نمی‌کند؛ بازخورد را اعتبارسنجی کنید و با Review انسانی تکمیل کنید.
Agent نباید تنها Approve لازم برای مسیرهای auth، پرداخت، یا داده‌های شخصی باشد—حتی اگر محصول «Copilot approvals» در پیش‌نمایش ارائه دهد. سیاست تیم را جدا از قابلیت محصول بنویسید.
۵) Deploy و عملیات
نزدیک‌ترین کمک ایمن Agent در این ایستگاه: تولید یادداشت انتشار از روی PRها، پیشنهاد چک‌لیست rollback، یا اصلاح pipeline در شاخهٔ جدا با Review. اتصال مستقیم Agent به secrets Production، SSH سرور، یا دکمهٔ Deploy بدون لایهٔ CI و انسان، ترکیب Excessive Agency و Improper Output Handling است.
NIST بر اندازه‌گیری و مدیریت ریسک در چرخهٔ عمر تأکید دارد: اگر Deploy را به مدل می‌سپارید، حداقل متریک و مدار شکن (circuit breaker) و Approval انسانی برای انتشارهای پرریسک لازم است.
الگوی جریان توصیه‌شده
- Issue با AC و محدودیت شعاع (فایل‌ها/سرویس‌های مجاز).
- Plan یا تحقیق Agent → تأیید انسان روی رویکرد.
- پیاده‌سازی روی شاخهٔ جدا (محلی یا cloud).
- اجرای تست/lint؛ شکست‌ها یا درست می‌شوند یا گزارش شفاف.
- PR با توضیح Diff و ریسک؛ Review انسانی (+ اختیاری AI review).
- Merge فقط با CI سبز و دروازه‌های branch protection.
- Deploy توسط مسیر آزادسازی موجود تیم—نه از چت Agent.
چه کارهایی را خوب بلداست؟
- کارهای تکراری با الگوی مشخص در مخزن.
- گشت‌زنی برای یافتن نقاط اتصال API یا استفاده‌های یک نماد.
- پیش‌نویس تست برای توابع خالص و قراردادهای واضح.
- رفع خطاهای واضح کامپایلر/typechecker در حلقه.
- مستندسازی و به‌روزرسانی مثال‌ها همزمان با تغییر کد.
- Issueهای «nice to have» که منابع انسانی کم است—طبق پیشنهاد GitHub برای محول‌کردن کارهای بهبود کیفیت.
محدودیت‌ها؛ صادقانه
محدودیت محصولی
- زمینهٔ ناقص نسبت به دانش ضمنی تیم و تاریخچهٔ حوادث.
- سقف زمان/دامنه (یک مخزن، یک PR، timeout).
- وابستگی به کیفیت Issue، Rules، و custom instructions.
- خطای مطمئن‌به‌نظر (hallucination) در توضیح علت یا ادعای پوشش تست.
محدودیت سازمانی
- نبود Branch protection یعنی Agent می‌تواند میان‌بر خطرناک پیدا کند—یا برعکس، ruleset ناسازگار جلوی cloud agent را می‌گیرد.
- بدون مالک سرویس، خروجی Agent یتیم می‌ماند.
- هزینهٔ Actions و اعتبار مدل اگر بدون بودجه و نرخ‌محدودیت رها شود (Unbounded Consumption در خانوادهٔ ریسک‌های LLM).
خط قرمز
- اعمال خودکار روی main بدون PR.
- دسترسی نوشتنی به Production DB یا vault.
- اجرای فرمان‌های مخرب بر اساس خروجی اعتبارسنجی‌نشده.
- سپردن تصمیم حقوقی/合规 یا پذیرش ریسک امنیتی به مدل.
تنظیمات که قابلیت را واقعی می‌کند
Cursor: Rules پروژه، انتخاب حالت (Plan قبل از کار بزرگ)، Checkpoints برای برگشت. Copilot: custom instructions مخزن، skills، MCP محدود، hooks برای اسکن/اعتبارسنجی، و جدا کردن agent mode IDE از cloud agent از نظر سیاست. در هر دو حالت: شاخهٔ جدا، PR کوچک، و ممنوعیت Secret در پرامپت.
OWASP برای کاهش Excessive Agency می‌گوید ابزارها را حداقل کنید، کارکرد ابزار را باریک کنید، از ابزارهای باز مثل «هر فرمان shell» پرهیز کنید، مجوز پایین‌دستی را کم کنید، و برای اقدام پراثر تأیید انسان بخواهید. این‌ها را به چک‌باکس تنظیمات محصول ترجمه کنید.
نمونهٔ داستان یک اسپرینت
تیم یک سرویس صورتحساب دارد. دوشنبه: Agent روی Issue «افزودن لاگ ساختاریافته به مسیر شکست پرداخت» Plan می‌دهد؛ Lead مرز فایل‌ها را تأیید می‌کند. سه‌شنبه: cloud agent PR می‌سازد؛ تست واحد جدید قرمز است؛ Agent در همان شاخه اصلاح می‌کند. چهارشنبه: Copilot code review چند نکتهٔ سبک و یک null-check می‌دهد؛ انسان یک باگ منطقی در retry را می‌گیرد که AI ندید. پنجشنبه: Merge پس از CI. Deploy طبق pipeline؛ Agent فقط پیش‌نویس Release Notes می‌دهد. جمعه: متریک—زمان انجام Issue کاهش یافت، Incident صفر. این موفقیت ابزار نیست؛ موفقیت جریان با ناظر است.
اشتباه‌های رایج
- یک پرامپت «کل فیچر را بساز و Deploy کن».
- اندازه‌گیری فقط با تعداد PRهای Agent نه با نرخ برگشت و Incident.
- خاموش کردن تست چون Agent گفت سبز است—بدون دیدن گزارش CI.
- دادن MCP باز به تقویم، ایمیل، و cloud حسابداری «برای راحتی».
- فرض اینکه Agent محدودیت‌های compliance را رعایت می‌کند چون در Rules نوشته‌اید—Rules جایگزین کنترل فنی نیست.
سوالات متداول
آیا Agent می‌تواند به‌تنهایی یک میکروسرویس جدید از صفر بسازد؟
از نظر فنی اسکلت می‌سازد؛ از نظر مهندسی، بدون قرارداد API، مشاهده‌پذیری، و مالکیت عملیاتی، فقط بدهی سریع‌تری می‌سازید. اسکلت را بله؛ تعریف سرویس در Production را خیر.
تفاوت Agent محلی و cloud برای پروژه چیست؟
محلی سریع و روی ماشین شماست؛ مناسب آزمایش. Cloud شفافیت تیمی و محیط ایزوله‌تر دارد؛ مناسب Issueهای محول‌شده. سیاست دسترسی و Secret برای هر کدام جدا تعریف شود.
از کجا بفهمیم زیاده‌روی کرده‌ایم؟
اگر PRها بزرگ‌تر، Review سطحی‌تر، و Incidentهای مسیر AI-touched بیشتر شده، خودمختاری را کم و AC را سخت‌تر کنید—نه لزوماً ابزار را عوض کنید.
خلاصه
در پروژهٔ نرم‌افزاری، Agent در تحقیق، طرح، پیاده‌سازی محدود، اجرای تست، و پیش‌نویس PR قوی است؛ در مالکیت نیاز، پذیرش ریسک، Approve نهایی مسیر حساس، و Deploy بدون دروازه ضعیف یا خطرناک است. جریان Issue→کد→تست→Review→Deploy را نگه دارید و Agent را در ایستگاه‌های میانی با شعاع انفجار معلوم بگذارید.
شکستن کار برای Agent: اندازهٔ درست Issue
Issue ایده‌آل برای Agent یک جملهٔ هدف، فهرست فایل‌ها یا ماژول‌های مجاز، معیار Done قابل‌اجرا (تست نام‌برده)، و آنچه نباید لمس شود دارد. Issue بد: «پرداخت را بهتر کن». Agent در Issue بد یا پرگویی می‌کند یا گستره را بی‌مهار باز می‌کند.
قانون سرانگشتی اندازه: اگر Review انسانی نتواند Diff را در سی دقیقه بفهمد، Issue برای یک نشست Agent بزرگ بوده است. بشکنید به «افزودن لاگ»، «افزودن تست»، «اصلاح retry» جداگانه.
هم‌زیستی با CI/CD موجود
Agent جایگزین pipeline نیست؛ مصرف‌کنندهٔ آن است. بهترین حالت این است که همان چک‌هایی که برای انسان اجباری است برای PRهای Agent هم اجباری باشد: lint، typecheck، unit، SCA، secret scan. اگر برای سرعت پایلوت این‌ها را خاموش کنید، متریک پایلوت بی‌معنا می‌شود.
برای Deploy، از feature flag و rollout تدریجی استفاده کنید تا حتی پس از Merge، شعاع انفجار کنترل شود. Agent می‌تواند پیشنهاد flag بدهد؛ مالک انتشار هنوز انسان است.
مشاهده‌پذیری کار Agent
ترجیح دهید کارهایی که در Git دیده می‌شوند: شاخه، commit، لاگ Actions، PR. کار فقط داخل چت محلی برای آزمایش شخصی خوب است؛ برای تحویل تیمی ردپای ضعیف می‌سازد. cloud agent از این نظر با روح شفافیت تیمی سازگارتر است، به شرط بودجه و سیاست مخزن.
لاگ ابزارها را نگه دارید: کدام MCP صدا خورده، کدام فرمان اجرا شده. در حادثه، بدون این ردپا، Postmortem حدس می‌شود.
آموزش تیم بدون افسانه
یک کارگاه نود دقیقه‌ای: سی دقیقه تعریف و طیف (مقاله ۱۲۷)، سی دقیقه اجرای یک Issue کم‌ریسک با Plan و PR، سی دقیقه Review جمعی Diff. خروجی کارگاه باید قالب Issue و قالب PR به‌روزشده باشد—نه فقط اسلاید.
Juniorها را با Agent روی مسیر Production تنها نگذارید؛ Pair یا Review اجباری ارشد تا وقتی الگوی امن درونی شود.
مرز دانش دامنه و کد میراث
در کدبیس میراث با نام‌گذاری متناقض، Agent بیشتر اشتباه می‌کند مگر Rules و مثال‌های طلایی بدهید. سرمایه‌گذاری روی AGENTS.md / copilot-instructions کوتاه، بازده Agent را بیشتر از عوض‌کردن مدل بالا می‌برد. برای دانش دامنه، لینک به ADR و runbook را در Issue بگذارید؛ مدل آن‌ها را «حدس» نزند.
منابع و مراجع
- About GitHub Copilot cloud agent — GitHub Docs — https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
- About GitHub Copilot code review — GitHub Docs — https://docs.github.com/en/copilot/concepts/agents/code-review
- Cursor Agent overview — https://cursor.com/docs/agent/overview
- Cursor Plan Mode — https://cursor.com/docs/agent/plan-mode
- OWASP GenAI LLM Top 10 2026 (LLM03 Excessive Agency) — 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
نویسنده
سا
سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.
یادداشت‌های مرتبط
برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟
از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.
