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
Когда монолит действительно пора делить
Сервис вырос до сотни модулей, сборка занимает вечность, а схему базы уже никто не помещает в голове.
Кажется, пора переходить на микросервисы.
Но размер сам по себе — слабый архитектурный аргумент. Большой монолит может годами оставаться удобным. А пять маленьких сервисов — превратиться в распределённый монолит, который падает по частям, а релизится всё равно целиком.
Я бы смотрел не на количество строк кода, а на то, живут ли части системы по разным правилам.
Вот несколько признаков.
Разные причины изменений
Одна часть меняется из-за требований бухгалтерии, другая — из-за экспериментов продуктовой команды, третья — при подключении новых партнёров.
Если изменения регулярно затрагивают только одну область, а остальные приходится собирать, тестировать и выкатывать за компанию, внутри монолита уже появились самостоятельные контуры.
Разные профили нагрузки
Каталог в основном читает данные. Биллинг обрабатывает транзакции. Генерация отчётов создаёт тяжёлую фоновую нагрузку.
Масштабировать весь сервис ради одного горячего участка дорого и неудобно. Особенно когда отчёт за прошлый квартал начинает конкурировать за ресурсы с оформлением заказов.
Разная скорость релизов
Одна часть продукта требует нескольких релизов в день. Другая меняется раз в месяц и должна проходить длинный цикл проверок.
Общий релизный процесс заставляет либо тормозить быстрый контур, либо принимать лишний риск в стабильном. Разделение позволяет каждому двигаться в своём темпе.
Разные владельцы
Если у компонентов есть отдельные команды, свои планы и ответственность за результат, общий код часто превращается в территорию постоянных согласований.
Но здесь важна оговорка: отдельный репозиторий ещё не создаёт автономность. Команда должна иметь возможность изменить, протестировать и выпустить свою часть без координационного совещания со всеми соседями.
Независимые failure domains
Падение рекомендаций не должно мешать оформить заказ. Ошибка в генерации документов не должна останавливать авторизацию.
Если части системы имеют разную критичность и должны отказывать независимо, техническая граница начинает приносить реальную пользу.
При этом вынести код в отдельный процесс недостаточно. Если сервисы используют одну базу, синхронно вызывают друг друга по длинной цепочке и релизятся только согласованным набором, failure domain остаётся общим. Просто теперь у него появился HTTP.
Именно поэтому аргумент «микросервисы сейчас делают все» ничего не говорит об архитектуре.
Разделение добавляет сетевые ошибки, контракты, наблюдаемость, версионирование, сложные тесты и новые сценарии отказа. За эту сложность стоит платить только тогда, когда она покупает независимость.
Не потому, что сервис стал большим.
А потому, что его части меняются, нагружаются, выпускаются, управляются и ломаются по-разному.
Сервис вырос до сотни модулей, сборка занимает вечность, а схему базы уже никто не помещает в голове.
Кажется, пора переходить на микросервисы.
Но размер сам по себе — слабый архитектурный аргумент. Большой монолит может годами оставаться удобным. А пять маленьких сервисов — превратиться в распределённый монолит, который падает по частям, а релизится всё равно целиком.
Я бы смотрел не на количество строк кода, а на то, живут ли части системы по разным правилам.
Вот несколько признаков.
Разные причины изменений
Одна часть меняется из-за требований бухгалтерии, другая — из-за экспериментов продуктовой команды, третья — при подключении новых партнёров.
Если изменения регулярно затрагивают только одну область, а остальные приходится собирать, тестировать и выкатывать за компанию, внутри монолита уже появились самостоятельные контуры.
Разные профили нагрузки
Каталог в основном читает данные. Биллинг обрабатывает транзакции. Генерация отчётов создаёт тяжёлую фоновую нагрузку.
Масштабировать весь сервис ради одного горячего участка дорого и неудобно. Особенно когда отчёт за прошлый квартал начинает конкурировать за ресурсы с оформлением заказов.
Разная скорость релизов
Одна часть продукта требует нескольких релизов в день. Другая меняется раз в месяц и должна проходить длинный цикл проверок.
Общий релизный процесс заставляет либо тормозить быстрый контур, либо принимать лишний риск в стабильном. Разделение позволяет каждому двигаться в своём темпе.
Разные владельцы
Если у компонентов есть отдельные команды, свои планы и ответственность за результат, общий код часто превращается в территорию постоянных согласований.
Но здесь важна оговорка: отдельный репозиторий ещё не создаёт автономность. Команда должна иметь возможность изменить, протестировать и выпустить свою часть без координационного совещания со всеми соседями.
Независимые failure domains
Падение рекомендаций не должно мешать оформить заказ. Ошибка в генерации документов не должна останавливать авторизацию.
Если части системы имеют разную критичность и должны отказывать независимо, техническая граница начинает приносить реальную пользу.
При этом вынести код в отдельный процесс недостаточно. Если сервисы используют одну базу, синхронно вызывают друг друга по длинной цепочке и релизятся только согласованным набором, failure domain остаётся общим. Просто теперь у него появился HTTP.
Именно поэтому аргумент «микросервисы сейчас делают все» ничего не говорит об архитектуре.
Разделение добавляет сетевые ошибки, контракты, наблюдаемость, версионирование, сложные тесты и новые сценарии отказа. За эту сложность стоит платить только тогда, когда она покупает независимость.
Не потому, что сервис стал большим.
А потому, что его части меняются, нагружаются, выпускаются, управляются и ломаются по-разному.
❤1