چگونه یک پروژه را به AI Coding Agent بسپاریم بدون اینکه کنترل پروژه را از دست بدهیم؟

ترس رایج این است که اگر کار را به Agent بدهید، مالکیت و کیفیت و امنیت از دست می‌رود. ترس مقابلش هم هست: اگر ندهید، از رقبا عقب می‌مانید. هر دو اغراق‌اند. کنترل از دست نمی‌رود چون ابزار جادویی است؛ کنترل از دست می‌رود چون محدوده، دروازهٔ بازبینی، Secret، شاخه، و Definition of Done تعریف نشده‌اند.

مقاله‌های ۰۹۸ تا ۱۰۰ همین لایه‌ها را جداگانه باز کردند: کیفیت، Secret، و دسترسی سرور. این مقاله آن‌ها را در یک چارچوب تفویض جمع می‌کند تا Tech Lead بتواند تصمیم بگیرد چه چیزی را، با چه دروازه‌هایی، به Coding Agent بسپارد.

هدف، فلج کردن اتوماسیون نیست؛ طراحی شعاع انفجار است. بدون ترس‌افکنی، با چک‌لیست تصمیم.

پاسخ کوتاه

پروژه را کامل «تحویل مطلق» ندهید؛ کار را به تکه‌های دارای معیار پذیرش بشکنید، روی شاخهٔ جدا اجرا کنید، Secret را بیرون از پرامپت نگه دارید، دروازهٔ بازبینی انسانی قبل از Merge بگذارید، و Done را از قبل بنویسید. Agent پیش‌نویس و اجرای محدود می‌سازد؛ انسان مالک ریسک و ادغام می‌ماند.

تفویض یعنی واگذاری اجرا با حفظ تصمیم.

چارچوب پنج‌بخشی تصمیم

۱) Scope: چه چیزی را می‌سپارید؟

محدوده را با نتیجهٔ قابل مشاهده بنویسید نه با احساس. مثال خوب: «پوشش تست ماژول صورتحساب را به X برسان» یا «این سه باگ با بازتولید مشخص را رفع کن». مثال بد: «کل بک‌اند را مدرن کن». هرچه Scope بزرگ‌تر، Diff بزرگ‌تر و کنترل سخت‌تر.

سقف پیشنهادی برای شروع: یک هدف که در یک PR قابل Review بگنجد. اگر بزرگ‌تر است، به چند تفویض پشت‌سرهم بشکنید.

۲) Review gates: کجا انسان می‌ایستد؟

حداقل سه دروازه تعریف کنید: تأیید برنامه برای کارهای چندفایلی، بازبینی Diff قبل از Accept یا Merge، و تأیید جدا برای مسیرهای حساس مثل auth و پرداخت و مهاجرت داده. دروازه یعنی توقف اجباری، نه توصیهٔ اخلاقی.

Cursor از نقاط بازرسی و حالت برنامه حرف می‌زند؛ Anthropic روی مجوز ابزار تأکید دارد؛ Copilot cloud agent کار را برای Review برمی‌گرداند. ابزار فرق می‌کند؛ وجود دروازه نباید اختیاری باشد.

۳) Secrets: چه چیزی هرگز وارد پرامپت نشود؟

کلید API، توکن، رمز پایگاه‌داده، و دادهٔ شخصی مشتری در پرامپت ممنوع‌اند — موضوع مرکزی ۰۹۹ و ۰۸۱. به Agent بگویید از متغیر محیطی یا Vault بخواند اگر اصلاً لازم است، و ترجیحاً در محیط بدون Secret واقعی کار کند. نشت از پرامپت گاهی خاموش‌تر از نشت Git است.

۴) Branch strategy: کجا بنویسد؟

شاخهٔ فیچر جدا، محافظت روی main، و ممنوعیت push مستقیم به شاخهٔ آزادسازی. Agent روی شاخهٔ خودش کار کند؛ Merge بعد از CI سبز و Review انسانی. این الگو هزینهٔ کمی دارد و جلوی بسیاری از حوادث را می‌گیرد.

