Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

На первый взгляд, решение логичное. На второй, уже менее. Если агент генерирует изменения в темпе, к которому люди не привыкли, один сениор превращается в бутылочное горлышко для бесконечного потока PR. Это не решение проблемы. Это антипаттерн, оформленный как процесс.

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

Статья написана по мотивам доклада Александра Поломодова (Technical Director & Fellow, Т-Технологии) "State of AI4SDLC: результаты исследования и AI-native-разработка" на DevOpsConf 2026.

Откуда цифры

В середине 2025 года стало очевидно: глобальных исследований о влиянии AI на разработку много, российских мало. Те, что есть, часто методологически зависят от вендора, который их заказал, и заранее знают ответ. Поэтому в Т-Банке решили провести собственное исследование, объединив два подхода.

Первый, мета-исследование: анализ более 50 источников за 2023-2025 годы. Серии DORA (DevOps Research and Assessment, которую в своё время купил Google Cloud и продолжает развивать), ежегодные опросы Stack Overflow и JetBrains, GitHub-аналитика по репозиториям и коммитам, полевые эксперименты вроде исследования Metr, где 16 разработчиков решали задачи в крупных кодовых базах, в которых они сами были мейнтейнерами.

Второй, собственный онлайн-опрос российских инженеров и техлидов. Анкету увидели около 80 тысяч человек, заполнили порядка тысячи, до конца дошли меньше 400. Вопросы касались самооценки продуктивности, качества, доверия к AI-инструментам, частоты их применения в разных задачах SDLC и связи с платформенными практиками.

У исследования есть ограничения: выборка может быть нерепрезентативной, эффекты сложно чисто атрибутировать AI, а не общим контексту компании, и существует эффект новизны, когда в начале использования инструмента человек настроен позитивнее, чем через полгода. Тем не менее данные дают достаточно чёткую картину.

Шесть паттернов, которые повторяются во всех исследованиях

Мета-анализ выявил шесть паттернов, которые воспроизводятся независимо от методологии и источника.

AI стал дефолтным инструментом. По данным Stack Overflow, к 2025 году более 90% инженеров используют AI-инструменты так или иначе, 83% делают это регулярно. DORA фиксирует то же самое. AI перестал быть экспериментом избранных, это новая операционная реальность.

Продуктивность растёт неравномерно. Выигрыш более 80% и экономия от 10 часов в неделю хорошо заметны на рутинных задачах, которые сильно зависят от контекста работы. На задачах с большим legacy или сложной кодовой базой картина иная.

Кодинг ускоряется быстрее, чем delivery. Это, пожалуй, самый важный из шести паттернов. DORA 2024 зафиксировала неожиданный результат: throughput и стабильность по индустрии просели. Каждый отдельный инженер говорит, что стал продуктивнее. Но end-to-end картина ухудшается. Узкие места смещаются дальше по контуру: в ревью, тестирование, интеграцию и релизы. Код генерируется быстрее, чем его успевают принять.

Доверие не поспевает за adoption. В российском опросе и в зарубежных исследованиях (в частности, от Stack Overflow) примерно 30-46% инженеров говорят, что не доверяют AI-результатам. Массовое использование не отменяет verify-first: AI-ответы и AI-код по-прежнему требуют проверки.

Роль инженера становится шире. Ожидания смещаются: уже не просто владеть одним языком и уметь кодить, но понимать системный контекст, управлять агентами, валидировать и принимать ответственность за то, что они генерируют. Более 66% инженеров ждут, что AI-навыки станут обязательными.

ROI появляется через процессы, не через пилоты. Доклад MIT Sloan приводит жёсткую воронку: 60% идей о применении AI доходят до стадии пилота, 20% пилотов раскатываются шире, и лишь 5% дают измеримые бизнес-результаты. Эффект возникает не от самого инструмента, а от его интеграции в delivery-платформу и SDLC-контур.

Что видно в российском разрезе

Картина в российском опросе в целом совпадает с глобальной, но с поправочным коэффициентом. Проникновение AI-инструментов ниже, чем в зарубежных отчётах. Генерация кода и отладка, основные зоны применения, есть у большинства. Документация тоже: генерировать её стало заметно проще. Но code review и legacy-задачи присутствуют менее чем у 20% инженеров.

По качеству сигналы разнонаправленные: у 30% оно улучшилось, у 15% ухудшилось, остальные фиксируют статус-кво. Доверие к AI-коду остаётся низким. Ожидания бизнеса скорее позитивные. Роль AI внутри компаний декларативно растёт.

От классического SDLC к AI-native: как меняется контур

Когда 90% инженеров ежедневно используют AI, возникает вопрос: а меняется ли сам процесс разработки или только инструментарий внутри него?

В 2025 году большинство компаний двигались по первому пути: автоматизировали отдельные сценарии внутри существующих ролей. Появились code review-агенты, генерация тестов, системный анализ, написание спецификаций, агенты-ассистенты для SRE. Каждый из них встраивался в свою нишу, не меняя общей архитектуры процесса.

Классический SDLC выглядит так: каждая стадия цикла (Idea, Req, Dev, Test, Deploy, Support) закреплена за конкретной ролью. Product, Analyst, Developer, QA Engineer, SRE, Support Engineer. Передача контекста между ними происходит руками, зачастую с потерями.

В SE 2.0 картина другая. Количество ролей сокращается. Агенты берут на себя сквозные сценарии. Там, где в SE 1.0 работали пять специалистов с чёткими границами ответственности, в SE 2.0 может работать один инженер, у которого часть workflow автоматизирована. Потери на передачах контекста уменьшаются. Скорость итерации растёт.

В стартапах этот переход происходит быстрее: там проще пилотировать с чистого листа. В корпорациях сложнее: действующие процессы, оргструктуры и команды не меняются за квартал. Практический ответ выглядит так: на greenfield-проектах пробовать agent-based разработку с нуля, на brownfield брать из новых практик то, что работает, и постепенно переносить.

Почему SE 2.0 не даёт бесплатного ускорения

Здесь начинается самое нетривиальное.

Когда код генерируется быстрее, кажется, что delivery тоже должно ускориться. На практике происходит иначе. Быстрая генерация при слабом version control порождает больше конфликтов и rework. Быстрый код вместе с шумными тестами создаёт нестабильность. Агент открывает PR за минуты, а review не перестроен под такой темп: узкое место просто смещается.

Ускоряется локальный coding loop. End-to-end delivery не ускоряется. И это проблема, потому что конечная цель это доставка ценности клиентам, а не количество строк кода или pull request в день.

DORA 2025 формулирует это так: AI усиляет те эффекты, которые уже есть в организации. Хорошая платформа, сильные инженерные практики, выстроенные процессы плюс AI даёт ещё лучший результат. Слабая платформа плюс AI даёт ускоренный хаос.

Это означает, что branch protection, CI policies, signing и supply chain controls это не опциональные детали. Это несущие элементы SE 2.0, без которых само здание не стоит.

Орг-дизайн: сжимаются уже не роли, а слои

Когда delivery-контур меняется, следующим начинает меняться орг-дизайн. Это уже хорошо видно в западных компаниях.

В SE 2.0 сжимались роли внутри цикла разработки. Теперь начинают сжиматься управленческие слои вокруг него. Логика простая: когда требования, код, тесты и документация создаются быстрее, узким местом становится скорость принятия решений. Узким местом становится latency между появлением нового требования и реакцией на него.

Параллельно меняется то, как рынок оценивает компании. Всё больше смотрят не просто на выручку или прибыль, а на выручку в пересчёте на одного сотрудника. Оптимизируется leverage, не только headcount.

Результат виден в публичных данных. Марк Цукерберг выстраивает структуру, где один менеджер управляет 50 репортами. У Дженсена Хуанга в Nvidia примерно такое же соотношение. Amazon повышает соотношение individual contributors к менеджерам. Microsoft и Google уплощают иерархию.

Но и здесь есть ловушка. Плоская структура работает только при сильной внутренней платформе: golden paths, fast feedback, policy-as-code, observability. Без этого менеджер начинает тонуть в исключениях. Senior IC превращаются в роутеров проблем. Все выгорают. Соотношение 1:50 в конкретной компании может быть совсем другим: нужно смотреть на свою организацию, а не копировать чужие бенчмарки.

Роль менеджера тоже меняется содержательно. Если раньше это была статизация задач и координация, то теперь это дизайн процессов и контекста. Метрики для оценки тоже должны меняться: throughput ценности, decision latency, DevEx и качество продукта, а headcount и объём AI-кода перестают быть основными ориентирами.

Task management: от тикета к контекстному work graph

Четвёртый уровень изменений менее очевиден, но его последствия ощущаются повседневно. Меняется сама единица работы.

Классический подход к task management выглядит так: человек вручную заводит задачу, переносит контекст из чата и документов, триажит, двигает статусы. Это не масштабируется, когда рядом работают агенты.

Представьте: агент генерирует задачи по клику. Бедный продакт или тимлид видит, как бэклог растёт бесконечно. Вручную расставить приоритеты в таком темпе невозможно. Синхронизировать состояние задачи вручную тоже: слишком много всего происходит параллельно.

В AI-native task management работа начинается раньше тикета. Система сама создаёт work item из разговора, документа, тикета поддержки или сигнала из инцидент-менеджера. AI предлагает тим, ассайни, связанные задачи и следующий шаг. Агенты берут ограниченные задачи на исполнение, а человек удерживает приоритеты, risk profile и конечную ответственность.

Трассируемость при этом становится критической. Если раньше цепочку от намерения до деплоя мог восстановить человек, который прошёл её руками, то теперь часть этого пути делают агенты. Без возможности проследить всю цепочку, откуда пришло изменение и какой задачей оно было инициировано, разбирать инциденты становится очень сложно.

Что происходит с инструментами

Рынок task management реагирует по-разному.

Linear, система для стартапов с оценкой выше миллиарда долларов, в мае 2025 года выпустила эссе с заголовком "Task management is dead" и объявила пивот. Теперь это платформа для управления работой людей и агентов вместе. MCP-интеграции, автоматическое создание задач из разных источников, агентские сценарии прямо в интерфейсе. Их аудитория это стартапы, которые очень чутко чувствуют направление рынка.

Atlassian прошла другой путь. Компания пыталась сделать AI-аналитику поверх Jira своими силами, но рынок не поверил: за год-два капитализация упала в три раза. В конце 2025 года Atlassian купила платформу DX примерно за миллиард долларов. DX это команда исследователей, которые за несколько лет продвинули методологии DORA, Space и DX-framework, собрали адаптеры к десяткам систем и застолбили нишу измерения AI-эффектов на разработку. Покупка сигнализирует: одного Jira-workflow для понимания реального состояния delivery уже недостаточно.

Как Big Tech ставит цели на 2026

Пятая часть исследования отвечает на вопрос, который больше всего интересует тех, кто принимает решения: а что конкретно делать?

Когда смотришь на западные компании, видно общую структуру метрик, вокруг которых они выстраивают AI-стратегию.

Adoption и распределение сценариев. Не просто "сколько людей еженедельно открывают инструмент", а сколько агентных сценариев приходится на пользователя, в каких поверхностях он взаимодействует с AI, и что за сценарии в топе. Это позволяет понимать, закрываются ли действительно важные задачи.

Throughput delivery-контура. Здесь таргетируются на два показателя. Первый: та же команда может поставлять больше при том же составе. Второй: cycle time, скорость прохождения задачи от старта до деплоя. Для части бизнесов, например, в банковском секторе с риск-менеджментом, скорость реакции на изменения имеет прямую финансовую ценность.

Quality, risk, stability как контрметрики. Добиться высокого throughput и короткого cycle time легко, если ничего не проверять. Поэтому рядом всегда стоят метрики стабильности и качества. Ответ "мы верим Клоду, он классно пишет" не считается.

Экономические эффекты. Google, Meta и ряд других компаний научились измерять время выполнения инженерами конкретных "джобов" (в продуктовом смысле) и сравнивать его с AI и без. Можно посчитать, сколько стоили миграции со старого стека и насколько дешевле они стали с агентами. Это бенефитная часть. Костовая: лицензии, токены, инфра, платформенная команда. Соотношение двух частей и есть ROI.

Uber, например, явно таргетируется на количество агентных сценариев, которые выполняются полностью автономно, без касания инженера. Google разбил свой SDLC на отдельные стадии, внутри выделил джобы, измерил, где болит, и точечно добавляет AI. Meta запустила концепцию just-in-time тестирования: агент пишет код, второй агент генерирует эфемерные тесты специально под этот diff, которые ищут проблемы в конкретном PR, а не хранятся постоянно.

GitHub встроил делегацию задач coding-агентам прямо в интерфейс: настраиваешь контекст, и задача из бэклога уходит в работу к агенту. Claude Code и Cursor предлагают review изменений. Всё это уже не эксперименты, а продуктовые фичи с раскаткой на миллионы пользователей.

Автономность агентов и guardrails. Отдельный блок это условия, при которых агент может работать без постоянного надзора. Cloud-based Devbox, где агент разворачивает среду сам, сильно упрощает автономную работу. Если всё привязано к локальной машине, агент буквально занимает рабочее место: экраны открываются, код меняется, а параллельную задачу начать нельзя. Никакой параллельности не получается.

