Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты

Всем привет! Меня зовут Станислав Денисов, я 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 промптов, чтобы провести агента от проектирования до тестов и фронтенда. Логика простая: вести разработку итеративно и не загонять кодового ассистента в жесткие рамки.

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

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

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

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

# schemas.pyclass SecretCreate(BaseModel):    """Schema for creating a new secret."""    secret: str = Field(..., description="The secret text to store", min_length=1, max_length=10000)    ttl_seconds: int = Field(        default=3600,         description="Time to live in seconds",        ge=60,  # Minimum 1 minute        le=30 * 24 * 3600  # Maximum 30 days    )    max_views: int = Field(        default=1,        description="Maximum number of times the secret can be viewed",        ge=1,        le=10    )

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

# main.py@app.post("/secrets", response_model=SecretResponse, status_code=status.HTTP_201_CREATED)def create_secret(    secret_data: SecretCreate,    background_tasks: BackgroundTasks,    db: Session = Depends(get_db)):    # ... (генерация ID, шифрование, сохранение в БД) ...        # Schedule cleanup task for expired secrets    background_tasks.add_task(cleanup_expired_secrets, db)        return SecretResponse(        id=secret_id,        access_url=access_url,        expires_at=expires_at,        message="Secret created successfully."    )

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

# main.pyfrom .rate_limiter import RateLimitMiddleware# Add rate limiting middlewareapp.add_middleware(    RateLimitMiddleware,    requests_per_minute=int(os.getenv("RATE_LIMIT_PER_MINUTE", "60")))

Выглядит так, будто этот код можно заворачивать в 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.

Что смутило:

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

Выводы

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

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