ابزار توسعهدهنده باید متنباز باشه
هوش مصنوعیخلاصهٔ کاملتر
نویسنده تعریف میکنه که تا چند سال پیش خیلی از مهندسها هیچ نرمافزاری برای خودشون ننوشته بودن؛ چون نوشتن و مهمتر از اون نگهداری یه ابزار شخصی، صرف نمیکرد. به گفتهٔ اون ایجنتها این معادله رو از دو طرف عوض کردن: هم شروع کردن آسونتر شده، هم ادامه دادنش.
کل ترفند تو دوتا پرامپته: اول اینکه سورس نرمافزار رو بگیر، لوکال بیلدش کن و انگیزهٔ هر تغییر رو تو ورژنکنترل ثبت کن؛ دوم و مهمتر، یه کرونجاب شبانه بذار که تغییرات آپاستریم رو بگیره، پچهای محلی رو روش ریبیس کنه و تست کنه که همهچی سر جاشه. این پرامپتها رو میشه به شکل یه skill داخل خود ایجنت گذاشت تا کاربر حتی لازم نباشه چیزی تنظیم کنه.
یه نمونهٔ عملی هم میزنه: ابزار شخصیش meat که با کمک LLM بخشهای کماهمیت یه diff — ایمپورتها، nil-checkها و هندل خطا — رو حذف میکنه تا فقط مغز تغییرات بمونه. با یه پرامپت، همین ابزار به ادیتور Shelley وصل شد و حالا بهمحض ساخته شدن هر کامیت، پردازش رو تو پسزمینه شروع میکنه. به گفتهٔ نویسنده انجام همین کار با API افزونههای VS Code یا vimdiff عملاً کابوس بود.
همینجاست که فرق کانفیگ کلاسیک با شخصیسازی ایجنتمحور معلوم میشه: نقطههای توسعهپذیریِ از پیش تعریفشده همیشه شکل درستی ندارن، ولی ایجنت خودش سورس رو میفهمه و هرجا لازم باشه تغییرش میده. نویسنده معتقده تو نرمافزار تککاربره، بازبینی سختگیرانهٔ کد هم اغلب جاش رو میده به «کار میکنه یا نه؟».
جمعبندیاش صریحه: محصولهای خیلی قابلتنظیم مثل تسکمنیجر و CMS و CRM دارن منطقشون رو از دست میدن، چون تیمها میتونن دقیقاً همون چیزی که میخوان رو سرهم کنن. تو همین چارچوب ایجنتهای متنبازی مثل Codex یا Pi قابل شخصیسازیان، ولی Claude Code چون بستهست فقط همون هوکهای سنتیش رو داره؛ و اگه نیازت تو اون هوکها جا نشه، باید ابزارت رو عوض کنی.
نکات کلیدی:
- ایجنتها هزینهٔ شروع و نگهداری شخصیسازی نرمافزار رو بهشدت کم کردن
- کرونجاب شبانه برای ریبیس تغییرات محلی روی آپاستریم، کلید ماجراست
- وقتی سورس در دسترس باشه، سیستم پلاگین و فایل کانفیگ ضرورتش رو از دست میده
- محصولهای خیلی قابلتنظیم جاشون رو به ابزارهای سرهمشده میدن
- ابزار بسته مثل Claude Code فقط تا جایی انعطاف داره که هوکهاش اجازه بدن
