Всем привет! Меня зовут Станислав Денисов, я 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 есть несколько модов:
Architect: проектирование и дизайн до реализации.
Code: написание и рефакторинг кода.
Ask: ответы на вопросы и объяснения.
Debug: поиск и исправление багов.
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 и не забыл про ограничения, чтобы базу не положили гигабайтным секретом:
# schemas.py
class 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.py
from .rate_limiter import RateLimitMiddleware
# Add rate limiting middleware
app.add_middleware(
RateLimitMiddleware,
requests_per_minute=int(os.getenv("RATE_LIMIT_PER_MINUTE", "60"))
)Выглядит так, будто этот код можно заворачивать в Docker (который, к слову, агент тоже написал) и деплоить на прод. Почти.
Где ИИ не смог обойтись без человека
Ассистент реализовал шифрование на стороне сервера (через cryptography.fernet). Ключ генерируется на основе мастер-ключа сервера и ID секрета.
Сервер знает всё. Любой администратор с доступом к базе и переменным окружения может прочитать базу секретов.
Для Zero-Knowledge подходит шифрование на клиенте (Web Crypto API). Ключ передается в URL после хеша (#KEY), браузер не отправляет его на бэкенд. Сервер хранит только зашифрованный набор символов.
Эндпоинт получения секрета делает SELECT, проверяет if db_secret.accessed: raise, затем отдает секрет и делает UPDATE accessed = True.
Классический TOCTOU (Time-of-Check to Time-of-Use). Если отправить два параллельных запроса в одну миллисекунду, оба прочитают флаг False и вернут секрет. Одноразовый секрет перестал быть одноразовым.
В этом случае лучше использовать транзакционные блокировки БД (SELECT ... FOR UPDATE) или атомарный UPDATE ... RETURNING.
Когда секрет прочитан, ассистент заботливо ставит secret.deleted = True в базе. При этом сам зашифрованный текст навсегда остается в базе.
Секреты должны удаляться аппаратно (физический DELETE). А в идеале крипто-шреддинг: перед удалением перезаписывать колонку с секретом мусором, чтобы не оставить следов даже в WAL-файлах базы данных.
Итоги
Задача ИИ ー рутинный код и экономия времени человека на базовых задачах. Полной автоматизации разработки не ждем (пока что).
Задача человека ー бизнес-логика, безопасность и контроль. Разработчик может не писать код вручную. Но обязан понимать ограничения, нюансы и риски конкретной предметной области, чтобы вовремя бить агента по рукам, если что-то идет не так.
Что стоит отметить
Плюсы:
Режим Оркестратора привычный и удобный. Не нужно нянчиться с ИИ, он сам понимает, когда строить архитектуру, а когда писать код.
Работа с обширным контекстом. Просишь добавить ограничение на количество просмотров — он точечно правит схему БД и логику, не ломая соседние файлы.
Визуализация и аргументация изменений. Информативный diff-режим сильно упрощает code review сгенерированного кода.
Инфраструктура. ИИ без проблем накидал docker-compose.yml, Dockerfile для фронта и бэка и конфиг Nginx.
Что смутило:
Не считая описанного в одной из глав выше, путаница с языками. Промпты и документация на русском, фронт (внезапно) на английском.
Выводы
Выдыхаем, разработчиков ИИ пока не заменит. Без глубокого технического ревью код (справедливости ради, как и любого другого ИИ на рынке) нельзя было заливать в продакшен.
А вообще результатами теста кодового ассистента Яндекса остался доволен. То, на что раньше ушел бы целый день, агент сделал за час. Моя роль в процессе смещается от рутинного кода к бизнес-логике и проектированию, ревью, управлению архитектурой и безопасностью. При вдумчивом подходе инструмент крайне полезный. Но вряд ли поможет в бездумных попытках навайбкодить что-то без знаний.