Multi-file edit با AI

وقتی اول با ابزارهای AI برای کدنویسی آشنا می‌شی، احتمالاً اول روی تکمیل خودکار یه خط کد یا توضیح یه تابع متوقف می‌مونی. ولی خیلی زود می‌فهمی که مشکل واقعی توسعه‌نرم‌افزار این نیست، مشکل اینه که یه فیچر معمولاً پنج، ده، یا بیست فایل رو درگیر می‌کنه. اینجاست که «Multi-file edit» معنا پیدا می‌کنه.

Multi-file edit یعنی چی؟

ساده بگم: وقتی از AI می‌خوای یه کار کامل انجام بده (نه فقط یه تابع بنویس)، مثلاً «یه API endpoint برای ثبت‌نام کاربر اضافه کن که شامل مدل دیتابیس، سرویس، کنترلر، و تست باشه»، مدل باید همزمان چند فایل مختلف رو بخونه، درک کنه، و ویرایش هماهنگ بکنه. این یعنی Multi-file edit.

این کار از نظر فنی خیلی سخت‌تر از تکمیل کد در یه فایله. مدل باید:

• معماری کلی پروژه رو بفهمه
• وابستگی‌های بین فایل‌ها رو ردیابی کنه
• تغییرات رو به‌صورت منسجم روی چند فایل اعمال کنه
• با ایجاد تغییر در یک فایل، فایل‌های دیگه رو هم update کنه

چطور Cursor این کار رو می‌کنه

Cursor از نسخه‌های اخیرش یه قابلیت به اسم Agentic Composer داره. وقتی Agent mode رو فعال می‌کنی، Cursor یه حلقه داره: برنامه‌ریزی → اجرا → اعمال تغییر → احتمالاً ران کردن تست → تنظیم مجدد. این حلقه تا وقتی کار تموم بشه ادامه پیدا می‌کنه.

نقطه‌قوت Cursor اینه که رابط بصری داره، می‌تونی ببینی کدوم فایل‌ها تغییر کردن و diff رو مستقیم تأیید یا رد کنی.

چطور Aider این کار رو می‌کنه

Aider یه ابزار ترمینال‌محور اوپن‌سورسه که از GPT یا Claude استفاده می‌کنه. روش کارش جالبه: یه repo-map از کل پروژه می‌سازه، یه نقشه فشرده از ساختار کد، کلاس‌ها، توابع، و وابستگی‌ها. با این نقشه، مدل می‌تونه بدون اینکه کل کد داخل context بره، بفهمه تغییر در فایل A روی فایل B چه اثری داره.

Aider برای کاربری که راحت با ترمینال کار می‌کنه خیلی قدرتمنده؛ ولی یه چیز مهم ندی: حافظه بین session‌ها. هر بار که Aider رو باز می‌کنی، با یه پروژه‌شناس جدید طرفی که باید دوباره همه‌چیز رو از اول توضیح بدی.

محدودیت‌های واقعی Multi-file edit

این قابلیت‌ها قوی‌ان ولی کامل نیستن:

پنجره context: هر مدل یه محدودیت context داره. وقتی پروژه بزرگ می‌شه، نمی‌شه همه فایل‌ها رو همزمان داد مدل؛ باید انتخاب کرد. این انتخاب هوشمندانه یا دستی، کیفیت نتیجه رو تعیین می‌کنه.

خطاهای حلقوی: گاهی مدل در فایل A یه تغییر می‌ده که با فایل B ناسازگاره و یه bug جدید می‌سازه. بدون تست اتوماتیک، فهمیدن این مشکل سخته.

پروژه‌های بزرگ: در monorepo‌های بزرگ با ده‌ها ماژول، Multi-file edit بدون راهنمایی دستی اغلب از مسیر خارج می‌شه.

چرا «حافظه پروژه» فرق می‌کنه

همهٔ مشکلاتی که بالا گفتم یه ریشه مشترک دارن: مدل پروژهٔ تو رو نمی‌شناسه. می‌دونه چطور کد بنویسه، ولی نمی‌دونه معماری اون پروژهٔ خاص چیه، تصمیمات قبلی چی بودن، و چرا اون ساختار خاص انتخاب شده.

AiraCode این مشکل رو با حافظه پیوسته پروژه حل می‌کنه. وقتی هفته پیش درباره چرایی انتخاب یه معماری خاص توضیح دادی، AiraCode این رو یادداشت کرده، و وقتی امروز یه Multi-file refactor می‌خوای، همون context رو در نظر می‌گیره. این یعنی یه همکار، نه یه ابزار که هر بار باید از صفر آموزشش بدی.

یه سناریوی واقعی

فرض کن می‌خوای یه سیستم auth موجود رو از JWT به session-based تبدیل کنی. این کار شامل می‌شه:

• تغییر middleware
• به‌روزرسانی تمام endpoint‌هایی که token validate می‌کنن
• تغییر تست‌ها
• به‌روزرسانی مستندات API

با Cursor Agent یا Aider می‌شه این کار رو کرد، ولی باید هر بار context کامل بدی. با AiraCode، چون پروژه از قبل می‌شناسه، نقطه شروع خیلی بهتره.

در چه پروژه‌هایی Multi-file edit بیشترین ارزش رو داره؟

• Refactoring بزرگ: تغییر اسم یه entity در کل پروژه، تغییر signature یه تابع پرکاربرد
• اضافه کردن فیچر cross-cutting: چیزی مثل logging یا auth که باید به همه جای کد اضافه بشه
• Migration: مثلاً از یه ORM به ORM دیگه، یا از REST به GraphQL
• اضافه کردن تست: نوشتن تست برای کد موجود، فایل به فایل

همچنین بخوان

• کدنویسی با هوش مصنوعی چیست؟
• AiraCode چیست؟ معرفی کامل
• Aider چیست؟
• شناخت پیوسته در هوش مصنوعی