ایجنتهای کدنویس رو مثل یک تیم مدیریت کن
نوشتن قرارداد کار بهجای دستور مبهم، موازیکردن بدون تداخل، راستیآزمایی خودکار، و تصمیمگیری دربارهٔ اینکه کجا ایجنت اجازهٔ حدسزدن داره.
محمد فغانیمنتشرشده بازنگری
دستور نده، قرارداد کار بنویس
دستور «این قابلیت رو بساز» تقریباً همهٔ تصمیمهای مهم رو باز میذاره. کجا بسازه، با چه الگویی، چه چیزی رو دست نزنه، از کجا بفهمه تموم شده — هیچکدوم گفته نشده، پس همهشون حدس زده میشن.
قرارداد خوب هدف، زمینه، محدودهٔ فایلها، محدودیتها، معیار پذیرش و فرمان اثبات نتیجه رو مشخص میکنه. همچنین میگه چه چیزی خارج از دامنهست. ایجنت با این اطلاعات کمتر حدس میزنه و تو میتونی خروجی رو با یه معیار مشخص بسنجی، نه با حس.
هدف: کاربر بتواند ایمیلش را از صفحه تنظیمات عوض کند.
زمینه: جریان فعلی تغییر رمز در `app/pages/settings/password.vue` است؛
همان الگو را دنبال کن.
دامنه: فقط `app/pages/settings/` و `server/api/account/`.
به لایه احراز هویت دست نزن.
محدودیتها: ایمیل جدید باید تایید شود قبل از اعمال.
آدرس قبلی تا زمان تایید فعال میماند.
معیار پذیرش:
- تغییر بدون تایید اعمال نمیشود.
- ایمیل تکراری خطای قابل فهم میدهد.
اثبات: `npm run typecheck && npm test`موازیکاری بدون تداخل
وسوسهی اجرای چند ایجنت همزمان زیاده و گاهی هم درسته؛ مثلاً یکی تحقیق کنه و دیگری تست بنویسه. ولی اگه چند ایجنت همزمان یه مؤلفهٔ مرکزی رو ویرایش کنن، هزینهٔ ادغام از سودِ موازیکاری بیشتر میشه.
قاعدهای که خوب جواب میده: موازیسازی بر اساس مرز فایل، نه بر اساس مرحله. دو کار که به فایلهای جدا دست میزنن بیخطرن؛ دو کار که هر دو به یه فایل مشترک دست میزنن، حتی اگه منطقاً مستقل باشن، در عمل نیستن.
- بیخطر: یکی روی صفحهٔ پرداخت، یکی روی صفحهٔ پروفایل.
- بیخطر: یکی کد مینویسه، یکی مستندات همون بخش رو بهروز میکنه.
- پرریسک: دو کار که هر دو مدل داده یا فایل پیکربندی مشترک رو عوض میکنن.
- پرریسک: کاری که خروجیش ورودی اون یکیه. اینها موازی نیستن، فقط به نظر میرسن.
هر کار موازی هم باید شاخه یا فضای کاری خودش رو داشته باشه. ادغامکردن دو تغییر مستقل خیلی راحتتر از جداکردن دو تغییر درهمتنیدهست.
راستیآزمایی: مرز بین کمک و دردسر
ایجنتی که نمیتونه کارش رو بسنجه، سرعت تولید کد رو بالا میبره و سرعت تولید باگ رو هم. تفاوت بین این دو حالت، وجود یه فرمان اثباته: چیزی که بدون دخالت آدم بگه درست شد یا نه.
- typecheck — ارزونترین و سریعترین. بخش بزرگی از خطاهای ساختاری رو همینجا میگیره.
- تست — مخصوصاً تستی که برای همون باگ نوشته شده. «قبل از رفع، تست شکستخورده» بهترین قرارداد ممکنه.
- اجرای واقعی — بعضی چیزها فقط وقتی معلوم میشن که برنامه بالا بیاد و صفحه باز بشه.
و یه قاعدهٔ سخت: گزارش ایجنت مدرک نیست. «تستها پاس شدند» یه ادعاست تا وقتی خودت فرمان رو اجرا کنی و خروجی رو ببینی. این نه بدبینیست نه بیاعتمادی؛ همون کاریست که با هر تغییر کد، از هر کسی، باید بکنی.
کجا اجازهٔ حدسزدن بدی
ایجنت باید بدونه کجا میتونه با فرض معقول جلو بره و کجا باید بایسته و بپرسه. اگه این مرز رو نکشی، یا برای هر تصمیم کوچک متوقف میشه — که کل سود سرعت رو میخوره — یا روی تصمیمهای بزرگ خودسر عمل میکنه.
مرزی که معمولاً درست از آب درمیاد:
- آزاد: نام متغیر، ساختار داخلی تابع، ترتیب کارها، افزودن تست.
- آزاد با گزارش: انتخاب بین دو الگوی موجود در پروژه — انجام بده، ولی بگو کدوم رو انتخاب کردی و چرا.
- بایست و بپرس: افزودن وابستگی جدید، تغییر مدل داده، تغییر قرارداد API، هر چیزی که مهاجرت لازم داره.
- هرگز بدون تأیید: حذف داده، ارسال به بیرون، تغییر تنظیمات محیط عملیاتی.
ریتم کار: یک چرخهٔ کامل
همهٔ قاعدههای بالا وقتی معنی پیدا میکنن که توی یه ریتم تکرارشونده جا بیفتن. چرخهای که در عمل خوب جواب میده این شکلیه:
- قرارداد بنویس — پنج تا ده دقیقه. این گرانترین قدم به نظر میرسه و ارزانترین قدم واقعیه.
- واگذار کن و برو سراغ کار دیگه — اگه قراره بالای سرش بشینی، خودت سریعتر مینوشتی.
- diff رو بخون، نه گزارش رو — اولین چیزی که نگاه میکنی باید تغییر واقعی باشه.
- فرمان اثبات رو خودت اجرا کن — هر بار، بدون استثنا.
- کامیت کوچک بزن — قبل از شروع کار بعدی، نه بعد از سه تا کار.
- اگه الگوی تکراری دیدی، بنویسش — در سند قواعد، تا دفعهٔ بعد لازم نشه بگی.
دو تا از این شش قدم معمولاً حذف میشن و دقیقاً همون دو تا هستن که همهچیز رو نگه میدارن. قدم اول حذف میشه چون عجله داری، و نتیجهاش کاریست که باید دوباره انجام بشه. قدم ششم حذف میشه چون کار تموم شده و حوصله نداری، و نتیجهاش اینه که هفتهٔ بعد همون اصلاح رو دوباره مینویسی.
اون قدم آخر در واقع همون چیزیه که یه مجموعه ایجنت رو از یه دستیار موقتی به یه تیم تبدیل میکنه: هر چیزی که یک بار یاد گرفتی، جایی بمونه که دفعهٔ بعد خودش اعمال بشه.
بازبینی، همون کاری که با آدم میکنی
کدی که ایجنت نوشته دقیقاً همون بازبینیای رو لازم داره که کد یه همکار. نه بیشتر از سر بدگمانی، نه کمتر از سر اعتماد. ولی چیزهایی که باید دنبالشون بگردی کمی فرق دارن:
- کدی که کار میکنه ولی با الگوی بقیهٔ پروژه نمیخونه.
- مدیریت خطایی که وجود داره ولی خطا رو میبلعه بهجای اینکه گزارشش کنه.
- تستی که نوشته شده ولی چیزی رو که مهمه نمیسنجه.
- کد یا وابستگیای که اضافه شده ولی هیچجا استفاده نمیشه.
- کامنتی که چیزی رو توضیح میده که از خود کد پیداست، و سکوت در جایی که واقعاً چرایی لازم بود.
اگه در بازبینی یه الگوی تکراری دیدی، اون الگو رو توی سند قواعد بنویس. هر چیزی که دو بار اصلاحش کردی، دفعهٔ سوم باید از اول درست نوشته بشه.
پرسشهای پرتکرار
- چند تا ایجنت همزمان معقوله؟
- محدودیت واقعی، تعداد ایجنت نیست؛ تعداد کارهای واقعاً مستقلیه که داری. اگه سه تا کار داری که به فایلهای جدا دست میزنن، سه تا خوبه. اگه سه تا کار داری که هر سه به مدل داده دست میزنن، یکی هم زیاده. و فراموش نکن ظرفیت بازبینی خودت هم یه سقفه.
- وقتی ایجنت گیر میکنه چی کار کنم؟
- ادامهدادن گفتوگو معمولاً بدترین گزینهست، چون تاریخچهای که پر از تلاشهای ناموفقه خودش مانع میشه. بهتره برگردی به آخرین وضعیت سالم، و قرارداد کار رو بازنویسی کنی با اضافهکردن چیزی که تازه فهمیدی. اغلب گیرکردن یعنی صورت مسئله ناقص بوده، نه اینکه مدل کم آورده.
- آیا باید به ایجنت دسترسی نوشتن مستقیم به مخزن اصلی بدم؟
- نه. همون قاعدهای که برای آدمها داری اینجا هم صادقه: کار روی شاخه، ادغام بعد از بازبینی. این فقط محافظت نیست؛ باعث میشه بتونی چند کار موازی رو بدون تداخل پیش ببری و هر کدوم رو جداگانه برگردونی.
- اگه تیم من فقط خودم هستم، باز هم اینها لازمه؟
- بیشتر لازمه، نه کمتر. توی تیم، بازبینی همکار بعضی از این شکافها رو میپوشونه. وقتی تنهایی، قرارداد کار و فرمان اثبات تنها چیزهایی هستن که بین تو و یه مخزن درهمریخته میایستن.