Всем привет! Меня зовут Станислав Денисов, я ML-инженер в компании «Инфосистемы Джет».

Вайбкодинг уже стал неотъемлемой частью разработки. Claude Code отвечает за 4% всех публичных коммитов на GitHub, а в Google 50% кода генерируется ИИ. Это не временная мода — технологии пришли надолго.

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

Сегодня протестируем Yandex Code Assistant на задаче, где важна безопасность: создание MVP сервиса для одноразовой передачи секретов, как в Privnote или Yopass. Задача выглядит как простой CRUD, но под капотом — множество уязвимостей, если не продумать архитектуру и защиту.

Цель — понять, насколько ассистент автономен, где он справляется, а где без человека не обойтись.

Почему Yandex Code Assistant

Наша команда регулярно использует Cursor, GitHub Copilot и Claude Code. С 2024 года Yandex SourceCraft Code Assistant стал не просто подсказчиком, а полноценным агентом в SDLC — поэтому тестируем его на реальной задаче.

Задача с подвохом: написать MVP сервиса, где секрет можно прочитать только один раз или до истечения TTL. Если ИИ просто сделает CRUD — получится уязвимый сервис. Интересно, сможет ли ассистент сам продумать threat model и безопасность.

Оболочка агента: роли и визуализация

Проект стартовал с нуля. Ассистент предложил выбрать режим работы. Доступны пять модов:

1. Architect: проектирование до реализации.
2. Code: написание и рефакторинг.
3. Ask: объяснения и ответы.
4. Debug: поиск и исправление багов.
5. Orchestrator: автоматическое управление задачами.

Orchestrator — ключевая фишка. Как в Cursor, он сам переключается между ролями: архитектор, разработчик, тестировщик.

На промпт «Помоги спроектировать MVP… Опиши архитектуру и threat model» ассистент создал 8 markdown-файлов: описал этапы, нарисовал диаграммы, структурировал систему.

После каждого промпта он обновлял внутренний To-Do и шел по нему шаг за шагом.

Особенно удобна визуализация изменений. Встроенный diff показывает, что именно меняется в файлах, с пояснениями к каждому действию.

Под капотом — расширяемость через Model Context Protocol (MCP). Есть скиллы вроде create-mcp-server и create-mode для кастомных ролей. В тесте не использовали, но потенциал есть.

Разбор полетов: успехи и ограничения ИИ

Я дал агенту 10 итеративных промптов — от архитектуры до фронтенда. Основные из них:

• Проектирование: «Спроектируй MVP сервиса для одноразовой передачи секретов. Опиши архитектуру, threat model и меры безопасности».
• Бэкенд: «Сгенерируй backend на FastAPI с SQLAlchemy и SQLite/PostgreSQL. Эндпоинты: создать, получить, пометить как прочитанный, удалить просроченные».
• Безопасность: «Покажи безопасный подход к хранению: шифрование, генерация токена, TTL, одноразовый доступ. Перепиши код и объясни».
• QA: «Напиши pytest-тесты: одноразовое чтение, истекший TTL, неверный токен, повторный доступ, физическое удаление».

Что получилось хорошо

Ассистент отлично справился с рутиной:

• Настроил валидацию через Pydantic с ограничением размера секрета.
• Использовал BackgroundTasks из FastAPI для очистки просроченных записей — без лишних cron-скриптов.
• Добавил In-Memory Rate Limiter как Middleware — защита от брутфорса.
• Сгенерировал docker-compose.yml, Dockerfile и конфиг Nginx.

Код выглядел готовым к деплою. Почти.

Где потребовался человек

