واقعیت اینه که ساختن ایجنت‌های کدنویس که واقعا به درد بخورن، یه چالش کلیدی داره: نحوه‌ی اعمال تغییرات. به جای بازنویسی کامل فایل‌ها که هم کند و سنگینه و هم ریویو کردنش عذابه، باید روی تولید diff تمرکز کنیم. یعنی ایجنت باید یاد بگیره یک patch تمیز و مینیمال تولید کنه که بشه راحت با git اعمالش کرد و کنترلش کرد.

مسئله اصلی اینه که مدل‌های زبانی بزرگ، با پیش‌بینی توکن به توکن، مجبور میشن کل فایل رو از اول بنویسن. این کار هم توکن زیادی مصرف می‌کنه و هم پنجره‌ی خطا رو بزرگتر می‌کنه. راه حلش، آموزش مدل روی patch-level هست. یعنی مدل یاد می‌گیره به جای توکن بعدی، patch بعدی رو پیش‌بینی کنه. این روش هزینه‌های آموزش رو تا ۵۰٪ کم می‌کنه و خروجی‌ای تولید می‌کنه که مستقیم با git apply کار می‌کنه.

چندتا الگوی طراحی مهم از مقالات اخیر که میشه ازشون استفاده کرد:

* آموزش در سطح پچ: ایده اینه که مدل رو جوری train کنیم که به جای next token، یک patch کامل رو در فرمت unified-diff پیش‌بینی کنه. این کار خروجی رو با ورک‌فلوی توسعه‌دهنده‌ها هماهنگ می‌کنه.

* پرامپت‌نویسی ساختاریافته: برای دقت بالاتر در پیدا کردن محل تغییر، میشه از پرامپت‌های دو بخشی مثل ⟨where, what⟩ استفاده کرد. مثلا به مدل میگی @@ line 42 @@ REPLACE …. این ساختار به مدل کمک می‌کنه دقیقاً بفهمه کجا و چه چیزی رو باید تغییر بده.

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

* تعمیر خودکار باگ: به جای اینکه فقط باگ رو به مدل بدیم، باید خروجی تست‌های fail شده و stack trace ها رو هم به عنوان کانتکست اضافه کنیم. این کار به مدل اجازه میده هم محل باگ رو پیدا کنه و هم خودش patch مناسب رو تولید کنه.

* افزودن هدر: یه ترفند ساده ولی موثر اینه که تو پرامپت از هدرهای diff مثل --- a/foo.py\n+++ b/foo.py استفاده کنیم. این کار به طرز چشمگیری نرخ موفقیت تغییرات چندفایلی رو بالا می‌بره.

مقایسه ابزارهای معروف تو این زمینه هم جالبه:
* Cursor:
این ابزار به خوبی diff رو پیاده‌سازی کرده. تغییرات رو به شکل side-by-side نشون میده و به راحتی میشه هر تیکه (hunk) رو اعمال یا رد کرد. تمام تغییرات رو به شکل commit های تدریجی ذخیره می‌کنه و rollback خیلی ساده‌ست.
* VS Code + Copilot:
متاسفانه Copilot هنوز در سطح بازنویسی کل فایل کار می‌کنه. این باعث میشه diff های شلوغ و کندی تولید کنه و خیلی‌ها برای دیدن تغییرات مجبورن از ابزارهای جانبی استفاده کنن.
* Windsurf:
برای تغییرات چندفایلی و ریفکتورینگ‌های بزرگ تحسین شده، چون کانتکست گلوبال بهتری داره. diff ها رو مستقیم به فرمتی تبدیل می‌کنه که با git سازگاره.

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

📃 مقاله آموزش در سطح پچ:
https://arxiv.org/abs/2407.12665

📃 مقاله FineEdit برای ویرایش دقیق:
https://arxiv.org/html/2502.13358v1

📃 مقاله Coeditor برای کانتکست ریپازیتوری:
https://arxiv.org/html/2305.18584v2

🛠 Join @LLMEngineers Community