از وایبکدینگ تا کدنویسی ایجنتی: جریان امن ساخت محصول
English
پاسخ کوتاه: وایبکدینگ برای تبدیل سریع یک ایده به نمونه قابلدیدن مفید است؛ اما وقتی ایجنت میتواند فایل بخواند، کد تغییر دهد، command اجرا کند، وابستگی نصب کند یا حتی با سرویس بیرونی تعامل داشته باشد، دیگر فقط با «تولید کد» روبهرو نیستیم. اینجا باید مانند یک سیستم مهندسی عمل کرد: قرارداد کار را بنویسید، دسترسی را محدود کنید، تغییر را در محیط ایزوله بسازید، diff را بازبینی کنید، تست رفتاری بگیرید و وضعیت انتشار را با مدرک بخوانید.
در سال ۲۰۲۶، قابلیتهایی مثل کار طولانیمدت، ابزارهای بیشتر و اجرای چندایجنتی از یک نمایش جذاب به بخشی از ابزارهای واقعی توسعه تبدیل شدهاند. در معرفی رسمی GPT‑5.6، حالتهای پرتوانتر و multi-agent برای هماهنگکردن چند مسیر کاری مطرح شدهاند. گزارش روند کدنویسی ایجنتی Anthropic نیز حرکت از اصلاحهای چنددقیقهای به کارهای چندساعته و طولانیتر را توصیف میکند. اینها شواهد جهت بازارند، نه تضمین کیفیت پروژه شما. هرچه افق کار ایجنت بلندتر شود، هزینه یک فرض اشتباه، permission اضافی یا تست ناقص هم بیشتر میشود.
وایبکدینگ، کدنویسی ایجنتی و مهندسی ایجنتی چه فرقی دارند؟
در وایبکدینگ، سازنده بیشتر نتیجه ظاهری و حس جریان را هدایت میکند: «این فرم را بساز»، «این صفحه را جذابتر کن» یا «این خطا را رفع کن». در کدنویسی ایجنتی، مدل علاوه بر پیشنهاد، ابزار بهکار میگیرد و بین چند مرحله حرکت میکند. مهندسی ایجنتی یک لایه مدیریتی بالاتر است: چه چیزی مجاز است، چه مدرکی برای قبولی لازم است، شکست چگونه متوقف میشود و چه کسی تصمیم انتشار میگیرد.
نکته اصلی این است که خروجی با مدرک یکی نیست. وجود فایل جدید ثابت نمیکند feature درست کار میکند. سبزشدن یک unit test ثابت نمیکند رابط در مرورگر قابلاستفاده است. پاسخ موفق API ثابت نمیکند تغییر deploy شده است. و عبارت «انجام شد» از طرف ایجنت، read-back سیستم مقصد نیست. جریان حرفهای باید بین ساختهشده، تستشده، mergeشده، deployشده و تأییدشده در محیط واقعی فرق بگذارد.
جریان هفتگیتی برای ساخت امن با ایجنت
۱. قرارداد محصول را پیش از prompt بنویسید
درخواست را با نتیجه کاربر آغاز کنید، نه با نام فناوری. بنویسید کاربر چه کاری انجام میدهد، چه چیزی نباید تغییر کند، معیار قبولی چیست و کدام اثر جانبی مجاز است. برای مثال «فرم رزرو بساز» مبهم است؛ اما «کاربر بازه زمانی را انتخاب کند، ورودی نامعتبر پیام روشن بگیرد، هیچ پرداختی انجام نشود و تست موبایل و دسکتاپ پاس شود» یک قرارداد قابلبررسی است.
محدوده فایل و سیستم را هم تعیین کنید. اگر task فقط frontend است، دسترسی به دیتابیس production یا secret store لازم نیست. اگر هدف diagnosis است، اجازه deploy از ابتدا منطقی نیست. این تفکیک، هم احتمال حادثه را کاهش میدهد و هم کیفیت تصمیم ایجنت را بهتر میکند؛ چون فضای انتخاب بیدلیل بزرگ نمیشود.
۲. وضعیت فعلی را ثبت کنید
پیش از تغییر، branch، مسیر workspace، فایلهای dirty، نسخه runtime و نتیجه تست پایه را بخوانید. کار ناتمام دیگران را متعلق به خود فرض نکنید. یک diff قبل از شروع، جلوی پاکشدن تغییرات unrelated را میگیرد. برای پروژههای جدی، worktree یا branch جدا ایجاد کنید تا بازگشت و مقایسه ساده باشد.
ثبت وضعیت فقط برای Git نیست. اگر کار به CMS، داشبورد، Sheet یا API بیرونی وصل است، رکورد زنده را دوباره باز کنید. memory ایجنت یا توضیح قبلی شما میتواند کهنه باشد. شناسه، عنوان، محیط و status مقصد باید در لحظه اقدام دوباره بررسی شود.
۳. permission را پلهای افزایش دهید
ایجنت را ابتدا با کمترین دسترسی لازم اجرا کنید: خواندن فایلها و اجرای بررسیهای بیاثر. ویرایش، نصب dependency، شبکه، ارسال پیام، انتشار و عملیات مالی باید مرزهای جدا باشند. مستندات رسمی Gemini CLI برای workspaceهای untrusted، تنظیمات محلی، فایلهای محیطی، extensionها و auto-accept را محدود میکند؛ مستندات sandbox همان ابزار هم تأکید میکند که ایزولهسازی ریسک را کم میکند، نه اینکه آن را صفر کند.
دکمه «همهچیز را خودکار قبول کن» سرعت ظاهری میسازد، اما blast radius را بالا میبرد. read-only را برای شناخت، write محدود را برای پیادهسازی و دسترسی بیرونی را فقط برای مرحلهای فعال کنید که قرارداد آن را لازم دارد. secretها نباید در prompt، log یا فایل repo کپی شوند. اگر کار به credential نیاز دارد، آن را از محیط یا secret manager در زمان اجرا بخوانید و خروجی redacted نگه دارید.
۴. task را به واحدهای قابلاثبات بشکنید
یک task خوب آنقدر کوچک است که بتوان تغییر و معیار قبولی آن را در یک بازبینی فهمید، اما آنقدر خرد نیست که پیوند میان رفتارها گم شود. «سیستم احراز هویت را کامل کن» بزرگ است. «اعتبارسنجی redirect بعد از login را با سه سناریوی مثبت، منفی و URL خارجی اصلاح کن» قابلمدیریتتر است.
برای هر واحد، ورودی، خروجی، فایلهای مالک، تست و stop condition بنویسید. اگر schema با انتظار فرق داشت، دسترسی قطع بود یا نتیجه پایه از ابتدا قرمز بود، ایجنت باید توقف ایمن داشته باشد؛ نه اینکه برای رسیدن به cadence، گیت را ضعیف کند.
۵. از ایجنت بخواهید شواهد تولید کند، نه روایت
مدرک مناسب با ریسک تغییر فرق دارد. برای تابع خالص، unit test کافی است. برای flow مرورگر، رفتار واقعی، network و console اهمیت دارد. برای deploy، exact commit، نتیجه workflow و پاسخ route مقصد را بخوانید. برای محتوای عمومی، URL، canonical، زبان، تصویر و متن رندرشده را بررسی کنید.
یک پژوهش ۲۰۲۶ روی بیش از ۳۸۰۰ bug گزارششده در Claude Code، Codex و Gemini CLI نشان داد بخش بزرگی از مشکلها عملکردی بودهاند و خطاهای API، integration و configuration سهم مهمی از علتها داشتهاند؛ tool invocation و command execution نیز نقاط پرتکرار اثر بودند. این پژوهش درباره bugهای خود ابزارهاست، نه نرخ خطای هر کدی که تولید میکنند، اما یک درس عملی دارد: مسیر اجرای ابزار باید مثل خود کد مشاهدهپذیر و قابلتست باشد.
۶. diff و فرضها را جداگانه بازبینی کنید
بازبینی فقط پیدا کردن syntax error نیست. ابتدا بپرسید: آیا ایجنت مسئله درست را حل کرده؟ آیا فایل اضافهای را لمس کرده؟ آیا validation فقط در client انجام شده؟ آیا error handling حالتهای واقعی را پوشش میدهد؟ آیا dependency تازه لازم بوده؟ آیا داده حساس وارد log شده؟ سپس diff نامدار را بخوانید و تستها را مستقل اجرا کنید.
برای سازندهای که syntax همه زبانها را نمیداند، بازبینی مفهومی همچنان قدرتمند است. از ایجنت بخواهید تغییر را به زبان ساده توضیح دهد، قرارداد قبل و بعد را نشان دهد، failure modeها را فهرست کند و commandهای verification را جدا ارائه دهد. بعد یک reviewer مستقل—انسان یا ایجنت دیگر با context و نقش محدود—ادعاها را در برابر کد و تست بررسی کند.
۷. انتشار را یک مرحله مستقل بدانید
ساخت موفق مجوز انتشار نیست مگر قرارداد از ابتدا آن را شامل شده باشد. قبل از release، secretها، migration، rollback، health check، domain و environment را دوباره بررسی کنید. اگر workflow یک خطای مبهم داد، پیش از retry وضعیت واقعی run را بخوانید؛ تکرار کور ممکن است دو deploy یا دو رکورد بسازد.
پس از انتشار، URL عمومی و رفتار اصلی را از بیرون بررسی کنید. برای سایت، HTTP 200 بهتنهایی کافی نیست؛ canonical، indexability، assetها، زبان و لینکها مهماند. برای محصول، identity، authorization، write واقعی و recovery را با داده امن و scope محدود بسنجید. گزارش نهایی باید دقیقاً بگوید چه چیزی local، CI، deployed یا هنوز تأییدنشده است.
چه زمانی چند ایجنت بهتر از یک ایجنت است؟
چندایجنتی زمانی ارزش دارد که مسیرها واقعاً مستقل باشند: یک agent نقشه codebase را بخواند، دیگری منابع رسمی را بررسی کند و سومی یک ماژول جدا را پیادهسازی کند. اگر همه روی همان فایل یا تصمیم معماری کار کنند، هزینه هماهنگی و conflict میتواند از سود موازیسازی بیشتر شود.
- استفاده کنید: پژوهشهای مستقل، اجرای تستهای جدا، بررسی امنیتی read-only و ماژولهای با مالکیت روشن.
- استفاده نکنید: task کوچک، فایل مشترک، تصمیم مبهم یا زمانی که نتیجه یک مسیر ورودی مسیر بعدی است.
- قانون هماهنگی: هر ایجنت باید مالکیت، خروجی، محدودیت و منع بازگرداندن تغییر دیگران را بداند.
عبارت «ultra» یا «multi-agent» بهخودیخود نتیجه بهتر نمیسازد. معیار درست، زمان تا خروجی پذیرفتهشده است: هزینه مدل، زمان بازبینی، تعداد conflict، retry و نرخ قبولی را با حالت تکایجنت مقایسه کنید.
چکلیست کوتاه پیش از سپردن کار واقعی
- نتیجه کاربر، موارد خارج از scope و اثر جانبی مجاز نوشته شده است.
- وضعیت Git، branch، فایلهای dirty و تست پایه ثبت شده است.
- ایجنت فقط به فایل، شبکه و ابزار لازم دسترسی دارد.
- secretها خارج از prompt و repo نگه داشته میشوند.
- هر task معیار قبولی و stop condition دارد.
- diff، test و رفتار رندرشده جداگانه بررسی میشوند.
- release، rollback و read-back مقصد مدرک مستقل دارند.
نکته دسترسی برای کاربران ایران
قابلیت فنی یک ابزار با دسترسی رسمی به آن یکی نیست. در تاریخ بازبینی این مقاله، ایران در فهرست رسمی کشورهای پشتیبانیشده ChatGPT نبود و OpenAI هشدار میدهد دسترسی از مناطق خارج از فهرست میتواند به محدودیت حساب منجر شود. این مقاله راه دورزدن محدودیت منطقهای پیشنهاد نمیکند. پیش از وابستهکردن پروژه یا مشتری به هر provider، فهرست کشورها، شرایط حساب، مسیر پرداخت، محل داده و سیاست سازمان را از منبع رسمی همان روز بررسی کنید.
جمعبندی
وایبکدینگ میتواند نقطه شروع خلاقانه خوبی باشد؛ مهندسی ایجنتی کاری میکند که سرعت اولیه به بدهی پنهان تبدیل نشود. قرارداد را پیش از prompt بنویسید، permission را پلهای بدهید، Git را مرز بازیابی بدانید، تست را با رفتار واقعی تطبیق دهید و انتشار را فقط با read-back مقصد کامل اعلام کنید.
برای طراحی معیارهای دقیقتر، چارچوب ارزیابی ایجنت هوش مصنوعی را بخوانید. اگر محصول فارسی است، راهنمای ساخت مجموعه آزمون فارسی کمک میکند زبان، عدد، تاریخ، شواهد و ایمنی را به test case تبدیل کنید. زمینه پروژهها و نوشتههای نویسنده نیز در صفحه فارسی سپهر بیات در دسترس است.