Подготовительный рефакторинг

Preparatory refactoring — это когда сначала рефакторишь код, чтобы упростить будущие изменения, а потом уже делаешь сами изменения. Рефакторинг может быть сложным, но поскольку он сохраняет функциональность, его проще ревьюить, чем изменения логики.

Современные LLM без четкого плана не умеют декомпозировать изменения таким образом — они пытаются сделать все сразу. Иногда они еще и переусердствуют, как тот инженер-перфекционист, который слишком серьезно воспринял "правило бойскаута" и начинает чистить весь код подряд, пока вносит изменения. Поскольку ревью изменений от LLM критично важно, весь рефакторинг должен происходить заранее в отдельных PR'ах.

В идеале нужно просто запретить LLM делать посторонний рефакторинг (хотя Cursor Sonnet 3.7 плохо следует таким инструкциям, так что это не всегда работает). Альтернатива — сделать предварительный проход по коду, который LLM планирует изменить, дать ей шанс "навести красоту", а потом уже делать основные изменения. Иногда проблему усугубляет контекст с best practices (например, "код должен иметь type annotations") — модель может решить добавлять аннотации везде. Помогает четко ограничить область кода, которую LLM должна редактировать.

Примеры

• Попросил LLM исправить import error после моих локальных изменений. Она починила импорт, но заодно решила добавить type annotations к нетипизированным лямбдам в файле. Мало того что это было не нужно — она еще и одну аннотацию сделала неправильно, что привело к "танцам с бубном" при исправлении.