Как мы делали презентацию про ИИ-агентов для VS Code без единого слайда — и совет директоров наконец сказал «да»

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

Мы позвонили и сказали: давайте вообще без слайдов.

Почему обычная колода не работала

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

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

Ни один из этих вопросов слайдами не закрывается. Их закрывает демо, которого на встрече не было.

Первая идея была плохая

Мы честно сначала пошли по проторенной дорожке. Взяли open-source проект, поставили ИИ-агент на компьютер, записали видео, вставили в презентацию. Показали клиенту. Он посмотрел, вздохнул:

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

Он был прав. Демо на чужой репе — это не демо, это ролик. Совет директоров смотрит такое ровно с тем же уровнем доверия, что и рекламу.

Тогда мы предложили странную вещь: провести встречу как рабочую сессию. Проектор, ноутбук, реальный монорепо клиента, реальная задача из их трекера. Никаких слайдов вообще. Час живой работы ИИ-агента прямо в VS Code, на настоящем коде компании. Директор согласился не сразу — было страшно, что что-то сломается на публике. Мы договорились, что берём задачу заранее, прогоняем её в песочнице, но на встрече показываем «как в первый раз», и если пойдёт не так — честно комментируем почему.

Как готовили стенд

VS Code с расширениями для агентов — базовая часть. Дальше начинается интересное: чтобы агент не был «умной автодополнялкой», ему нужны руки. Руки — это MCP-серверы.

Мы подняли для клиента несколько:

• MCP к их трекеру задач — чтобы агент читал тикет по номеру и понимал контекст;
• MCP к их монорепо — с индексом по модулям и правилами, где что лежит;
• MCP к их базе, только на чтение и только через отдельную роль — чтобы агент мог заглянуть в схему, но никак не в прод-данные;
• MCP-обёртку над их системой сборки — чтобы после правок агент запускал тесты и показывал результат.

Всё это на изолированной ветке, в отдельном воркспейсе, с явным допуском только тех репозиториев, что мы обсудили. Мы отдельно проговорили с ИБ, что этот компьютер — тестовый, доступ у него урезанный, и после демо мы его гасим.

Отдельно про модель. Российский контур, требования по 152-ФЗ у клиента жёсткие, поэтому «взять популярную зарубежную модель» было нельзя даже для демо. Мы взяли GigaChat Pro для рабочего сценария и параллельно локальную Qwen3.8-27B на нашем стенде для сравнения — благо, свежие open-source модели этого размера уже вполне тянут агентные задачи и запускаются на разумном железе. Идея была показать, что выбор моделей есть, и никто не заставляет прибивать компанию к одному поставщику.

Что показывали на самой встрече

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

Дальше говорил уже не консультант, а ИИ-агент в VS Code.

• Прочитал тикет через MCP, пересказал своими словами, как понял задачу.
• Нашёл в монорепо соответствующий модуль отчёта. Показал, какие файлы затрагивает.
• Открыл схему таблицы через MCP к базе, свериллся с моделью данных. Заметил, что фильтр не учитывает архивные склады, и объяснил, почему это может давать расхождение.
• Предложил правку, показал её как обычный диff в VS Code.
• Запустил юнит-тесты через MCP-обёртку над сборкой.
• Собрал описание PR — коротко, по делу, со ссылкой на исходный тикет.

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

Момент с ИИ-агентом на компьютере

Один из директоров задал каверзный вопрос: «А если задача не только про код? У нас же ещё Confluence, схемы, дизайнер что-то присылает в Figma».

Тут мы включили вторую часть демо — ИИ-агент на компьютере, тот самый computer-use подход. Отдельная сессия, отдельная песочница. Агент открыл браузер, зашёл в тестовый Confluence, нашёл описание фичи, вернулся в VS Code и учёл его в правке. Никакой магии — просто скриншоты и клики, но выглядит как работа живого человека, которого научили не отвлекаться.

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

Что зашло, а что мы бы переделали

Совет проголосовал за пилот в тот же вечер. Не потому что мы гении презентации, а потому что перестали её делать. Живой ИИ-агент в их же коде отвечает на вопросы, которые не закрывает ни один слайд.

Но было и то, чего мы не учли.

Один из руководителей команд забеспокоился: «А что мои разработчики будут делать, если инструмент внезапно отвалится?». Мы про это на встрече говорили общими словами, а надо было показать: агент — это ассистент, а не костыль, и код никуда не убегает из репозитория. В следующий раз мы будем это проговаривать до того, как спросят.

Второй момент — про C и другие «неудобные» языки. У клиента часть кода на C, часть на C++, и они справедливо спросили, как ИИ-агенты работают с языками, где ошибка стоит дороже, чем на TypeScript. Мы показали, что на C агент осторожнее, чаще предлагает разобраться, реже правит молча. Но признались: тут человеческое ревью важнее, чем на веб-фронтенде. Врать, что «модель одинаково хороша везде», — самый быстрый способ потерять доверие инженеров.

Что мы из этого забрали для себя

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

И ещё: не стесняйтесь показывать пределы. Место, где ИИ-агент делает ошибку и вы её ловите — это самая убедительная часть демонстрации. Там появляется главный вопрос совета директоров: «А как вы это встроите в наши процессы?». Именно тот вопрос, ради которого всё и затевалось.

Похожие статьи

• «А ваш ИИ-агент это умеет?» — вопрос, из-за которого мы разложили агента на скиллы
• ИИ-агент, который работает сам на ноутбуке: как мы выбирали open-source модель после августовских релизов
• Что такое сеть ИИ-агентов простыми словами: как мы собрали команду из пяти ролей для разбора техзадания
• Внутренняя платформа для создания ИИ-агентов: как мы перестали писать один и тот же код на каждого клиента