تصور کنید یک ابزار هوشمند، یک قطعه کد را در یک لحظه تایید می‌کند و دقیقاً همان کد را در لحظه‌ای دیگر رد می‌کند. این تناقض، بزرگ‌ترین کابوس مهندسان DevOps است که می‌خواهند اتوماسیون را به لایه‌های حساس استقرار کد برسانند.
به گزارش یک مهندس DevOps که طی دو ماه Claude Code را آزمایش کرده، عامل‌های هوش مصنوعی در برخورد با یک درخواست تغییر (Pull Request) یکسان، می‌توانند نتایج متضادی بدهند. در یک مورد خاص، عامل کد را تایید کرد، اما در اجرای دوم و کاملاً مشابه، همان کد را به دلیل یک مشکل مسدودکننده (Blocking Issue) رد کرد. این یعنی مدل‌ها به‌جای اینکه مثل یک ابزار بررسی خطای سنتی (Linter) عمل کنند، شبیه به یک سیستم نمونه‌بردار (Sampler) رفتار می‌کنند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبودِ پیش‌بینی‌پذیری در خروجی، استفاده از این ابزارها را به‌عنوان «شرط لازم» (Required Status Check) برای ادغام کد خطرناک می‌کند. این عدم ثبات در عملکرد، یادآور پدیده‌ی رانش خاموش در مدل‌های AI است که می‌تواند به‌مرور زمان نرخ تشخیص باگ‌ها را کاهش دهد و دقت سیستم‌های بازبینی را زیر سؤال ببرد.
هوش مصنوعی زاینده (Generative AI) — مثل هنرمندی که هر بار یک نقاشی متفاوت از یک موضوع می‌کشد — در محیط‌های عملیاتی که نیاز به پاسخ «بله یا خیر» قطعی دارند، لنگ می‌زند. برای کاهش این نوسان، توصیه می‌شود تنظیمات دما (Temperature) — که در واقع درجه‌ی خلاقیت و ریسک‌پذیری مدل است — روی کم‌ترین مقدار قرار گیرد و پرامپت‌ها به‌صورت نسخه‌بندی‌شده (Version-controlled) مدیریت شوند تا ورودی‌ها پایدار بمانند. ارزش واقعی این ابزارها در «سیگنال مجموع» (Aggregate Signal) نهفته است، نه در یک حکم تک‌مرحله‌ای و باینری.
بسیاری از موفقیت‌های ادعایی در دنیای AI، در واقع داستان‌هایی درباره‌ی اعمال محدودیت‌های شدید هستند. در حال حاضر، فشار برای خودکارسازی «آخرین مایل» (Last Mile) استقرار، تیم‌ها را وسوسه می‌کند تا استقلال زیادی به عامل‌ها بدهند. اما این آزمایش استدلال می‌کند که تنها راه ایمن برای استقرار DevOps عامل‌محور این است که با یک عامل AI مثل یک برنامه‌نویس جونیورِ باهوش اما گاهی بیش‌ازحد مطمئن برخورد کنید.
برای تبدیل این گردش‌کار به یک سیستم قابل اعتماد و ایمن برای اجرا و ضبط، مجموعه‌ای از حفاظ‌های (Guardrails) سخت‌گیرانه و حیاتی تعریف شده است:
- دسترسی فقط برای ویرایش: عامل هیچ دسترسی به شل (Shell)، شبکه یا مجوزهای نصب نرم‌افزار ندارد؛ او فقط می‌تواند فایل‌ها را بخواند، ویرایش کند و PRها را باز کند.
- شاخه‌های موقت (Throwaway branches): هوش مصنوعی هرگز مستقیماً روی شاخه اصلی (Main) کد نمی‌زند و تغییرات در شاخه‌های موقت اعمال می‌شود.
- ممنوعیت ادغام: حق کلیک روی دکمه Merge فقط و فقط برای انسان است. استقلال مدل به‌طور عمدی دقیقاً در نقطه دکمه ادغام متوقف می‌شود تا یک انسان هر تغییر را بازبینی کند.
- محدودیت تک‌تلاش: سیستم اجازه نمی‌دهد مدل وارد حلقه‌های تکرار (Retry Loops) برای سوزاندن توکن‌ها شود تا به طور شانسی به وضعیت Pass برسد.
- تست‌ها به‌عنوان مرجع (Spec): مدل اکیداً منع شده است که برای رسیدن به وضعیت سبز (Green)، تست‌های شکست‌خورده را ساکت کند یا استانداردهای آن‌ها را تضعیف نماید.
با وجود مشکل قطعیت، این عامل در «کارهای کسالت‌بار» (Boring Middle) DevOps درخشید. طبق مستندات این آزمایش، مدل توانست خطاهای خط لوله (Pipeline) در GitHub Actions را با خواندن لاگ‌ها تحلیل و علت ریشه‌ای (Root Cause) را شناسایی کند. در یک مورد واقعی، مدل سه شکست را مدیریت کرد: یک تداخل در وابستگی‌ها (Dependency Conflict)، یک خطای واقعی Off-by-one در یک تست، و یک گردش‌کار (Workflow) که روی نسخه اشتباه پایتون تنظیم شده بود. مدل برای هر کدام کوچک‌ترین اصلاح ممکن را پیشنهاد داد و ثابت کرد در تریژ (Triage) یا اولویت‌بندی خطاهای کسالت‌بار، سریع‌تر از انسان است، هرچند گاهی اوقات به‌جای علت ریشه‌ای، علائم (Symptoms) را درمان می‌کرد.
برای مقیاس‌پذیری بدون هزینه، از رانرهای موقت (Ephemeral) روی Kubernetes از طریق Actions Runner Controller استفاده شد. این ساختار باعث شد برای هر PR یک پاد (Pod) تازه ساخته شود، بررسی را انجام دهد و سپس خودبه‌خود نابود گردد. این معماری باعث شد هزینه API مدیریت‌شده به صفر برسد.
سایر مکانیزم‌های بهینه‌سازی شامل موارد زیر بود:
- بررسی آنی (Instant Review): یک گردش‌کار در GitHub Actions که تنها چند ثانیه پس از باز شدن PR، بازبینی را ثبت می‌کند.
- حافظه بازبین (Reviewer Memory): یک فایل تحت کنترل git که شامل قراردادهای کدنویسی تیم است. مدل این فایل را می‌خواند و یاد می‌گیرد تا از تکرار ایرادگیری روی الگوهایی که تیم قبلاً پذیرفته است، جلوگیری کند.
در نهایت، ارزش هوش مصنوعی در DevOps در «سیگنال کلی» است، نه یک حکم قطعی. استک تکنولوژی شما باید لایه‌ای مشاور باشد که روی کد کامنت می‌گذارد، نه دروازبانی که جلوی آن را می‌گیرد. هدف این است که به عامل‌ها «دست» (خواندن/ویرایش/PR) بدهیم تا کار کنند، اما هرگز «کلید» (ادغام/استقرار) محیط عملیاتی را در اختیارشان نگذاریم.
اگر در حال حاضر در حال متصل کردن AI به خط لوله CI/CD خود هستید، باید بررسی‌های وضعیت (Status Checks) خود را بازرسی کنید تا مطمئن شوید هیچ حکم تولیدشده توسط AI، یک شرط مسدودکننده برای استقرار نباشد. به خاطر داشته باشید که «YAML معتبر است» و «تست‌ها پاس شدند»، با «کد صحیح است» یکی نیستند.
گام بعدی شما
- اگر از AI در CI/CD استفاده می‌کنید، بررسی کنید که هیچ حکم تولیدشده توسط مدل، شرطِ مسدودکننده (Blocking) برای استقرار نباشد.
- برای کاهش نوسان خروجی، Temperature مدل را روی ۰ تنظیم کنید.
- یک فایل «قراردادهای تیم» بسازید و آن را به عنوان زمینه (Context) به مدل بدهید تا از تکرار ایرادات تکراری جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو