ИИ ускоряет разработку, багов больше, наблюдаемость дорожает, платформенная инженерия на подъёме
Ключевые идеи
ИИ-инструменты заметно разгоняют разработку, но по качеству есть вопросы — значит, нужны новые подходы к тестированию и контролю качества.
Командная работа никуда не делась: несмотря на прогресс ИИ, растёт риск, что инженеры пойдут за ответами к боту, а не к коллегам — и это бьёт по культуре сотрудничества, от которой зависит высокая эффективность.
Джуны всё так же нужны индустрии: сегодня они быстрее вникают с помощью ИИ и приходят к сеньорам уже с более точными вопросами.
Психологическая безопасность остаётся фундаментом сильных команд, хотя постпандемийные сдвиги в корпоративной культуре и экономическое давление её подтачивают.
Затраты на наблюдаемость растут без остановки; относиться к ней стоит как к стратегической инвестиции, а не просто к строке расходов.
Agile и DevOps уже стали фоном — «воздухом, которым дышим». Следующий виток — платформенная инженерия: продуктовое и дизайнерское мышление, применённое к разработческим инструментам и платформам.
Ускорение с ИИ, инженерное мастерство и меняющаяся командная динамика
В ежегодном подкасте «Culture & Methods Trends Report» редакторы InfoQ по направлению Культура & Методы вместе со специальной гостьей Чарити Мейджорс обсудили, как меняются культура разработки, инструменты и практики. Из разговора сложилась картина ключевых трендов 2025 года — от того, как ИИ перестраивает рабочие процессы, до новых взглядов на эффективность команд и наблюдаемость.
Чтобы уверенно ориентироваться в текущих и будущих трендах — на InfoQ и на наших конференциях QCon и DevSummit — мы опираемся на ментальную модель «преодоления пропасти» (crossing the chasm) из книги Джеффри Мура. Мы ищем идеи для «раннего рынка», где, по Муру, клиентская база состоит из техноэнтузиастов и визионеров, стремящихся опередить назревающую возможность или looming-проблему.
Как и в отчётах о трендах Культура & Методы за 2024, 2023, 2022, 2021, 2020, 2019, 2018, и 2017 годы, мы представляем граф тем на 2025 год:
Для контекста, вот наша карта тем за 2024 год:
Двойственная роль ИИ в разработке
Главный тренд — как ИИ перевернул практики разработки. Продуктивность взлетела, но вместе с ней выросли и риски для качества. Команды только учатся с этим справляться.
Внедрение ИИ прошло путь от осторожных проб к статусу обязательной части пайплайна. Свежие отчёты вроде State of DevOps уже относят ассистентов наподобие Copilot к базовым инструментам современного процесса. Но в тех же материалах фиксируют тревожный рост доли неуспешных изменений.
Итог — пакеты изменений раздуваются:
«Теперь порции изменений стали крупнее. А ведь мы годами добивались, чтобы они были маленькими. Теперь ты просто говоришь: “Робот, дай решение”, и получаешь страницы кода, которые, возможно, даже не успеешь прочитать».
При этом команды отмечают, что с ИИ удаётся сделать больше и не сильно урезать функциональность — особенно в формате хакатонов. На «неделе ИИ» в одной компании успели всё: от тёмной темы до инструментов, которые объясняют SQL-запросы или импортируют дашборды от других вендоров. Масштаб и глубина результатов за считанные дни впечатляли.
Но есть и обратная сторона. В продакшене растёт число отказов, связанных с кодом, сгенерированным ИИ. В одном из недавних исследований — «на 300% больше выпускаемого кода и на 400% больше багов», с мрачной оговоркой: «насколько им известно». Это рифмуется с State of DevOps 2024: скорость ИИ ведёт к укрупнению пакетов изменений и нарушению принципа DORA о малых партиях — а значит, повышает нестабильность.
Подводя итоги прошлых лет, авторы замечают: ИИ настолько разогнал продуктивность и скорость генерации кода, что мы позабыли о базовом принципе DORA — маленькие партии изменений. Кода за то же время становится больше, чейнджлисты пухнут. А DORA из года в год показывает: крупные изменения идут медленнее и чаще ломают систему. Вывод простой: «улучшить процесс разработки» ≠ «улучшить доставку». Без дисциплины малых батчей и надёжного тестирования стабильности не будет.
Из этого вытекает и новая боль. Раньше баги разбирали через «позовём того, кто писал». С ИИ-генерацией такого «назначенного эксперта» может просто не быть. Индустрия только начинает вырабатывать практики, как жить с кодом от ИИ: как его ревьюить, сопровождать и распределять ответственность.
Разрыв между лидерами и отстающими во внедрении технологий
Разрыв между теми, кто принял новые технологии, и теми, кто всё ещё сомневается, становится очевидным. Передовые команды уже используют широкий набор ИИ-технологий, а более консервативные организации держат доступ под замком, ограничиваясь узким набором закрытых инструментов вроде Microsoft Copilot.
Пока более зрелые команды раздвигают рамки возможного, многие другие только осваивают базовую работу по agile. Без прочного фундамента проверенных практик добавление новых технологий и методик превращается в рискованное упражнение.
И этот разнобой, похоже, будет только расти. Ранние последователи оттачивают использование ИИ и ставят «перила» для качества, тогда как те, кто продолжает ограничивать доступ, будут всё сильнее отставать по возможностям и экспертизе.
Командное взаимодействие в мире, усиленном ИИ
ИИ поднимает индивидуальную скорость, но вызывает тревогу за командную «химию». Высокоэффективная разработка держится на слаженной работе — это по-настоящему совместная деятельность. Ключ к результатам — сотрудничество, и ИИ потенциально может его размывать.
Инженеры всё чаще спрашивают ИИ вместо того, чтобы обсудить с коллегами — так страдает культура взаимодействия, на которой и держится высокая эффективность.
«Люди гораздо чаще спрашивают ИИ, затем смотрят на то, что он выдал, и думают: “Окей, ответ уже есть, значит, нам больше не нужно идти к другим людям в организации”.»
В погоне за ИИ важно сохранять «пространства» для человеческого общения, рефлексии и обучения. Наблюдаемость, поэтапное развёртывание и проверка гипотез прямо в продакшене по-прежнему требуют человеческого контроля и совместной работы.
Ценность младших разработчиков в индустрии, усиленной ИИ
Несмотря на опасения, что ИИ «съест» роль младших инженеров, их ценность никуда не делась — участники дискуссии это подчёркивают. Реплики в духе «джуны больше не нужны» — мимо кассы:
«Я много слышу, как говорят: “Я больше никогда не буду нанимать младших разработчиков”, и считаю это крайне недальновидным. Это индустрия наставничества. Мы все учились, перенимая опыт у других».
Сегодняшние джуны не заменяются ИИ — они быстрее растут за его счёт. Используют ИИ как ускоритель, приходят к сеньорам уже с отточенными вопросами, и общение становится точнее и продуктивнее.
Команды, где ценят обучение и постоянные улучшения, — естественная среда для джунов. Они проверяют, насколько команда реально умеет делиться знаниями. Те, кто отказываются от найма младших, рискуют потерять важный элемент долгосрочной устойчивости.
Высокоэффективные команды: психологическая безопасность и рефлексия
Что делает команды высокоэффективными в 2025-м? Участники выделили проверенные принципы и новые практики.
Психологическая безопасность — это фундамент.
«Если хотите строить высокоэффективные команды, нужно, чтобы все реально участвовали в работе и вносили свой лучший вклад… и для этого в команде должна быть психологическая безопасность».
После пандемии, на фоне экономического давления, с ней стало хуже. Компании урезают коучей и другие «помогающие» роли; пробелы закрывают менеджеры и недавно повышенные инженеры — часто без нужной подготовки.
С технической стороны — короткие фидбэк-циклы. Укорачивайте путь от написания кода до продакшена. Делайте этот цикл максимально коротким и плотным.
Высокая эффективность требует «запаса» в системе. Команда, загруженная на 100%, по сути стоит на месте.
«Если держать загрузку на уровне 90% всё время, вы выжигаете людей, и на восстановление уйдёт много времени».
Метрики и циклы улучшений
Инженерные метрики — рабочий инструмент роста команды. Трекинг Lean-потерь помогает понять, где утекает время: упавшие сборки, расплывчатые требования, прочие блокеры.
Сильные команды не боятся метрик, но и не превращают их в вердикт. Цифры — повод для разговора, а не инструмент оценки людей. Не судите по метрикам отдельных инженеров; используйте их, чтобы находить узкие места в системе и чинить процесс.
Регулярные обзоры дают критично важный фидбэк: стоимость, время цикла, пропускная способность, число инцидентов и время восстановления (MTTR), плюс продуктовые метрики. Это не обязано быть долгим — даже короткие, но регулярные чек-ины работают.
И да, само выделение времени на улучшения уже ценно. Смотреть на производительность, задавать вопросы к цифрам, разбираться, что на самом деле происходит в команде, — вот что запускает реальные улучшения.
Кризис стоимости наблюдаемости
Один из самых болезненных трендов — стоимость наблюдаемости растёт как на дрожжах. По данным Gartner, у одного клиента счёт поднялся с $50 000 в 2009-м до $14 млн в 2024-м — примерно по 40% в год на протяжении 15 лет.
«Это разорит нас всех, если мы не возьмём это под контроль», — предупреждает один из участников.
Компаниям нужно честно ответить себе: наблюдаемость — это статья, которую «режут», или стратегическая инвестиция с отдачей. Когда в стеке 10–20 инструментов наблюдаемости, вы фактически получаете 10–20-кратный множитель расходов по отношению к росту бизнеса.
Часть роста затрат объяснима: системы усложняются быстрее, чем мы успеваем строить ментальные модели. Современные сервисы слишком сложны и быстро меняются — одной «карты в голове» уже недостаточно. Чтобы понимать поведение системы, нужны надёжные средства наблюдаемости.
Один из вариантов — подход «озера данных»: собирать телеметрию один раз и давать к ней доступ через интерфейсы с поддержкой ИИ. И в целом закупки в области наблюдаемости стоит рассматривать как инвестиции, а не просто как расходы.
За пределами «Agile» и «DevOps»: что дальше?
Про Agile и DevOps почти не говорили — и это показательно: эти практики настолько прочно вросли в повседневную работу, что их больше не выделяют отдельно.
«Когда-то раздел Culture & Methods на InfoQ крутился вокруг agile — это был пост-agile период. Примечательно, что за весь подкаст слово почти не прозвучало — и это точно описывает текущую реальность».
И с DevOps похожая история: «Мы в “сумерках” движения — не потому что DevOps устарел, а потому что он стал воздухом, которым дышим».
Дальше — фокус на опыте разработчиков. Платформенная инженерия выстреливает как следующий шаг: продуктовый и дизайнерский подходы к внутренним инструментам и платформам, чтобы прокачать DX. Признание простое, но важное: «инженеры — тоже люди, и хорошо спроектированные, удобные инструменты делают разработчиков продуктивнее».
В качестве рамки мышления отлично ложатся «Три пути» Джина Кима — поток, обратная связь, непрерывное обучение. Они в унисон с остальными трендами: ускоряем поток, улучшаем фидбэк через наблюдаемость и строим среду, где команда постоянно учится.
Заключение: будущее распределено неравномерно
Участники завершили разговор цитатой Уильяма Гибсона: «Будущее уже здесь — просто распределено неравномерно». Это про нашу отрасль сейчас: одни команды уже живут на переднем крае инструментов и практик, другие всё ещё разбираются с базой.
Есть и позитив: платформенная инженерия выходит в мейнстрим, карьерные треки Staff+ закрепляются — можно расти вне менеджмента. Часто именно ведущие инженеры запускают программы найма и наставничества для джунов, признавая простую вещь: когда речь о том, что нужно разработчикам, никого авторитетнее практикующего разработчика нет.
Чтобы не отстать в быстро меняющемся ландшафте, командам стоит сфокусироваться на следующем:
использовать ИИ, параллельно выстраивая «перила» и практики качества вокруг его применения;
сохранять и усиливать командное взаимодействие;
инвестировать в младших разработчиков и создавать обучающую среду;
сокращать цикл обратной связи от написания кода до продакшена;
считать наблюдаемость стратегической инвестицией и управлять растущими затратами;
держать «запас» ресурсов на эксперименты, рефлексию и улучшения;
помнить, что DevOps и Agile — это уже фундамент, а не конкурентное преимущество.
Сфокусировавшись на этих точках, команды легче пройдут через вызовы 2025 года и построят более устойчивые, высокоэффективные процессы — способные надёжно поставлять всё более сложные системы.
Чтобы превратить эти тренды в операционные практики, пригодится курс «CTO / Технический директор». Разбираем платформенную инженерию и DX, стратегию наблюдаемости и cost-control, DORA-метрики и малые батчи, оргдизайн и матрицу компетенций — на кейсах действующих CTO. Финальный артефакт — ваш стратегический план развития подразделения.
На странице курса можно записаться на бесплатные уроки для будущих CTO. Также приглашаем всех желающих на открытые уроки по темам:
20 октября в 20:00. От KPI к бизнес-ценности: как Project Manager помогает бизнесу зарабатывать. Записаться
21 октября в 20:00. Цепочки создания ценности: моделирование, анализ, проектирование. Записаться