Atlassian می‌خواهد Jira فقط محل ثبت و پیگیری کار مهندسی نباشد؛ سامانه باید بتواند به‌صورت پیوسته تشخیص دهد کدام کارهای آماده را می‌توان به عامل کدنویسی سپرد، نتیجه را آزمایش کرد و در پایان یک درخواست ادغام کد برای بررسی انسان ساخت. قابلیت تازه Agent loops در کنار ابزارهایی برای دسترسی به اطلاعات چند مخزن، محدود کردن دسترسی عامل‌ها، اعمال استانداردهای کدنویسی و بررسی خودکار تغییرات قرار می‌گیرد.

نکته اصلی این نیست که Jira حالا می‌تواند یک عامل کدنویسی را صدا بزند. Atlassian در تیرماه نیز Jira Automation را به‌عنوان لایه‌ای برای هماهنگ کردن عامل‌های GitHub Copilot، Cursor و Claude معرفی کرده بود. تفاوت انتشار جدید در ادامه‌دار شدن این فرایند است: سامانه می‌تواند خودش بارها صف کار را ببیند و موارد مناسب را انتخاب کند. در نتیجه مسئله مهم‌تر از توانایی تولید کد است: چه کاری اصلاً اجازه دارد بدون دستور تازه انسان وارد این مسیر شود، عامل به چه اطلاعاتی دسترسی دارد و کدام تصمیم‌ها باید همچنان دست انسان بماند؟

نقطه شروع، کیفیت تعریف کار است

طبق اعلام Atlassian، Agent loops کارهای بدون مسئولی را که به‌اندازه کافی روشن تعریف شده‌اند پیدا می‌کند، آن‌ها را به Jira Coding Agent می‌سپارد، اجرای تغییر و آزمایش را پیش می‌برد و در نهایت درخواست ادغام کد آماده بررسی می‌سازد. تصمیم نهایی برای ادغام همچنان با توسعه‌دهنده یا مدیر محصول است.

همین عبارت «به‌اندازه کافی روشن» یک مرز کنترلی مهم می‌سازد. پیش از آنکه عامل حتی کدنویسی را شروع کند، باید مشخص باشد چه نوع کاری اجازه ورود به این فرایند را دارد. اگر وضعیت‌ها و برچسب‌های فهرست کار فقط برای نظم اداری استفاده شوند و نه به‌عنوان قواعد اجرایی دقیق، ممکن است یک درخواست مبهم ناخواسته به کار خودکار تبدیل شود.

معرفی قبلی Jira Automation امکان واگذاری رویدادمحور کار به چند عامل کدنویسی را فراهم کرده بود. قابلیت جدید یک انتخاب‌گر دائمی به این مسیر اضافه می‌کند؛ سامانه برای هر کار منتظر فرمان تازه نمی‌ماند. بنابراین کیفیت تعریف کار، شرط‌های ورود و نحوه برخورد با استثناها بخشی از ایمنی سامانه می‌شوند.

اطلاعات لازم و مجوز دسترسی دو موضوع جدا هستند

Atlassian هم‌زمان می‌کوشد میان «اطلاعاتی که برای انجام کار مفید است» و «اطلاعاتی که عامل حق دیدن آن را دارد» تفکیک ایجاد کند. Code Context بر پایه Teamwork Graph اطلاعات چند مخزن را در اختیار Rovo و عامل‌های کدنویسی قرار می‌دهد. Agent Context Controls نیز برای مدیران فنی طراحی شده تا تعیین کنند هر عامل در کدام فضای کاری فعال باشد و چه چیزهایی را ببیند.

این جداسازی ضروری است. اطلاعات بیشتر می‌تواند برنامه‌ریزی را بهتر کند و جست‌وجوی بیهوده در کد را کاهش دهد، اما هم‌زمان سطح بیشتری از کد، مستندات و دانش سازمانی را در معرض عامل می‌گذارد. یک معماری قابل‌کنترل باید دو پرسش مستقل داشته باشد: چه اطلاعاتی برای این وظیفه لازم است و عامل مورد نظر مجاز به دیدن کدام بخش از آن است؟

