تصور کنید برنامه‌نویسی هستید که هرگز ابزاری را برای نیازهای شخصی‌اش ننوشته است، زیرا هزینه‌ی نگهداری آن برای وی بسیار وحشتناک بود. طبق گزارشی از وب‌سایت blog.exe.dev در ۳ آگوست ۲۰۲۶، عامل‌های هوش مصنوعی اکنون این سد را به‌طور کامل شکسته‌اند و در نتیجه، تنها شرط بهره‌وری و کاربردی بودن یک ابزار، در دسترس بودن کد منبع (Source Code) آن است.
زمینه‌ای تاریخی: نرم‌افزارهای سفارشی
تا همین پنج سال پیش، اکثر مهندسان نرم‌افزاری که نویسنده با آن‌ها صحبت کرده بود، هیچ برنامه‌ای نداشتند که خودشان برای استفاده شخصی نوشته باشند. این مشاهده در حالی صورت گرفت که نویسنده سعی داشت بفهمد ابزار Tailscale چگونه می‌تواند در زندگی مهندسان جای بگیرد. برای چندین دهه، مهندسان روزهای خود را با استفاده از برنامه‌هایی می‌گذراندند که دیگران نوشته بودند تا بتوانند برنامه‌هایی برای دیگران بنویسند.
توسعه‌دهندگان مجبور بودند با نرم‌افزارهای «تقریباً مناسب» که به صورت آماده در بازار بودند کنار بیایند؛ مانند مولدهای سایت استاتیک (Static Site Generators) یا دستگاه‌های زیگبی (Zigbee). شخصی‌سازی یک ابزار معمولاً به معنای کلنجار رفتن با فایل‌های تنظیمات بسیار پیچیده و عجیبی بود یا دست‌وپنجه نرم کردن با APIهای محدودکننده برای پلاگین‌ها. بسیاری از مهندسان از برنامه‌هایی که برای دیگران نوشته بودند به عنوان کاربر استفاده می‌کردند، اما نرم‌افزارهای سفارشی برای یک آزمایشگاه خانگی یا یک وبلاگ شخصی، اتفاقی نادر و یک امتیاز خاص بود.
این اجتناب کاملاً منطقی بود. بازگشت سرمایه (ROI) برای نرم‌افزارهای شخصی مورد تردید بود، زیرا یک مهندس در یک روز فقط مقدار محدودی کد می‌توانست بنویسد. نگهداری کدها «به‌طور فوق‌العاده‌ای دردناک» بود، به‌خصوص زمانی که فرد پس از یک سال به پروژه‌ای بازمی‌گشت. اولویت‌های کاری (مثلاً زمانی که در محل کار مشکلی پیش می‌آمد) اغلب بر پروژه‌های شخصی غلبه می‌کرد. نویسنده حتی در سال‌های اول حضورش در گوگل، کامپیوتر شخصی نداشت. سال‌هایی وجود داشت که او تمام نرم‌افزارهای سفارشی خود را دور می‌انداخت تا از استانداردترین و معمولی‌ترین محیط‌های ممکن استفاده کند.
سازوکار شخصی‌سازی مبتنی بر عامل
این پویایی اکنون تغییر کرده است، زیرا عامل‌ها می‌توانند «کارهای سخت» نگهداری نرم‌افزار را بر عهده بگیرند. به نقل از blog.exe.dev، عامل‌ها نه‌تنها می‌توانند کد منبع را برای یک نیاز خاص تغییر دهند، بلکه می‌توانند همگام‌سازی (Synchronization) این تغییرات با پروژه اصلی را نیز خودکار کنند. این رویکردی است که در معماری‌های پیشرفته‌تر، مانند پروژه Persephone که در آن کد منبع به محیط زندگی عامل‌ها تبدیل شده، به شکلی بنیادی‌تر پیاده‌سازی شده است.
شخصی‌سازی نرم‌افزار در دنیای امروز بر دو دسته کلی از پرامپت‌های ارسالی به عامل استوار است:
- راه‌اندازی اولیه: «کد منبع
را دانلود کن و آن را برای استفاده محلی بساز (Build). حافظه‌ای که عامل از آن استفاده می‌کند را به‌گونه‌ای تغییر بده که بداند هرگونه تغییر آتی در این نرم‌افزار به معنای تغییر در کد منبع و جایگزینی نسخه فعلی است. انگیزه اصلی پشت این تغییر را در سیستم کنترل نسخه (Version Control) ثبت کن.» - نگهداری مستمر: یک دستور شبانه (Cron Job) که این عبارت را اجرا می‌کند: «تغییرات جدید را از منبع اصلی (Upstream) دریافت کن و تمام تغییرات محلی را روی نسخه‌ی جدید Rebase کن. بررسی کن که نرم‌افزار طبق انتظار کار می‌کند و سپس نسخه فعلی را جایگزین کن.»
در قلب این تحول، این درک نهفته است که عامل‌ها می‌توانند فرآیند همگام‌سازی تغییرات با نسخه‌های اصلی را به‌طور خودکار مدیریت کنند. این موضوع بازگشت سرمایه شخصی‌سازی را از دو جهت تغییر می‌دهد: شروع کار بسیار آسان‌تر شده و تداوم آن نیز بسیار ساده‌تر است.
تعمیق شخصی‌سازی از طریق «مهارت‌ها»
این پرامپت‌ها می‌توانند مستقیماً به‌عنوان یک «مهارت» (Skill) در قالب دستورالعمل‌های متنی در جایی که برای عامل قابل شناسایی باشد، تعریف شوند. تا زمانی که عامل متن‌باز باشد، این کار نیازی به برنامه‌نویسی واقعی ندارد.
این قابلیت در Shelley پیاده‌سازی شده است. اکنون کاربران دیگر نیازی به نوشتن مقدمات طولانی یا پیکربندی تایمر برای ویرایش Shelley ندارند. یک پرامپت ساده مانند «رابط کاربری Shelley را با کنتراست بالا (High-contrast) بساز»، اجازه می‌دهد تا خودِ عامل به‌طور فوری شخصی‌سازی شود.
مورد مطالعاتی: ادغام meat.dev در Shelley
برای اثبات این موضوع، نویسنده از Shelley استفاده کرد تا یک پروژه شخصی به نام meat.dev را با آن ادغام کند. در ماه گذشته، نویسنده از meat.dev برای بازبینی کدها (Code Review) استفاده کرده است. در حالی که عامل‌ها کد می‌نویسند، نویسنده هنوز قبل از ارسال کدها به سیستم‌های حساس، آن‌ها را می‌خواند.
نویسنده در طول بیست سال بازبینی کدهای انسانی متوجه شد که انسان‌ها با موارد خاص (Edge Cases)، مانند بررسی‌های مقدار تهی (nil-checks) و اینکه آیا خطاها اطلاعات مفیدی گزارش می‌دهند یا خیر، مشکل دارند. با این حال، در شش ماه گذشته کشف کرد که مدل‌های هوش مصنوعی در صحت‌سنجی‌های تکراری و روتین (Rote Correctness) بسیار دقیق‌تر از انسان‌ها هستند. این افزایش دقت در کدنویسی با ظهور مدل‌هایی مانند GLM-5.2 که به عنوان جایگزینی عملی برای توسعه‌دهندگان معرفی شده‌اند، شتاب بیشتری گرفته است. خطاهای مدل‌ها در عوض، محدود به معماری، موارد استفاده غیرمنتظره، یا مشکلات خروجی بصری در محیط تست است.
از آن‌جآنیکه بیشتر خطوط کد در یک Diff تولید شده توسط LLM اکنون مربوط به صحت‌سنجی‌های روتین و «غیرمهم» است، نویسنده meat.dev را نوشت تا نویزها — مانند بلوک‌های import، بررسی‌های nil و مدیریت خطاها — را حذف کند تا بتواند بر «گوشت» یا همان هسته اصلی منطق کد تمرکز کند.
ادغام سنتی این دو ابزار یک «عذاب پیچیده» (Convoluted Misery) می‌بود. این کار نیازمند پیمایش در APIهای پیچیده افزونه‌های VS Code یا انتقال آن به vimdiff بود. برای اینکه این ادغام به‌طور یکپارچه کار کند، باید یک برنامه جانبی به نام "meatd" پیاده‌سازی می‌شد که به سیستم فایل گوش می‌داد و یک حافظه پنهان (Cache) برای API شخصی‌سازی فراهم می‌کرد.
در عوض، تنها با سه پرامپت ساده، این ادغام محقق شد:
- «لطفاً meat.dev را در Shelley بساز و آخرین نسخه را در PATH نصب کن.»
- «وقتی یک git commit توسط Shelley ایجاد شد، پردازش meat را در پس‌زمینه روی آن commit شروع کن.»
- «یک دکمه Toggle به نمای Diffs در Shelley برای meat اضافه کن. اگر commit هنوز در حال پردازش است، به کاربر اطلاع بده که در جریان است.»
این روش به نویسنده اجازه داد تا منتظر کاهش حجم Diff توسط مدل نماند، زیرا پردازش در پس‌زمینه اتفاق می‌افتاد. تنها انتخاب «ناخوشایند» مدل این بود که از یک ایموجی استیک (🥩) برای دکمه Toggle استفاده کرد.
مرگ سیستم‌های پلاگین
این تغییر نشان می‌دهد که فایل‌های تنظیمات سنتی و معماری‌های پلاگین در حال منسوخ شدن هستند. در گذشته، کد هسته پروژه‌هایی مثل Vim بسیار حجیم و پیچیده می‌شد، زیرا طراحان مجبور بودند هزینه سیستم پلاگین را بین بسیاری از کاربران توزیع کنند. غیرمنطقی بود که انتظار رود یک مهندس تنها، یک کدبیس عظیم را یاد بگیرد تا فقط باعث شود شماره خطوط به صورت پیش‌فرض چاپ شوند.
اکنون هزینه یادگیری کد به‌طور چشمگیری کاهش یافته است. برای نرم‌افزارهای تک‌کاربره، بررسی دقیق کد می‌تواند با یک پرسش ساده جایگزین شود: «آیا به نظر می‌رسد درست کار می‌کند؟»
- مقادیر سخت‌افزاری (Hardcoded): اگر کاربر بخواهد اندازه فونت را تغییر دهد، عامل مقدار سخت‌افزاری را در منبع پیدا کرده و ویرایش می‌کند.
- جایگزینی دارایی‌ها: اگر از یک فونت بیت‌مپ سخت‌افزاری استفاده شده باشد، عامل یک جایگزین را دانلود می‌کند یا از Monobit برای ساخت یکی جدید استفاده می‌کند.
در واقع، خودِ کد منبع به نهایی‌ترین سیستم توسعه (Extension System) تبدیل شده و قلاب‌های (Hooks) تخصصی دیگر ضرورتی ندارند.
پیامدها برای نرم‌افزارهای سازمانی و تیم‌ها
این روند به تیم‌های کوچک مهندسی و محصولات B2B نیز گسترش می‌یابد. دلیل کمی وجود دارد که تیمی یک مدیریت وظایف، CMS یا CRM بسیار قابل‌پیکربندی بخرد و گردش کار خود را برای گنجاندن در محدودیت‌های آن تغییر دهد، در حالی که می‌توانند ویژگی‌های خاص را از بلوک‌های سازنده‌ی رایج و متن‌باز جمع‌آوری کنند.
هم هزینه‌های ثابت اولیه و هم هزینه‌های جاری نگهداری برای شخصی‌سازی نرم‌افزار از بین رفته است. وبلاگی که نویسنده نوشته است نمونه‌ای از این است؛ این یک نرم‌افزار سفارشی است که در Shelley نوشته شده، زیرا شخصی‌سازی کتابخانه‌هایی مانند Tiptap بسیار ساده‌تر از سفارشی‌سازی محصولات نرم‌افزاری سنتی بود. برای اینکه یک شرکت امروز بتواند تولید یک محصول برای کاربر نهایی را توجیه کند، آن محصول باید شخصی‌سازی‌پذیر باشد، و این یعنی کد منبع باید در دسترس باشد.
دیوار سورس‌بسته: Claude Code در مقابل Codex
این تکنیک مبتنی بر مهارت را می‌توان روی هر عامل متن‌باز، مانند Pi یا Codex اعمال کرد. این قابلیت دسترسی گسترده به مدل‌های باز با سرمایه‌گذاری‌های کلانی نظیر بودجه ۸۸ میلیون دلاری Ollama برای گسترش استنتاج، احتمال شخصی‌سازی ابزارها را برای کاربران عادی افزایش داده است. نویسنده اشاره می‌کند که چون کد منبع اکنون به عنوان سیستم توسعه عمل می‌کند، مشخص نیست چرا Pi اصلاً به یک سیستم توسعه داخلی نیاز دارد، هرچند اعمال این روش روی Codex نیازمند تعداد توکن‌های به‌مراتب بیشتری خواهد بود.
جایی که این رویکرد به دیوار می‌رسد، Claude Code است. به دلیل سورس‌بسته بودن Claude Code، کاربران نمی‌توانند آن را شخصی‌سازی کنند. آن‌ها محدود به «قلاب‌های شخصی‌سازی قدیمی» هستند. اگر نیازهای کاربر با آن قلاب‌های خاص هم‌خوانی نداشته باشد، نویسنده پیشنهاد می‌کند که کاربر به عاملی مهاجرت کند که اجازه شخصی‌سازی کامل از طریق دسترسی به سورس را می‌دهد.
گام بعدی شما
- بررسی کنید کدام ابزارهای ضروری شما کد منبع باز دارند تا آن‌ها را به عامل‌های خود معرفی کنید.
- به جای جست‌وجوی پلاگین‌های پیچیده، از عامل‌ها بخواهید تغییرات مورد نیاز شما را مستقیماً روی کد منبع اعمال کنند.
- برای مدیریت تغییرات، یک گردش کار خودکار (Cron Job) برای Rebase کردن کدهای شخصی روی نسخه‌های اصلی تعریف کنید.
اما تأثیر این رویکرد بر معماری مدل‌های زبانی بعدی چیست؟ بررسی کنید که چگونه پنجره‌های متنی بزرگ‌تر، مرگ کامل فایل‌های کانفیگ را تسریع می‌کنند.
گفتگو