🔗🔗**** معرفی LayerFS برای وقتی ایجنت‌ها زیاد می‌شن!**
فرض کنین یه پروژه نرم‌افزاری بزرگ دارین و به‌جای اینکه یه ایجنت رو مأمور Refactoring کنین، تصمیم می‌گیرین ۲۰ تا ایجنت رو هم‌زمان به کار بگیرین؛ ۵ تا برای refactoring، پنج‌تا هم برای پیدا کردن و رفع Bug، پنج‌تا برای نوشتن تست و پنج‌تای دیگه هم برای امتحان کردن روش‌های مختلف بهینه‌سازی performance. خب؟
روی کاغذ خوبه؛ ولی یه مشکل اساسی داریم: هر Agent برای کارش به سورس‌کد پروژه، dependencyها و یه محیط اجرایی مستقل نیاز داره.
راه‌حل‌های دوران پیشاهوشواره (ماقبل AI) مثل git تا حد خوبی این نیاز رو برطرف می‌کنن، ولی وقتی تعداد Agentها به ده‌ها یا صدها برسه، مدیریت این محیط‌ها، نگهداری فایل‌های تکراری، آماده‌سازی dependencyها و هماهنگی تغییرات، خودش تبدیل به یه چالش جدی می‌شه.
مثلاً وقتی یه پروژه با سورس‌کد ۱۰۰ گیگابایتی دارین؛ چرا باید برای هر Agent یک کپی جداگانه از همه‌چیز داشته باشین؟ از طرفی هم نمی‌شه همه از یه نسخه مشترک استفاده کنن و فقط تغییرات خودشون رو مستقل نگه دارن؟
دلیل پیدایش پروژه متن‌باز LayerFS همین مسئله بود! ایده اصلیش Ephemeral Workspaces, Durable Shared History است؛ یعنی محیط‌های کاری موقت، با تاریخچه تغییرات ماندگار و مشترک.
به زبون ساده، هر ایجنت یه workspace مستقل داره، بدون اینکه لازم باشه همه فایل‌ها و dependencyهای پروژه براش کپی بشن. همه از یه پایه مشترک استفاده می‌کنن و فقط تغییرات اختصاصی خودشون رو نگه می‌دارن.
قابلیت جذاب‌ترش اینکه تغییرات می‌تونن به‌صورت checkpoint ثبت بشن. فرض کنین یه ایجنت برای refactoring چهار مرحله جلو رفته، ولی توی مرحله چهارم به بن‌بست رسیده. می‌شه از مرحله دوم یه branch جدید ساخت و به چند ایجنت دیگه سپرد تا مسیرهای متفاوتی رو امتحان کنن.
حتی می‌شه ۵۰ تا ایجنت رو روی ۵۰ راه‌حل متفاوت برای یه مسئله به کار گرفت، بعد خروجی‌ها رو تست و مقایسه کرد و بهترین گزینه رو انتخاب کرد. البته انتخاب بهترین راه‌حل کار خود LayerFS نیست؛ این زیرساخت فقط اجرای چنین الگویی رو ساده‌تر می‌کنه.
از نظر فنی هم پروژه با ترکیبی از تکنیک‌های شناخته‌شده و حتی قدیمی مثل Copy-on-Write، Content-Addressed Storage و SQLite پیاده‌سازی شده و ادعاهای جالبی درباره کاهش مصرف استورج و زمان آماده‌سازی Workspaceها داره.
البته هنوز محدودیت‌هایی هم داره، مثل محدودیت اشتراک Store بین ماشین‌های مستقل، یا مدیریت Conflictهای منطقی و بعضی ملاحظات مربوط به Durability.
بنابراین فعلاً نباید بهش به‌عنوان «امروزه، عصر، عسر LayerFS است و هر کس بلد نباشه یا استفاده نکنه، ابله است» نگاه کنیم.
💡 اما به نظرم نکته مهم‌تر از خود LayerFS؛ مسئله‌ایه که داره حل می‌کنه.
ما داریم به سمتی می‌ریم که توسعه نرم‌افزار لزوماً به معنی همکاری یه برنامه‌نویس با یه ایجنت نیست. ممکنه به معنی اجرای ده‌ها یا صدها ایجنت باشه که هم‌زمان فرضیه‌های مختلف رو امتحان می‌کنن، شکست می‌خورن، به عقب برمی‌گردن و مسیرهای جدیدی رو پیش می‌گیرن.
برای چنین آینده‌ای، فقط مدل‌های هوشمندتر کافی نیستن. به زیرساخت‌هایی نیاز داریم که این شکل از توسعه رو از نظر هزینه، سرعت، مدیریت state و قابلیت ردیابی عملی کنن.
و LayerFS قرار نیست ایجنت‌ها رو باهوش‌تر کنه؛ می‌خواد کاری کنه که بتونیم تعداد خیلی بیشتری از اون‌ها رو به شکل مؤثر، کنار هم به کار بگیریم و هزینه منابع رو در سطح استورج و زمان، کنترل کنیم.
و شاید این بخشِ کمتر دیده‌شده یا کمتر پرداخته‌شده‌ای از تحول AI-Native Software Engineering باشه: تحول توی زیرساخت توسعه، نه صرفاً ابزار تولید کد یا حتی محصول.