VTORNIK.Вечер #2: саммари выступлений

30 сентября мы провели второй VTORNIK.Вечер в рамках серии бесплатных оффлайн мероприятий о внедрении AI в организациях. На мероприятии присутствовали СЕО и CDO компаний, технические руководители, AI-leaders, аналитики, ML-инженеры, разработчики и др. В программе Вечера было два доклада спикеров, которые несколько лет назад проходили образовательные программы по большим данным в компании, где основатели VTORNIK.Company работали на тот момент. С тех пор мы на связи и не могли не пригласить их поделиться своим опытом.

Основная мысль доклада — современные языковые модели (LLM) и построенные на них мультиагентные системы способны взять на себя рутинные задачи на каждом этапе разработки, от анализа ТЗ до деплоя.

Ключевые тезисы и как они раскрывались:
Спикер последовательно разобрал весь жизненный цикл разработки ПО, показав, как ИИ-агенты могут быть встроены в каждый этап.

1. Анализ требований: От хаоса к структуре
Тезис: ИИ-агент может взять на себя самую неблагодарную работу — разбор технического задания, будь то многостраничный «талмуд» или одна размытая строчка.
Раскрытие: Роман объяснил, что модели можно «скормить» исходный документ. На выходе она сгенерирует структурированные артефакты:

• Бизнес-требования и функциональные требования.
• Реестр рисков.
• Спецификацию и даже предварительную оценку трудозатрат.
• Что особенно важно (и прозвучало в вопросах из зала), агент способен находить и подсвечивать противоречия в требованиях, что экономит недели на старте проекта.

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

3. Генерация кода: Почему у LLM это так хорошо получается?
Тезис: Языковые модели отлично пишут код, потому что программный код, в отличие от естественного языка, имеет очень ограниченный и строгий «словарик».
Раскрытие: Спикер подчеркнул, что задача LLM — предсказать следующее слово (токен). В программировании выбор следующих «слов» гораздо более детерминирован, чем в человеческой речи, что делает генерацию кода высокоэффективной. Для повышения качества агент должен работать с контекстом всей кодовой базы (через векторизацию и RAG-подход), чтобы новый код органично вписывался в существующий проект.

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

• Сначала генерируется код.
• Затем из него извлекается «синтаксическое дерево» (сигнатуры функций, классы).
• И уже на основе этой структуры другой ИИ-агент пишет релевантные тесты.
• Таким же образом агент может проверять код на соответствие внутренним стандартам (статанализ), отлавливая до 70-80% стилистических ошибок, что, по словам Романа, превосходит эффективность даже опытного тимлида.

5. Деплой: Самая консервативная область под угрозой
Тезис: Задачи DevOps (написание Dockerfile, скриптов для развертывания) автоматизируются проще всего.
Раскрытие: Спикер с юмором отметил, что DevOps-инженеры часто наиболее скептически относятся к таким системам, так как их работа максимально алгоритмизирована и легко поддается автоматизации с помощью ИИ-агентов, которым можно просто дать задачу: «Вот продукт, разверни его».

Как это работает вместе: Оркестрация агентов

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

• ReAct (Reason + Act): Агент анализирует ситуацию, действует, анализирует результат и снова действует.
• Self-ask агенты: Работают как любознательные исследователи. Получив сложный вопрос, они: разбивают его на простые части, отвечают на каждую часть отдельно, собирают все ответы воедино.
• Plan-and-Execute: Наиболее подходящий для разработки. «Агент-оркестратор» получает задачу, декомпозирует ее на подзадачи (написать модуль, покрыть тестами, задеплоить) и распределяет их между специализированными агентами (агент-разработчик, агент-тестировщик и т.д.).

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

Барьер №1: Люди
По мнению Александра, человеческий фактор — это первое и самое очевидное препятствие. Он разделил проблему на три составляющие:

Отрицают. Сотрудники и менеджеры просто не верят в технологию, не видят ее потенциала или считают очередной модной игрушкой.
Как с этим быть? Убеждать с помощью успешных кейсов и бенчмарков конкурентов или «заставлять» через постановку конкретных KPI от высшего руководства.

Боятся. Страх здесь не в том, что «AI заменит меня», а в более приземленных вещах:

• Потеря статуса: Оптимизация процессов приведет к сокращению команды и бюджета.
• Страх ошибки: AI-проекты высокорискованны, а в корпоративной культуре за неудачу часто наказывают.

Как с этим быть? Создавать культуру, толерантную к экспериментам, и доносить, что внедрение AI — это вопрос конкурентоспособности, а не просто проект «для галочки».

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

Барьер №2: Организационный сетап
Даже если люди готовы, сама структура компании может стать непреодолимой стеной.

Завышенные ожидания. Руководство, начитавшись новостей, ждет магии.
Как с этим быть? Тактически — привязывать бонусы менеджеров к реалистичным целям AI-проектов. Стратегически — разрабатывать и защищать полноценную AI-стратегию, которая превращает размытые ожидания в конкретные обязательства по ресурсам и результатам.

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

Неполная реализация потенциала («Потемкинские деревни»). У компании есть один микроскопический AI-проект, сделанный стажером три года назад, который используется как ширма. На все предложения о развитии следует ответ: «У нас уже есть искусственный интеллект, отстаньте».
Как с этим быть? Вводить метрики реального проникновения AI в бизнес-процессы (как это делают в Сбере) и ставить амбициозную большую цель, которая заставит двигаться вперед, а не стоять на месте.

Барьер №3: Технологический ландшафт
По словам Александра, это самый сложный и болезненный барьер, о который разбивается половина всех выживших идей.

Встраивание в legacy-системы. Новый блестящий AI-инструмент нужно интегрировать со старым, неповоротливым софтом. В итоге скорость всей системы определяется ее самым медленным элементом. Консультанты показывают красивое MVP за 2 месяца, а реальное внедрение в промышленные системы занимает полтора года.
Как с этим быть? Защищать честные бизнес-кейсы, которые включают в себя реальную стоимость интеграции, а не только разработки прототипа.

Качество и доступность данных. Данные либо недоступны (например, логи хранятся всего 2 дня), либо их качество не позволяет строить модели.
Как с этим быть? Проактивная работа CТO/CDO. Нужно не ждать, пока понадобятся данные, а заглядывать в будущее и отвечать на вопрос: «Какие данные нам будут нужны через год для реализации бизнес-стратегии?».

Доступность инфраструктуры. Из-за долгих циклов бюджетирования получить нужные серверы (те же GPU) можно в лучшем случае через год. А служба безопасности блокирует использование гибких облачных решений из-за страха утечки данных.
Как с этим быть? Продвигать гибридную инфраструктурную модель (on-prem + cloud) и целенаправленно работать с «кибербезом», чтобы научиться вычищать и анонимизировать данные для безопасного использования во внешних сервисах.

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

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

Отдельная благодарность нашим партнерам, компании «Virtu Systems», за возможность провести этот митап в их гостеприимном офисе.