برای عامل ابری هم همین منطق برقرار است: شاخهٔ خروجی را مثل شاخهٔ یک همکار دورکار ببینید، نه مثل commit روی main.

۵) Definition of Done

Done را قبل از شروع بنویسید: رفتار، تست‌ها، مستند لازم، و محدودیت‌های غیرعملکردی. بدون Done، Agent و انسان هر دو می‌توانند خودشان را قانع کنند که کار تمام شده است. این همان اتصال به ۰۹۸ و منطق Acceptance Criteria است.

جدول تصمیم: چه چیزی را بسپارید؟

اتصال ذهنی به ۰۹۸، ۰۹۹، ۱۰۰

۰۹۸ می‌گوید کیفیت با معیار پذیرش و Review و متریک حفظ می‌شود؛ بدون آن تفویض فقط بدهی را سریع‌تر می‌سازد. ۰۹۹ می‌گوید Secret را به مدل ندهید؛ تفویض بدون این خط قرمز، حادثه می‌سازد. ۱۰۰ می‌گوید دسترسی کامل سرور پیش‌فرض قابل‌قبول نیست؛ تفویض باید روی محیط محدود باشد.

اگر یکی از این سه مقاله در تیم جا نیفتاده، اول همان را جمع کنید بعد دامنهٔ Agent را باز کنید. ترتیب برعکس، کنترل را سخت‌تر می‌کند.

الگوی واگذاری یک‌هفته‌ای

1. روز ۱: انتخاب یک سرویس کم‌ریسک و نوشتن سیاست یک‌صفحه‌ای.
2. روز ۲: تنظیم Rules و شاخهٔ محافظت‌شده.
3. روز ۳–۴: دو یا سه تسک کوچک با DoD.
4. روز ۵: بازبینی متریک CI و کیفیت Review.
5. روز ۶–۷: تصمیم برای گسترش یا اصلاح فرآیند.

اگر در پایان هفته Diffها خوانده نمی‌شوند یا Secret در پرامپت دیده شد، گسترش ندهید — فرآیند را درست کنید.

نقش‌ها در تفویض کنترل‌شده

انسان هدف و ریسک را تعیین می‌کند. Agent پیش‌نویس و اجرای محدود می‌سازد. Pipeline تغییر را تکرارپذیر اعمال می‌کند. QA یا Reviewer کیفیت را تأیید می‌کند. قاطی کردن این نقش‌ها — مثلاً Agent هم بنویسد هم مستقیم روی production اعمال کند — همان از دست دادن کنترل است.

در تیم سه‌نفره هم می‌توانید نقش‌ها را سبک نگه دارید: یک نفر صاحب Scope و DoD، یک نفر Reviewer، و CI به‌جای Pipeline پیچیده. مهم جدایی تصمیم و اجراست.

چه چیزی را عمداً تفویض نکنید؟

• تصمیم معماری نهایی بدون سند تصمیم.
• تغییر سیاست دسترسی و IAM.
• مدیریت پول و دادهٔ حساس مشتری به‌صورت مستقیم.
• هر کار برگشت‌ناپذیر بدون تمرین بازیابی.
• نوشتن سیاست حقوقی یا امنیتی به‌عنوان حقیقت نهایی.

Agent می‌تواند گزینه‌ها و پیش‌نویس بدهد؛ امضای تصمیم با انسان می‌ماند. این مرز ترس نیست؛ مهندسی مسئولیت است.

شاخص‌های از دست رفتن کنترل

اگر این نشانه‌ها را دیدید، دامنه را کوچک کنید: PRهای هزارخطی بدون برش، Merge بدون خواندن Diff، افزایش Incident بعد از PRهای AI-heavy، Secret در تاریخچهٔ چت، و ناتوانی در توضیح تغییر توسط نویسندهٔ انسانی.

NIST AI RMF بر نظارت انسانی و اندازه‌گیری تأکید دارد؛ OWASP هم Excessive Agency را ریسک می‌داند. ترجمهٔ عملی همان کوچک کردن Scope و سفت کردن دروازه‌هاست، نه کنار گذاشتن کامل ابزار.

ارتباط با تعریف Agent و حلقهٔ کار

