Не всякую задачу, которую может сделать AI, стоит ему отдавать

Когда обсуждают AI в разработке, разговор быстро превращается в список:

— пишет код; — генерирует тесты; — делает документацию; — анализирует логи.

Но «AI это умеет» — слабый критерий для делегирования.

Я бы оценивал задачу по четырём параметрам.

1. Повторяемость

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

2. Формализуемость

Можно ли чётко описать входные данные, ограничения и ожидаемый результат? Если постановка звучит как «посмотри и предложи что-нибудь нормальное», AI придётся додумывать контекст.

3. Проверяемость результата

Можно ли быстро и объективно понять, что ответ правильный? Компиляция, тесты, линтер или сверка со схемой снижают риск. «Архитектура выглядит разумно» — уже не проверка.

4. Цена ошибки

Что произойдёт, если AI ошибётся? Придётся поправить черновик документации или восстанавливать production?

Хорошие первые кандидаты:

— boilerplate-код; — заготовки тестов; — документация; — типовые миграции с проверкой; — первичный анализ логов.

Плохие кандидаты:

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

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

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

Генерация миграции и выполнение этой миграции в production — две совершенно разные задачи. И границу между ними лучше проводить до первого инцидента.