Что происходит с разработчиками, когда ИИ берёт на себя 80% их работы

На одном из недавних мероприятий эксперты из Сбера, Яндекса и red_mad_robot обсуждали внедрение ИИ в жизненный цикл разработки продукта — AI PDLC. В выступлениях снова и снова звучала одна и та же мысль: роль разработчика меняется. Всё чаще он не пишет код вручную, а формулирует задачу для ИИ, проверяет результат, удерживает архитектурный замысел и задаёт рамки.

Если выстроить эту дискуссию в логике «от стратегии к человеку, от человека — к производственной практике, а затем — к рыночным кейсам», картина становится особенно ясной. Сначала — взгляд Сбера на зрелость AI‑driven разработки. Затем — разбор того, что этот сдвиг делает с людьми. После этого — разговор о том, что действительно работает в корпоративной среде. И уже потом — внешние кейсы Яндекса и red_mad_robot, на которых видно, как меняется повседневная инженерная работа и экономика выпуска продукта.

Сбер. От эксперимента к AI‑driven разработке

Кирилл Меньшов, старший вице‑президент, руководитель блока «Технологии», Сбер

Логично начать с уровня системы координат. Кирилл Меньшов описывает путь Сбера как движение без готовых прецедентов: компания начала внедрять ИИ раньше, чем на рынке сложился устойчивый стандарт, и потому одновременно выстраивала и инструменты, и саму логику перехода.

Чтобы оценивать зрелость ИИ‑трансформации, в Сбере используют шкалу PDLC от нулевого до пятого уровня. Нулевой уровень означает, что ИИ в разработке вообще нет. Пятый — что человек формулирует задачу, а ИИ сам её реализует, проверяет и возвращает готовый результат.

Сейчас Сбер находится на третьем уровне — Supervised automation, или автоматизация под наблюдением. ИИ встроен в большинство этапов производственного цикла, разработчик постоянно с ним взаимодействует, но финальное решение всегда остаётся за человеком. Модель предлагает и исполняет, человек проверяет, принимает или отклоняет.

Впереди ещё четвёртый и пятый уровни — агентная разработка, где ИИ не только пишет код, но и сам формулирует подзадачи, запускает тесты и реагирует на ошибки. В такой схеме human‑in‑the‑loop, то есть участие человека в контуре, смещается от операционного контроля к стратегическому управлению.

GigaCode 3.0: когда числа говорят не о коде, а об использовании

GigaCode здесь рассматривают не как корпоративный аналог Copilot. Разница принципиальная: Copilot встроен в IDE и помогает по ходу набора, а в Сбере строили экосистему, которая растёт вместе с разработчиком — от автодополнения до полноценного агента, способного закрывать релиз.

Сегодня GigaCode используют примерно 14 000 разработчиков. Почти 80% из них работают с инструментом ежедневно. Для корпоративной среды это ключевая метрика: важен не факт регистрации, а привычка использовать инструмент в реальной работе.

В начале 2025 года доля ИИ‑кода, принятого командами, составляла 45%, к концу года — 69%. Рост на 24 процентных пункта за год говорит не только об удобстве. Он показывает, что меняется сам рабочий паттерн: значительная часть кода в эксплуатации уже проходит через ИИ.

GigaIDE PRO: когда IDE перестаёт быть средой разработки

В ноябре 2025 года в Сбере сделали шаг, который даже внутри индустрии выглядел нетривиально: все разработчики перешли с JetBrains IDE на GigaIDE PRO — собственную среду разработки.

JetBrains — это IDE с двадцатилетней историей, десятками тысяч плагинов и огромным запасом пользовательской привычки. По сути, речь шла о замене 25 фреймворков и инструментальных цепочек. Такой переход потребовал не только инженерной, но и большой организационной работы.

Причина была в том, что GigaIDE PRO уже не сводится к классической IDE. Внутри работают семь ИИ‑агентов: они отвечают за документацию кода, журналирование, модульность, транзакционность, автотесты, анализ тестовых моделей и командную аналитику. Разработчики принимают больше половины их предложений.

К моменту публикации инструмент скачали 165 тысяч раз, а сам продукт включили в Реестр российского ПО. В итоге преимущества ИИ‑нативной среды перевесили тот объём привычек и инструментов, который раньше держал команду в JetBrains.

DX: как ИИ меняет экономику адаптации

Дальше важнее смотреть не на сам код, а на экономику адаптации. Есть метрика, которую хорошо понимает любой менеджер: за сколько дней новый разработчик выходит на полную продуктивность.

В 2024 году в Сбере этот показатель составлял 71 день. Сейчас — 36 дней.

Мировой бенчмарк DX — исследование на 135 тысячах разработчиков в 435 компаниях — показывает снижение с 91 до 49 дней. Сбер сокращает адаптацию на 13 дней быстрее этого тренда.

35 сэкономленных дней — не абстрактный HR‑результат. Это 35 дней зарплаты, которые раньше уходили на погружение в контекст. Когда новых инженеров много, экономический эффект становится заметным.

Ещё одна метрика из того же исследования касается продуктивности разработчиков, которые работают с ИИ‑ассистентом. Её измеряли по количеству pull request. В мировой выборке рост составил 60%, в Сбере — 62%.

Два лагеря и горизонт 2030

Но даже внутри одной компании переход идёт неравномерно. По словам Кирилла Меньшова, сейчас внутри Сбера хорошо видны два лагеря: одни сотрудники уже работают с ИИ‑агентами, другие находят много причин этого не делать. Для большой организации это нормальная картина любой глубокой трансформации. Вопрос не в том, как слить эти группы в одну, а в том, как масштабировать первых и понять, что именно останавливает вторых.

Финальный горизонт этой логики — Zero‑Friction PDLC, то есть производственный цикл без трения: идея, код, тесты и продакшен связаны в одну цепочку без ручных переключений контекста, потерь между этапами и ожидания на стыках процессов.

Такая концепция может звучать как слишком дальний горизонт, но архитектура уже собирается. 90% реализации делает ИИ, а 90% управления замыслом остаётся за людьми. Человек формулирует цель, агент строит маршрут и выполняет работу.

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

Отказаться нельзя использовать: отношение к ИИ у профессиональных пользователей

Андрей Курпатов, научный руководитель Лаборатории нейронаук и поведения человека, Сбер

На этот вопрос Андрей Курпатов смотрит с другой стороны — через то, как ИИ меняет разработчиков на разных этапах карьеры. Лаборатория нейронаук и поведения человека Сбера изучила, как профессионалы воспринимают ИИ‑копилотов в работе. Серия глубинных интервью показала: вместе с технологическими возможностями появляются и новые психологические сложности.

У разработчиков разных уровней есть скрытый страх за свое будущее. Многие опасаются, что из‑за ИИ могут утратить свои профессиональные навыки и со временем стать менее востребованными на рынке. Переход от роли «творца» к роли «оператора нейросети» переживается довольно болезненно — как понижение статуса. В такой ситуации человек может начать сомневаться в собственной ценности как специалиста.

Молодые разработчики нередко попадают в своеобразную ловушку: вместо того чтобы учиться работать с кодом и формировать профессиональную компетентность, они практически сразу должны решать задачи проверки кода, созданного ИИ. Возникает парадокс: начинающий специалист оказывается в роли эксперта, хотя еще не успел накопить достаточный опыт. Отсюда — растерянность и фрустрация.

У более опытных разработчиков другая проблема. Значительная часть их профессионального удовольствия раньше была связана решением сложных задач. Этот «момент победы» поддерживал интерес к работе. Когда часть решений предлагает ИИ, процесс меняется. У некоторых специалистов из‑за этого возникает ощущение, что их работа становится более механической — как будто они постепенно превращаются в «скучного контролера на конвейере».

При этом использование ИИ‑инструментов действительно ускоряет многие процессы и дает компаниям технологическое преимущество в краткосрочной перспективе. Но если не учитывать психологические эффекты, возникающие у сотрудников, есть риск столкнуться со стратегическими вызовами. Технологический выигрыш сегодня, в отсутствие серьезных мер по сбережению человеческого капитала, может обернуться деградацией инженерной культуры и потерей экспертизы завтра.

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

Голос изнутри об агентах, коде и людях

Рафаел Тонаканян, директор дивизиона SberWorks и руководитель Developer Tools, Сбер

Именно так вопрос звучит на уровне production: что действительно работает в корпоративной среде, а что остаётся удобным лишь для личных проектов.

По оценке Рафаела Тонаканяна, Vibe Coding в корпоративной разработке неприменим. Он хорошо работает там, где есть личный контекст и свободный режим эксперимента, например в pet‑проектах. Но в корпорации агенты должны учитывать регуляторные требования, внутренние API и правила безопасности. Иначе решение просто не будет работать.

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

Когда GigaCode в декабре закрыл первый полноценный релиз продукта для загрузки и проверки библиотек на безопасность без единой ручной строки кода, это был уже не эксперимент. В релиз вошли пять крупных задач и несколько исправлений дефектов. Агенты выполнили всю работу, а команда приняла результат без нареканий.

Отдельно изменился и рабочий паттерн опытных инженеров, которые глубоко вошли в агентный режим. Они почти перестали писать код руками, но начали значительно больше взаимодействовать с агентами. Рутинные задачи уходят ИИ, а у человека остаётся время на творческую и архитектурную работу, где действительно нужен опыт.

После этого внутреннего взгляда полезно сделать шаг назад и посмотреть на более широкий сдвиг: как вообще менялась роль человека по мере взросления ИИ‑инструментов.

Как менялась роль человека

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

Первая волна пришлась на 2023 год, когда появились ИИ‑ассистенты в виде чатботов. Сценарий был простым: запрос, ответ с кодом, ручное копирование в проект. Удобство уже было заметным, но взаимодействие оставалось линейным. Разработчик по‑прежнему выступал полноправным автором решения.

Потом появился Copilot — ИИ внутри IDE, то есть прямо в среде разработки. Переключаться между окнами стало не нужно. Модель начала предлагать продолжения по мере набора, угадывать намерение и дописывать функции. Работа ускорилась, но сдвиг уже произошёл: код всё чаще не пишут с нуля, а принимают или отклоняют.

Следом пришёл агентный режим. ИИ сам открывает файлы, запускает тесты, видит ошибку, вносит исправление и проверяет результат ещё раз. Человек формулирует задачу и возвращается уже к готовому решению. Роль автора постепенно смещается к роли постановщика намерения.

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

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

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

Когда строки кода перестают быть метрикой

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

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

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

Эти волны разные компании проходили по‑своему. Ниже — два кейса, в которых особенно хорошо видно, как агентный подход меняет ежедневную разработку и экономику выпуска продукта.

Яндекс. Когда агент перестаёт быть инструментом

Дмитрий Иванов, руководитель SourceCraft, Яндекс

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

В Яндексе начали с вопроса, который звучит почти философски: что изменится, если разработчик перестанет «использовать ИИ» и начнёт «работать с ИИ»? Разница кажется словесной, пока не смотришь на цифры.

Первый год ушёл на выстраивание качества. В 2024 году команда провела 120 сессий с пользователями и шаг за шагом собирала метрики: сколько предложений принимают, сколько отклоняют, кто возвращается к инструменту регулярно. Речь тогда шла не об агентном режиме, а о надёжном и предсказуемом помощнике внутри IDE.

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

Сегодня теми или иными ИИ‑инструментами пользуются все сотрудники Яндекса — от универсального AI Chat до специализированных решений вроде «Нейроюриста» для юридических задач и Yandex Code Assistant для инженеров. Около 70% разработчиков регулярно применяют ИИ‑ассистентов при написании кода. В среднем такие инженеры делают на 10–20% больше коммитов.

