Кто вырастит 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