Не всякую задачу, которую может сделать AI, стоит ему отдавать
Не всякую задачу, которую может сделать AI, стоит ему отдавать
Когда обсуждают AI в разработке, разговор быстро превращается в список:
— пишет код;
— генерирует тесты;
— делает документацию;
— анализирует логи.
Но «AI это умеет» — слабый критерий для делегирования.
Я бы оценивал задачу по четырём параметрам.
1. Повторяемость
Задача регулярно возникает и каждый раз решается примерно одинаково? Чем больше рутины, тем больше смысла в автоматизации.
2. Формализуемость
Можно ли чётко описать входные данные, ограничения и ожидаемый результат? Если постановка звучит как «посмотри и предложи что-нибудь нормальное», AI придётся додумывать контекст.
3. Проверяемость результата
Можно ли быстро и объективно понять, что ответ правильный? Компиляция, тесты, линтер или сверка со схемой снижают риск. «Архитектура выглядит разумно» — уже не проверка.
4. Цена ошибки
Что произойдёт, если AI ошибётся? Придётся поправить черновик документации или восстанавливать production?
Хорошие первые кандидаты:
— boilerplate-код;
— заготовки тестов;
— документация;
— типовые миграции с проверкой;
— первичный анализ логов.
Плохие кандидаты:
— архитектурные решения при неясных требованиях;
— критические миграции без rollback;
— самостоятельные действия с production-данными;
— изменения, ошибку в которых сложно заметить сразу.
Получается простое правило: чем выше повторяемость, формализуемость и проверяемость, а цена ошибки ниже, тем больше работы можно отдать AI.
Если цена ошибки высокая, AI всё ещё может подготовить варианты, найти риски или сделать черновик. Но решение и запуск должны оставаться за человеком.
Генерация миграции и выполнение этой миграции в production — две совершенно разные задачи. И границу между ними лучше проводить до первого инцидента.
Когда обсуждают AI в разработке, разговор быстро превращается в список:
— пишет код;
— генерирует тесты;
— делает документацию;
— анализирует логи.
Но «AI это умеет» — слабый критерий для делегирования.
Я бы оценивал задачу по четырём параметрам.
1. Повторяемость
Задача регулярно возникает и каждый раз решается примерно одинаково? Чем больше рутины, тем больше смысла в автоматизации.
2. Формализуемость
Можно ли чётко описать входные данные, ограничения и ожидаемый результат? Если постановка звучит как «посмотри и предложи что-нибудь нормальное», AI придётся додумывать контекст.
3. Проверяемость результата
Можно ли быстро и объективно понять, что ответ правильный? Компиляция, тесты, линтер или сверка со схемой снижают риск. «Архитектура выглядит разумно» — уже не проверка.
4. Цена ошибки
Что произойдёт, если AI ошибётся? Придётся поправить черновик документации или восстанавливать production?
Хорошие первые кандидаты:
— boilerplate-код;
— заготовки тестов;
— документация;
— типовые миграции с проверкой;
— первичный анализ логов.
Плохие кандидаты:
— архитектурные решения при неясных требованиях;
— критические миграции без rollback;
— самостоятельные действия с production-данными;
— изменения, ошибку в которых сложно заметить сразу.
Получается простое правило: чем выше повторяемость, формализуемость и проверяемость, а цена ошибки ниже, тем больше работы можно отдать AI.
Если цена ошибки высокая, AI всё ещё может подготовить варианты, найти риски или сделать черновик. Но решение и запуск должны оставаться за человеком.
Генерация миграции и выполнение этой миграции в production — две совершенно разные задачи. И границу между ними лучше проводить до первого инцидента.