Но генерация кода — лишь часть инженерной работы, примерно треть общего объёма. Остальное занимают проектирование архитектуры, отладка, тестирование, код‑ревью, коммуникация и документация. Поэтому в Яндексе оценивают эффект ИИ по всему циклу, а не только по скорости написания кода.

Например, на поиск информации разработчики тратят от 10 до 30% рабочего времени: открывают внутренние wiki‑страницы, ищут документацию, задают вопросы коллегам. ИИ‑чат сократил эти затраты в разы. Те, кто активно им пользуется, заходят на внутренние wiki вдвое реже, потому что получают ответ раньше, чем успевают открыть браузер.

Отдельно выделяют DeepAgent — инструмент для сложных поисковых задач с режимом рассуждения, то есть с пошаговой логикой решения. Там, где раньше уходили дни на исследование кодовой базы, он даёт десятикратное ускорение. Речь идёт не о задачах уровня «напиши функцию», а о разборах вроде «найди, где в 20 миллионах строк живёт эта логика, проследи цепочку зависимостей и объясни, почему всё падает».

Т‑Технологии. Когда строки кода перестают быть метрикой

Александр Краснов, CTO T‑Insurance, Т‑Технологии

В Т‑Технологиях на этот вопрос ответили методично: сначала определили, что именно нужно измерять, и только потом начали масштабное внедрение. Методологической основой стал фреймворк SPACE, который описывает пять измерений разработки:

• Satisfaction — удовлетворённость и выгорание

• Performance — время от коммита до развёртывания и частота изменений

• Activity — количество коммитов, строк кода и открытых MR

• Communication — качество рецензий, работа DevOps и зрелость процессов

• Efficiency — фокус‑время, переключения контекста и длительность адаптации

Фреймворк определяет саму картину. Если смотреть только на строки кода и adoption, вывод будет одним. Если добавить выгорание и когнитивную нагрузку, картина меняется.

По внутренней телеметрии доля разработчиков, которые регулярно используют ИИ, выросла с 17% до 85% за последние 10 месяцев. Число еженедельных пользователей увеличилось с ≈2 тысяч до ≈12 тысяч.

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

Поэтому фокус сместили на DevEx — Developer Experience, то есть на то, как разработчик ощущает рабочую среду и инструменты. Здесь эту метрику рассматривают не как HR‑показатель для отчёта, а как ранний индикатор. Если специалисту неудобно работать с инструментом, он выберет другую среду — и, возможно, другого работодателя.

Оценка выглядит так. Состояние потока измеряют через время от первого коммита до развёртывания и долю фокус‑времени, а не через объём кода. Когнитивную нагрузку — через цикломатическую сложность, размер merge request, число инструментов в одном процессе и длительность адаптации. Качество обратной связи — через скорость первой рецензии и долю нестабильных тестов. Строки кода, число коммитов и длительность ревью в Т‑Технологиях сознательно не считают опорными метриками.

В компании сделали ставку на осознанную адаптацию и добровольное внедрение. Через четыре недели после первого использования функций ИИ‑ассистента 80% разработчиков продолжили работать с инструментом в IDE, а 75% — в веб‑интерфейсе. Логика простая: полезный инструмент удерживает пользователя без принуждения.

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

red_mad_robot. Когда время разработки измеряется часами

Валерий Ковальский, Head of AI, red_mad_robot

Опыт red_mad_robot показывает, как меняется экономика разработки, когда агентный подход доводят до предельной автоматизации.

red_mad_robot — продуктовая студия. Скорость для неё — не факультативная метрика, а часть бизнес‑модели, потому что клиенты платят именно за быстрый выход продукта. Поэтому ИИ с самого начала рассматривали не как эксперимент, а как рабочий инструмент.

Контекст у этого решения жёсткий. К 2030 году дефицит IT‑специалистов в России, по оценке компании, достигнет 1,5 миллиона человек. Один мобильный разработчик обходится более чем в $150 тысяч в год. Средний цикл мобильной разработки занимает от шести месяцев до года. На этом фоне команда поставила вопрос: можно ли собрать мобильное приложение и фронтенд за 48 часов до стадии прототипа и без участия разработчиков? Подход назвали «автономным заводом».