Что брать в свои команды уже сейчас

Из всего сказанного складывается несколько практических выводов.

Встраивайте AI в обычный workflow разработки, а не оставляйте его побочным пилотом внутри IDE. Code review, генерация тестов, системный анализ, помощь с архитектурными решениями, SRE-ассистент. Это должно быть частью Internal Developer Platform, не отдельным инструментом по желанию.

Давайте агентам bounded autonomy. Агент выполняет ограниченную задачу, человек удерживает approvals, guardrails и финальную ответственность. История AWS показывает, что бывает, когда этот принцип нарушается в другую сторону.

Стройте вокруг агентных сценариев evals, telemetry и platform observability. Без этого масштабирование слепое. Нельзя улучшать то, что не измеряешь. Качество контекста, который агент получает для работы, это прямой рычаг качества его результата.

Меряйте end-to-end delivery outcomes, а не AI-written LOC. Throughput, quality/risk, economics. Прокси-метрики в стиле "сколько строк нагенерировалось" не отражают, приносит ли процесс ценность.

Смещайте роль инженеров к оркестрации, review, quality ownership и дизайну системы работы. Это не значит, что писать код больше не нужно. Это значит, что когнитивный фокус смещается: меньше реализации, больше архитектуры решения, контроля качества и работы с контекстом для агентов.

Когнитивная нагрузка и open source: вопросы, которые пока без ответа

Два вопроса из дискуссии после доклада заслуживают отдельного упоминания, потому что они честно описывают то, что ещё не решено.

Когнитивная нагрузка. Когда раньше инженер писал код в состоянии потока, это был один режим работы. Сейчас появляется другой: придумать задачу, загрузить агента, пока он работает придумать следующую задачу, потом ревью, потом ещё один цикл. За пять часов такой работы можно сделать очень много. Но это принципиально другая интенсивность принятия решений. Ощущение к концу дня описывают примерно так: встаёшь из-за компа в совершенно разобранном состоянии, хотя формально сделал больше, чем когда-либо.

Очевидно, что в какой-то момент людская когнитивная пропускная способность станет ограничением. Ответ исследователей на это пока звучит оптимистично: модели становятся автономнее и берут на себя больше, снижая количество микрорешений. Но насколько этот оптимизм обоснован к 2027-2030 годам, ещё предстоит увидеть.

Open source. Здесь ситуация двойственная. С одной стороны, contribut'ить в open source стало намного проще: то, что раньше занимало недели итераций с мейнтейнерами, теперь можно пройти за сутки. С другой, именно мейнтейнеры начинают захлёбываться: количество PR от AI-инструментов растёт, часть репозиториев уже явно указывает, что сгенерированные патчи без содержательного review не принимаются.

Параллельно AI снизил барьер для создания форков. По методике cleanroom можно взять open source проект и переписать его на другом языке или под свои нужды гораздо быстрее, чем раньше. Для крупных компаний это означает: вместо того чтобы продавливать нужную фичу в мейнстримный проект, проще сделать свою версию. Заградительная функция сложности open source разработки снижается. Куда это приведёт индустрию, пока открытый вопрос.

Куда движется всё это

Интересно, что ни один из описанных трендов не является изолированным. Они вытекают один из другого.

Когда AI-инструменты становятся дефолтными (паттерн 1), кодинг ускоряется быстрее delivery (паттерн 3). Это создаёт давление на delivery-контур и оргструктуру. Оргструктура уплощается и начинает оптимизировать leverage. Задачи начинают создаваться и двигаться иначе. Метрики успеха смещаются.

DORA-инсайт, который стоит запомнить: AI усиляет то, что уже есть. Хорошая платформа с AI станет лучше. Слабая с AI получит ускоренный хаос.

Это означает, что правильный порядок вопросов такой: сначала разобраться, что у вас есть сейчас, где реальные узкие места в delivery, насколько стабильны процессы и инфраструктура. И только потом думать, куда и какой AI встраивать.

Кодинг, как говорят некоторые исследователи, уже в значительной мере "решён". Вопросы о том, как это катить дальше, как проверять, как доставлять и как принимать решения в темпе, который задают агенты, ещё открыты. И над ними сейчас работает весь рынок.

Если хочется разобраться с этими вопросами в живом формате: 3 июля в Москве пройдёт Agentic Dev Conf — конференция о будущем IT-профессий в эпоху AI. А сразу следом, 4-5 июля — AI Weekends: два дня очной практики, три параллельных воркшопа по внедрению AI, с рабочим артефактом на выходе.