AI ускоряет не разработку. Он ускоряет вашу систему
За последнюю неделю я прочитал около двадцати материалов про AI в разработке: исследования DORA и Microsoft, статьи Atlassian и Habr, обсуждения на Hacker News.
Удивительно, насколько часто они приходят к одной и той же мысли.
Ещё год назад все сравнивали модели:
Claude.
GPT.
Gemini.
Cursor.
Кто лучше пишет код. Кто точнее понимает контекст. Кто быстрее закрывает задачу.
Сегодня вопрос «умеет ли AI писать код?» уже не так интересен.
Фокус сместился на другое:
что произойдёт с инженерной командой, когда код перестанет быть главным ограничением?
И здесь ответы разных исследований сходятся.
AI усиливает существующую систему работы.
Если задачи хорошо описаны, архитектурные решения зафиксированы, тесты надёжны, а ревью не занимает неделю — команда действительно ускоряется.
Если требования меняются по дороге, знания живут в головах, а каждый PR проходит археологическую экспертизу — AI просто быстрее создаёт следующую порцию незавершённой работы.
Формально кода становится больше.
Фактически очередь перед ревью, тестированием и приёмкой растёт ещё быстрее.
Вот что мне особенно запомнилось:
— DORA рассматривает AI не как замену инженерным практикам, а как усилитель уже существующих возможностей команды.
— Microsoft делает акцент не только на инструментах, но и на роли руководителей, устройстве работы и организационных изменениях.
— Atlassian пишет о смещении узкого места: генерация кода ускоряется, поэтому ограничением становятся контекст, согласования, ревью и проверка результата.
— В обсуждениях практиков на Hacker News спор всё чаще идёт не о том, какая модель умнее, а о том, как встроить её в процесс и не потерять качество.
Кажется, эпоха главного вопроса:
«Какую модель выбрать?»
постепенно заканчивается.
Начинается эпоха вопросов:
«Как поставить задачи так, чтобы AI не угадывал требования?»
«Кто и как будет проверять результат?»
«Где теперь появится очередь?»
«Какие части процесса придётся перестроить?»
Выбор модели всё ещё важен. Но разница между двумя моделями может оказаться менее значимой, чем разница между командами, в одной из которых есть понятный инженерный процесс, а в другой — только лицензия на новый инструмент.
Что почитать:
— DORA: State of AI-assisted Software Development 2025
— Microsoft Work Trend Index 2026
— Atlassian: The bottleneck keeps shifting
— Atlassian: How AI is Changing Developer Workflows
А у вашей команды после внедрения AI где сместилось узкое место: постановка задач, контекст, ревью, тестирование или приёмка?
За последнюю неделю я прочитал около двадцати материалов про AI в разработке: исследования DORA и Microsoft, статьи Atlassian и Habr, обсуждения на Hacker News.
Удивительно, насколько часто они приходят к одной и той же мысли.
Ещё год назад все сравнивали модели:
Claude.
GPT.
Gemini.
Cursor.
Кто лучше пишет код. Кто точнее понимает контекст. Кто быстрее закрывает задачу.
Сегодня вопрос «умеет ли AI писать код?» уже не так интересен.
Фокус сместился на другое:
что произойдёт с инженерной командой, когда код перестанет быть главным ограничением?
И здесь ответы разных исследований сходятся.
AI усиливает существующую систему работы.
Если задачи хорошо описаны, архитектурные решения зафиксированы, тесты надёжны, а ревью не занимает неделю — команда действительно ускоряется.
Если требования меняются по дороге, знания живут в головах, а каждый PR проходит археологическую экспертизу — AI просто быстрее создаёт следующую порцию незавершённой работы.
Формально кода становится больше.
Фактически очередь перед ревью, тестированием и приёмкой растёт ещё быстрее.
Вот что мне особенно запомнилось:
— DORA рассматривает AI не как замену инженерным практикам, а как усилитель уже существующих возможностей команды.
— Microsoft делает акцент не только на инструментах, но и на роли руководителей, устройстве работы и организационных изменениях.
— Atlassian пишет о смещении узкого места: генерация кода ускоряется, поэтому ограничением становятся контекст, согласования, ревью и проверка результата.
— В обсуждениях практиков на Hacker News спор всё чаще идёт не о том, какая модель умнее, а о том, как встроить её в процесс и не потерять качество.
Кажется, эпоха главного вопроса:
«Какую модель выбрать?»
постепенно заканчивается.
Начинается эпоха вопросов:
«Как поставить задачи так, чтобы AI не угадывал требования?»
«Кто и как будет проверять результат?»
«Где теперь появится очередь?»
«Какие части процесса придётся перестроить?»
Выбор модели всё ещё важен. Но разница между двумя моделями может оказаться менее значимой, чем разница между командами, в одной из которых есть понятный инженерный процесс, а в другой — только лицензия на новый инструмент.
Что почитать:
— DORA: State of AI-assisted Software Development 2025
— Microsoft Work Trend Index 2026
— Atlassian: The bottleneck keeps shifting
— Atlassian: How AI is Changing Developer Workflows
А у вашей команды после внедрения AI где сместилось узкое место: постановка задач, контекст, ревью, тестирование или приёмка?
👍1
Кто вырастит senior-разработчиков, если AI заберёт junior-задачи
Раньше путь junior-разработчика выглядел довольно предсказуемо.
Поправить небольшой баг.
Добавить поле в API.
Написать простой тест.
Разобраться, почему задача работает локально, но падает в CI.
Сами по себе эти задачи не делали человека senior. Но именно на них разработчик учился читать чужой код, ходить по стеку вызовов, замечать архитектурные ограничения и восстанавливаться после собственных ошибок.
Теперь значительную часть такой работы можно отдать AI.
Junior получает готовый фрагмент кода, запускает тесты, немного правит результат и отправляет PR. Формально задача выполнена быстрее.
Но есть проблема: скорость выполнения задачи и скорость обучения — не одно и то же.
Можно получить правильный ответ, не поняв:
— почему решение устроено именно так;
— какие варианты были отброшены;
— где оно сломается на реальных данных;
— почему тесты зелёные, но уверенности всё равно нет;
— как найти ошибку, если AI уверенно предложил не тот путь.
Раньше обучение частично происходило автоматически — просто потому, что без понимания задачу было сложно закончить.
С AI этот механизм перестаёт работать. Можно закрывать задачи и почти не накапливать инженерный опыт.
Значит, выращивание разработчиков придётся проектировать отдельно.
Не запрещать AI. Это примерно как запретить IDE, чтобы люди лучше запоминали синтаксис.
Но и не считать закрытые тикеты доказательством развития.
Нужны другие практики:
— просить объяснить решение и его ограничения;
— разбирать не только итоговый код, но и ход рассуждений;
— давать задачи на диагностику, а не только на генерацию;
— обсуждать альтернативы на ревью;
— постепенно увеличивать область ответственности;
— оставлять человеку право ошибиться и самостоятельно найти причину.
Возможно, главной задачей senior-разработчика скоро станет не написание сложного кода, а создание среды, в которой junior не превращается в оператора кнопки «сгенерировать».
AI забирает рутину. Но вместе с рутиной он может случайно забрать и практику.
И тогда вопрос уже не в том, сможет ли junior быстрее закрывать задачи.
Кто и как будет выращивать следующего senior, если путь от проблемы к решению он больше не проходит сам?
Раньше путь junior-разработчика выглядел довольно предсказуемо.
Поправить небольшой баг.
Добавить поле в API.
Написать простой тест.
Разобраться, почему задача работает локально, но падает в CI.
Сами по себе эти задачи не делали человека senior. Но именно на них разработчик учился читать чужой код, ходить по стеку вызовов, замечать архитектурные ограничения и восстанавливаться после собственных ошибок.
Теперь значительную часть такой работы можно отдать AI.
Junior получает готовый фрагмент кода, запускает тесты, немного правит результат и отправляет PR. Формально задача выполнена быстрее.
Но есть проблема: скорость выполнения задачи и скорость обучения — не одно и то же.
Можно получить правильный ответ, не поняв:
— почему решение устроено именно так;
— какие варианты были отброшены;
— где оно сломается на реальных данных;
— почему тесты зелёные, но уверенности всё равно нет;
— как найти ошибку, если AI уверенно предложил не тот путь.
Раньше обучение частично происходило автоматически — просто потому, что без понимания задачу было сложно закончить.
С AI этот механизм перестаёт работать. Можно закрывать задачи и почти не накапливать инженерный опыт.
Значит, выращивание разработчиков придётся проектировать отдельно.
Не запрещать AI. Это примерно как запретить IDE, чтобы люди лучше запоминали синтаксис.
Но и не считать закрытые тикеты доказательством развития.
Нужны другие практики:
— просить объяснить решение и его ограничения;
— разбирать не только итоговый код, но и ход рассуждений;
— давать задачи на диагностику, а не только на генерацию;
— обсуждать альтернативы на ревью;
— постепенно увеличивать область ответственности;
— оставлять человеку право ошибиться и самостоятельно найти причину.
Возможно, главной задачей senior-разработчика скоро станет не написание сложного кода, а создание среды, в которой junior не превращается в оператора кнопки «сгенерировать».
AI забирает рутину. Но вместе с рутиной он может случайно забрать и практику.
И тогда вопрос уже не в том, сможет ли junior быстрее закрывать задачи.
Кто и как будет выращивать следующего senior, если путь от проблемы к решению он больше не проходит сам?
❤2
Почему AI не уменьшает ответственность тимлида
AI может написать код, подготовить тесты, собрать документацию, найти подозрительное место в PR и предложить решение.
Кажется, что чем больше работы забирают инструменты, тем меньше остаётся руководителю.
На практике — наоборот.
AI снимает часть рутины. Но он не решает, какую задачу действительно нужно делать первой. Не определяет, какой технический долг допустим сейчас. Не отвечает за то, что команда быстро и качественно решает не ту проблему.
У тимлида по-прежнему остаются:
— приоритеты;
— архитектурные решения;
— развитие команды;
— качество процесса;
— инженерная культура;
— ответственность за результат.
Можно делегировать AI подготовку решения. Нельзя делегировать ему понимание контекста и последствий.
Если агент создал PR за десять минут, кто-то всё равно должен проверить, соответствует ли он требованиям, не ломает ли архитектуру и не создаёт ли новый риск. Скорость генерации кода не отменяет инженерного контроля. Она лишь быстрее доставляет решения к точке, где этот контроль необходим.
Более того, автономные инструменты увеличивают масштаб каждого управленческого решения.
Плохой приоритет теперь можно реализовать быстрее. Слабое архитектурное решение — распространить шире. Неясное требование — превратить в работающий, протестированный и совершенно ненужный код.
AI делает команду производительнее не сам по себе. Он усиливает систему, в которую встроен.
Поэтому чем больше автономии получают инструменты, тем важнее качество решений тимлида. Его работа постепенно смещается от контроля выполнения к проектированию среды: правил, ограничений, обратной связи и границ ответственности.
AI уменьшает объём ручной работы.
Но не уменьшает ответственность за то, зачем, как и с каким результатом эта работа выполняется.
AI может написать код, подготовить тесты, собрать документацию, найти подозрительное место в PR и предложить решение.
Кажется, что чем больше работы забирают инструменты, тем меньше остаётся руководителю.
На практике — наоборот.
AI снимает часть рутины. Но он не решает, какую задачу действительно нужно делать первой. Не определяет, какой технический долг допустим сейчас. Не отвечает за то, что команда быстро и качественно решает не ту проблему.
У тимлида по-прежнему остаются:
— приоритеты;
— архитектурные решения;
— развитие команды;
— качество процесса;
— инженерная культура;
— ответственность за результат.
Можно делегировать AI подготовку решения. Нельзя делегировать ему понимание контекста и последствий.
Если агент создал PR за десять минут, кто-то всё равно должен проверить, соответствует ли он требованиям, не ломает ли архитектуру и не создаёт ли новый риск. Скорость генерации кода не отменяет инженерного контроля. Она лишь быстрее доставляет решения к точке, где этот контроль необходим.
Более того, автономные инструменты увеличивают масштаб каждого управленческого решения.
Плохой приоритет теперь можно реализовать быстрее. Слабое архитектурное решение — распространить шире. Неясное требование — превратить в работающий, протестированный и совершенно ненужный код.
AI делает команду производительнее не сам по себе. Он усиливает систему, в которую встроен.
Поэтому чем больше автономии получают инструменты, тем важнее качество решений тимлида. Его работа постепенно смещается от контроля выполнения к проектированию среды: правил, ограничений, обратной связи и границ ответственности.
AI уменьшает объём ручной работы.
Но не уменьшает ответственность за то, зачем, как и с каким результатом эта работа выполняется.
👍2❤1
Как измерять продуктивность AI в разработке
Не строками кода.
Не количеством коммитов.
И точно не количеством промптов.
Все эти цифры показывают активность, но ничего не говорят о том, стала ли команда быстрее доставлять рабочие изменения.
Я бы смотрел на другие метрики:
— Review Time — сколько времени уходит на проверку AI-кода. Если код генерируется за минуту, а ревью занимает два часа, ускорения не произошло.
— Revert Rate — как часто изменения приходится откатывать. Быстро написанный код, который ломает прод, — это не продуктивность.
— Lead Time — сколько проходит от постановки задачи до доставки результата пользователю.
— Throughput — сколько завершённых изменений команда действительно выпускает за период, а не сколько начинает.
— Change Failure Rate — какая доля изменений приводит к инцидентам, откатам или срочным исправлениям.
— Количество ручных исправлений — сколько работы остаётся разработчику после генерации: переписать логику, добавить проверки, исправить архитектуру.
— Процент принятого AI-кода — какая часть предложений доходит до итогового изменения без существенной переработки.
Но важное ограничение: эти метрики нельзя превращать в рейтинг разработчиков или соревнование между командами.
Иначе AI начнут использовать не там, где он полезен, а там, где проще улучшить цифру.
Главный вопрос не в том, сколько кода написал AI.
Главный вопрос — помог ли он быстрее доставить качественное изменение без роста риска и скрытой ручной работы.
Не строками кода.
Не количеством коммитов.
И точно не количеством промптов.
Все эти цифры показывают активность, но ничего не говорят о том, стала ли команда быстрее доставлять рабочие изменения.
Я бы смотрел на другие метрики:
— Review Time — сколько времени уходит на проверку AI-кода. Если код генерируется за минуту, а ревью занимает два часа, ускорения не произошло.
— Revert Rate — как часто изменения приходится откатывать. Быстро написанный код, который ломает прод, — это не продуктивность.
— Lead Time — сколько проходит от постановки задачи до доставки результата пользователю.
— Throughput — сколько завершённых изменений команда действительно выпускает за период, а не сколько начинает.
— Change Failure Rate — какая доля изменений приводит к инцидентам, откатам или срочным исправлениям.
— Количество ручных исправлений — сколько работы остаётся разработчику после генерации: переписать логику, добавить проверки, исправить архитектуру.
— Процент принятого AI-кода — какая часть предложений доходит до итогового изменения без существенной переработки.
Но важное ограничение: эти метрики нельзя превращать в рейтинг разработчиков или соревнование между командами.
Иначе AI начнут использовать не там, где он полезен, а там, где проще улучшить цифру.
Главный вопрос не в том, сколько кода написал AI.
Главный вопрос — помог ли он быстрее доставить качественное изменение без роста риска и скрытой ручной работы.
❤2✍1👍1🔥1
Не всякую задачу, которую может сделать 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