Программирование с ИИ
ENRU
3.13

Приём — ограничить зону правок

чем меньше трогаем, тем легче проверять

Что это

По умолчанию ИИ считает, что может менять всё, до чего дотянется. Попросил починить функцию — заодно переименованы переменные в соседней, переставлены импорты и «улучшена» обработка ошибок там, где никто не просил.

Приём состоит в том, чтобы назвать границы заранее. Выгода не в аккуратности, а в проверяемости: дифф на десять строк ты прочитаешь, дифф на двести — нет. А непрочитанный дифф — это код, который ты не контролируешь.

Как выглядит в коде

Схема из книги — будет перерисована для сайта
Чем уже зона, тем меньше дифф и тем вероятнее, что ты его действительно прочитаешь.

Фразы, которые работают

Запрос
Меняй только функцию format_report. Остальной файл не трогай.
Запрос
Правки только в handlers/weather.py. Если понадобится менять
что-то ещё — скажи, но не делай.
Запрос
Импорты, форматирование и имена существующих переменных
не трогай. Только логика внутри указанной функции.

Третья формулировка снимает самый частый источник шума: ИИ любит переставлять импорты и «причёсывать» стиль, и эти изменения занимают в диффе больше места, чем настоящая правка.

Вторая половина приёма

Ограничить зону мало — надо дать выход, если границы окажутся неверными:

Лучше
Меняй только fetch_weather. Если задачу невозможно решить,
не трогая остальное, — остановись и скажи, что ещё нужно менять
и почему. Не делай этого сам.

Без этой фразы ИИ, упёршись в ограничение, либо нарушит его молча, либо выдаст решение похуже, лишь бы уложиться в границы. С ней он спросит — и ты решишь сам.

Как сказать ИИ

Границы бывают трёх размеров

ЗонаКогдаКак сказать
Функцияточечная правка, баг«только функция X»
Файлфича в одном месте«правки только в файле Y»
Набор файловсвязанное изменение«можно трогать A, B и C, остальное нет»

Начинай с самой узкой, которая кажется достаточной. Расширить по просьбе ИИ легко, сузить после того, как он переписал полпроекта, — нет.

Проверка границ по диффу

После правки первым делом смотри не на содержание, а на размер:

git diff --stat

Одна строка вывода вместо ожидаемой одной — хорошо. Семь изменённых файлов там, где ждал один, — сигнал остановиться и прочитать внимательно, что бы там ни было написано в ответе.

На что смотреть

Границы нарушены молча. Проверяется не чтением ответа, а git diff --stat. В тексте ответа ИИ обычно пишет, что сделал только просимое.

Переставлены импорты, изменено форматирование. Само по себе безвредно, но раздувает дифф и прячет в нём настоящие изменения. Запрещай отдельной строкой.

Границы оказались слишком узкими. Если ИИ трижды подряд сообщает, что задачу не решить в заданных рамках, — он, скорее всего, прав. Расширь зону осознанно, а не отменяй ограничение целиком.

Правка размазана по файлу. Даже внутри разрешённой зоны изменения могут оказаться в десяти местах вместо одного. Проси: «сделай изменение в одном месте, а не правь в нескольких».

Шпаргалка

  • Называй зону заранее: функция · файл · набор файлов.

  • Начинай с самой узкой; расширить легче, чем откатить.

  • Отдельно запрещай трогать импорты и форматирование.

  • Всегда добавляй: «не получится — скажи, а не делай сам».

  • Проверяй границы через git diff --stat, а не по ответу ИИ.

  • За непрочитанный дифф отвечаешь ты.