عامل برنامه‌نویسی هوش مصنوعی ابزاری است که یک تسک کامل را می‌گیرد، چند فایل را می‌خواند و تغییر می‌دهد، تست‌ها را اجرا می‌کند و نتیجه را برای بازبینی می‌آورد. در پروژه‌های ما، برای کارهای خوش‌تعریف 20 تا 40 درصد زمان را کم می‌کند؛ برای منطق کسب‌وکار، امنیت و مسائل خاص فارسی هنوز به بازبین انسانی وابسته است. این مقاله روش کار واقعی ما را در 1405 شرح می‌دهد.
عامل برنامه‌نویسی چیست و با «تکمیل کد» چه فرقی دارد
تا 1403 بیشتر ابزارهای هوش مصنوعی برنامه‌نویسی یک کار می‌کردند: خط بعدی یا تابع بعدی را پیشنهاد می‌دادند. برنامه‌نویس می‌نوشت، ابزار حدس می‌زد، برنامه‌نویس می‌پذیرفت یا رد می‌کرد. مفید بود، ولی سرعتِ تایپ را زیاد می‌کرد نه سرعت فکر.
عامل (agent) چیز دیگری است. به آن می‌گویید «برای ماژول قرارداد، یک تاریخچه‌ی تغییر مبلغ بساز که هر تغییر را با کاربر و زمان ثبت کند و در گزارش ماهانه بیاید». عامل خودش فایل‌های مرتبط را پیدا می‌کند، الگوی پروژه را می‌خواند، موجودیت و مهاجرت پایگاه‌داده و تست را می‌نویسد، تست‌ها را اجرا می‌کند، اگر شکست خورد اصلاح می‌کند، و در پایان یک تغییر کامل تحویل می‌دهد. ابزارهای شناخته‌شده‌ی این دسته در 1405 عبارت‌اند از Claude Code، عامل کدنویسی GitHub Copilot، Cursor و Codex.
تفاوت اصلی در حلقه‌ی بازخورد است: عامل می‌تواند کد را اجرا کند و نتیجه را ببیند. همین یک قابلیت، بخش بزرگی از خطاهای نسل قبل را حذف کرد، چون کدی که کامپایل نمی‌شود یا تستش می‌شکند، پیش از رسیدن به انسان اصلاح می‌شود.
از 1403 تا 1405 چه چیزی واقعاً عوض شد
سه تغییر مشخص:
- پنجره‌ی متن بزرگ‌تر و ارزان‌تر شد. عامل می‌تواند ده‌ها فایل یک ماژول را یک‌جا بخواند و الگوی پروژه را از روی کد موجود یاد بگیرد، نه از روی توضیح ما.
- ابزارها استاندارد شدند. با پروتکل MCP، عامل به پایگاه‌داده، مستندات، سیستم تیکت و مرورگر وصل می‌شود و لازم نیست همه‌چیز را در متن پرامپت بگذاریم.
- اجرای تست و بیلد جزو کار عامل شد. تغییری که تست نداشته باشد یا تستش بشکند، تحویل داده نمی‌شود.
چیزی که عوض نشد: عامل هنوز نمی‌داند کسب‌وکار شما چطور کار می‌کند. اگر قانون «تسویه‌ی فروشنده پس از 14 روز از تحویل» را در کد یا مستندات پروژه پیدا نکند، خودش یک قانون معقول ولی غلط می‌سازد، و با اطمینان کامل.
روش کار ما در پنج مرحله
این روش را روی نرم‌افزار CRM ایده‌پو شکل دادیم؛ نرم‌افزاری با بیش از 130 جدول، مهاجرت‌های شماره‌دار و تست‌های ساختاری که هر انحراف از الگو را رد می‌کنند. همان روش را الان در پروژه‌های مشتری به کار می‌بریم.
- مشخصات، نه آرزو. تسک با یک سند کوتاه شروع می‌شود: چه چیزی، برای که، چه قانون‌هایی، چه چیزی نباید تغییر کند. جمله‌ی «یک گزارش خوب بساز» به عامل داده نمی‌شود؛ «گزارش ماهانه‌ی تعهد قراردادی با این سه ستون، مرتب بر اساس تاریخ شمسی» داده می‌شود.
- قیدهای پروژه در خود مخزن. فایل راهنمای پروژه می‌گوید کجا چه چیزی می‌نشیند، کدام الگوها اجباری است و کدام کتابخانه‌ها ممنوع. عامل این فایل را قبل از هر کار می‌خواند.
- تست‌های معماری، نه فقط تست واحد. در CRM، تستی داریم که کد کامپایل‌شده را می‌خواند و اگر جایی به‌جای استثنای دامنه از استثنای عمومی استفاده شده باشد، بیلد را می‌شکند. تست دیگری تعداد مهاجرت‌های اعمال‌شده را با عدد دقیق مقایسه می‌کند. این تست‌ها برای انسان نوشته شده بودند و برای عامل حیاتی‌تر شدند.
- بازبینی تغییر، نه بازبینی کد. بازبین انسانی diff را می‌خواند، ولی سؤالش کد نیست؛ سؤالش این است که «آیا این همان چیزی است که خواستیم و آیا قانون کسب‌وکار درست است». کدی که تست دارد و الگو را رعایت کرده، از نظر فنی قابل اعتماد است؛ از نظر دامنه هنوز نه.
- هیچ کلید و رمزی در دسترس عامل نیست. رمزها در متغیرهای محیطی یا مخزن رمز می‌مانند و در فایل‌هایی که عامل می‌خواند وجود ندارند. این قاعده استثنا ندارد.
کجا واقعاً سریع‌تر می‌شود
از تجربه‌ی یک سال گذشته‌ی ما، این کارها بیشترین صرفه‌جویی را داشتند:
- کد تکراری ساختاری: موجودیت، پیکربندی پایگاه‌داده، DTO، نقطه‌ی پایانی API با همان الگوی بقیه‌ی پروژه. اینجا عامل تقریباً بی‌خطاست چون از روی الگوی موجود کپی می‌کند.
- مهاجرت و تغییر اسکیمای پایگاه‌داده با به‌روزرسانی تست‌های وابسته.
- نوشتن تست برای کد موجود، به‌خصوص تست‌های مرزی که انسان حوصله‌ی نوشتن‌شان را ندارد.
- بازآرایی (refactor) ایمن: تغییر نام، جابه‌جایی ماژول، حذف کد مرده، با تست‌هایی که اثبات می‌کنند رفتار عوض نشده.
- مستندسازی و چندزبانه‌سازی: استخراج رشته‌ها، ساخت فایل ترجمه، نوشتن راهنمای API.
- ممیزی و گزارش: «همه‌ی جاهایی که این قانون اعمال نشده را فهرست کن» یا «تفاوت این دو نسخه‌ی اسکیما را توضیح بده».
در این دسته، تسکی که یک روز کاری می‌گرفت معمولاً در دو تا سه ساعت با بازبینی تمام می‌شود.
کجا اشتباه می‌کند و چطور می‌فهمیم
- قانون کسب‌وکار. عامل قانون را از کد و مستندات پروژه می‌گیرد؛ اگر آن‌جا نباشد، می‌سازد. راه‌حل: قانون‌ها در مستندات و تست‌ها نوشته شود، نه در ذهن مدیر پروژه.
- مسائل خاص فارسی. تقویم شمسی، یکسان‌سازی «ی» و «ک» عربی و فارسی، اعداد فارسی، ترتیب راست‌به‌چپ در PDF. مدل‌ها اینجا آموزش کمتری دیده‌اند و خطاهای ریز و مطمئن می‌کنند. در پروژه‌های فروشگاهی ما هر تابع نرمال‌سازی جست‌وجو تست مخصوص خودش را دارد.
- هم‌زمانی و پول. دو کاربر که آخرین واحد کالا را با هم می‌خرند، پرداختی که تأیید شده ولی پیامکش نرفته. عامل «راه‌حل معمول» را می‌نویسد که در بار عادی درست است و در فشار اشتباه. این‌ها را با تست هم‌زمانی می‌گیریم، نه با بازبینی چشمی.
- امنیت. بررسی مجوز که «فعلاً» گذاشته نشده، رمزی که در تست هاردکد شده، وابستگی قدیمی. ابزار تحلیل ایستا و سیاست وابستگی‌ها این‌ها را می‌گیرد؛ به بازبین اعتماد نمی‌کنیم.
- اطمینان بی‌جا. عامل نمی‌گوید «مطمئن نیستم». پس هر ادعای «انجام شد» باید با تست یا مشاهده‌ی مستقیم تأیید شود. قاعده‌ی ما: بعد از هر تغییر، دو بار بررسی.
اثر روی قیمت و زمان پروژه‌ی شما
عدد صادقانه این است: در پروژه‌های نرم‌افزار سفارشی ما، بین 20 تا 40 درصد از زمان ساخت بخش‌های خوش‌تعریف کم شده است. اما هزینه‌ی یک پروژه فقط کد نوشتن نیست:
- کشف و تحلیل نیاز همان زمان قبلی را می‌گیرد؛ کسی باید با شما بنشیند و بفهمد قانون تسویه چیست.
- طراحی رابط و تجربه‌ی کاربر با عامل سریع‌تر پروتوتایپ می‌شود ولی تصمیم‌گیری انسانی می‌ماند.
- تست پذیرش، استقرار، آموزش و پشتیبانی تقریباً بدون تغییر.
نتیجه: پروژه‌ای که 1403 چهار ماه بود، الان حدود سه ماه است، نه یک ماه. کسی که به شما «ده برابر سریع‌تر و ده برابر ارزان‌تر» می‌گوید، یا تجربه‌ی پروژه‌ی واقعی ندارد یا بخشی از کار را حذف کرده که هنوز نمی‌دانید. مقاله‌ی طراحی سایت با هوش مصنوعی: چه کاری را واقعاً انجام می‌دهد همین موضوع را از نگاه سفارش‌دهنده‌ی سایت بررسی می‌کند.
اگر می‌خواهید نرم‌افزار سفارش بدهید، این پنج سؤال را بپرسید
- کد را چه کسی بازبینی می‌کند و چه تست‌هایی جلوی خطای عامل را می‌گیرد؟
- قانون‌های کسب‌وکار من کجا نوشته می‌شود که عامل حدس نزند؟
- کدام بخش‌ها با عامل ساخته می‌شود و کدام دستی، و چرا؟
- کلیدها و داده‌ی من در دسترس ابزار هوش مصنوعی خارجی قرار می‌گیرد یا نه؟
- سورس و مستندات با تست تحویل داده می‌شود؟ (در ایده‌پو، بله؛ سورس مال شماست.)
پرسش‌های متداول
آیا کدی که عامل نوشته از کد انسان بی‌کیفیت‌تر است؟
نه لزوماً. در پروژه‌ای با الگوی روشن و تست کافی، کد عامل یکدست‌تر از کد یک تیم چندنفره است. بدون الگو و تست، بله، و سریع‌تر هم خراب می‌شود.
آیا برنامه‌نویس دیگر لازم نیست؟
لازم است، ولی کارش عوض شده: مشخصات نوشتن، معماری، بازبینی و مسئولیت. پروژه‌ی بدون برنامه‌نویس باتجربه، پروژه‌ای است که کسی مسئول خطاهایش نیست.
داده‌ی من به سرورهای خارجی می‌رود؟
اگر از مدل ابری استفاده شود، کدی که عامل می‌خواند به سرویس‌دهنده می‌رود. برای پروژه‌هایی که این قابل‌قبول نیست، از مدل‌های وزن‌باز روی سرور خودمان استفاده می‌کنیم؛ کندتر و محدودتر، ولی داخلی. این تصمیم را قبل از شروع با شما می‌گیریم.
جمع‌بندی
عامل‌های برنامه‌نویسی واقعی‌اند و ما هر روز با آن‌ها کار می‌کنیم؛ ارزش‌شان در کارهای خوش‌تعریف با تست است، و خطرشان در قانون کسب‌وکار، امنیت و مسائل خاص فارسی. تفاوت بین تیمی که از آن‌ها درست استفاده می‌کند و تیمی که فقط سریع‌تر خطا تولید می‌کند، در مشخصات، تست معماری و بازبینی است. اگر پروژه‌ای در ذهن دارید، توسعه با .NET و React را ببینید یا یک پاراگراف برایمان بنویسید؛ همان تیمی که این را نوشته، می‌سازد.
دیدگاه‌ها
هنوز دیدگاهی ثبت نشده است؛ اولین نفر باشید.