بذر پاک در برابر تاریخچه چت‌ها برای جلوگیری از رشد کدهای میرا

تصور کنید توسعه‌دهنده‌ای هستید که تمام خطوط یک معماری معیوب در یک پلاگین را پاک کرده است، اما یک هفته بعد متوجه می‌شود که عامل هوش مصنوعی او، بی‌سروصدا همان الگوهای غلط را دوباره در پروژه تزریق کرده است. این «رشد مجدد» (Regrowth) رخ می‌دهد چون عامل‌ها صرفاً کد را نمی‌خوانند؛ آن‌ها شبکه‌ای گسترده و درهم‌تنیده از حافظه‌های پایدار، تاریخچه گفتگوها و مستندات را می‌بلعند. برای حل این مشکل و تبیین اینکه چرا بازسازی‌های سنتی در این محیط شکست می‌خورند، در ۱۷ اوت ۲۰۲۶، راهنمای دقیقی در وب‌سایت dev.to منتشر شد که دیسیپلین جدیدی به نام تقطیر پروژه (Project Distillation) را پیشنهاد می‌کند.

گردش کار توسعه مدرن

امروزه شروع یک پروژه نرم‌افزاری دیگر با ایجاد یک مخزن (Repository) و کدنویسی فوری آغاز نمی‌شود. در عوض، توسعه‌دهندگان زمان قابل توجهی را صرف گفتگو با هوش مصنوعی برای پالایش نیازمندی‌ها، انتخاب معماری و تعریف جریان‌های کاری می‌کنند. این فاز اولیه، فایل‌های راهنمای حیاتی را تولید می‌کند؛ اسنادی مانند AGENTS.md و CLAUDE.md و مشخصات فنی (Specifications) و سوابق تصمیمات معماری (ADRs).

در حالی که این رویکرد اجازه می‌دهد کارهایی که زمانی هفته‌ها زمان می‌برد در عرض چند ساعت انجام شوند، یک ریسک جدید ایجاد کرده است: تصمیمات غلط حالا با همان سرعتی که تصمیمات درست پخش می‌شوند، در کل پروژه مقیاس می‌گیرند. وقتی یک تصمیم بنیادی — مثلاً یک مدل دامنه (Domain Model) معیوب یا یک معماری پلاگین غیرضروری — اشتباه تشخیص داده شود، این خطا پیش از آنکه اصلاح شود، پیشاپیش در کدها، تست‌ها، مستندات، انتزاع‌ها (Abstractions)، قراردادهای نام‌گذاری و حتی دستورالعمل‌های عامل پخش شده است. این تغییر در نقش عامل‌ها، بحث‌های جدیدی را درباره جایگزینی بازبین‌های انسانی با عامل‌های هوشمند در چرخه توسعه و میزان اتکای ما به نظارت خودکار بر کدها برانگیخته است.

خطر زمینه مرده (Dead Context)

در مهندسی نرم‌افزار سنتی، کد قدیمی (Legacy) به این دلیل زنده می‌ماند که فایل‌ها در مخزن باقی می‌مانند. اما در عصر عامل‌های هوش مصنوعی، کد منسوخ حتی پس از حذف فیزیکی هم می‌تواند بازتولید شود. این اتفاق زمانی رخ می‌دهد که یک عامل، فایلی مانند architecture-v1.md یا یک خلاصه قدیمی در حافظه‌اش را پیدا می‌کند و فرض می‌کند آن الگوهای قدیمی هنوز استاندارد مورد نظر هستند.

یک مخزن را در نظر بگیرید که حاوی توالی زیر از اسناد است: architecture-v1.md و architecture-v2.md و architecture-final.md و architecture-final2.md و در نهایت new-architecture.md. در حالی که یک توسعه‌دهنده انسانی می‌داند کدام یک نسخه جاری است، یک عامل کدنویس ممکن است از طریق جستجو در مخزن، خلاصه‌ها یا تاریخچه گفتگوها با هر یک از این‌ها مواجه شود. این وضعیت منجر به یک حالت شکست عجیب می‌شود: عامل بی‌سروصدا الگویی از نسخه A را بازمی‌گرداند؛ ابتدا یک اینترفیس، سپس یک فکتوری و بعد یک لایه سازگاری، تا زمانی که معماری حذف‌شده دوباره رشد کند و بازگردد.

این امر منجر به ایجاد «بدهی معرفتی» (Epistemic Debt) می‌شود؛ وضعیتی که در آن هزینه تشخیص اینکه «چه چیزی در پروژه واقعاً حقیقت دارد» به‌مرور افزایش می‌یابد. توسعه‌دهندگان در این حالت با این پرسش مواجه می‌شوند که آیا یک اینترفیس خاص، یک نیازمندی واقعی محصول است یا صرفاً اثر به‌جامانده از یک طراحی دورریخته‌شده.

