AI-патч как проверка стоимости задачи до начала разработки

Что именно проверяет AI-патч

AI-патч — это изменение в изолированной рабочей копии, которое модель готовит не для немедленного слияния, а для исследования задачи. Оно должно пройти достаточно далеко, чтобы проявились затронутые файлы, интерфейсы, тесты и неоднозначности. При этом работа останавливается до полировки, длительных прогонов и публикации.

Это разновидность инженерного зонда. Команда временно заменяет вопрос «сколько это займёт?» на четыре более проверяемых вопроса:

1. Как распространяется изменение? Какие слои, файлы и контракты пришлось затронуть?
2. Как доказать корректность? Можно ли написать локальные проверки, или результат виден только в собранной системе?
3. Что может сломаться? Есть ли данные, совместимость, конкурентный доступ, безопасность или внешние потребители?
4. Что останется после релиза? Появятся ли новый режим, ветвление поведения, конфигурация, метрики или постоянная обязанность поддержки?

Ценность метода не в скорости генерации кода. Её создаёт раннее столкновение гипотезы с устройством репозитория. AI вынужден найти точки входа, прочитать соседние реализации и попытаться провести изменение через существующие границы. Даже несовершенная попытка часто показывает больше, чем обсуждение по названию задачи.

Почему это не обычная оценка задачи

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

Метод особенно полезен для задач, которые звучат локально:

• добавить необязательное поле;
• показывать дополнительный статус;
• изменить правило валидации;
• поддержать ещё один формат импорта;
• разрешить повтор операции;
• добавить настройку на уровне проекта;
• передавать новый параметр во внешний сервис.

В таких формулировках скрывается число границ, которые пересекает изменение. Новое поле может существовать одновременно в форме, клиентском типе, HTTP-запросе, серверном валидаторе, доменной модели, таблице, событии и экспорте. Каждая граница увеличивает не только первоначальную работу, но и пространство будущих ошибок.

Проба также отделяет неопределённость от объёма. Большой, но механический diff может быть предсказуемым. Пять строк внутри плохо определённого правила доступа могут быть маленьким diff с высокой неопределённостью. Эти случаи нельзя оценивать одной цифрой.

Конкретный кейс: комментарий к доставке заказа

Рассмотрим учебную задачу без привязки к реальному клиенту: «Добавить необязательный комментарий к доставке. Пользователь вводит его при создании заказа, оператор видит его в карточке».

На встрече такая задача легко превращается в спор. Один разработчик представляет текстовое поле и две строки шаблона. Другой вспоминает базу данных. Третий предполагает, что комментарий должен попасть в интеграцию доставки. Продуктовый менеджер ещё не решил, разрешено ли редактирование после создания заказа.

Исходное предположение

Для пробы фиксируем минимальную трактовку:

• поле называется delivery_note;
• поле необязательное;
• длина — не более 500 символов;
• значение задаётся только при создании заказа;
• оператор видит его в существующей карточке;
• внешней службе доставки значение пока не передаётся;
• пустая строка нормализуется в null;
• старые заказы продолжают читаться без изменений.

Это не окончательные требования. Это контролируемая гипотеза, достаточная для зонда. Нерешённые вопросы записываются отдельно и не маскируются случайными решениями модели.

Каким может оказаться след изменения

После чтения репозитория пробный патч может затронуть:

• тип формы создания заказа;
• компонент ввода;
• клиентский сериализатор запроса;
• серверную схему валидации;
• доменный объект заказа;
• миграцию базы данных;
• репозиторий чтения и записи;
• ответ карточки заказа;
• компонент отображения;
• модульные и интеграционные проверки.

Если это действительно обнаружено в коде, разговор меняется. Команда обсуждает не абстрактное «поле», а изменение, которое проходит через несколько контрактов и имеет конкретные открытые решения.

Что нельзя выдавать за результат

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

Что должно остаться после проверки

Хорошая проба заканчивается не сообщением «AI справился», а небольшим пакетом доказательств:

1. Постановка. Зафиксированные границы задачи и принятые для пробы допущения.
2. Патч. Неслитое изменение в отдельной ветке или рабочей копии.
3. Статистика. Файлы, строки, модули и типы изменений.
4. Карта контрактов. Интерфейсы, форматы, данные и потребители, которых касается изменение.
5. План проверок. Какие свойства можно доказать автоматически, а какие требуют ручной проверки.
6. Журнал неопределённостей. Вопросы, на которые репозиторий не дал ответа.
7. Карточка стоимости. Итог по объёму, тестируемости, риску и сопровождению.
8. Решение. Разрабатывать, сначала уточнить требования, разбить задачу или отказаться.

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

