Не всякую задачу, которую может сделать 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 — две совершенно разные задачи. И границу между ними лучше проводить до первого инцидента.
👍2
AI сэкономил разработчику десять часов. Почему команда не стала быстрее
Представим, что с AI разработчик пишет код в два раза быстрее.
Логично ожидать, что фичи тоже начнут выходить в два раза быстрее.
Но delivery почти не изменился.
Причина простая: написание кода занимает лишь часть пути от задачи до продакшена.
До AI:
- код — 20%
- ревью — 20%
- ожидание — 40%
- релиз — 20%
После внедрения AI:
- код — 8%
- ревью — 25%
- ожидание — 47%
- релиз — 20%
Это условный пример, но он хорошо показывает механику.
AI сократил активную работу разработчика. Однако задача по-прежнему ждёт ревью, уточнений, согласований, тестового окружения и окна для релиза.
Более того, если кода стало больше, нагрузка на ревью и тестирование может вырасти.
Именно поэтому локальная экономия десяти часов не превращается в десять часов для всей команды.
Исследования DORA предлагают смотреть не на скорость написания кода, а на весь поток: lead time, частоту поставки, стабильность изменений и время восстановления.
Atlassian приходит к похожему выводу со стороны developer experience: значительная часть рабочего времени теряется из-за организационных препятствий, переключения контекста и неэффективных процессов.
AI редко устраняет бутылочное горлышко.
Чаще он просто переносит его из написания кода в ревью, тестирование или ожидание.
Поэтому после внедрения AI полезно спрашивать не «насколько быстрее мы пишем код?», а:
насколько быстрее изменение доходит до пользователя?
Представим, что с AI разработчик пишет код в два раза быстрее.
Логично ожидать, что фичи тоже начнут выходить в два раза быстрее.
Но delivery почти не изменился.
Причина простая: написание кода занимает лишь часть пути от задачи до продакшена.
До AI:
- код — 20%
- ревью — 20%
- ожидание — 40%
- релиз — 20%
После внедрения AI:
- код — 8%
- ревью — 25%
- ожидание — 47%
- релиз — 20%
Это условный пример, но он хорошо показывает механику.
AI сократил активную работу разработчика. Однако задача по-прежнему ждёт ревью, уточнений, согласований, тестового окружения и окна для релиза.
Более того, если кода стало больше, нагрузка на ревью и тестирование может вырасти.
Именно поэтому локальная экономия десяти часов не превращается в десять часов для всей команды.
Исследования DORA предлагают смотреть не на скорость написания кода, а на весь поток: lead time, частоту поставки, стабильность изменений и время восстановления.
Atlassian приходит к похожему выводу со стороны developer experience: значительная часть рабочего времени теряется из-за организационных препятствий, переключения контекста и неэффективных процессов.
AI редко устраняет бутылочное горлышко.
Чаще он просто переносит его из написания кода в ревью, тестирование или ожидание.
Поэтому после внедрения AI полезно спрашивать не «насколько быстрее мы пишем код?», а:
насколько быстрее изменение доходит до пользователя?
✍2❤1💯1
Почему разработчики скрывают использование AI
Есть странная тема, о которой почти никто не говорит.
Многие разработчики уже используют AI в работе: пишут код, разбирают легаси, ищут ошибки, генерируют тесты, готовят документацию.
Но коллегам об этом рассказывают не всегда.
И дело не только в страхе выглядеть менее компетентными.
Разработчик может опасаться, что:
— ему просто начнут давать больше задач;
— результат обесценят: «Это же AI сделал»;
— любую ошибку модели запишут на его счёт;
— использование AI сочтут нарушением негласных правил;
— однажды спросят: «Если AI делает за тебя работу, зачем тогда нужен ты?»
Получается довольно токсичная конструкция.
Компания хочет повысить эффективность с помощью AI, но сотрудник не заинтересован показывать, насколько эффективнее он стал.
Поэтому AI используют тихо. Без обмена опытом, общих практик и честного обсуждения ошибок.
Так AI-native культура не появляется.
Она начинается не с покупки лицензий на очередной Copilot. Она начинается с безопасности: разработчик может открыто рассказать, где использовал AI, что получилось, что пришлось переделать и где модель ошиблась.
Пока это приходится скрывать, AI остаётся личным чит-кодом отдельных сотрудников, а не инструментом всей команды.
Есть странная тема, о которой почти никто не говорит.
Многие разработчики уже используют AI в работе: пишут код, разбирают легаси, ищут ошибки, генерируют тесты, готовят документацию.
Но коллегам об этом рассказывают не всегда.
И дело не только в страхе выглядеть менее компетентными.
Разработчик может опасаться, что:
— ему просто начнут давать больше задач;
— результат обесценят: «Это же AI сделал»;
— любую ошибку модели запишут на его счёт;
— использование AI сочтут нарушением негласных правил;
— однажды спросят: «Если AI делает за тебя работу, зачем тогда нужен ты?»
Получается довольно токсичная конструкция.
Компания хочет повысить эффективность с помощью AI, но сотрудник не заинтересован показывать, насколько эффективнее он стал.
Поэтому AI используют тихо. Без обмена опытом, общих практик и честного обсуждения ошибок.
Так AI-native культура не появляется.
Она начинается не с покупки лицензий на очередной Copilot. Она начинается с безопасности: разработчик может открыто рассказать, где использовал AI, что получилось, что пришлось переделать и где модель ошиблась.
Пока это приходится скрывать, AI остаётся личным чит-кодом отдельных сотрудников, а не инструментом всей команды.
👍3❤1