ایجنت کدنویسی Delta با نصف درخواست‌ها رقبای خود را به چالش کشید؛ رقابت با Codex و Claude Code

برابری عملکرد Delta با هارنس‌های بومی در تست‌های Zed

تیم توسعه‌دهنده ویرایشگر Zed به‌تازگی نتایج بنچمارک مربوط به Delta، ایجنت همکار کدنویسی خود را منتشر کرده است. بر اساس آزمایش‌های انجام‌شده، هارنس Delta در نرخ موفقیت حل تسک‌ها روی چهار مدل پیشرو، با Codex و Claude Code برابری کرده یا حتی از آن‌ها پیشی گرفته است؛ در حالی که هزینه آن به‌ازای هر تسک موفق بین ۰.۸۰ تا ۱.۱۲ برابر هارنس‌های بومی ثبت شده است. این گزارش بنچمارک همچنین مواردی را که معیارهای معمولِ نرخ قبولی نادیده می‌گیرند بررسی می‌کند: آرتیفکت‌های مخزن کد، فراخوانی‌های ناموفق ابزارها، تلاش‌های مجدد و زمان صرف‌شده.

کاهش مزیت انحصاری توسعه‌دهندگان مدل توسط Delta

تیم Zed مدل‌های GPT-5.6 Sol و GPT-6 Astra از OpenAI را در برابر Codex، و مدل‌های Claude Opus 5 و Claude Fable 5.1 را در برابر Claude Code مورد ارزیابی قرار داد. هر چهار مقایسه از بنچمارک Terminal-Bench 2.1 بهره برده‌اند؛ مجموعه‌آزمونی که توانایی یک ایجنت را در تکمیل تسک‌های مبتنی بر ترمینال می‌سنجد.

در میان این چهار مدل، هزینه گزارش‌شده Delta به‌ازای هر تسک موفق بین ۰.۸۰ تا ۱.۱۲ برابر نتیجه هارنس‌های بومی بوده است. هزینه به‌ازای هر قبولی، هم هزینه‌های پردازش استنتاج مدل و هم تعداد تسک‌های موفق را در بر می‌گیرد.

برای مدل متن‌باز Kimi K3، شرکت Zed از مجموعه ۳۰ تسکی FrontierHarness استفاده کرد. بر اساس این گزارش، Delta از نظر نرخ قبولی از سایر هارنس‌های بررسی‌شده بهتر عمل کرد و در عین حال از نظر هزینه نیز رقابتی باقی ماند.

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

نقش کلیدی هارنس در نحوه اجرای فرایندها

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

شرکت‌های توسعه‌دهنده مدل می‌توانند سیستم‌های خود را همگام با هارنس‌های اختصاصی‌شان آموزش دهند و تنظیم کنند و خطاهای داخلی را بررسی نمایند. شرکت‌های ارائه‌دهنده ابزارهای توسعه به چنین دسترسی‌هایی مجهز نیستند؛ بنابراین دستیابی به نتایجی قابل مقایسه نشان می‌دهد که معماری و طراحی هارنس می‌تواند بخشی از برتری ذاتی سازندگان مدل را جبران کند.

پنهان ماندن کیفیت پیاده‌سازی در سایه نمره قبولی

بنچمارک Terminal-Bench تنها بررسی می‌کند که آیا محیط به وضعیت نهایی مورد انتظار رسیده است یا خیر. این شیوه نمره‌دهی ممکن است به ایجنت‌هایی که کدهای کاملاً متفاوتی در مخزن بر جای می‌گذارند، نمره قبولی یکسانی بدهد.

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

محاسبه نشدن تلاش‌های مجدد در نمره‌دهی نهایی

بر اساس گزارش Zed، هارنس‌ها می‌توانند فراخوانی‌های ناموفق ابزارها را درون خود جذب و پیش از دستیابی به نتیجه نهایی مجدداً تکرار کنند؛ موضوعی که باعث می‌شود معیارهای مبتنی بر نرخ قبولی، تعداد درخواست‌های اضافی و تأخیر ناشی از آن را نادیده بگیرند. این شرکت نرخ شکست فراخوانی ابزار در Claude Code را بالا توصیف کرده و نرخ خطای Delta را روی مدل‌های Anthropic حدود ۱.۵ درصد اندازه‌گیری کرده است. همچنین Zed اعلام کرده هر دو هارنس توکن‌های مدل را با سرعتی یکسان دریافت می‌کنند و بخش عمده تأخیرِ محسوس برای کاربران ناشی از اجرای ابزارها و مدیریت تلاش‌های مجدد است.