مقالهٔ ۱۰۱ می‌گوید Agent هدف‌محور و ابزاردار است؛ پس تفویض بدون هدف و ابزار مجاز بی‌معناست. مقالهٔ ۱۰۲ حلقهٔ context تا observe را نشان می‌دهد؛ تفویض خوب یعنی شما در plan و observe و Merge حاضرید. مقالهٔ ۱۰۳ پرامپت را قرارداد می‌کند؛ بدون پرامپت قیددار، Scope می‌لغزد.

سناریوی نمونه: سپردن یک اپیک بدون از دست دادن کنترل

اپیک «بهبود مشاهده‌پذیری سرویس سفارش» را به سه تفویض بشکنید: افزودن متریک، افزودن لاگ ساختاریافته، و داشبورد. برای هر کدام DoD جدا، شاخهٔ جدا، و Review جدا بنویسید. Agent هر تکه را انجام می‌دهد؛ شما بین تکه‌ها یکپارچگی را چک می‌کنید. اگر اپیک را یکجا بدهید، کنترل را از همان اول رها کرده‌اید.

در پایان هر تکه بپرسید: آیا می‌توانم این تغییر را برای تیم توضیح دهم؟ اگر نه، Merge نکنید تا بفهمید — حتی اگر تست سبز است.

سیاست یک‌صفحه‌ای پیشنهادی

• ابزارهای مجاز و وضعیت حریم خصوصی.
• ممنوعیت Secret در پرامپت.
• محیط‌های مجاز برای اجرا.
• مسیرهای نیازمند Review دوم.
• قانون شاخه و Merge.
• مالک بازبینی هفتگی دسترسی‌ها.

این صفحه را در onboarding بگذارید. بدون آن، هر فرد استاندارد خودش را اختراع می‌کند و کنترل میانگین پایین می‌آید.

پاسخ به فشار «بگذار خودش تمام کند»

اتوماسیون کامل برای کارهای تکراری و کم‌ریسک خوب است؛ برای مسیر پول و هویت نه. بگویید: Agent می‌تواند PR آماده کند، Pipeline می‌تواند به staging ببرد، انسان برای production تصمیم می‌گیرد. این جمله را در سیاست بنویسید تا بحث هر بار از صفر شروع نشود.

پیوندهای داخلی

جزئیات عملی برای Tech Lead

یک ماتریس ساده روی ویکی بگذارید: ستون‌های محیط، نوع کار، سطح خودمختاری مجاز، دروازهٔ بازبینی، و صاحب. هر درخواست جدید برای باز کردن دامنهٔ Agent باید یک ردیف به این ماتریس اضافه کند. این کار جلوی تصمیم‌های شفاهی فراموش‌شونده را می‌گیرد.

در جلسات برنامه‌ریزی اسپرینت، کارت‌های AI-assisted را با برچسب مشخص کنید تا بعداً متریک جداگانه داشته باشید. بدون برچسب، نمی‌فهمید سرعت از کجا آمده و کیفیت از کجا رفته است.

تمرین Tabletop یک‌ساعته

سناریو: Agent روی شاخهٔ فیچر دستوری پیشنهاد می‌کند که دادهٔ staging را پاک می‌کند. تیم چه می‌کند؟ چه کسی دسترسی را قطع می‌کند؟ چگونه PR را متوقف می‌کنید؟ اگر جواب‌ها مبهم‌اند، تفویض را گسترش ندهید تا پاسخ عملی داشته باشید.

این تمرین ترس‌افکنی نیست؛ همان آمادگی حادثه است که برای هر سیستم خودکار لازم دارید.

جمع‌بندی مدیریتی

به زبان مدیریت: هزینهٔ یک Incident ناشی از تفویض بدون دروازه معمولاً از هزینهٔ چند ساعت اصطکاک Review بیشتر است. کنترل اینجا ضد نوآوری نیست؛ شرط پایدار ماندن سرعت است. با پنج قفل این مقاله می‌توانید هم Agent را وارد جریان کار کنید هم مالک پروژه بمانید.

لایهٔ امنیتی بدون اغراق

جمع‌بندی برای تصمیم