1. бизнес‑аналитик или PM описывает фичи на естественном языке;

2. оркестратор разбивает задачу на подзадачи и направляет их нужным агентам;

3. агенты параллельно генерируют код, прогоняют линтер и пишут тесты;

4. CI/CD, то есть непрерывная сборка и доставка, собирает нативное приложение;

5. QA‑агент запускает автотесты и сверяет скриншоты с эталоном.

Во всей этой цепочке человек остаётся один — ИИ‑инженер, который управляет конвейером и принимает финальное решение.

За три дня команда собрала прототипы сразу на трёх платформах: React для веба, Swift для iOS и Kotlin для Android. В сумме получилось около 80 тысяч строк кода и 208 коммитов. Речь идёт не о наборе экранов, а о рабочем коде с архитектурой, тестами и CI/CD.

Цифры выглядят необычно, поэтому важно правильно их прочитать. Сокращение длительности в 60 раз — это переход от трёх‑четырёх месяцев к 48 часам. Сокращение числа разработчиков в 200 раз не означает массовую замену людей. Оно означает, что задачу, которую раньше шесть специалистов решали четыре месяца, теперь один ИИ‑инженер закрывает за двое суток. Меняется не только скорость, но и сам тип работы: вместо координации команды — управление конвейером агентов.

Стоимость одного API‑запроса к модели Kimi K2 составляет $0,01. Себестоимость прототипа — примерно $27 плюс инфраструктура.

Отдельный слой этой истории — корпоративная безопасность. В качестве основы команда взяла OpenClaw — фреймворк с открытым кодом и более 300 тыс. звёзд на GitHub. Базовая идея проста: агентный инструмент получает корпоративный контекст и работает автономно. Но в корпоративном сегменте этого недостаточно.

В исходной open source‑версии OpenClaw рассчитан на одного пользователя, одного агента и общее рабочее пространство. Между проектами нет изоляции, нет и соответствия 152-ФЗ — российскому закону о персональных данных. Во время аудита Cisco в OpenClaw нашли 512 уязвимостей. Среди них была критическая CVE-2026-25253: RCE через WebSocket, то есть возможность выполнить произвольный код через сетевое соединение. Поэтому в red_mad_robot пересобрали инструмент под корпоративные требования:

• добавили многопользовательский режим с изолированными рабочими пространствами для каждого проекта;

• реализовали усиленную защиту: seccomp‑профили, gVisor‑изоляцию контейнеров и полный аудит действий агента;

• подготовили on‑premise‑версию, то есть установку внутри контура компании, с поддержкой российского законодательства о данных;

• добавили поддержку независимых моделей — Kimi K2 и Qwen3, чтобы не зависеть от одного провайдера.

Разница между OpenClaw из GitHub и OpenClaw после пересборки — это разница между инструментом для личного использования и инструментом, который можно внедрять в банке или госкомпании. В корпоративной среде такой «паспорт» — не украшение, а обязательное условие.

Главный вывод из этого кейса связан не только со скоростью. Ускорение в 60 раз — это не просто «делаем то же самое быстрее». Появляется другой класс задач, который раньше не сходился по экономике: проект стоимостью 1,5 миллиона рублей при агентном подходе может стоить 50 тысяч. Меняется и процесс, и сам круг задач, которые бизнес готов брать в работу.

Если собрать все выступления в одну линию, картина получается такой: компании сначала выстраивают инфраструктуру AI‑driven разработки, затем сталкиваются с человеческими ограничениями, после этого перестраивают production‑среду под агентный режим — и уже на этой основе меняют не только скорость, но и саму экономику выпуска продукта. Разработчик в этой схеме всё реже выступает исполнителем отдельных операций и всё чаще становится постановщиком намерения, редактором результата и управляющим контуром агентов.

Поэтому горизонт Zero‑Friction PDLC — не футурология, а практический вопрос: успеют ли компании и сами разработчики подняться на следующий уровень абстракции, не накопив при этом технический долг в людях.