Inline Edit решает узкую задачу: изменить выделенный фрагмент по короткой инструкции, не поднимая полноценный агентный цикл. Выделяете код, вызываете окно правки, пишете, что нужно, - и получаете предложение прямо на месте. Смысл инструмента в том, что контекст уже виден вам обоим: не нужно объяснять, где находится код, и не нужно платить за поиск по репозиторию. Экономия здесь не только в секундах и деньгах. Выделение работает как готовая и точная формулировка границы задачи: модель не догадывается, что именно вы имели в виду, - вы это показали.
Наивное использование выглядит так: раз это удобное окно, пусть оно делает всё. Через несколько попыток обнаруживается, что инструкции вроде найди все места, обнови зависимости или прогони тесты либо не выполняются, либо выполняются частично и странно. Это не недоработка: локальная правка по определению работает с тем, что выделено, и не отвечает за согласованность изменений по дереву. Частичное выполнение опаснее отказа: отказ виден сразу, а половина изменения выглядит как результат и уезжает в коммит вместе с остальным.
Граница проходит по слову распределённый. Пока задача укладывается в видимый фрагмент - изменить сигнатуру, упростить условие, добавить обработку крайнего случая, переписать текст сообщения - Inline Edit быстрее и точнее агента: меньше контекста, меньше свободы, меньше шансов уйти в сторону. Как только в формулировке появляется несколько модулей, поиск, терминал или проверка, это уже работа для агента или плана. Притворяться, что перед вами локальная правка, вредно по конкретной причине: маленькое окно показывает ровно тот кусок, который вы выделили, и тем самым скрывает реальный размер изменения.
Полезно один раз увидеть, как выглядит хорошая инструкция для такого окна. Ниже - пример: сохранить публичную сигнатуру, убрать дублирование внутри функции, не менять формат ошибок и добавить тест только на новый крайний случай. Она короткая, но в ней есть всё, что нужно: цель, явные границы и критерий, по которому видно, что сделано лишнее.
Границы в такой инструкции - не формальность, а способ удержать правку локальной. Фраза не меняй формат ошибок стоит одну строку, а экономит разбор diff, где вместе с полезным изменением приехала смена контракта. Это тот же контракт задачи, что и в большой работе, только сжатый до двух предложений: чем меньше окно, тем важнее назвать, чего делать не нужно. Причина в асимметрии внимания: полезную часть правки вы ищете глазами и находите сразу, а лишнюю замечаете позже, когда на неё уже кто-то опёрся.
Рядом стоят два соседних жеста, которые стоит различать. Быстрый вопрос по выделению сам по себе код не меняет - он объясняет, и это правильный первый шаг, когда фрагмент непонятен; предложенную им правку применяют отдельной короткой командой. Перенос выделения в агента, наоборот, признаёт, что задача переросла окно: нужен поиск, терминал или несколько файлов. Осознанный переход между этими тремя режимами и есть навык: сначала понять, потом поправить локально, и только при необходимости поднимать агента. Обратный порядок стоит дороже всего: правка непонятого кода даёт diff, который потом приходится объяснять себе задним числом.
Типичный случай выглядит так. В функции разрослось условие: четыре ветки, две из которых отличаются одной проверкой. Задача читается целиком в пределах экрана, публичный контракт менять не нужно, вызывающая сторона не затронута - это ровно тот размер, ради которого окно и сделано. Инструкция здесь занимает строку: свести ветки, сохранив поведение на всех входах. А соседняя формулировка про обновление всех, кто эту функцию вызывает, переводит задачу в другой класс, потому что вызывающие места не выделены и вы их не видите.
Окно правки стоит отличать и от подсказки при наборе. Подсказка угадывает продолжение вашего действия и не требует формулировки; окно правки исполняет названное намерение и потому уместно там, где вы уже знаете, чего хотите, но набирать это руками дольше, чем объяснить. Признак, по которому в реальной работе видно, что инструмент выбран неверно, один: вы открываете окно второй и третий раз подряд на соседних фрагментах, дописывая одно и то же. Значит, изменение по природе не локальное, и ставить его надо как задачу целиком.
Инженерный вывод простой: Inline Edit - инструмент точности, а не мощности. Его ценность в том, что он ограничен, и терять это ограничение ради удобства не стоит. Каждый раз, когда рука тянется написать в маленькое окно большую задачу, полезно спросить себя, видно ли всё, что изменится, - если нет, это работа для другого режима.
Типичные провалы предсказуемы. Просить локальное окно согласовать несколько модулей и получить половину изменения. Не назвать границы и обнаружить в diff смену контракта рядом с полезной правкой. Использовать правку там, где нужен был вопрос: код меняется раньше, чем вы поняли, зачем он такой. И наоборот - поднимать агента ради переименования переменной в выделенном блоке.
Сохрани публичную сигнатуру. Убери дублирование внутри функции,
не меняй формат ошибок и добавь тест только для нового крайнего случая.