1. Шифрование на стороне сервера: ассистент использовал cryptography.fernet с ключом на основе мастер-ключа и ID секрета. Это означает, что администратор с доступом к БД и переменным окружения может расшифровать всё. Для zero-knowledge нужно шифрование на клиенте (Web Crypto API), где ключ передаётся в URL-хеше (#KEY) и не попадает на сервер.
2. TOCTOU-уязвимость: при получении секрета агент делал SELECT, проверял флаг accessed, отдавал данные, потом обновлял запись. При двух параллельных запросах оба могут прочитать секрет. Решение — использовать SELECT ... FOR UPDATE или атомарный UPDATE ... RETURNING.
3. Физическое удаление: ассистент помечал секрет как удалённый, но не удалял зашифрованный текст из БД. Настоящая безопасность требует физического DELETE и, по возможности, крипто-шреддинга — перезаписи данных мусором перед удалением, чтобы не оставить следов в WAL-файлах.

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

Итоги

Yandex Code Assistant впечатлил:

• Режим Orchestrator — удобен и автономен.
• Работа с контекстом — точечные правки без поломки архитектуры.
• Diff-режим — упрощает ревью.
• Инфраструктура — Docker, Nginx, всё на месте.

Но есть нюансы:

• Промпты на русском, а фронт — на английском. Не критично, но странно.
• Без глубокого ревью код нельзя сливать в прод. Как и любой ИИ-ассистент, он не идеален.

Разработчиков ИИ пока не заменит. Но меняет их роль: от писателя кода — к архитектору, ревьюеру и контролёру безопасности.

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

Всем привет! Меня зовут Станислав Денисов, я ML-инженер в компании «Инфосистемы Джет».

Из-за вайбкодинга Хабр пережил уже не один холивар и переживет еще столько же, потому что, судя по всему, он с нами надолго.

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

Ситуация, когда ИИ сам пишет, проверяет и деплоит код по запросу разработчика, уже данность.Claude Code создаёт 4% всех публичных коммитов на GitHub, а в Google заявляют, что50% их кода ー AI-generated. По прогнозам цифры будут только расти, и это само по себе не проблема.

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

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

Спойлер: почти Cursor.

Почему именно Yandex Code Assistant

Наша команда разработки регулярно работает с Cursor, GitHub Copilot и Claude Code.

С 2024 года Яндекс сделал Yandex SourceCraft Code Assistant не просто чатом с подсказками, а уже полноценным агентом, встроенным в SDLC. Поэтому тестировать его будем на реальных задачах.

Я выбрал задачу с подвохом: написать MVP сервиса для безопасной одноразовой передачи секретов, по образу Privnote или Yopass.

На первый взгляд, это простой CRUD: создать запись, отдать ссылку, удалить запись при чтении. Но дьявол кроется в деталях безопасности. Если ИИ просто напишет CRUD-приложение, сервис будет уязвим. Посмотрим, сможет ли ассистент сам продумать архитектуру, threat model и защитить секреты пользователей.

Оболочка агента: роли и визуализация

На старте у нас был абсолютно пустой проект (что неудивительно) и предложение выбрать подходящий режим работы агента.

В Code Assistant есть несколько модов:

1. Architect: проектирование и дизайн до реализации.
2. Code: написание и рефакторинг кода.
3. Ask: ответы на вопросы и объяснения.
4. Debug: поиск и исправление багов.
5. Orchestrator: автоматический координатор задач.

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

В ответ на первый же промпт («Помоги спроектировать MVP сервиса… Опиши архитектуру и threat model») ассистент создал сразу 8 markdown-файлов:

В целом, он грамотно расписал этапы построения, нарисовал архитектурные диаграммы и описал систему.

После каждого моего промпта ассистент обновлял свой внутренний To-Do лист и методично шел по нему:

Отдельно отмечу, как Code Assistant демонстрирует изменения. Встроенный diff-инструмент показывает, что именно агент меняет в файлах, с пояснениями к каждому шагу:

Стандартными ролями кодовый ассистент не ограничивается. Под капотом есть скиллы, как в том же Cursor: create-mcp-server для расширения инструментария агента через Model Context Protocol и create-mode для создания кастомных ролей. В тестировании их не использовали, но упомянуть стоит.

Разбор полетов: с чем ассистент справился, а где человек все еще нужен

Я подготовил пошаговый план из 10 промптов, чтобы провести агента от проектирования до тестов и фронтенда. Логика простая: вести разработку итеративно и не загонять кодового ассистента в жесткие рамки.

Ниже примеры ключевых запросов. Я адаптировал их для статьи, но сохранил суть:

Проектирование: «Помоги спроектировать MVP сервиса для безопасной одноразовой передачи паролей и секретов. Пользователь создает секрет, получает ссылку, секрет можно открыть только один раз или до истечения TTL. Опиши архитектуру, threat model и минимальные меры безопасности».

Бэкенд: «Сгенерируй backend на FastAPI для сервиса one-time secret share. Нужны эндпоинты: создать секрет, получить секрет по токену, пометить как прочитанный и удалить просроченные записи. Используй SQLAlchemy и SQLite/PostgreSQL».

Безопасность: «Покажи безопасный подход к хранению секретов: чем шифровать секрет, как генерировать токен, нужно ли хранить хэш токена вместо самого токена, как реализовать TTL и одноразовый доступ. Перепиши текущий код в безопасном виде и объясни изменения».

QA: «Напиши pytest-тесты для этого сервиса: проверь одноразовое чтение, истекший TTL, неверный токен, попытку повторного доступа и физическое удаление после просмотра».

Качественная и структурированная база

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

Например, настроил грамотную валидацию через Pydantic и не забыл про ограничения, чтобы базу не положили гигабайтным секретом:

А еще догадался, что просроченные секреты нужно как-то вычищать. Вместо того, чтобы городить внешние cron-скрипты на первом же этапе, он использовал BackgroundTasks из FastAPI:

Агент позаботился и о защите от брутфорса ー написал In-Memory Rate Limiter и подключил его как Middleware:

Выглядит так, будто этот код можно заворачивать в Docker (который, к слову, агент тоже написал) и деплоить на прод. Почти.

Где ИИ не смог обойтись без человека

1. Ассистент реализовал шифрование на стороне сервера (через cryptography.fernet). Ключ генерируется на основе мастер-ключа сервера и ID секрета.Сервер знает всё. Любой администратор с доступом к базе и переменным окружения может прочитать базу секретов.Для Zero-Knowledge подходит шифрование на клиенте (Web Crypto API). Ключ передается в URL после хеша (#KEY), браузер не отправляет его на бэкенд. Сервер хранит только зашифрованный набор символов.
2. Эндпоинт получения секрета делает SELECT, проверяет if db_secret.accessed: raise, затем отдает секрет и делает UPDATE accessed = True.Классический TOCTOU (Time-of-Check to Time-of-Use). Если отправить два параллельных запроса в одну миллисекунду, оба прочитают флаг False и вернут секрет. Одноразовый секрет перестал быть одноразовым.В этом случае лучше использовать транзакционные блокировки БД (SELECT ... FOR UPDATE) или атомарный UPDATE ... RETURNING.
3. Когда секрет прочитан, ассистент заботливо ставит secret.deleted = True в базе. При этом сам зашифрованный текст навсегда остается в базе.Секреты должны удаляться аппаратно (физический DELETE). А в идеале крипто-шреддинг: перед удалением перезаписывать колонку с секретом мусором, чтобы не оставить следов даже в WAL-файлах базы данных.

Задача ИИ ー рутинный код и экономия времени человека на базовых задачах. Полной автоматизации разработки не ждем (пока что).

Задача человека ー бизнес-логика, безопасность и контроль. Разработчик может не писать код вручную. Но обязан понимать ограничения, нюансы и риски конкретной предметной области, чтобы вовремя бить агента по рукам, если что-то идет не так.

Что стоит отметить

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

Работа с обширным контекстом. Просишь добавить ограничение на количество просмотров — он точечно правит схему БД и логику, не ломая соседние файлы.

Визуализация и аргументация изменений. Информативный diff-режим сильно упрощает code review сгенерированного кода.

Инфраструктура.ИИ без проблем накидал docker-compose.yml, Dockerfile для фронта и бэка и конфиг Nginx.

Что смутило:

Не считая описанного в одной из глав выше, путаница с языками. Промпты и документация на русском, фронт (внезапно) на английском.

Выдыхаем, разработчиков ИИ пока не заменит. Без глубокого технического ревью код (справедливости ради, как и любого другого ИИ на рынке) нельзя было заливать в продакшен.

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