Подготовка безопасной копии

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

git status --short
git branch --show-current
git rev-parse HEAD

Если рабочее дерево не чистое, не удаляйте изменения. Создайте отдельный Git worktree от нужной базовой ревизии:

git worktree add ../cost-probe-delivery-note -b probe/delivery-note HEAD
cd ../cost-probe-delivery-note
git status --short

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

Перед работой определите границу полномочий:

• не публиковать ветку и не создавать pull request;
• не менять рабочие данные;
• не выполнять миграцию на общей базе;
• не обращаться к внешним сервисам с настоящими учётными данными;
• не добавлять новые зависимости без отдельного обоснования;
• не обновлять lock-файл зависимостей, если задача этого не требует;
• не исправлять соседние проблемы, обнаруженные по пути;
• остановиться по истечении лимита времени.

Если проект требует сервисов, используйте локальные заглушки, тестовые контейнеры или существующий sandbox. Цель — прочитать архитектуру и построить diff, а не воспроизвести рабочую инфраструктуру любой ценой.

Короткое задание для AI

Не просите «реализовать функцию полностью». Такое задание поощряет модель закрывать пробелы догадками и полировать код. Опишите исследовательский результат.

Цель: подготовить ограниченный пробный патч для оценки задачи.

Задача:
добавить необязательное поле delivery_note при создании заказа
и показать его оператору в существующей карточке.

Границы пробы:
- максимум 60 минут на исследование и изменение;
- не публиковать ветку и не создавать PR;
- не выполнять команды против внешних или рабочих сервисов;
- не добавлять зависимости;
- не рефакторить код вне необходимого пути;
- не угадывать продуктовые требования;
- миграцию можно создать как файл, но нельзя применять к общей базе;
- запускать только локальные проверки, уже предусмотренные проектом.

Требуемый результат:
1. минимальный связный diff;
2. список изменённых контрактов и слоёв;
3. тесты или точный план недостающих тестов;
4. команды, которые были безопасно запущены;
5. вопросы и допущения;
6. риски выпуска и сопровождения;
7. места, где работа остановлена из-за лимита или нехватки решения.

Критерий остановки:
как только форма изменения и основные неизвестные стали видны,
прекратить полировку и подготовить отчёт.

Ограничение времени здесь является таймбоксом. Оно не обещает закончить реализацию за час. Оно делает стоимость самого исследования предсказуемой.

90-минутный протокол

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

0–10 минут: сформулировать наблюдаемое поведение

Запишите от трёх до семи критериев приёмки. Они должны описывать поведение, а не способ реализации.

• запрос без нового поля продолжает работать;
• значение длиннее лимита отклоняется предсказуемо;
• пустое значение не превращается в значащие пробелы;
• сохранённое значение возвращается в карточке;
• старые записи читаются без специального ремонта.

Рядом перечислите то, что исключено: редактирование, поиск, экспорт, отправка партнёру. Исключение должно быть явным, иначе AI может реализовать удобную, но более широкую задачу.

10–25 минут: найти путь изменения

До редактирования модель должна найти аналогичное поле и проследить его путь. Для репозитория с Git полезны команды:

rg -n "delivery|shipping|order.*create" .
rg -n "CreateOrder|OrderResponse|OrderDetails" .
git log --oneline --all -- '*order*'
git log -S'existing_similar_field' --oneline --all

Поиск истории через git log -S показывает прежние изменения похожего контракта. Это не внешняя ссылка и не догадка: команда изучает собственные решения проекта.

Результатом этапа должна быть карта:

UI input
  → client request type
  → HTTP schema
  → application command
  → domain model
  → persistence
  → response serializer
  → operator UI

Если путь нельзя восстановить за отведённое время, это уже сигнал стоимости. Запишите причину: динамические типы, скрытая генерация кода, несколько реализаций, отсутствующая документация или непрозрачная интеграция.

25–65 минут: построить минимальный связный патч

«Связный» означает, что изменение проходит через выбранный сценарий от входа до наблюдаемого результата. Не оставляйте поле только в интерфейсе, если задача подразумевает сохранение. Одновременно не добавляйте экспорт и редактирование, если они исключены.

На этом этапе допустимы:

• минимальные типы и преобразования;
• черновой файл миграции;
• одна реализация счастливого пути;
• характеризующий тест существующего поведения;
• новый тест на основной контракт;
• комментарий TODO(probe) в месте подтверждённой неопределённости.

