‏ایجنت‌های کدنویسی چطور فایل‌ها رو ویرایش می‌کنن

نویسنده می‌گه نوشتن تغییرات روی دیسک بیشتر از خطای استدلال مدل، ایجنت‌ها رو زمین می‌زنه. مدل‌های زبانی خط نمی‌شمرن و فقط توکن بعدی رو پیش‌بینی می‌کنن. برای همین وقتی ازشون unified diff می‌خوای (همون فرمت git diff که بالای هر تیکه شماره خط شروع و طولش رو می‌نویسه)، یه خط اشتباه کافیه تا patch رد بشه. طبق بنچمارک‌های Aider، اجبار مدل‌ها به unified diff سخت‌گیرانه نرخ موفقیت رو روی فایل‌های پیچیده از 59٪ به 26٪ رسوند.

مشکلات دیگه هم هست: مدل جای کد موجود کامنتی مثل «بقیهٔ کد تغییری نکرده» می‌ذاره و نوشتنش روی دیسک کد رو پاک می‌کنه؛ اختلاف tab و space تو Python یا YAML تطبیق رشته رو خراب می‌کنه؛ بازنویسی یه فایل 1,500 خطی برای تغییر سه خط حدود 5,000 توکن و 15 تا 25 ثانیه وقت می‌گیره؛ و تو سیستم‌های چندایجنتی ممکنه یه ایجنت تغییرات اون یکی رو رونویسی کنه.

رایج‌ترین راه، بلوک‌های search/replace هست. تو فرمت Aider، مدل اول کد قبلی و بعد کد جدید رو می‌نویسه و ابزار متن قبلی رو تو فایل پیدا و جایگزین می‌کنه:

<<<< SEARCH
export function verifyToken(token: string) {
  return jwt.verify(token, SECRET);
}
====
export function verifyToken(token: string) {
  if (!token) throw new AuthError("Token required");
  return jwt.verify(token, SECRET);
>>>> REPLACE

طبق بنچمارک‌های Aider، برای فایل‌های بالای 400 خط این روش ده برابر توکن کمتری مصرف می‌کنه (200 تا 500 توکن در برابر 4,000 تا 6,000). ابزار Edit تو Claude Code هم با str_replace همین کارو می‌کنه، با یه قانون سخت: old_str باید فقط به یه جای فایل بخوره، وگرنه درخواست رد می‌شه و مدل باید خط‌های اطراف بیشتری بده. OpenCode هم که به گفتهٔ نویسنده تطبیق دقیقش 20 تا 30 درصد مواقع شکست می‌خوره، یه matcher نه‌مرحله‌ای داره که قدم‌به‌قدم سخت‌گیری رو کم می‌کنه.

برای مشکل هم‌زمانی، ابزار Oh My Pi از Hashline استفاده می‌کنه: هر بار خوندن فایل یه hash چهاررقمی می‌گیره و اگه فایل قبل از ویرایش عوض شده باشه، patch رد می‌شه. برای عوض‌کردن یه تابع کامل هم Tree-sitter (یه پارسر که ساختار کد رو می‌فهمه) آخر بلوک رو پیدا می‌کنه تا مدل مجبور نباشه شماره خط بشمره. DeepSeek Harness هم برای ارزیابی SWE-bench ابزارها رو به persistent_bash و str_replace_editor محدود کرده.

سریع‌ترین روش، جدا کردن فکر کردن از ویرایشه. تو Instant Apply در Cursor، مدل اصلی فقط یه تیکهٔ خلاصه می‌نویسه و یه Llama-3-70B فاین‌تیون‌شده اونو تو فایل ادغام می‌کنه. چون 95٪ فایل عوض نمی‌شه، از speculative decoding استفاده می‌شه (یعنی فایل اصلی حدس اولیهٔ خروجی حساب می‌شه و موازی تأیید می‌شه) و سرعت به حدود 1,000 توکن در ثانیه می‌رسه. Morph هم می‌گه مدلش با دقت 98٪ در 6 ثانیه کار می‌کنه، در حالی که str_replace معمولی 86٪ دقت و 35 ثانیه زمان داره.

نکات کلیدی:

• unified diff سخت‌گیرانه تو بنچمارک Aider موفقیت رو از 59٪ به 26٪ رسوند.
• برای فایل‌های بالای 400 خط، search/replace حدود ده برابر توکن کمتری از بازنویسی کامل مصرف می‌کنه.
• old_str تو ابزار Edit در Claude Code باید دقیقاً یه جای فایل رو پیدا کنه.
• Hashline تو Oh My Pi با hash چهاررقمی جلوی ویرایش روی نسخهٔ قدیمی فایل رو می‌گیره.
• Morph Fast Apply دقت 98٪ در 6 ثانیه گزارش کرده، در برابر 86٪ و 35 ثانیه برای str_replace.