Писать код — уже не главное: как ИИ меняет инженерные команды и зачем это знать бизнесу

CTO Яндекс Карт, Т-Банка, X5 и Циана — о том, что происходит с разработкой прямо сейчас.На технической конференции AHA’26, которую 22 мая провела команда «Матемаркетинга», CTO крупнейших технологических компаний обсудили AI-first разработку на основе того, что уже происходит в их командах. 

Анатолий Панов (CTO Яндекс Карт), Владимир Ионов (CTO Т-Банк Покупки), Ярослав Тулупов (директор по разработке X5) и Максим Нечаев (Head of AI, Uzum Fintech) говорили о реальных кейсах, новых архитектурных решениях и о том, где граница, которую агентам пока не переступить. Модерировал дискуссию Максим Радюков, CIO Циана.
Реклама на New Retail. Медиакит

Роль разработчика: три стадии за три года 

Переход к AI-инструментам в инженерных командах идет снизу — без специальных программ и KPI по адопшену. Разработчики, которые годами игнорировали документацию и тесты, теперь пишут их сами: качество работы модели напрямую зависит от того, насколько хорошо описан контекст. AI сделал то, чего не смогли годы внутренних регламентов.

За этим стоит более широкий сдвиг, который Владимир Ионов описал через три стадии: «Три года назад мы считали главной компетенцией сильного разработчика — писать код. Сейчас мы на стадии, когда компетенция перекочевывает в сторону ревьювить код. А дальше — уметь ответить на вопрос, почему должно быть сделано именно так. Уметь проектировать контекст».

Практически это выражается в spec-driven development: сначала совместно с моделью проектируешь решение и фиксируешь спецификацию, потом реализуешь. Анатолий Панов добавил: без знания Clean Architecture, TDD и принципов микросервисов невозможно правильно сформулировать задачу для модели. Лучшие инженерные практики, которые годами оставались уделом немногих, становятся рабочим стандартом.

Что уже работает: кейсы компаний

Владимир Ионов, до перехода в Т-Банк работавший в Авито, привёл конкретный пример: маркетинговый лендинг для распродажи, который раньше делали пять дней, теперь собирает один тимлид за день. В X5 система автоматической документации работает на локальной внутренней модели — 90% сгенерированного текста не требует правки руками. 

В Uzum за неделю-две можно написать решение, запустить пилот на небольшом трафике и получить первые результаты; есть системы, написанные агентом и работающие в продакшене. В Яндексе команда Браузера переписала страницу настроек с нуля, а коллеги из Такси собрали новую админку для управления сетями. 

Максим Радюков привел цифры по Циану как ориентир: к началу 2026 года 75% разработчиков используют модели в том или ином формате, около 30% кода пишется с помощью AI. По его словам, интереснее теперь смотреть не на сам факт использования, а на глубину: сколько дней в неделю разработчик работает с моделью и какой процент строк пишется с агентами.

Инфляция кода и новое бутылочное горлышко

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

Ярослав Тулупов показал один из рабочих ответов на этот вызов: когда в его pet-проекте Claude Code начал ломать написанные им же фичи, эксперт запустил систему из пяти агентов — один пишет новые фичи, второй гоняет тесты, цикл повторяется.Тестирование тоже автоматизируется, но полностью без людей пока не работает.

Параллельно меняется сама ценность кода. Код как набор классов и функций теряет самостоятельный вес — он переходит к спецификациям, архитектурным описаниям, контрактам между сервисами. Максим Нечаев смотрит на это прагматично: компании начнут выбрасывать код — разбивать системы на части с четкими контрактами и переписывать их с нуля под новые модели. «Мы перестаем быть заложниками своей архитектуры» — отметил спикер.

Платформизация как архитектурный ответ

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

Максим Радюков описал архитектуру Циана через три слоя с разным уровнем проникновения AI:

• верхний, продуктовый — максимально агентский, гибридные команды из людей и агентов;
• средний — общие платформенные решения для вертикалей;
• нижний, инфраструктурный — минимальное проникновение AI.

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

Куда агентов не пускают

Финтех-процессинг, персональные данные, код с ключами доступа — здесь AI-инструменты на полную мощность не используют нигде из участников дискуссии. Максим Нечаев обозначил верхнюю планку риска: критичные системы уровня банковских транзакций или управления безопасностью в аэропортах. 

Ярослав Тулупов добавил инфраструктуру: «Я пару раз локально развернутый Docker просто удалял. Почему? Непонятно. Я не просил — он удалил, потому что ему так было проще».

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

Ответственность: то, что нельзя делегировать

Когда код пишет агент, возникает вопрос, у которого пока нет универсального ответа: кто отвечает, если что-то пойдет не так? «Ответственность — это единственное, что мы не сможем полностью делегировать. Когда в три ночи что-то упало, нужен кто-то, кто понимает, как это все устроено, потому что по логам понять причину невозможно — это следствие» — говорит Владимир Ионов. 

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

Что меняется для продуктовых команд

Трансформация затрагивает не только инженеров. Когда все компании смогут генерировать примерно одинаковый код с одинаковой скоростью, конкурентное преимущество сместится. Владимир Ионов: «Задача продакта максимально уйдет в сторону того, как получить гипотезу, которая зайдет пользователям, — зная, что 200 команд из 200 компаний прямо сейчас за то же время могут сгенерировать такой же код и такую же фичу».

Специалисты описали одну из идей, которую в Т-Банке рассматривают как инструмент для продактов: MCP-аналитик — агент, знающий все эксперименты, метрики, прокси-метрики и сезонность компании. Продакт получает возможность проверять идеи до того, как они уходят в разработку. 

Отдельным итогом дискуссии стал тезис о культуре. Максим Радюков обозначил барьер, о котором говорят реже: люди, привыкшие быть экспертами, чувствуют себя некомфортно рядом с AI. Компании, где можно открыто сказать «я не знаю, как с этим работать» и получить нормальный ответ, внедряют быстрее тех, кто делает ставку только на энтузиастов.

В 2026 году модели дешевеют, агентские пайплайны усложняются, границы автоматизации сдвигаются каждые несколько месяцев. При этом дефицитом становится не технический навык, а люди, которые понимают архитектуру достаточно глубоко, чтобы ставить задачи, проверять результат и отвечать за систему в три ночи, когда что-то упало. Именно это участники дискуссии называли новым запросом к инженерной команде на AHA’26. 

Благодарим пресс-службу Матемаркетинга за предоставленные комментарии экспертов. 

Для NEW RETAIL

Источник: new-retail.ru