Недопустимы бесконтрольный рефакторинг, массовое форматирование и обновление пакетов. Они раздувают diff и уничтожают измеримость.

65–75 минут: запустить узкие проверки

Используйте команды проекта, найденные в документации или конфигурации. Не придумывайте их по аналогии. Типичный набор может выглядеть так:

git diff --check
npm test -- order
npm run typecheck
npm run lint -- src/orders

Для Python-проекта это может быть:

git diff --check
pytest tests/orders -q
python -m mypy app/orders
python -m ruff check app/orders tests/orders

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

75–90 минут: измерить и вынести решение

Остановите редактирование. Снимите статистику, классифицируйте файлы и заполните карточку стоимости. Если патч не завершён, это не автоматически провал: незавершённость может точно показать, где скрыта основная неопределённость.

Как измерять размер diff

Число строк полезно, но недостаточно. Двадцать строк миграции и двадцать строк CSS имеют разный профиль риска. Сначала соберите сырой след:

git status --short
git diff --stat
git diff --numstat
git diff --name-status
git diff --check

Затем посмотрите содержимое без лишнего контекста:

git diff --unified=3
git diff --word-diff=plain -- '*.json' '*.yaml' '*.yml'

Классифицируйте каждый файл

Считайте границы, а не только файлы

Для оценки полезны пять отдельных чисел:

• количество смысловых файлов;
• количество изменённых модулей или пакетов;
• количество изменённых контрактов;
• количество новых ветвей поведения;
• количество систем, нужных для проверки.

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

Отделяйте обязательный diff от случайного

Для каждой строки изменений задайте вопрос: «Если удалить это, перестанет ли работать заявленный сценарий или его проверка?» Если нет, строка относится к полировке, соседнему ремонту или рефакторингу. В пробе её лучше убрать или вынести в отдельную задачу.

Как оценивать тестируемость

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

Проверьте четыре уровня

1. Чистая логика. Можно ли отдельно проверить нормализацию, ограничение длины и преобразование пустой строки?
2. Граница модуля. Принимает ли обработчик новый вход и возвращает ли ожидаемую ошибку без запуска всей системы?
3. Хранение или интеграция. Сохраняется ли значение и читается ли обратно через реальный адаптер?
4. Пользовательский путь. Видит ли оператор то, что ввёл пользователь?

На первом уровне обычно подходит модульный тест. Для границы с базой или HTTP нужен интеграционный тест. Не подменяйте хранение моком, если основной риск находится именно в схеме и преобразовании данных.

Минимальная матрица для учебного кейса

Признаки дорогой проверки

• результат можно увидеть только после полного развёртывания;
• тест требует общего изменяемого окружения;
• нет стабильного способа создать исходные данные;
• время или случайность встроены в основную логику;
• ошибка видна только по ручному просмотру логов;
• ожидаемое поведение нельзя выразить без копирования внутреннего алгоритма;
• существующие тесты зависят от порядка запуска.

Эти признаки увеличивают стоимость самой задачи и каждого будущего изменения рядом с ней. Запишите их отдельно, даже если AI сумел собрать работающий пример.

Как находить риски

Размер diff не показывает радиус воздействия. Для каждого изменённого контракта проследите потребителей и задайте вопрос о совместимости.

Данные

• Допускает ли новый столбец null?
• Нужен ли default, и одинаково ли он понимается приложением и базой?
• Может ли миграция блокировать большую таблицу?
• Нужна ли обратная миграция или достаточно отката кода?
• Как новая версия читает старые записи?
• Как старая версия работает после применения новой схемы?

Контракты

• Является ли поле действительно необязательным во всех слоях?
• Не проверяют ли клиенты точный список полей?
• Попадает ли значение в кэш, событие, индекс или экспорт?
• Есть ли сгенерированные клиенты, которые нужно обновить?
• Отличаются ли missing, null и пустая строка?

Безопасность и приватность

• Можно ли ввести HTML или управляющие символы?
• Где значение экранируется при отображении?
• Попадает ли пользовательский текст в логи?
• Кто имеет право читать поле?
• Нужно ли ограничить содержание или срок хранения?

Эксплуатация

• Нужен ли feature flag?
• Можно ли отключить чтение нового поля без удаления данных?
• Что увидит оператор при частичном развёртывании?
• Есть ли метрика ошибок валидации?
• Можно ли выполнить откат приложения после миграции?

Как записывать риск

Не используйте формулировку «возможны проблемы с базой». Риск должен связывать условие, событие и ущерб:

Если столбец будет создан как NOT NULL без безопасного default,
то старая версия приложения не сможет записывать заказы
во время поэтапного развёртывания.

