Hashline vs Replace：編集形式は重要なのか？

内容

Can Bölükのハーネスの問題では、コーディングエージェントにおいて、hashline方式の編集（4#WBのように行番号をアンカーにする方式）が、従来のreplaceモードの編集（old_string/new_stringのマッチング）を上回ることが示されていました。私は独自のハーネス（tau）を試作していて、この結果を検証し、そこでhashlineをデフォルトの編集戦略として検討すべきか確かめたいと思いました。そこで、複数の言語とモデルで自分でも検証するために、edit-benchを作りました。

実験設定

edit-benchは、既存のコードベースからミューテーションに基づくテストを生成します。スクリプトにディレクトリを指定すると、文の削除、真偽値の反転、引数の入れ替えなどのミューテーションを生成します。

言語: Python（hiveから）、TypeScript（oh-my-piから）、Rust（irradiateから）
モデル: gpt-4.1-mini, google/gemini-3-flash-preview, qwen/qwen3.5-397b-a17b
編集モード: replace（old_string/new_string）とhashline（行番号をアンカーにする方式）
各言語20タスク、試行は1回のみのワンショット実行
最近、tauにファジーマッチング（段階的なトリム処理: trim_end → trim_both → unicode normalization）も追加したので、これが役立つかどうかも確かめたくなりました

結果

Replaceモード:

モデル	Python	TypeScript	Rust
gemini-3-flash	95%	80%	95%
qwen3.5-397b	90%	85%	85%
gpt-4.1-mini	65%	75%	45%

Hashlineモード（以前の実行結果より）:

モデル	Python	TypeScript	Rust
gemini-3-flash	70%	85%	90%
qwen3.5-397b	85%	85%	90%
gpt-4.1-mini	50%	70%	55%

HashlineではPythonの成績が明らかに下がり、TypeScriptとRustではほぼ差がないようです。この言語依存性は興味深い点です。Pythonでは空白が意味を持つため、行をアンカーにする編集でミスが起きやすくなるのかもしれません。

ファジーマッチングは役立つのか？

どうやら役立たないようです。

段階的なトリム処理によるtauのファジーマッチングが、replaceモードでの実行中に発動することがあるのかを調べるため、トレース収集を追加しました。成功した編集114件と失敗した編集20件（3モデル × 3言語）を通じて、ファジーマッチングの発動は0回でした。

失敗した編集20件の内訳は次のとおりです。

1件は末尾に空白がありました（理論上は修正可能）
約8件はold_stringに行番号を含めていました（モデルのバグ）
約11件は完全に架空の内容でした

モデルがold_stringを正しく再現できるときは、空白も正しく再現できます。間違えるときは大きく間違えるので、トリム処理を段階的に適用しても役に立ちません。

（トレース分析の詳細）

わかったこと

Hashlineとreplaceのどちらかが明確に優れているわけではありません。 影響は言語とモデルによって変わります。Pythonではhashlineが不利で、TypeScriptでは差がなく、Rustでは優劣をつけられません。
Canの結果を一般化するのは難しいです。 react-edit-benchmarkはJavaScriptのみを対象とし、検証のフィードバックにLSPを使っています。私たちの実験設定（LSPなし、複数言語）では、違う傾向が見られます。特に、LSPのフィードバックループは交絡要因になっている可能性が高いです。型エラーをモデルに渡して再試行できるようにすると、性能が実質的に向上し、編集形式との相互作用も生じます。
現在のモデルでは、ファジーマッチングが必要になる問題は実質的にありません。 LLMはソースのテキストを正確に再現するか、ハルシネーションでまったく別のものを生成するかのどちらかです。ファジーマッチングが対象とする、空白だけが少し違うケースは、実際にはほぼ起きません。
現在のハーネスと現行世代のモデルの組み合わせでは、編集形式はボトルネックではありません。 モデル間の差（gemini-3-flashは90%以上、gpt-4.1-miniは55〜65%）は、編集形式間の差をはるかに上回ります。編集形式を気にする前に、モデル選択とプロンプトエンジニアリングに力を注ぎましょう。

お決まりの注意書きですが、サンプル数は少なく、統計的に厳密ではないので、その点を踏まえて受け止めてください。

全データ: nwyin/edit-bench、Issue #13と#14。