تصور کنید یک مهندس DevOps در یک بعدازظهر سه شنبه، تنها با چند جمله ساده به زبان انگلیسی، کل شبکه مجازی (VPC) شرکت را به اشتباه پاک کند. این کابوس، رویمدال تاریک Vibe Coding یا «کدنویسی بر اساس حس» است؛ روشی که در آن توسعهدهنده صرفاً هدف خود را توصیف میکند — مثلاً یک پروکسی معکوس NGINX با محدودیت نرخ (rate-limited) را توصیف میکند — و مدل در عرض دو ثانیه، ۴۰ خط تنظیمات بینقص تحویل میدهد.
به نقل از راهنمای منتشر شده در dev.to در ۲۲ ژوئن ۲۰۲۶، مشکل اصلی اینجاست که مدلها در بازنویسی نحو (Syntax) و جایگزینی کد با «قصد کاربر» (Intent) عالی هستند، اما هیچ درکی از وابستگیهای مشترک ندارند؛ مثلاً مدل نمیداند یک سرویس ممکن است یک «آپاستریم» (upstream) مشترک با API پرداختها داشته باشد یا اینکه یک دستور «بارگذاری مجدد» (reload) که در ظاهر بیضرر است، ممکن است در ساعات اوج ترافیک باعث قطع اتصالات در حال جریان (in-flight connections) شود. همانطور که در تحلیلهای قبلی ما دربارهی مخاطرات استقرار خودکار مدلها اشاره کردیم، سرعت تولید کد نباید از سرعت تأیید آن پیشی بگیرد.
زیرساخت به عنوان کد (IaC) — که مانند یک دفترچه دستورالعمل دقیق برای ساخت ساختمان است تا هیچ آجری جابهجا نشود — پیش از این برای جلوگیری از قطعیها بر قواعد سختگیرانه، نحو صلب و مستندات جامع استوار بود. اما Vibe Coding این اصطکاکها را حذف میکند و شکاف خطرناکی بین سرعت تولید و سرعت تأیید ایجاد میکند. برای کسانی که با OpenStack، Kubernetes و Terraform سروکار دارند، خطر اصلی خودِ کد نیست، بلکه نبودِ «انسان در حلقه» (Human-in-the-loop) در مرحلهی اجرا (Apply) است. مدل کد را مینویسد، اما پیامدهای آن را تحمل نمیکند؛ این مهندس است که مسئولیت عواقب را بر دوش میکشد.
زمینه و مفهوم Vibe Coding
ویبکدینگ به عنوان ساخت سیستمها از طریق توصیف قصد و بهرهبرداری از خروجی مدل تعریف میشود. در حوزه زیرساخت، این روش به دلیل حذف ساعتها کلنجار رفتن با نحو پیچیده HCL یا جستجوهای بیپایان در Stack Overflow برای یافتن تنظیمات درست، بهشدت اعتیادآور و سریع است. با این حال، این متد مانند یک ابزار برقی قدرتمند است و درست مثل هر ابزار برقی دیگر، ایمنی آن تنها به مهارت و دقت اپراتور بستگی دارد.
طبق گزارش این راهنما، برای ادغام ایمن هوش مصنوعی در محیطهای عملیاتی، باید ۵ حفاظ یا Guardrails (نردههای ایمنی) اجباری را رعایت کرد تا مهندس همچنان مسئول محدوده اثر (Blast Radius) باقی بماند و ماشین تنها وظیفه تایپ کردن را بر عهده بگیرد:
۱. ویب کردنِ پیشنویس، نه اجرا
هوش مصنوعی فقط باید پیشنهاد دهد، نه اجرا کند. تفاوت حیاتی و مرگباری بین دریافت یک دستور kubectl patch از مدل و داشتن باتی است که آن دستور را برای شما اجرا کند. گردش کار پیشنهادی برای جلوگیری از خطاهای «جایگزینی اجباری» (force-replace) که معمولاً در خطوط پایین پلان (مثلاً خط ۲۰۰) دفن شدهاند و ویبکدینگ آنها را نادیده میگیرد، شامل مراحل زیر است:
- اجرای دستور
terraform plan -out=tfplanو سپس انتقال خروجی با دستورterraform show -json tfplan | <paste into the model>به مدل. - استفاده از پرامپتی که مدل را مجبور کند پلان را بخواند و تغییرات را به زبان انگلیسی ساده توضیح دهد.
- دستور صریح به مدل برای شناسایی هرگونه حذف یا جایگزینی منابع و رتبهبندی ۳ مورد از ریسکیترین تغییرات.
- تأکید صریح بر این جمله: «به من نگو همه چیز درست است؛ بگو چه چیزی ممکن است خراب شود».
۲. سختسازی اسکریپتهای شل (Shell Scripts)
اسکریپتهای Bash تولید شده با ویبکدینگ بهشدت بیثبات هستند، زیرا Bash با خوشرویی دستور rm -rf "$DIR/" را اجرا میکند، حتی اگر متغیر $DIR خالی باشد. هر اسکریپت باید پیش از اجرا تحت یک «بررسی ریسک» قرار گیرد و از مدل خواسته شود موارد زیر را اسکن کند:
- دستورات تخریبی یا غیربرگشتپذیر: حذفها (deletes)، بازنویسیها (overwrites)، فورس-پوشها (force-pushes) و Dropها.
- افشای اعتبارنامههای محیط عملیاتی (Production Credentials).
- متغیرهای بدون کوتیشن که باعث شکست یا تکهتکه شدن کلمات (word-splitting) میشوند.
- دستورات
kubectl deleteکه فاقد تعیین محدوده یا Namespace هستند.
برای هر ریسک شناسایی شده، مدل باید «محدوده اثر» را تخمین بزند و یک نسخه ایمنتر ارائه دهد؛ مانند افزودن فلگ dry-run، درخواست تأیید از کاربر یا رویکرد «ابتدا بکآپ». همچنین افزودن حالت سختگیرانه set -euo pipefail به همراه trapها و مسیرهای بازگشت (back-out paths) پیش از هرگونه اجرا، غیرقابل مذاکره است.
۳. مرحلهبندی «ویب»
سرعت نباید به بهانه حذف لایههای ایمنی باشد. این چارچوب یک Rollout لایهای را میطلبد تا اشتباهات در محیط ترمینال (که رایگان هستند) شناسایی شوند، نه در محیط عملیاتی:
- تأیید بدون اثر (No-op): استفاده همیشگی از حالتهای شبیهساز مانند
--dry-run=serverدر کوبرنتیز،terraform planیاansible --check. - گسترش تدریجی (Incremental Widening): اعمال تغییرات ابتدا روی یک گره (Node) واحد، یک Namespace خاص یا یک محیط غیرعملیاتی (non-prod). مشاهده نتایج پیش از گسترش دامنه تغییرات.
- قانون ۶۰ ثانیه: اگر نمیتوانید در ۶۰ ثانیه به این سوال پاسخ دهید که «چگونه این تغییر را به حالت قبل برگردانم»، صرفنظر از میزان اعتماد مدل به پاسخ خود، شما آماده اجرای تغییر نیستید.
۴. تعیین محدوده اثر (Blast Radius)
همه بخشهای زیرساخت ارزش اعتماد یکسانی ندارند و مهندس باید سطح نظارت خود را با ریسک احتمالی تغییر تطبیق دهد:
- کارهای کمریسک (Low-Risk Toil): مواردی مثل ساخت یک داشبورد Grafana، یک جاب Linter در CI، یک اسکریپت مهاجرت تکباره یا bootstrapping محیط توسعه که میتوان با نظارت حداقلی ویبکد کرد، زیرا بدترین حالت آن تنها ۱۰ دقیقه زمان تلف شده است.
- جواهرهای تاج (Crown Jewels): تغییرات با ریسک بالا — شامل بهروزرسانی سیاستهای IAM، Failoverهای دیتابیس، لیستهای کنترل دسترسی شبکه (Network ACLs) یا هر چیزی که در مسیر جریان مالی مشتریان قرار دارد — باید مانند یک PR متخاصم (hostile PR) خط به خط خوانده و بررسی شوند.
مدل نمیتواند بین این دو دسته تفاوت قائل شود؛ این وظیفه اپراتور انسانی است.
۵. ساخت کتابخانه پرامپت
برای نتایج پایدار و تکرارپذیر، نباید به «شانس» یا حسات (Vibes) تکیه کرد. یک درخواست کلی مثل «تنظیمات nginx من را اصلاح کن» تنها جوابهای دور ریختنی میدهد. یک پرامپت حرفهای باید از مدل بخواهد: «در نقش یک SRE ارشد عمل کن»، تنظیمات و خطا را ارائه دهد و درخواست کند که علتها را رتبهبندی کرده و در نهایت دستور nginx -t را برای تأیید پیکربندی پیش از Reload پیشنهاد دهد.
نویسنده یک کتابخانه پرامپت قابل جستجو را توصیه میکند که بر اساس معیارهای زیر فیلتر شود:
- پشته تکنولوژی (Technology Stack).
- سطح دشواری.
- شامل دستورالعملهای ایمنی محیط عملیاتی.
این کار تضمین میکند که برای کارهایی مانند ایجاد ایندکس Postgres یا Rollout کوبرنتیز، اپراتور با پرامپتی شروع کند که نردههای ایمنی از پیش در آن تعبیه شده است.
این رویکرد، تمرکز عملیاتی را از «نوشتن کد» به «حسابرسی قصد و هدف» تغییر میدهد. با سپردن کارهای تکراری و خستهکننده به هوش مصنوعی و مدیریت محدوده اثر توسط انسان، سرعت توسعه بدون قربانی کردن پایداری حفظ میشود. در نهایت، مدل کد را مینویسد، اما مهندس پیامدهای آن را میپذیرد. با ویبکد کردن پیشنویس، خواندن پلان، مرحلهبندی اجرا و نگه داشتن نام یک انسان در تیکت تغییرات، ویبکدینگ از یک «اعتراف به بیدقتی» به یک «گردش کار حرفهای» تبدیل میشود.
گام بعدی شما
- هر اسکریپت Bash تولید شده توسط AI را با دستور
set -euo pipefailسختسازی کنید. - فهرستی از «جواهرهای تاج» زیرساخت خود تهیه کنید تا در هنگام ویبکدینگ، سطح نظارت را بالا ببرید.
- یک کتابخانه پرامپت مشترک برای تیم SRE ایجاد کنید تا استانداردهای ایمنی در تمام درخواستها تکرار شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو