AI Dev Day — AI лихорадка продолжается

Очнулись...

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

А поскольку я уже давно хотел посетить конференцию на эту тему, то к моей радости подоспело таргетированное предложение — конференция AI Dev Day от Яндекса. Знаю, что у Яндекса нет своего стадиона, поэтому количество мест для офлайн-приглашений всегда ограничено, но обычно мне вежливо присылают ссылку на прямой эфир. Зарегистрировался. И вдруг — приглашение на офлайн! Обрадовался.

Атмосфера

Над входом красовалась вывеска — «Экстрополис». Получил бейдж, прошел в зал, осмотрелся. Заглянул в туалет — кувшина не обнаружил, но зато есть гигиенический душ: видимо, чтобы подмываться после особо тяжелых Agile-сессий.

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

Внимание привлекли вывески-указатели с именами известных предпринимателей XIX и XX веков: Морозов, Саввин и другие. Может, это таблички с названиями офисов? Но думаю, для простых смертных слишком круто. Потом стал припоминать фамилии из истории государства Российского. Нужно будет уточнить, зачем они висят и куда ведут эти указатели, — наверняка найдется повод для еще одной статьи.

Начало: строго по таймингу

Ровно в 13-00, ведущий вышел на сцену и, выбросив несколько шуток, объявил первого докладчика.

Доклад 1: Андрей Попов (Яндекс) — AI в Яндексе. Стали ли мы продуктивней за год?

• Основные тезисы:

  • За год прошли путь от прототипов к фокусу на направлениях с измеримым эффектом.

  • Ключевая цель: Экономить время разработчиков, которое они тратят на код (30-40%) и коммуникации (30%).

  • Adoption: Внутренний ассистент (YCA) используют ~57% инженеров (в бэкенде/фронте — 60-75%). Ключевые драйверы: обучение, удобство, доступность инференса, безопасность.

  • Инфраструктура: >90% инфраструктуры покрыто MCP-серверами (трекер, поиск, данные).

  • Эффекты:

    • Разработчики, использующие ИИ, коммитят на 10% больше (в Go/Python/JS — до 20%).

    • Доля кода, сгенерированного в агентском режиме — 23% (среди активных пользователей).

  • Бенчмаркинг: Используют внутренний бенчмарк ARCE (аналог SWE Bench) на своих задачах. Топ-модели — Claude, но open-source модели быстро догоняют. Модели пока плохо работают с внутренним тулингом.

  • Конкретные треки:

    • Поиск информации: Внутренний чат-бот снизил посещаемость страниц на 50%. Решение сложных техзадач агентами сократилось с 20 до 2 минут.

    • Code Review: Фокус на автоматическом поиске и предложении фиксов для бизнес-логики.

    • Тестирование: Генерация чек-листов и тест-кейсов удвоила прогон тестов. Автовыполнение UI-тестов.

  • Измерение эффекта: Используют формулу целевое действие время коэффициент качества. Суммарная экономия — 42 000 часов в месяц (~2%).

  • Будущее (AI First): Переход к метрике disengagement rate — когда агент работает автономно, а человек подхватывает управление лишь изредка.

  • Вывод: ИИ уже полноценно закрывает часть работы джуна/мидла. Профессия меняется, специалисты "сливаются" (могут делать задачи вне своей прямой компетенции).

• Вопрос:

  • Как измеряете затраты на поддержку кода, сгенерированного ИИ? Пока единой метрики нет. Видят как негативные эффекты (снижение качества), так и нормальные кейсы в разных командах.

Доклад 2: Саша Лукьянченко (Авито) — Внедрение GenAI в разработке

• Основные тезисы:

  • Сдвиг парадигмы: Перешли от идеи ассистентов в IDE к агентам, которые сами меняют код.

  • Модели: Дообучать открытые модели под специфику компании оказалось менее эффективно, чем давать SoTA-моделям (Claude и др.) хороший контекст.

  • Реальность: Несмотря на хайп, ускорения всего цикла разработки (cycle time) пока почти не видно (макс. 4-5% в отдельных командах).

  • Почему? Кодинг занимает лишь 32% времени разработчика. Инвестировать нужно во весь цикл. К тому же, 30% кода и так генерилось детерминированно.

  • Сетап: Open-source агенты + MCP-серверы (доступ к кодовой базе, документации, API) + внутренние и внешние модели. Ключевой фокус — one-button setup для разработчика.

  • Измерение:

    1. Adoption (не дает ценности бизнесу).

    2. AI-assisted PRs (доля изменений, созданных с помощью ИИ).

    3. Cycle Time (конечная бизнес-метрика, но очень устойчива к изменениям).

  • Подход к прогрессу: Создание внутреннего SWE-бенчмарка из специфичных для Авито задач (от рутины до продуктовых фич). Постепенное "закрашивание" этого бенчмарка связкой агент + модель + контекст. Параллельно — глубокая работа с несколькими командами для реального улучшения cycle time.

  • Что уже хорошо умеют агенты: Автотесты, атомарная рутина, декомпозиция задач, помощь в code review (20-40% правок после авто-ревью).

  • Планы: Снижение числа итераций human-in-the-loop, улучшение работы со "зрелым" кодом (браунфилд), агенты на всей цепочке создания продукта.

• Вопросы:

  • Как боретесь с тест-хакерством моделей? Сейчас это контролируется человеком на ревью. В будущем потребуются гейты, валидирующие не код, а функциональное поведение/спеки.

  • Как заставляете разработчиков ревьюить код от модели? Никак. Это общая проблема. Решение видится в автоматизации ревью агентом (первичный фильтр) и переходе к валидации спецификаций, а не кода.

Доклад 3: Саша Лукьянов (Озон) — Развитие кодовых ассистентов

• Основные тезисы:

  • Платформа: Опираются на собственную GPU-облачную платформу (2 кластера по 20k флопс).

  • Сетап: Развернуты open-source модели (основная — MiniMax, также DeepSeek) для агентского кодинга. Используются Continue и open-source CLI-агенты.

  • Авторевью кода: Очень востребованный продукт (интеграция с GitLab), пришлось даже ограничивать автоматический запуск из-за наплыва пользователей.

  • Доступ к моделям: Через LM-прокси с роутингом по сценариям (большая модель для сложных задач, маленькая для тестов). Это упрощает смену моделей под капотом.

  • Числа: Агентским ассистентом ежедневно пользуются 1100 человек (~25-30% разработчиков). Резкий рост после перехода на связку MiniMax + open-source CLI-агент.

  • Работа с моделями: Быстрая адаптация новых open-source моделей. Оценка через открытые бенчмарки и внутренние сценарии (от простых тестов до сложных задач, с которыми MiniMax пока не справляется).

  • Внешние модели: Пока не дают широко из-за рисков безопасности (утечка кода), но качество их выше, поэтому рассматривают этот вариант, взвешивая риски и стоимость.

  • Планы:

    1. Контекст: Наполнение моделей внутренними знаниями (кодстайлы, библиотеки).

    2. Экосистема: Развитие MCP и объединение с другими агентами (например, в Confluence).

    3. Эффективность: Умный роутинг задач между моделями.

    4. Аналитика: Смещение от техметрик к измерению бизнес-ценности (time-to-market, пропускная способность команд) и отслеживанию влияния на качество (дефекты, инциденты).

    5. Люди: Обучение и вовлечение разработчиков, подготовка процессов к новой реальности.

• Вопросы:

  • Как сравнимы экономически раннинг своих моделей и плата за токены? Точного сравнения пока нет. Использование внешних моделей известно как очень дорогое. Основная причина консервативного подхода — безопасность, а не цена.

  • Почему MiniMax, а не GLM? MiniMax меньше и быстрее. GLM сейчас тестируют, планируют переводить часть нагрузки на нее.

Доклад 4: Анна Громова (Т-банк) — Измерение AI в SDLC: от Adoption к ценности для бизнеса

• Основные тезисы:

  • Фреймворки для оценки SDLC:

    • DORA: Оценивает конвейер (скорость и надежность поставки).

    • SPACE: Оценивает людей (удовлетворенность, перформанс, коммуникации).

    • DevEx: Оценивает комфорт разработчика (когнитивная нагрузка, состояние потока).

  • В Т-банке объединили эти подходы в единое "дерево метрик" для оценки поставки кода.

  • Adoption: Встроенный AI-ассистент имеет adoption 50-75% в IDE и 75% в инструментах аналитики.

  • Продуктовый подход: Сначала считали базовые метрики (adoption, retention, доля сгенерированных артефактов). Затем перешли к оценке пользовательских сценариев (например, генерация юнит-тестов).

  • Пирамида метрик:

    • Верх: Бизнес-метрики SDLC (time-to-market, надежность).

    • Середина: Метрики пользовательских сценариев (закрыта ли потребность?).

    • Низ: Технические метрики ассистента (скорость работы модели).

  • Результаты опросов: Люди отмечают рост продуктивности. Сеньоры скептичны, джуны категоричны. Самые активные пользователи — вовлеченные в профессию разработчики.

  • Влияние на метрики:

    • Медианное время merge time снизилось на 12%. У команд-"амбассадоров" lead time за год снизился на 30%.

    • Количество пользователей, генерирующих юнит-тесты, выросло в 4 раза (12% от всех запросов).

  • Вывод: ИИ действительно может сокращать время, но важно перестраивать процессы, иначе узкое горлышко просто сместится. Массовая генерация кода ИИ может кардинально изменить процессы (например, code review).

• Вопросы:

  • Какими моделями пользуетесь? Разными, под разные задачи, как внутренними, так и внешними.

  • Как меряете сложность поддержки сгенерированного кода? Через "чудо-дерево" метрик. Если с кодом проблемы, это отразится на инцидентах, change fail rate, откатах деплоев.

  • Как боретесь с тест-хакерством? Проблемы с юнит-тестами (нерепрезентативными, но проходящими) проявятся в метриках падающих пайплайнов.

Обед

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

Организаторам пришлось срочно дозаказывать еду: предусмотренные запасы смели за час. Запасы пополнили уже к этапу нетворкинга.

Я, кстати, честно нагулял аппетит, внимая докладам, но моя порция ушла кому-то более шустрому. Впрочем, контент оказался сытнее любого сэндвича — двигаемся дальше.

Доклад 5: Серёжа Бульдяев (Яндекс) — Как мы развиваем AI-ассистентов в Яндекс Code Assistant

• Основные тезисы (на примере двух агентов):

  • Часть 1: Агент в VS Code

    • Почему свое, а не готовое (Cursor, etc.): Нужна интеграция с внутренними сервисами, гарантия развития нужного функционала, контроль доступности, безопасность.

    • Стратегия: Не изобретать велосипед, а сделать форк open-source решения и дорабатывать его.

    • Борьба со скепсисом и рост adoption:

      1. Бесшовный вход: Авторизация, доступ к моделям, MCP "из коробки".

      2. Маркетплейс артефактов и пресеты: Централизованное хранение рул, скилов, MCP. Пресеты — как "линтеры" для агентов (кто-то настроил — все используют).

      3. Активный маркетинг и поддержка: Гайды, курсы, посты во всех каналах, круглосуточный чат поддержки ("нет неотвеченных вопросов"), воркшопы на реальных задачах.

      4. Прозрачная политика безопасности.

    • Результат: Рост аудитории после каждого этапа (релиз фич, воркшопы).

  • Часть 2: YQL-агент (для написания запросов в веб-интерфейсе)

    • Проблема: Модели не знают YQL (диалект SQL).

    • Кубики и их проблемы:

      • MCP: Важно не просто обернуть API, а делать качественные тулы.

      • Промты: Проблема фейкового тулколлинга (модель "думает", что вызвала тул, но не вызывает). Решение — пример вызова в системном промте.

      • RAG: Проблема неактуальной документации. Решение — административное (владелец сервиса следит) и системный разбор фидбека.

    • Контроль качества:

      • Оффлайн-метрики: Валидационный датасет (юнит-тесты на стероидах). Важно валидировать сами метрики (пример: слабая модель решала задачи за много итераций, метрика "успешность" не падала, добавили метрику "количество обращений к модели").

      • Пирамида метрик:

        1. Базовые (доступность, время ответа).

        2. Продуктовые (аудитория, ретеншн) — меняются медленно.

        3. Сценарные метрики (самые чувствительные): строятся на основе customer journey map (например, % успешных запусков, % запусков со 2-го раза, % неисправленных пользователем запросов).

        4. Deep-dive анализ: Регулярный ручной разбор всей обратной связи (логи, поддержка) для выявления точечных проблем и создания новых метрик (частота вызовов валидации, фейковый тулколлинг).

• Вопросы:

  • Какой агент форкнули? Roo Cline (на тот момент был одним из самых популярных).

  • Какой основной тип агентов в YCA? Дают инфраструктуру (маркетплейс), а команды сами выбирают фреймворки (React, Plan-and-Execute и т.д.) под свои задачи.

Доклад 6: Максим Швиденко (Сбер) — AI for Designers. Мультиагентная система Аида

• Основные тезисы:

  • Проблема: Ручное ревью дизайна — долго (30 мин - 2 ч на экран), дорого, зависит от человеческого фактора, нет автоматической обратной связи. Это создает узкие горлышки в дизайн- и код-ревью.

  • Решение: Мультиагентная система Аида (AI for Designers) с замкнутым контуром качества.

  • Архитектура: 3 столпа (Человек + Алгоритмы + ИИ)

    • Единая база знаний (RAG): Содержит компоненты дизайн-системы, гайдлайны, токены и результаты предыдущих работ агентов. Это "общая касса" для улучшения системы.

    • Агент-генератор:

      1. Формализует и очищает бизнес-требования.

      2. Генерирует user flow и JSON-спецификацию каждого экрана (компоненты, состояния, координаты).

      3. Алгоритм рендеринга собирает макет в Figma из компонентов дизайн-системы.

    • Агент-ревьюер:

      1. "Нарезает" макет на слои (компоненты, сетка, UX-политика, цвета).

      2. Сначала простая алгоритмическая проверка (попадание в сетку).

      3. LLM используется для сложных проверок (например, анализ цветов градиентов, оценка общей визуальной гармонии).

      4. Выставляет оценку по каждому свойству с динамическим весом в контексте макета (критично для кнопки оплаты, не критично для кнопки в футере).

      5. Результат (положительный или отрицательный) идет обратно в базу знаний.

    • Агент-саппорт:

      1. Гибридный поиск (векторный + BM25) по базе знаний.

      2. LLM генерирует ответ.

      3. Система проверки уверенности: Если модель неуверена или есть галлюцинации, ответ не показывается пользователю, а запрос эскалируется эксперту для пополнения базы знаний.

  • Проблемы ("ложки дегтя"):

    1. Консерватизм: Система генерирует слишком педантичные, "экселевские" интерфейсы без креатива.

    2. Галлюцинации: Борются через систему проверки уверенности, но полностью не победили.

    3. Убийство креатива: Дизайнеры могут соглашаться с консервативными решениями, чтобы быстрее закрыть задачу.

  • Решение проблем: Human-in-the-Loop. Человек может эскалировать свой "креативный" макет лиду, и он попадает в базу знаний как положительный пример нарушения правил.

  • Результаты (на пилотной дизайн-системе):

    • Ревью: с 1 часа → до 2 минут.

    • Создание нового макета: с 16 часов → до 5 минут.

    • Устранение замечаний: с 8 часов → до 5 минут.

    • Поддержка: с 8 часов → до 1 минуты.

• Вопросы:

  • Это все работает на GigaChat? Да, все на GigaChat, чтобы не питать лишних ожиданий от других моделей.

  • Почему проект появился в департаменте недвижимости? Спикер работает в недвижимости, но это не мешает продвигать крутые идеи внутри компании.

Доклад 7: Саша Фишер (Яндекс) — AI в SRE (Яндекс Go)

• Основные тезисы:

  • Цель: Сократить MTTR (время восстановления) и MTTRC (время нахождения корневой причины) за счет ИИ. Особенно важно для транзакционных сервисов (такси, лавка), где downtime = потерянные заказы.

  • Проблема: SRE-инженеры в Яндексе — это сеньорные разработчики с глубокой экспертизой в домене. Их мало, и они дороги. ИИ позволяет восполнить дефицит.

  • Бенчмарки: Мировой уровень точности нахождения root cause (рудкоза) — ~40%. Это "святой Грааль" для таких систем (по опыту Meta, Microsoft, Google).

  • Проект SRE GPT:

    • Мультиагентная система с оркестратором, интегрированная в инфраструктуру Яндекса.

    • Сценарии:

      1. "Холодная фаза": Автоматический анализ и заполнение постмортемов для 400 инцидентов в сутки (раньше 99% не анализировались). Экономия ~30 минут на инцидент.

      2. "Горячая фаза": Помощь в реальном времени (автостатусы в чатах, ответы на вопросы "что сломалось?").

      3. Нахождение Root Cause: Самый сложный сценарий.

  • Необходимые предпосылки (иначе проект не делать):

    • Свое облако и платформа Observability (логи, алерты, метрики по любому сервису).

    • Каталог сервисов (для микросервисной архитектуры).

    • Аудит всех событий на проде (релизы, конфиги, эксперименты — 70% инцидентов из-за изменений).

    • Граф зависимостей между сервисами.

    • Свой инференс или доступ к мощным моделям.

  • Проблемы и решения:

    • Язык: Промты на русском не работают (нет устоявшейся терминологии в SRE, меньше данных). Перешли на английский.

    • Потеря контекста: Используют "блокнот" (Memory Bank) для сохранения контекста и todo-лист, по которому агент действует строго последовательно.

    • Навыки (Skills): Используют Clio Skills — подключаемые пакеты знаний (анализ логов, алертов, событий).

    • Memory Bank для разных бизнесов: Хранит не только словарь терминов, но и граф знаний (например, "водитель влияет на цену").

  • Результаты и планы:

    • Точность нахождения root cause сейчас ~40-50% на части инцидентов, но пока не укладываются в целевое время 5 минут.

    • 17 февраля 2024 был прорыв: система на 100% точно указала на ошибку в коде, но ответила дольше 5 минут.

    • Этапы:

      1. Сейчас: сказать, что сломалось и почему.

      2. План: добавить кнопки для митигации (откатить, повысить лимит).

      3. 2027 год: система сама находит и чинит проблему (осторожно, чтобы не повторить опыт Amazon).

• Вопросы:

  • Какие модели используете? Open-source и YandexGPT под разные сценарии.

  • Как масштабируете на все локации? Пока все централизовано, готовы масштабировать при необходимости.

  • Насколько полный доступ у системы? Только на чтение (анализ логов). Вмешиваться в инфраструктуру не может.

  • Что по метрикам удалось улучшить? Сильно сэкономили время на постмортемах. По root cause кардинальных улучшений пока нет, цель — к концу года.

Заключение

Эпидемия AI-лихорадки в самом разгаре. Из каждого утюга вещают о конце света для разработчиков. Но, побывав в эпицентре событий — на конференции AI Dev Day, — понимаешь: конца света не будет. Будет жестокая, но увлекательная эволюция.

Да, если вы все еще пишете каждый юнит-тест вручную, тратите часы на поиск информации по внутренней вики или рисуете пиксели в Figma без помощи агента, вы рискуете остаться за бортом. Компании уже получили измеримый эффект от внедрения ИИ. В Авито и Т-банке cycle time потихоньку ползет вниз. В Яндексе код, сгенерированный в агентском режиме, — обычное дело. SRE-инженеры в Яндекс Go экономят часы на постмортемах. И это только начало.

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

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

А что думаете Вы?