مکانیزم تقطیر

تقطیر پروژه با بازسازی (Refactoring) متفاوت است زیرا به جای حفظ پیوستگی، آن را می‌شکند. بازسازی فرض می‌کند یک پیشرفت خطی وجود دارد (A $ \rightarrow $ A' $ \rightarrow $ A'' $ \rightarrow $ A''') که در آن سیستم بهبود می‌یابد در حالی که مفروضات زیربنایی حفظ می‌شوند. اما تقطیر زمانی به کار می‌رود که خودِ آن مفروضات غلط بوده‌اند.

در این روش، توسعه‌دهنده به جای تغییر دادن پروژه قدیمی تا تبدیل شدن به پروژه جدید، با مخزن موجود به عنوان یک «ورودی خام» برخورد می‌کند تا یک «بذر تأییدشده» (Verified Seed) بسازد. هدف این است که فقط دانشی که شایستگی بقا در نسخه بعدی را دارد، استخراج شود.

به نقل از گزارش dev.to، این فرآیند شامل یک فیلتر سخت‌گیرانه برای تصمیم‌گیری درباره موارد باقی‌مانده است:

• دانش‌های ماندگار (Knowledge to Keep): نیازمندی‌های محصول، قوانین دامنه، قراردادهای خارجی، موارد خاص (Edge Cases)، تضمین‌های رفتاری و باگ‌های تکرارپذیر.
• دانش‌های دورریختنی (Knowledge to Discard): انتزاع‌های وابسته به معماری خاص، راهکارهای موقت تاریخی (Workarounds)، مستندات جریان کاری منسوخ و تست‌هایی که به پیاده‌سازی گره خورده‌اند.

نتیجه، یک بذر تأییدشده است که از پیاده‌سازی قدیمی پاک شده اما تمام درس‌های آموخته‌شده در طول ساخت را حفظ کرده است. این کار همیشه مستلزم یک مخزن گیت جدید نیست؛ یک شاخه (Branch) تمیز، یک worktree یا یک فضای کاری ایزوله می‌تواند مرز زمینه (Context Boundary) لازم را ایجاد کند.

بازنشانی سه مرحله‌ای

پاک‌سازی سیستم فایل به تنهایی کافی نیست، زیرا «هارنس» (Harness) یا همان حالت پایدار عامل، اغلب شبح طراحی قدیمی را با خود حمل می‌کند. عامل ممکن است هنوز باور داشته باشد که یک ماژول خاص مسئولیت مشخصی دارد یا یک ویژگی باید از انتزاع خاصی استفاده کند. این راهنما سه بازنشانی متمایز را برای تضمین یک گسست کامل پیشنهاد می‌کند:

۱. بازنشانی مصنوعات (Artifact Reset): حذف تمام کدها و مستندات منسوخ از فضای کاری.
۲. بازنشانی زمینه (Context Reset): قطع پیوستگی با جلسات کاری قبلی برای پاک کردن حافظه کوتاه‌مدت.
۳. بازنشانی حافظه (Memory Reset): جداسازی یا حذف حالت‌های پایدار منسوخ پروژه، مانند خلاصه‌های عامل، فایل‌های حافظه یا دستورالعمل‌های پروژه.

تاریخچه قدیمی باید به عنوان یک آرشیو نگهداری شود، اما دیگر نباید بخشی از زمینه پیش‌فرض عامل جدید باشد. عامل جدید باید فقط سیستم جاری، نیازمندی‌های جاری، محدودیت‌های جاری و قراردادهایی را ببیند که باید صادق بمانند.

اعتبارسنجی بذر جدید

پس از ایجاد بذر تأییدشده، این راهنما هشدار می‌دهد که نباید اجازه داد عامل بلافاصله کد بنویسد. اولین دفعات نوشتن کد به عنوان لنگرهای قوی عمل می‌کنند؛ اگر عامل هنوز آلوده به مفروضات قدیمی باشد، آن خطاها را در بنیادهای جدید می‌بافد.

توالی توصیه‌شده به این صورت است: بذر تأییدشده $ \rightarrow $ زمینه تازه $ \rightarrow $ خواندن $ \rightarrow $ توضیح $ \rightarrow $ تأیید $ \rightarrow $ نوشتن. با مجبور کردن یک عامل تازه به خواندن بذر و توضیح سیستم برای توسعه‌دهنده، هرگونه «معماری شبح‌وار» که هنوز باقی مانده است، آشکار می‌شود. اگر مفروضات حذف‌شده در توضیحات ظاهر شوند، یعنی آلودگی هنوز وجود دارد.

