# Edit Formats & Architect/Editor Tiering — токен-экономные правки + распределение по моделям

## Принцип (2026-06-09, из разбора Aider)

Как именно агент кодирует правку файла — это **измеримый рычаг** стоимости, скорости и
надёжности, а не косметика. [Aider](https://aider.chat/docs/leaderboards/edit.html) эмпирически
показал, что один и тот же агент на одной модели даёт **разный pass-rate** в зависимости от
формата правок, и что разделение «планировщик / аппликатор» по двум моделям бьёт single-model.
Это правило кодифицирует выбор формата и маппит его на наш Generator-Evaluator + `/model`-tiering.

Источник: Aider edit-formats + architect/editor mode (Apache-2.0). Ложится на
[[practice_harness_design]] и skill `agent-harness-design`.

## 4 формата правок — когда какой

| Формат | Что это | Когда |
|---|---|---|
| **whole** | модель возвращает файл целиком | новые/мелкие файлы (<~50 строк); когда правок больше, чем нетронутого |
| **search/replace block** (diff) | блоки «найди ровно это → замени на это» (стиль git-конфликт-маркеров) | **дефолт для сильных моделей**; самый токен-экономный для точечных правок в больших файлах |
| **unified diff (udiff)** | стандартный `@@ … @@` патч | когда модель ленится и переписывает куски вместо точечных правок («lazy coding»); udiff дисциплинирует |
| **architect/editor split** | одна модель планирует правку прозой, вторая конвертирует в валидный diff | сложная правка + хочется сильную модель на «что», дешёвую на «как» |

В Claude Code наш нативный `Edit` tool = по сути **search/replace block** (`old_string`→
`new_string`, требование уникального совпадения). Это правило объясняет **почему** это дефолт и
когда отступать к whole (новый файл → `Write`) или к плану-первым (architect).

## Search/replace — дисциплина (почему наш Edit именно такой)

- `old_string` должен **точно** совпадать (включая отступы) и быть **уникальным** — иначе правка
  неоднозначна. Это не каприз tool'а, а защита от «правка ушла не туда» (см. Aider: большинство
  fail'ов слабых моделей — именно невалидный/неуникальный search-блок).
- Не возвращать файл целиком ради правки 3 строк — это токены + риск затереть несохранённое.
- Для нового файла — `Write` (whole), не Edit.

## Architect/Editor = наш Generator-Evaluator + `/model`-tiering

Aider'овский split — это **тот же паттерн**, что у нас, просто для конкретной операции «правка»:

- **Architect (planner)** = сильная модель (Opus): читает контекст, решает **ЧТО** менять,
  выдаёт план/прозу правки. Не обязана выдавать синтаксически валидный diff.
- **Editor (applier)** = дешёвая/быстрая модель (Sonnet/Haiku) или детерминированный аппликатор:
  превращает план в **валидные** search/replace-блоки. «Как», не «что».

Маппинг на наш стек:
- В **dynamic workflows**: `agent(planPrompt, {model: 'opus'})` → `agent(applyPrompt, {model: 'haiku'})`
  в pipeline. Дорогую модель тратим на рассуждение, дешёвую — на механику. (см. billing-дисциплину
  `workflow-orchestration`: рутинные стадии на меньшей модели.)
- В обычной сессии: `/model` повыше на план сложного рефактора → пониже на массовое применение
  однотипных правок.
- Это частный случай **Generator-Evaluator**: architect-плана недостаточно, пока editor реально
  не применил и правка не **верифицирована** (build/test/diff — proof-loop), а не «выглядит ок».

## Связь с CoT-выводами (2026-06-09)

Согласуется с [[feedback_communication_optimization]]: правка кода — «конститутивная» задача
(нужен явный проверяемый артефакт = сам diff). Здесь явная структура (search/replace, udiff)
причинно-несущая — в отличие от обычного рассуждения, где лучше дать модели свободу + бюджет.

## Anti-patterns
- ❌ whole-file rewrite ради точечной правки (токены + риск регрессии в нетронутом коде)
- ❌ неуникальный/неточный search-блок → правка уходит не туда (verify уникальность ДО)
- ❌ сильная дорогая модель на механическое применение 50 однотипных правок (трата бюджета)
- ❌ architect-план принят как «сделано» без applied+verified diff (нарушает proof-loop)

## Related
- skill `agent-harness-design` (references/agent-tool-design.md) — Edit/Write как typed tools; structured results
- `quality-over-tokens-independent-verify.md` — architect/editor = Generator-Evaluator на правках
- [[practice_proof_loop]] — diff применён И верифицирован, не «выглядит ок»
- [[feedback_communication_optimization]] — конститутивные задачи → явная структура полезна