تفویض کنترل‌شده یعنی فرض کنید Agent ممکن است اشتباه کند یا فریب بخورد؛ بنابراین دسترسی را حداقل، موقت و قابل ممیزی نگه دارید. این همان روح مقالات ۱۰۰ و ۰۲۷ است. لازم نیست از AI بترسید؛ لازم است مثل هر سرویس production-facing برایش سطح حمله تعریف کنید.

برای MCP و کانکتورهای خارجی هم همین قاعده را اعمال کنید: هر اتصال جدید یک ردیف در ماتریس دسترسی است. اگر صاحب و Scope ندارد، روشن نکنید.

کیفیت Review در حضور Agent

Review نباید به خلاصهٔ Agent اکتفا کند. Diff را بخوانید، روی مسیرهای حساس وقت بیشتر بگذارید، و از نویسنده بخواهید تغییر را با زبان خودش توضیح دهد. اگر توضیح فقط کپی خلاصهٔ مدل است، مالکیت وجود ندارد.

برای PRهای بزرگ، برش اجباری کنید. یک PR هزارخطی تولیدشده در یک نشست تقریباً همیشه نشانهٔ Scope بد است نه قدرت مدل.

معیار موفقیت تفویض بعد از یک ماه

• زمان چرخهٔ کارت‌های کم‌ریسک کاهش یافته بدون افزایش Rollback.
• تعداد یافته‌های Secret در پرامپت نزدیک صفر است.
• همهٔ PRهای AI-assisted برچسب دارند.
• ماتریس دسترسی ماهانه بازبینی شده.
• اعضای تیم می‌توانند بدون نگاه به چت، تغییر را توضیح دهند.

اگر این معیارها برقرار نیست، ابزار را عوض نکنید — Scope و دروازه‌ها را اصلاح کنید. بیشتر شکست‌های تفویض، شکست فرآیندند نه شکست مدل.

یادداشت پایانی

تفویض به AI Coding Agent وقتی بالغ است که بتوانید بگویید چه چیزی را سپرده‌اید، چه چیزی را عمداً نسپرده‌اید، و اگر اشتباه شد چگونه متوقف می‌کنید. با این سه جمله، کنترل پروژه دست شماست — حتی وقتی سرعت تولید بالاتر رفته است.

کنترل با پنج قفل حفظ می‌شود: Scope کوچک، Review gates، ممنوعیت Secret، شاخهٔ جدا، و Definition of Done. Agent را همکار سریع اما بی‌مسئولیت ببینید؛ مسئولیت با شماست. این رویکرد ضد سرعت نیست؛ ضد غافلگیری است.

این مقاله را کنار ۰۹۷ تا ۱۰۳ بخوانید تا نقشهٔ ابزار، تعریف Agent، حلقهٔ کار، پرامپت، کیفیت، Secret و دسترسی یک تصویر واحد بسازند.

برای مدیران غیرفنی: یک جملهٔ تصمیم

بله، می‌توان بخشی از اجرای پروژه را به Coding Agent سپرد؛ به شرطی که Scope محدود، Review انسانی، ممنوعیت Secret، شاخهٔ جدا و Definition of Done از قبل روشن باشد. بدون این پنج شرط، نه — اول فرآیند را بسازید. این پاسخ هم امید بی‌پایه نمی‌دهد هم ترس بی‌مورد پخش نمی‌کند.

قدم بعد: یک تسک کم‌ریسک را با همین پنج قفل بسپارید و بعد از Merge، پنج دقیقه صرف نوشتن درس‌آموخته کنید.

منابع و مراجع

• Cursor Docs — Agent overview (checkpoints, tools) — https://cursor.com/docs/agent/overview
• Anthropic — Agent SDK overview (permissions) — https://platform.claude.com/docs/en/agent-sdk/overview
• NIST AI RMF — https://www.nist.gov/itl/ai-risk-management-framework
• OWASP GenAI LLM Top 10 — https://genai.owasp.org/llm-top-10/
• GitHub Docs — Copilot cloud agent — https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

تفویض را مثل طراحی دسترسی Review کنید؛ چون همان‌قدر به کنترل پروژه گره خورده است.