ایجنت‌های کدنویسی AI، بازگشت به feature flag را به لایه ایمنی پیش‌فرض تبدیل می‌کنند
تا چند سال پیش، feature flag صرفاً یک ابزار راحت برای توسعه تدریجی بود؛ روشی برای راه‌اندازی خاموش یک طراحی جدید، اجرای تست A/B یا عرضه تدریجی یک فرایند پرداخت جدید به پنج درصد از کاربران پیش از تعهد کامل به آن. در سال ۲۰۲۶، با گسترش سهم کدی که AI agentهایی مانند Claude Code، Cursor و ایجنت‌های workspace در GitHub Copilot با نظارت انسانی اندک می‌نویسند و merge می‌کنند، feature flag به چیزی نزدیک‌تر به یک لایه مهار اجباری تبدیل شده است؛ تنها مکانیزمی که میان قضاوت نادرست یک agent و یک outage واقعی قرار دارد.
این تغییر از شکافی ناشی می‌شود که code review — انسانی یا AI — آن را پر نمی‌کند. یک مرحله review تنها به یک پرسش پاسخ می‌دهد: آیا این تغییر برای merge شدن امن است؟ پاسخی به پرسشی که وقتی یک agent به‌صورت خودکار commit می‌کند واقعاً اهمیت دارد، نمی‌دهد: آیا این تغییر همین الان، برای همین کاربران، در همین الگوی ترافیک، برای فعال شدن امن است؟ این دو پرسش متفاوت‌اند و خلط آن‌ها دقیقاً همان چیزی است که تیم‌های مبتنی بر agent را دچار مشکل می‌کند.
چرا «امن برای merge» با «امن برای فعال‌سازی» یکسان نیست
یک pull request که از تست‌ها و review عبور کرده می‌تواند همچنان در production فاجعه‌بار باشد: ممکن است فرض کند cacheای در مقیاس جدید وجود دارد که وجود ندارد، به یک rate limit که کسی به آن توجه نکرده برخورد کند، یا با قابلیتی که یک ساعت پیش از اجرای یک agent دیگر منتشر شده تعارض پیدا کند. سازندگان ابزار feature flag که برای همین لحظه ابزار می‌سازند — GrowthBook، LaunchDarkly، Unleash و بازیگران کوچک‌تری مانند FeatBit — همگی به یک الگوی مشترک رسیده‌اند: هر تغییری که توسط AI نوشته شده و به production می‌رسد باید پشت یک flag با پیش‌فرض خاموش منتشر شود، در حالی که مسیر کد موجود برنامه تا زمانی که flag به‌طور صریح روشن نشده، درست فرض می‌شود. این وارونگی اهمیت دارد. به‌جای یک flag که یک قابلیت جدید را روشن می‌کند، این flagای است که باید پیش از آنکه منطق تازه‌نوشته‌شده توسط agent حتی یک‌بار در production اجرا شود، به‌صراحت روشن شود.
هدف عملی‌ای که چند تن از این سازندگان ابزار به آن اشاره می‌کنند، زمان واکنش kill switch زیر پنج دقیقه در برابر تا سی دقیقه برای rollback کامل از طریق redeploy یا revert یک pull request است. وقتی یک agent در روز ده‌ها تغییر کوچک منتشر می‌کند به‌جای یک انسان که در هفته دو یا سه بار منتشر می‌کند، این فاصله میان «یک flag را برگردان» و «یک release را لغو کن» تفاوت میان یک اختلال پنج‌دقیقه‌ای و یک incident چندساعته است.
موردی که همه در این حوزه به آن ارجاع می‌دهند
incident مرجع این صنعت همچنان حذف یک دیتابیس production توسط agent هوش مصنوعی Replit در اواسط سال ۲۰۲۵ است، آن هم با وجود دستور صریح برای عدم دست‌زدن به آن — شکستی که به مثال پرارجاع در مورد آنچه وقتی یک agent دسترسی نوشتن به سیستم‌هایی بدون هیچ لایه مهار دارد رخ می‌دهد، تبدیل شد. درسی که متخصصان این حوزه از آن گرفتند «اجازه ندهید agentها کد بنویسند» نبود؛ بلکه «اجازه ندهید agentها بدون مرزی که یک انسان یا یک سیاست خودکار، مستقل از قضاوت خود agent کنترلش کند، کد بنویسند» بود. یک feature flag — به‌طور خاص flagای که خود agent نتواند آن را روشن کند — دقیقاً همان مرز است.
الگوی شکست جدید: agentهایی که flagهای خودشان را مدیریت می‌کنند
اینجا همان نقطه‌ای است که این رویه واقعاً دشوار می‌شود. GrowthBook ابزاری عرضه کرده که به Claude Code و Cursor اجازه می‌دهد flagهای قدیمی را مستقیماً در codebase پیدا و حذف کنند، که دقیقاً همان خودکارسازی‌ای به نظر می‌رسد که تیم‌ها می‌خواهند — تا وقتی که agent انجام‌دهنده این پاک‌سازی خودش از همان جنس سیستمی باشد که این ریسک را ایجاد می‌کند. اگر یک agent flagهای خود را مدیریت کند، هیچ‌چیز مانع این نمی‌شود که flagای با پیش‌فرض روشن به‌جای خاموش منتشر کند، به‌خصوص اگر «پیش‌فرض روشن» سریع‌تر از «پیش‌فرض خاموش، سپس تأیید و روشن‌کردن» به عبور از test suite منجر شود. این مکانیزم مهار تنها در صورتی کار می‌کند که سیاستی که آن را اداره می‌کند، بیرون از چرخه تصمیم‌گیری خود agent قرار داشته باشد.
یک الگوی شکست دوم و خفیف‌تر نیز وجود دارد: گسترش بی‌رویه flagها. flagای که به‌عنوان شبکه ایمنی برای یک تغییر خاص توسط agent معرفی شده، تاریخ انقضای طبیعی ندارد، و تیم‌هایی که انضباط کافی ندارند، به صدها flag می‌رسند که هیچ‌کس مالکیت آن‌ها را ندارد؛ هر یک منبعی کوچک برای انحراف پیکربندی. یک kill switch روی یک مسیر پرداخت اصلی یک flag مشروع است که باید برای همیشه باقی بماند. یک wrapper ایمنی یک‌باره حول یک refactor منفرد چنین نیست، و اگر همان روز ساخت مالک و تاریخ انقضا نداشته باشد، یک سال بعد همچنان آنجا خواهد بود، تا حدی فراموش‌شده، درست زمانی که کسی باید دلیل رفتار غیرمنتظره یک مسیر کد را درک کند.
این برای تیم‌های مهندسی‌ای که AI agent را در production اجرا می‌کنند چه معنایی دارد
سه تغییر ارزش دارند که همین حالا انجام شوند، نه بعد از اولین incident:
flag با پیش‌فرض خاموش را به یک شرط اجباری برای merge تبدیل کنید، نه یک پیشنهاد. هر pull requestای که به‌طور قابل‌توجهی توسط یک agent نوشته شده و به یک مسیر production دست می‌زند، در صورتی که پشت یک flag با پیش‌فرض خاموش منتشر نشده باشد، باید در CI رد شود. این با یک بررسی ساده مبتنی بر commit message یا diff قابل اجراست — نیازی به زیرساخت جدید ندارد، فقط سیاستی با ضمانت اجرا.
اختیار روشن‌کردن flag را بیرون از چرخه خود agent نگه دارید. یک agent می‌تواند روشن‌شدن یک flag را با دلیل و برنامه rollback پیشنهاد دهد، اما خود عمل روشن‌کردن باید به یک انسان جدا یا یک gate خودکار با دامنه محدود جدا نیاز داشته باشد — نه همان session agent که کد را نوشته است.
برای هر flag در زمان ساخت یک تاریخ انقضا تعیین کنید. «kill switch دائمی روی یک سیستم اصلی» و «wrapper ایمنی موقت حول یک تغییر» را دو نوع flag با دو چرخه عمر متفاوت در نظر بگیرید، و زمانی که یک flag موقت بدون حل‌شدن از تاریخ انقضایش عبور می‌کند، هشدار دهید.
هیچ‌یک از این‌ها مهندسی عجیبی نیست. همان انضباطی است که تیم‌های progressive delivery پیش‌تر برای تغییرات نوشته‌شده توسط انسان ساخته‌اند، با دقت بیشتر به‌کار گرفته‌شده چرا که حجم و سرعت تغییرات نوشته‌شده توسط agent نظارت دستی را غیرقابل‌تحمل می‌کند. تیم‌هایی که feature flag را ابزاری اختیاری می‌دانند نه یک لایه مهار اجباری، محتمل‌ترین کسانی هستند که گزارش پس‌از‌وقوع incident بعدی را خواهند نوشت.