AI ускоряет junior. Но ускоряет ли он его развитие?
Мы уже знаем, что AI способен ускорять выполнение задач. Но скорость delivery и скорость обучения — разные метрики.
В январе Anthropic опубликовал рандомизированное исследование о том, как AI-помощь влияет на формирование навыков программирования.
52 разработчика, преимущественно junior, изучали незнакомую им Python-библиотеку Trio. Одна группа могла обращаться к AI, другая писала код самостоятельно. После задания участники прошли тест на понимание концепций, чтение кода и отладку.
Группа с AI закончила в среднем примерно на две минуты раньше. Разница оказалась статистически незначимой.
Зато результат теста отличался заметно: 50% у группы с AI против 67% у тех, кто писал самостоятельно. Самый большой разрыв был в вопросах на отладку.
Это не означает, что AI вреден для junior.
Интереснее другое: результат зависел от того, как именно разработчик использовал модель.
Хуже справлялись те, кто делегировал AI написание и исправление кода. Лучше — те, кто задавал концептуальные вопросы, просил объяснить решение и продолжал разбираться самостоятельно.
По сути, исследование показывает риск cognitive offloading: задача решена, но часть размышлений, которые должны были сформировать навык, выполнила модель.
Раньше обучение часто выглядело так:
задача → тупик → документация → попытка → ошибка → отладка → понимание.
Теперь легко получить более короткий маршрут:
задача → агент → решение.
Формально результат есть. Фактически из процесса могла исчезнуть половина учебной петли.
И здесь появляется новая ответственность тимлида: различать задачи, которые нужно оптимизировать на скорость, и задачи, в которых разработчику нужно оставить пространство для обучения.
Например:
— знакомую рутину можно смело делегировать агенту;
— при освоении новой технологии AI лучше использовать как наставника, а не генератор ответа;
— после сгенерированного решения полезно просить разработчика объяснить его и найти возможные ошибки;
— часть задач стоит разбирать без автоматической генерации кода.
Возможно, AI-native командам придётся сознательно создавать «неэффективные» учебные ситуации. Не запрещать инструменты, а проектировать способ работы с ними.
Потому что максимальная скорость выполнения задачи и максимальная скорость развития человека — не одно и то же.
А у вас AI для junior сейчас скорее исполнитель или наставник?
Исследование Anthropic о влиянии AI на формирование навыков программирования
Мы уже знаем, что AI способен ускорять выполнение задач. Но скорость delivery и скорость обучения — разные метрики.
В январе Anthropic опубликовал рандомизированное исследование о том, как AI-помощь влияет на формирование навыков программирования.
52 разработчика, преимущественно junior, изучали незнакомую им Python-библиотеку Trio. Одна группа могла обращаться к AI, другая писала код самостоятельно. После задания участники прошли тест на понимание концепций, чтение кода и отладку.
Группа с AI закончила в среднем примерно на две минуты раньше. Разница оказалась статистически незначимой.
Зато результат теста отличался заметно: 50% у группы с AI против 67% у тех, кто писал самостоятельно. Самый большой разрыв был в вопросах на отладку.
Это не означает, что AI вреден для junior.
Интереснее другое: результат зависел от того, как именно разработчик использовал модель.
Хуже справлялись те, кто делегировал AI написание и исправление кода. Лучше — те, кто задавал концептуальные вопросы, просил объяснить решение и продолжал разбираться самостоятельно.
По сути, исследование показывает риск cognitive offloading: задача решена, но часть размышлений, которые должны были сформировать навык, выполнила модель.
Раньше обучение часто выглядело так:
задача → тупик → документация → попытка → ошибка → отладка → понимание.
Теперь легко получить более короткий маршрут:
задача → агент → решение.
Формально результат есть. Фактически из процесса могла исчезнуть половина учебной петли.
И здесь появляется новая ответственность тимлида: различать задачи, которые нужно оптимизировать на скорость, и задачи, в которых разработчику нужно оставить пространство для обучения.
Например:
— знакомую рутину можно смело делегировать агенту;
— при освоении новой технологии AI лучше использовать как наставника, а не генератор ответа;
— после сгенерированного решения полезно просить разработчика объяснить его и найти возможные ошибки;
— часть задач стоит разбирать без автоматической генерации кода.
Возможно, AI-native командам придётся сознательно создавать «неэффективные» учебные ситуации. Не запрещать инструменты, а проектировать способ работы с ними.
Потому что максимальная скорость выполнения задачи и максимальная скорость развития человека — не одно и то же.
А у вас AI для junior сейчас скорее исполнитель или наставник?
Исследование Anthropic о влиянии AI на формирование навыков программирования
❤1👍1
Bus Factor AI-агента: кто понимает процесс, кроме него
Всю неделю мы говорили о долге понимания в коде. Но с AI он появляется не только там.
Представим, команда автоматизировала процесс через агента.
Агент знает нужные промпты, использует MCP, ходит во внутренние системы, выполняет инструкции и закрывает заметную часть работы.
Формально Bus Factor вырос: процесс больше не зависит от одного Васи.
Фактически Вася просто стал цифровым.
Раньше говорили:
«Это знает только Вася».
Теперь:
«Это делает агент. Лучше его не трогать».
Получился тот же knowledge silo, только теперь он спрятан между системным промптом, конфигурацией MCP и особенностями конкретной модели.
Я бы проверял такую автоматизацию несколькими вопросами:
— Где хранятся инструкции агента?
— Версионируются ли промпты и конфигурация?
— Понятно ли, какие инструменты он вызывает и с какими правами?
— Можно ли восстановить логику процесса по шагам?
— Кто владеет агентом и отвечает за изменения?
— Что сломается при смене модели?
— Сможет ли человек проверить результат и разобраться, почему агент принял такое решение?
Необязательно уметь вручную повторить каждое действие агента за то же время. Но команда должна понимать входы, решения, ограничения и точки контроля.
Иначе агент ускоряет процесс, одновременно увеличивая долг понимания. Всё работает быстро, пока не меняется модель, API, сотрудник или исключение в бизнес-правиле. После этого начинается археология, только раскапывать приходится не код, а цепочку промптов и вызовов инструментов.
Автоматизация должна убирать ручную работу, а не превращать знание процесса в чёрный ящик.
Если завтра ваш основной AI-агент перестанет запускаться, команда восстановит процесс по документации или начнёт изучать его поведение по логам?
Всю неделю мы говорили о долге понимания в коде. Но с AI он появляется не только там.
Представим, команда автоматизировала процесс через агента.
Агент знает нужные промпты, использует MCP, ходит во внутренние системы, выполняет инструкции и закрывает заметную часть работы.
Формально Bus Factor вырос: процесс больше не зависит от одного Васи.
Фактически Вася просто стал цифровым.
Раньше говорили:
«Это знает только Вася».
Теперь:
«Это делает агент. Лучше его не трогать».
Получился тот же knowledge silo, только теперь он спрятан между системным промптом, конфигурацией MCP и особенностями конкретной модели.
Я бы проверял такую автоматизацию несколькими вопросами:
— Где хранятся инструкции агента?
— Версионируются ли промпты и конфигурация?
— Понятно ли, какие инструменты он вызывает и с какими правами?
— Можно ли восстановить логику процесса по шагам?
— Кто владеет агентом и отвечает за изменения?
— Что сломается при смене модели?
— Сможет ли человек проверить результат и разобраться, почему агент принял такое решение?
Необязательно уметь вручную повторить каждое действие агента за то же время. Но команда должна понимать входы, решения, ограничения и точки контроля.
Иначе агент ускоряет процесс, одновременно увеличивая долг понимания. Всё работает быстро, пока не меняется модель, API, сотрудник или исключение в бизнес-правиле. После этого начинается археология, только раскапывать приходится не код, а цепочку промптов и вызовов инструментов.
Автоматизация должна убирать ручную работу, а не превращать знание процесса в чёрный ящик.
Если завтра ваш основной AI-агент перестанет запускаться, команда восстановит процесс по документации или начнёт изучать его поведение по логам?
👍1
Разработчики работают не так, как сами считают продуктивным
Мы привыкли обсуждать productivity через результат:
— сколько задач завершили;
— сколько времени занимает delivery;
— сколько PR закрыли.
Но в исследовании Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era авторы задали другой вопрос:
На что разработчики хотели бы тратить рабочее время — и насколько это отличается от их реальной недели?
В опросе участвовали 484 разработчика Microsoft. Исследователи сравнили фактическое распределение времени с тем, которое сами разработчики считают оптимальным.
Обнаружилась простая закономерность: чем больше разрыв между желаемой и реальной неделей, тем ниже удовлетворённость работой и воспринимаемая продуктивность.
Это не означает, что любое неприятное занятие нужно немедленно отменить. Поддержка, координация и встречи иногда необходимы.
Но если человек считает важной одну работу, а большую часть недели вынужден делать другую, проблема может быть не в его мотивации. Возможно, система просто расходует его время не там.
Отсюда хороший вопрос для 1:1:
Если бы ты мог перераспределить свою рабочую неделю, чего в ней стало бы меньше, а чего — больше?
Ответ может показать то, чего не видно в отчёте по закрытым задачам:
— слишком много встреч;
— постоянные переключения контекста;
— ручные повторяющиеся операции;
— ожидание решений и доступов;
— coordination overhead;
— поддержку, которая незаметно вытеснила основную работу;
— недостаток времени на проектирование и глубокую работу.
И здесь появляется интересная связь с AI.
Обычно компании выбирают сценарии автоматизации от возможностей инструмента: что модель уже умеет писать, анализировать или генерировать.
Можно развернуть вопрос:
Какую работу люди меньше всего хотят продолжать делать руками?
Тогда приоритетом для AI становятся не самые эффектные демо, а задачи, которые создают наибольший разрыв между реальной и желаемой рабочей неделей.
Не «куда ещё встроить AI».
А «что вернуть людям, убрав из их недели лишнюю механику».
Если задать этот вопрос вашей команде, чего она попросит меньше: встреч, поддержки, ручной работы, ожидания или переключений контекста?
Мы привыкли обсуждать productivity через результат:
— сколько задач завершили;
— сколько времени занимает delivery;
— сколько PR закрыли.
Но в исследовании Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era авторы задали другой вопрос:
На что разработчики хотели бы тратить рабочее время — и насколько это отличается от их реальной недели?
В опросе участвовали 484 разработчика Microsoft. Исследователи сравнили фактическое распределение времени с тем, которое сами разработчики считают оптимальным.
Обнаружилась простая закономерность: чем больше разрыв между желаемой и реальной неделей, тем ниже удовлетворённость работой и воспринимаемая продуктивность.
Это не означает, что любое неприятное занятие нужно немедленно отменить. Поддержка, координация и встречи иногда необходимы.
Но если человек считает важной одну работу, а большую часть недели вынужден делать другую, проблема может быть не в его мотивации. Возможно, система просто расходует его время не там.
Отсюда хороший вопрос для 1:1:
Если бы ты мог перераспределить свою рабочую неделю, чего в ней стало бы меньше, а чего — больше?
Ответ может показать то, чего не видно в отчёте по закрытым задачам:
— слишком много встреч;
— постоянные переключения контекста;
— ручные повторяющиеся операции;
— ожидание решений и доступов;
— coordination overhead;
— поддержку, которая незаметно вытеснила основную работу;
— недостаток времени на проектирование и глубокую работу.
И здесь появляется интересная связь с AI.
Обычно компании выбирают сценарии автоматизации от возможностей инструмента: что модель уже умеет писать, анализировать или генерировать.
Можно развернуть вопрос:
Какую работу люди меньше всего хотят продолжать делать руками?
Тогда приоритетом для AI становятся не самые эффектные демо, а задачи, которые создают наибольший разрыв между реальной и желаемой рабочей неделей.
Не «куда ещё встроить AI».
А «что вернуть людям, убрав из их недели лишнюю механику».
Если задать этот вопрос вашей команде, чего она попросит меньше: встреч, поддержки, ручной работы, ожидания или переключений контекста?
❤2