نقش تست‌های رفتاری

تست‌ها ابزار اصلی برای جداسازی پیاده‌سازی از قرارداد در طول تقطیر هستند. نقش آن‌ها از پیشگیری ساده از رگرسیون به تعریف آنچه شایستگی بقا دارد تغییر می‌کند. این راهنما اشاره می‌کند تست‌هایی که روی فراخوانی‌های داخلی تمرکز دارند (مثلاً «سرویس A باید دقیقاً یک‌بار ریپازیتوری B را صدا بزند») تنها جزئیات پیاده‌سازی قدیمی را حفظ می‌کنند.

در مقابل، تست‌هایی که روی ناورداها (Invariants) تمرکز دارند، رفتار واقعی را حفظ می‌کنند که باید از بازطراحی جان سالم به در ببرد. مثال‌هایی از این تست‌ها عبارتند از:

• تضمین اینکه یک درخواست پرداخت یکسان، دو پرداخت ایجاد نکند.
• جلوگیری از دسترسی یک کاربر به داده‌های یک مستاجر (Tenant) دیگر.
• حفظ سازگاری با قراردادهای API خارجی.

اقتصاد جدید حذف

هوش مصنوعی هزینه تولید کد را کاهش داده است و این امر اقتصاد نگهداری نرم‌افزار را تغییر می‌دهد. در گذشته، دور ریختن ۱۰۰ هزار خط کد فعال می‌توانست به معنای ماه‌ها بازسازی باشد. اما اکنون، حفظ یک معماری معیوب از طریق لایه‌های سازگاری و مهاجرت‌ها، اغلب گران‌تر از استخراج دانش تأییدشده و بازسازی پروژه حول آن است.

در عین حال، زمینه (Context) بد گران‌تر می‌شود زیرا زاینده است. تصمیمات غلط می‌توانند کدهای جدیدی تولید کنند که سپس به زمینه برای نسل بعدی کدها تبدیل شوند.

برای پیاده‌سازی تقطیر پروژه، این راهنما یک مدل ۱۰ مرحله‌ای را پیشنهاد می‌کند:
۱. شناسایی یک تصمیم بنیادی تغییر یافته.
۲. تشخیص زمانی که زمینه قدیمی و جدید شروع به ترکیب شدن می‌کنند.
۳. استخراج نیازمندی‌ها، دانش دامنه، قراردادها و ناورداها.
۴. حذف مصنوعات وابسته به معماری قدیمی.
۵. حفظ رفتارهای مهم از طریق تست‌ها.
۶. ایجاد یک بذر تأییدشده.
۷. ایجاد یک مرز زمینه جدید.
۸. بازنشانی یا جداسازی زمینه و حافظه منسوخ عامل.
۹. اجازه دادن به یک عامل تازه برای درک بذر.
۱۰. تأیید درک عامل پیش از اجازه دادن به نوشتن کد.

این تمرین، هدف بنیادی بهداشت پروژه را تغییر می‌دهد. توسعه‌دهندگان اکنون باید نه تنها آنچه را که پروژه شامل می‌شود، بلکه آنچه را که هوش مصنوعی «مجاز به فراموش کردن» آن است مدیریت کنند. با پرداخت بدهی معرفتی، تیم‌ها می‌توانند پروژه‌های خود را به حالتی با سیگنال بالا و نویز کم بازگردانند، جایی که خروجی عامل توسط نیازمندی‌های جاری هدایت شود، نه اتفاقات تاریخی.

برای شروع، فایل‌های .md و حافظه عامل خود را برای یافتن نسخه‌های متضاد از معماری پروژه بازبینی کنید. اگر چندین سند معماری «نهایی» پیدا کردید، احتمالاً از زمینه مرده رنج می‌برید و کاندیدای اصلی برای تقطیر هستید.

گام بعدی شما

• فایل‌های .md و حافظه عامل خود را برای یافتن نسخه‌های متضاد از معماری پروژه بازبینی کنید.
• اگر بیش از یک سند «نهایی» برای معماری دارید، فوراً فرآیند تقطیر را آغاز کنید.
• تست‌های خود را از «تست پیاده‌سازی» به «تست رفتار» تغییر دهید تا بذر پروژه را ایمن کنید.

اما مدیریت این حافظه تنها بخشی از چالش است؛ برای درک اینکه چگونه پروتکل‌های جدید ارتباطی بین عامل‌ها این مشکل را حل می‌کنند، تحلیل ما درباره MCP را بخوانید.