Проверка:
поднять схему после миграции и выполнить запись старым кодом.

Снижение риска:
сначала добавить nullable-столбец, затем развернуть читающий
и пишущий код; ужесточение схемы вынести в отдельный этап.

Такая запись превращает тревогу в проверяемую инженерную работу.

Как оценивать стоимость сопровождения

Стоимость сопровождения появляется не только из количества кода. Главный источник — новые состояния, которые система обязана поддерживать после релиза.

Для каждого патча посчитайте:

• новые ветви поведения;
• новые значения конфигурации;
• новые состояния данных;
• новые роли или правила доступа;
• новые внешние контракты;
• новые панели, метрики и инструкции для поддержки;
• новые варианты восстановления после ошибки.

Постоянное ветвление дороже одноразовой работы

Миграция может быть одноразовой. Флаг, который навсегда оставляет два режима, удваивает часть сценариев проверки. Необязательное поле создаёт минимум два состояния: значение отсутствует или присутствует. Если добавить редактирование, появляются ещё неизменённое, изменённое и конфликтующее состояния.

Поэтому полезно разделить стоимость:

Вопрос удаления

Для любого добавленного механизма спросите: «Что придётся удалить, если функция не понадобится?» Если ответ включает схему, флаг, два API, фоновые задания и документацию, сопровождение уже не является маленьким.

Итоговая карточка стоимости

Карточка не переводит архитектуру в псевдоточную сумму. Она заставляет одинаково оценивать разные задачи и показывает, из-за чего оценка растёт.

Не складывайте баллы механически в часы. Используйте профиль для решения:

• Преимущественно 0. Можно планировать обычную небольшую задачу.
• Несколько 1. Нужны явный план тестов и проверка владельцем затронутого модуля.
• Хотя бы один 2. Сначала снимите конкретный риск или разделите работу на этапы.
• Высокая неопределённость. Не увеличивайте срок вслепую; получите недостающее решение и повторите пробу.

Шаблон заключения

Решение: сначала уточнить требования / можно разрабатывать / разбить.

Наблюдаемый размер:
- смысловых файлов:
- модулей:
- изменённых контрактов:
- новых ветвей поведения:
- требуемых систем для проверки:

Тестируемость:
- локально проверяется:
- требует интеграции:
- остаётся ручным:

Главные риски:
1.
2.
3.

Постоянная стоимость:
- новые режимы:
- конфигурация:
- мониторинг:
- процедура поддержки:

Открытые вопросы:
1.
2.

Следующий шаг:
- владелец:
- ожидаемый артефакт:
- условие повторной оценки:

Проверка качества пробы

AI может создать убедительный, но архитектурно неверный патч. Поэтому результат проверяет инженер, который не оценивает красоту решения, а подтверждает доказательства.

1. Проверьте происхождение изменений

git status --short
git diff --name-status
git diff --check
git diff --stat

В списке не должно быть секретов, локальных конфигураций, сгенерированных артефактов и несвязанных файлов.

2. Сравните с аналогичным изменением

Найдите существующее поле с похожим жизненным циклом. Проверьте, не пропустил ли AI сериализатор, политику доступа, фабрику тестовых данных или обновление схемы. Аналог является подсказкой, но не шаблоном для слепого копирования.

3. Проверьте обратную совместимость

Мысленно и, где возможно, автоматически выполните четыре комбинации:

• старый запрос → новый код;
• новый запрос без поля → новый код;
• старая запись → новый код;
• новая схема → старая версия приложения.

4. Проверьте тесты на чувствительность

Временно уберите смысловую строку реализации или замените ожидаемое преобразование. Соответствующий тест должен упасть. Если тест остаётся зелёным, он не доказывает заявленное свойство.

5. Запустите доступный контур проверки

Начните с узких тестов, затем используйте существующий локальный эквивалент CI. Не отмечайте весь проект проверенным, если запускалась только часть.

Итоговый отчёт должен различать четыре статуса:

• пройдено — команда запущена и завершилась успешно;
• не пройдено — получена конкретная ошибка;
• не запускалось — отсутствовала среда или время;
• неприменимо — проверка не относится к этому изменению.

6. Проверьте полноту вопросов

Хороший AI-патч не скрывает неопределённость. Если в исходной постановке не решено редактирование, права или передача партнёру, эти вопросы должны находиться в отчёте, а не быть молча решены кодом.

Когда метод даёт ложный ответ

AI построил демонстрацию вместо изменения

Поле появилось в интерфейсе, но не проходит через реальное сохранение. Diff выглядит маленьким, потому что модель остановилась перед дорогой частью.

