تصور کنید یک برنامهنویس برای رفع یک باگ ساده تنها ۱۵ خط کد مینویسد، اما عامل هوش مصنوعی شما برای همان اصلاح، ۵۰۰ خط از معماری سیستم را تغییر میدهد. این کابوس برنامهنویسان اکنون با Boffin به پایان میرسد تا تغییرات دقیقاً متناسب با نیاز باشند. Boffin این مشکل را با عمل کردن به عنوان یک لایهی کنترلی «مهندس ارشد» (Staff-Engineer) حل میکند؛ لایهای که به جای اعمال یک مجموعه واحد از قوانین کلی، محدودیتهای معماری خاصی را بر اساس دقیقاً همان فایلی که در حال ویرایش است، تزریق میکند.
بسیاری از توسعهدهندگان در حال حاضر از فایلهای دستورالعمل استاتیک مثل AGENTS.md یا بستههای پرامپت سیستمی (System Prompt) — که شبیه به یک دفترچه راهنمای ثابت برای کل ساختمان است — استفاده میکنند. این رویکردی است که در تلاش برای استانداردسازی قوانین کدنویسی در ابزارهای مختلف مورد بحث قرار گرفته است. این فرمتها معمولاً یک بلوک استاتیک از دستورالعملها را برای کل مخزن کد (Repository) ارسال میکنند، که اغلب برای عامل (Agent) — سیستمی که میتواند بهطور مستقل تصمیم بگیرد و ابزارها را به کار بگیرد — بیش از حد مبهم یا حجیم است و اعمال دقیق آن دشوار میشود. Boffin این مدل را تغییر داده و تنها محدودیتهای مرتبط با ویرایش فعلی را مسیریابی کرده و ارسال میکند و همچنین تأییداتی متناسب با اندازه تغییرات را الزامی میسازد.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کنترل دقیق روی خروجی مدلها تنها راه جلوگیری از توهمات ساختاری است. Boffin دقیقاً همین نقطه را هدف گرفته است. این رویکرد یادآور استراتژیهای جداسازی مدلها در سیستمهای پیچیده برای حذف توهمات است.
زمینه و جایگاهسازی
Boffin یک ابزار بررسی کد (Linter) یا یک گیت در خط لوله CI (CI gate) نیست؛ بلکه هم قبل و هم بعد از ویرایش عمل میکند تا ایمنی بازبینی (Review-safety) را تضمین کند. همچنین این ابزار یک ابزار افزایش سرعت نیست و به عنوان یک محیط امن (Sandbox) برای دستورات یا یک ابزار امنیتی عمل نمیکند. Boffin فرآیندها را ایزوله نمیکند، دستورات شل (Shell) را فیلتر نمینماید و دسترسی به سیستم فایل یا شبکه را محدود نمیکند. در عوض، وظیفهی تخصصی آن هدایت تصمیمات معماری در کدهای تولید شده است.
برخلاف قوانین استاتیک، Boffin تضمین میکند که عامل دلیل کافی برای توقف داشته باشد، پیش از آنکه یک مورد خاص (Special Case) واقعی را ادغام کند، مرز بین متدهای همگام و ناهمگام (Sync/Async) را محو کند، وضعیت (State) را از مالک اصلیاش جدا کند یا یک وظیفهی متمرکز را به یک «گشتوگذار برنامهریزینشده» در کدهای پروژه تبدیل نماید. این قابلیت برای جلوگیری از «انحراف معماری» مشابه رویکردهای ساختاریافته در مدیریت حافظه متنی عمل میکند. در مواردی که تداخل بین یک قانون «پاکسازی» (Cleanup) با یک قانون «صحت» (Correctness) ایجاد شود، همیشه اولویت با قانون صحت است و آن پیروز میشود.
این ابزار که به صورت یک بسته npm با نام boffinit منتشر شده، توسط ParselFire Core قدرت گرفته است. طبق مستندات این پروژه در گیتهاب، Boffin با محیطهای کدنویسی بزرگی مثل Cursor، Claude Code، Codex و OpenCode سازگار است. این سیستم بستههای محدودیت (Constraint Packs) قابل حمل و امضا شدهای را ارائه میدهد که با GPG امضا شدهاند و در دایرکتوری packs/ به صورت markdown قابل خواندن هستند؛ این امر تضمین میکند که هیچ قانون مخفی هنگام نصب اعمال نشود.
نتایج اثبات شده در متنباز
Boffin برای اثبات کارایی خود در مقایسه با پرامپتهای استاتیک، مطالعات موردی بازتولیدپذیری را روی کدهای واقعی متنباز ارائه میدهد. اینها بنچمارکهای کنترلشده A/B نیستند، بلکه بازسازیهای (Refactors) ثبت شده هستند:
- DuckDB: یک بازسازی هدایتشده تنها با ۱۷ خط تغییر مثبت و ۱۷ خط منفی (+17 / -17)، توانست ۲۱۰۴ مورد تأیید (Assertion) را در ۸ فایل تست با موفقیت پشت سر بگذارد. در این فرآیند، مسیرهای مجزای تداوم و بازیابی (Continuation and Recovery paths) بهطور کامل حفظ شدند.
- FastAPI: بازسازی کد با ۱۶ خط اضافه و ۳۳ خط حذف (+16 / -33)، بدون هیچ تغییری در API عمومی، ۴۹ تست را پاس کرد.
- LangChain: این ابزار توانست مرز بین متدهای همگام و ناهمگام (Sync/Async) را در ۴ تست مختلف با موفقیت حفظ کند.
جزئیات فنی و نصب
برای استفاده از Boffin، نصب Node.js نسخه ۱۸ یا جدیدتر الزامی است. روش تحویل و نصب بسته بسته به میزبان متفاوت است:
- Claude Code: کاربران میتوانند دستورات
/plugin marketplace add MicSm/boffinو سپس/plugin install boffin@boffinرا در محیط برنامه اجرا کنند. - Codex: نصب از طریق
codex plugin marketplace add MicSm/boffinوcodex plugin add boffin@boffinانجام میشود. از آنجایی که Codex بهطور خودکار به هوکهای پلاگین اعتماد نمیکند، کاربران باید یکبار دستور/hooksرا اجرا کرده و آنها را بررسی و تأیید کنند؛ در غیر این صورت، مهارتها (Skills) کار میکنند اما فعالسازی خودکار جلسه (Session) غیرفعال میماند. - OpenCode: راهنماییها از طریق مسیر
opencode.json->.boffin/AGENTS.mdاعمال میشوند. همچنین کاربران میتوانند از مهارتهای/boffinو/boffin-reviewاستفاده کنند. - Cursor: این ابزار مستقیماً از داخل پروژه اجرا میشود.
پروفایلها و ایمنی
این سیستم با انتخاب قوانین مرتبط از دایرکتوری packs/ در زمان ویرایش عمل میکند. برای اینکه توسعهدهندگان بتوانند روی میزان «جاهطلبی» هوش مصنوعی در پاکسازی کدها کنترل داشته باشند، Boffin سه پروفایل ارائه میدهد که از طریق دستور /boffin [profile] قابل انتخاب هستند:
۱. Lite: فشار پاکسازی را در سطح پایینی نگه میدارد تا کوچکترین تغییر مفید ممکن اعمال شود.
۲. Full: حالت پیشفرض و متوازن برای اکثر وظایف.
۳. Max: شدیدترین فشار پاکسازی را در مواردی که وظیفه توجیه کند، اعمال میکند.
نکته حیاتی این است که این پروفایلها فقط روی میزان جاهطلبی در پاکسازی اثر میگذارند و «کف ایمنی» (Safety Floor) برای همه ثابت است. هر سه پروفایل مراحل اولیه صحت و قوانین رد کردن (Rejection rules) یکسانی را اجرا میکنند؛ این قوانین شامل اعتبارسنجی مرزهای اعتماد (Trust-boundary)، جلوگیری از دست رفتن دادهها، الزامات امنیتی و استانداردهای دسترسپذیری (Accessibility) میشود.
این رویکرد، گردش کار کدنویسی با AI را از یک قمار به یک فرآیند قابل تأیید تبدیل میکند. برای یک تغییر متمرکز، Boffin محدوده درخواست را کوچک نگه میدارد و محدودترین بررسی ممکن را که صحت ویرایش را ثابت کند، میطلبد. برای یک بازسازی (Refactor) باز و گسترده، ابتدا یک حسابرسی فقط-خواندنی (Read-only audit) را الزامی میکند و سپس هر بار تنها یک یافتهی تأیید شده را پیش میبرد.
Boffin جایگزین تستهای واحد، CI gateها یا بازبینی انسانی نمیشود. این ابزار به عامل میگوید کدام قراردادها شایستهی توجه هستند و نیاز به چکهای خارجی دارند، اما تستهای خودِ مخزن کد همچنان مرجع نهایی (Authoritative) باقی میمانند. برای حذف نصب، کاربران میتوانند دستور npx boffinit cursor uninstall یا npx boffinit opencode uninstall را اجرا کنند که فایلهای مدیریت شده توسط میزبان را حذف میکند، در حالی که فایلهای مشترک .boffin/packs و .boffin/VERSION را دستنخورده باقی میگذارد.
گام بعدی شما
- اگر از Cursor یا Claude Code استفاده میکنید، بسته Boffin را نصب کرده و با پروفایل Lite شروع کنید تا اثر آن روی حجم تغییرات کد ببینید.
- فایلهای
packs/را بررسی کنید تا متوجه شوید چگونه میتوان محدودیتهای معماری را برای هر پوشهی پروژه بهصورت مجزا تعریف کرد. - در پروژههای بزرگ، ابتدا از حالت read-only audit برای شناسایی نقاط بحرانی استفاده کنید و سپس تغییرات را تکتک تأیید کنید.
اما اثر این لایهی کنترلی بر هزینههای استنتاج و مصرف توکنها در پروژههای عظیم هنوز بررسی نشده است — در گزارش بعدی به بررسی بهینهسازی توکنها در عاملهای کدنویس میپردازیم.
گفتگو