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

ایجنت کدنویسی ابزاری است که با گرفتن یک هدف، خودش فایل‌های پروژه را می‌خواند، تغییر می‌دهد و دستورهایی مثل اجرای تست را اجرا می‌کند. فرق نتیجه‌ی خوب و بد معمولاً در مدل نیست، در روال کار است. اگر با مفهوم ایجنت آشنا نیستید، اول ایجنت هوش مصنوعی چیست را بخوانید.

ایجنت کدنویسی دقیقاً چه کار می‌کند؟#

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

سه شکل رایج دارد:

شکلکجا کار می‌کندمناسب برای
داخل ویرایشگر کدروی پروژه‌ی باز در ویرایشگرکارهای کوچک و متوسط با نظارت لحظه‌ای
در ترمینالروی پوشه‌ی پروژه، با دستورهای خط فرمانکارهای چندفایلی، اجرای تست و ابزارهای پروژه
پس‌زمینه یا ابریروی کپی مخزن در محیط جداکارهای مشخص که نتیجه‌شان یک درخواست ادغام است

قبل از اولین اجرا، پروژه را چطور آماده کنیم؟#

با گیت تمیز، شاخه‌ی جدا، تست قابل‌اجرا و محیطی که کلید واقعی در آن نیست:

  1. وضعیت گیت تمیز باشد. قبل از شروع هیچ تغییر ثبت‌نشده‌ای نمانده باشد.
  2. شاخه‌ی جدا بسازید. اگر کار خراب شد، کل شاخه را کنار می‌گذارید.
  3. تست‌ها اجرا شوند. ایجنت با تست می‌فهمد کارش درست است یا نه؛ پروژه‌ی بدون تست یعنی همه‌ی بار بازبینی روی شما.
  4. محیط محلی با داده‌ی آزمایشی. فایل .env با کلید واقعی و اتصال به دیتابیس اصلی در دسترس ایجنت نباشد.
  5. فایل دستورالعمل پروژه. بیشتر ابزارها یک فایل متنی در ریشه‌ی پروژه را می‌خوانند؛ بعضی فایلی مثل AGENTS.md و بعضی فایل مخصوص خودشان. دستور اجرای تست، قواعد نام‌گذاری و پوشه‌هایی را که نباید دست بخورند آن‌جا بنویسید.
Bash
git status
git switch -c agent/fix-discount-total
php artisan test

به ایجنت چه سطح دسترسی بدهیم؟#

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

کارپیشنهاد
خواندن فایل‌های پروژهآزاد
ویرایش فایل در پوشه‌ی پروژهآزاد یا با تأیید، بسته به اعتمادتان
اجرای تست و ابزار بررسی کدآزاد، با فهرست دستورهای مجاز
نصب بسته‌ی تازهبا تأیید
مایگریشن، حذف فایل، بازنویسی تاریخچه‌ی گیتهمیشه با تأیید
هر چیزی مربوط به سرور اصلی یا انتشارنه

اگر ایجنت را از راه MCP به ابزارهای دیگری مثل دیتابیس یا مخزن کد وصل می‌کنید، همین قاعده آن‌جا هم صدق می‌کند: فقط‌خواندنی، مگر وقتی واقعاً لازم است.

روال امن یک کار با ایجنت چیست؟#

چهار قدم: اول برنامه، بعد تغییر در قدم‌های کوچک، بعد بازبینی تغییرها، و در آخر ثبت کوچک در گیت.

نمودار روال امن کار با ایجنت کدنویسی از شاخه‌ی جدا تا ثبت کوچک در گیت

۱. اول برنامه، بعد تغییر#

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

اگر ایجنت علت را اشتباه فهمیده، این‌جا ارزان‌ترین جای اصلاح است، نه بعد از تغییر شش فایل.

۲. تغییر در قدم‌های کوچک#

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

۳. بازبینی تغییرها#

گزارش «تمام شد» را باور نکنید؛ خود تغییرها را ببینید:

Bash
git diff --stat
git diff -- tests/
git diff -- composer.json composer.lock

دستور دوم نشان می‌دهد تست‌ها عوض شده‌اند یا نه، و دستور سوم نشان می‌دهد بسته‌ی تازه‌ای اضافه شده یا نه.

۴. ثبت کوچک#

هر کار کامل را جدا ثبت کنید. ثبت‌های کوچک هم بازبینی را ساده می‌کنند و هم برگشت را.

ایجنت‌ها معمولاً کجا اشتباه می‌کنند؟#

جایی که هدف یا محدوده مبهم است، و جایی که «سبز شدن تست» جای «درست شدن کد» را می‌گیرد:

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

برای مورد آخر، بازبینی کد با هوش مصنوعی کمک می‌کند، ولی جای چشم شما را نمی‌گیرد.

نکته‌های وردپرس و لاراول#

  • وردپرس: در هر فرم و درخواست AJAX که ایجنت می‌سازد، nonce، بررسی دسترسی با current_user_can و escape خروجی را چک کنید. اجازه ندهید هسته‌ی وردپرس یا افزونه‌ی دیگران را ویرایش کند؛ تغییرها فقط در افزونه‌ی خودتان یا پوسته‌ی فرزند.
  • لاراول: مایگریشن‌ها را خط‌به‌خط بخوانید و دستوری مثل migrate:fresh را فقط روی دیتابیس آزمایشی اجازه دهید. اگر فایل‌های config یا routes تغییر کرد، دلیلش را بپرسید. تجربه‌های بیشتر در هوش مصنوعی در پروژه‌ی لاراول.

این موضوع به کجا می‌رود#

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

برای آمادگی:

  • پوشش تست پروژه‌هایتان را بالا ببرید و از بخش‌های حساس مثل پرداخت شروع کنید.
  • یک فایل دستورالعمل پروژه بنویسید و مثل کد به‌روزش نگه دارید.
  • خواندن سریع و دقیق diff را تمرین کنید؛ این مهارت ارزشمندتر از قبل می‌شود.

خلاصه#

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