Что делать: требовать связный путь от входа до наблюдаемого результата и явно отмечать незавершённые границы.

Модель переписала соседний код

Массовый рефакторинг создаёт сотни строк шума и искусственно увеличивает оценку.

Что делать: запретить несвязанные улучшения, отключить автоматическое форматирование всего проекта и классифицировать механический diff отдельно.

Патч мал, потому что риск вынесен наружу

Три строки могут передать новый параметр внешнему партнёру, но реальная стоимость находится в согласовании контракта, тестовом окружении и обработке отказов.

Что делать: считать внешнюю зависимость отдельной границей, даже если её код минимален.

AI угадал отсутствующее требование

Модель решила, что поле редактируемое, доступно всем ролям или должно отправляться партнёру. Патч оценивает выдуманную задачу.

Что делать: отделять допущения от фактов и останавливать работу на решениях, существенно меняющих объём.

Зелёные тесты относятся только к старому поведению

Полный набор прошёл, но ни один тест не чувствителен к новому полю.

Что делать: связать каждый критерий приёмки с конкретной проверкой и провести тест чувствительности.

Проба превратилась в скрытую разработку

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

Что делать: соблюдать критерий остановки. Продолжение после таймбокса является отдельным решением владельца задачи.

Команда использует число строк как цену

Автогенерируемый файл может добавить тысячу строк почти без ручной работы, а изменение одной проверки полномочий потребовать тщательного анализа.

Что делать: оценивать границы, проверяемость и обратимость вместе со строками.

В отчёте появились вымышленные результаты

Модель пишет «все тесты проходят», хотя не могла установить зависимости или запустить сервис.

Что делать: сохранять точные команды и статусы. Утверждение без вывода команды считается неподтверждённым.

Ограничения

AI-патч хорошо обнаруживает структуру кодовой работы, но не заменяет исследование пользователя, продуктовое решение и планирование внешней координации.

• Новый продуктовый сценарий. Если команда ещё не знает, кому и зачем нужна функция, код покажет только одну случайную трактовку.
• Изменение инфраструктуры. Стоимость закупки, сертификации, доступа и эксплуатации может почти не отражаться в diff.
• Производительность под нагрузкой. Локальный патч не доказывает поведение на рабочих объёмах.
• Редкие миграционные случаи. Реальные данные могут содержать состояния, отсутствующие в фикстурах.
• Распределённая система. Изменение одного репозитория не показывает работу других команд и несовпадающие циклы выпуска.
• Незнакомая кодовая база. AI может выбрать видимый, но не канонический путь реализации.
• Юридические и организационные требования. Срок хранения, аудит, согласование и обучение поддержки не выводятся из кода автоматически.

В этих случаях патч остаётся полезным артефактом, но карточку стоимости нужно дополнить отдельным исследованием. Не расширяйте полномочия AI только ради того, чтобы получить «полный» ответ.

Готовый шаблон повторного запуска

Скопируйте этот протокол в задачу и заполните пропуски.

ПРОБА СТОИМОСТИ ИЗМЕНЕНИЯ

Задача:
[одно наблюдаемое изменение]

Пользовательский результат:
[кто что сможет сделать или увидеть]

Входит в пробу:
- [...]
- [...]

Не входит:
- [...]
- [...]

Критерии приёмки:
1. [...]
2. [...]
3. [...]

Допущения:
- [...]

Лимит:
- исследование: 15 минут;
- пробный diff: 40 минут;
- проверки: 10 минут;
- отчёт: 15 минут;
- общий предел: 90 минут.

Ограничения:
- отдельная рабочая копия;
- без публикации и слияния;
- без рабочих данных и внешних действий;
- без новых зависимостей;
- без несвязанного рефакторинга;
- остановка при необходимости продуктового решения.

Артефакты:
- diff;
- git diff --stat и git diff --numstat;
- карта затронутых контрактов;
- выполненные команды и их статусы;
- матрица тестов;
- риски и способы проверки;
- постоянные обязанности сопровождения;
- открытые вопросы;
- рекомендация следующего шага.

Критерий готовности решения

Проба завершена, когда команда может ответить на следующие вопросы без догадок:

1. Какой минимальный путь проходит изменение?
2. Какие контракты и данные оно затрагивает?
3. Какая часть diff смысловая?
4. Какими проверками будет доказано поведение?
5. Что нельзя проверить в текущем окружении?
6. Как выпускается и откатывается изменение?
7. Какие новые состояния придётся поддерживать постоянно?
8. Какие решения ещё должен принять человек?