سیستم DeltaDB تاریخچه نسخه‌های فایل و اقدامات پیشین ایجنت را ذخیره می‌کند. هنگامی که یک تغییر نرم‌افزاری (Patch) با دو خط کاملاً مشابه تطابق داشته باشد، این کانتکست به Delta کمک می‌کند تا خط مورد نظر را به‌درستی انتخاب کند. همچنین اگر یکی از اعضای تیم پس از خوانده شدن فایل توسط مدل، خطی را ویرایش کند، Delta محتوای قدیمی‌شده را تشخیص داده و پیش از اعمال ویرایش، به مدل دستور می‌دهد فایل را مجدداً مطالعه کند.

کاهش ۵۰ درصدی تعداد درخواست‌ها در یک تسک نمونه

در یکی از تسک‌های Terminal-Bench که به شمارش توکن‌ها در یک مجموعه داده Hugging Face اختصاص داشت، مدل GPT-6 Astra این وظیفه را از طریق هر دو بستر Codex و Delta به انجام رساند. با این حال، لاگ‌های اجرای این دو در تعداد درخواست‌ها، مدیریت دستورات و مدت‌زمان کل تفاوت‌های محسوسی داشتند.

شرکت Zed این تفاوت چشمگیر را ناشی از ابزار ترمینالی می‌داند که منتظر اتمام اجرای دستورات می‌ماند، در برابر هارنسی که می‌تواند عملیات‌های مستقل را به‌شکل هم‌روند و موازی به اجرا درآورد. در این مثال، Delta به هفت درخواست کمتر و ۳۲ ثانیه زمان کوتاه‌تر نیاز داشت؛ هرچند بنچمارک Terminal-Bench هر دو اجرا را با نتیجه قبولی یکسان ارزیابی کرد.

معیارهای جامع‌تر برای ارزیابی عملکرد ایجنت‌ها

انتخاب یک ایجنت کدنویسی نیازمند معیارهایی است که چرخه کامل توسعه نرم‌افزار را در بر بگیرد؛ از جمله قابلیت اطمینان، تأخیر و کیفیت کدهای ثبت‌شده. معیارهای ارزیابی کاربردی عبارت‌اند از:

• موفقیت در تسک: نرخ قبولی در مخازن کد استاندارد و در طول اجراهای مکرر.
• بهره‌وری هزینه: مجموع هزینه صرف‌شده به‌ازای هر تسک موفق، با احتساب تلاش‌های ناموفق و تکرارها.
• میزان تأخیر: زمان واقعی سپری‌شده، تعداد درخواست‌ها به مدل، فرآیندهای Polling و زمان انتظار برای دستورات.
• پایداری ابزارها: ویرایش‌های ناموفق، فراخوانی‌های ردشده، خواندن داده‌های قدیمی و توانایی بازیابی از خطا.
• کیفیت خروجی مخزن: کدهای قابل بازبینی، تست‌ها، اسکریپت‌های قابل بازتولید و حداقل نیاز به پاکسازی مجدد.
• همکاری تیمی: نحوه عملکرد زمانی که فایل‌ها در حین اجرا تغییر می‌کنند یا چندین برنامه‌نویس کدهای مرتبط را ویرایش می‌نمایند.

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

تیم Zed اعلام کرده است که ارزیابی‌های آتی این شرکت فراتر از Terminal-Bench خواهد رفت و بر چرخه ویرایش تعاملی و هم‌زمان تمرکز خواهد داشت؛ بستری که Delta به‌طور ویژه برای آن طراحی شده است. تسک‌هایی شامل ویرایش‌های هم‌روند، مدیریت تغییرات فایل‌ها و پچ‌های قابل بازبینی می‌توانند این ادعاها را به چالش بکشند. در چارچوب بنچمارک‌های فعلی، نتایج نشان می‌دهند که انتخاب هارنس می‌تواند حتی در صورت ثابت ماندن مدل زیربنایی، نرخ تکمیل تسک، هزینه، تأخیر و کیفیت خروجی پروژه را به‌کلی دگرگون کند.