Atlassian به تحلیلی داخلی از DX اشاره می‌کند که در آن تیم‌هایی با استفاده بیشتر از Teamwork Graph حدود ۶۴ درصد خروجی بیشتر به‌ازای هر توسعه‌دهنده داشته‌اند. این عدد یک هم‌بستگی گزارش‌شده از سوی خود فروشنده است و ثابت نمی‌کند افزایش اطلاعات زمینه‌ای علت مستقیم تفاوت بهره‌وری بوده است.

چند کنترل خودکار پیش از تصمیم نهایی انسان

قابلیت Standards به تیم‌های زیرساخت اجازه می‌دهد قواعد کدنویسی سازمان را به مخزن‌ها نسبت دهند. AI Review نیز تغییر پیشنهادی را پیش از رسیدن به بازبین انسانی با همان قواعد بررسی می‌کند. داشبورد مصرف عامل‌ها قرار است نشان دهد چه عامل‌هایی در جریان‌های کاری فعال‌اند و DX for Agentic Development نیز شاخص‌هایی درباره استفاده، هزینه، سرعت تحویل و کیفیت گردآوری می‌کند.

ارزش معماری در کنار هم قرار گرفتن این مراحل است. Jira تعیین می‌کند چه کاری وارد صف اجرا شود؛ کنترل دسترسی محدوده اطلاعات عامل را مشخص می‌کند؛ استانداردهای مخزن معیارهای فنی را تعیین می‌کنند؛ یک بررسی خودکار تغییر را می‌سنجد؛ و در پایان انسان مجوز ادغام را می‌دهد.

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

همه اجزای این معماری هنوز عمومی نشده‌اند

وضعیت انتشار محدودیت مهم خبر است. Atlassian می‌گوید Code Context به‌تدریج و در قالب نسخه آزمایشی عمومی برای مشتریان پولی عرضه می‌شود. Agent loops، Standards و AI Review هنوز در دسترسی آزمایشی خصوصی هستند. Agent Context Controls و داشبورد مصرف عامل‌ها قرار است در ماه‌های آینده برای مشتریان پولی Jira عمومی شوند و DX for Agentic Development نیز طبق برنامه در همین فصل به عرضه عمومی برسد.

گزارش مستقل IT Pro همین زمان‌بندی مرحله‌ای را تأیید می‌کند. پس این خبر را باید بیشتر به‌عنوان معماری کنترلی در حال شکل‌گیری دید، نه مدرکی که نشان دهد تیم‌های بزرگ همین امروز می‌توانند کل چرخه را در مقیاس تولید بدون مشکل اجرا کنند.

برای ارزیابی چنین سامانه‌ای، پرسش تعیین‌کننده این نیست که Jira می‌تواند خودکار درخواست ادغام بسازد یا نه. سه مرز باید دقیق و قابل مشاهده باشند: چه کاری اجازه ورود دارد، عامل از چه منابعی می‌تواند استفاده کند و کدام اثر نهایی بدون تأیید انسان مجاز نیست.

اگر این سه مرز روشن باشند، عامل‌های پیوسته می‌توانند بخشی از هماهنگی تکراری را حذف کنند بی‌آنکه فهرست کار به صف اجرایی با اختیار نامعلوم تبدیل شود. اگر این مرزها مبهم بمانند، «همیشه فعال» بودن فقط یک الگوی کنترلی ضعیف را با دفعات بیشتر اجرا می‌کند.

منابع
- https://www.atlassian.com/blog/jira/governed-agent-loops
- https://www.atlassian.com/blog/development/scale-agent-impact-with-jira-automation
- https://www.itpro.com/software/development/atlassian-introduces-always-on-capabilities-for-agentic-development-workflows