Мы аудитируем vibe-код проекты: вот что ломается чаще всего

За последние полгода я провел более 30 аудитов проектов, написанных с помощью vibe coding — подхода, где код генерируется почти полностью через AI-инструменты вроде Claude, Cursor или Copilot. Тренд взорвался в 2025-м, но к июлю 2026 года я вижу четкую картину: vibe coding позволяет запускать прототипы за недели, а не месяцы, но 80% этих проектов разваливаются при первой же нагрузке.

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

Что такое vibe coding и почему это стало проблемой

Vibe coding — это термин, введенный Андреем Карпаты в начале 2025 года. Суть: разработчик описывает задачу на естественном языке, AI генерирует код, разработчик копирует его в проект, тестирует и итеративно правит. Звучит идеально, но на практике я вижу одно и то же: код работает, пока вы смотрите на него в IDE, но ломается, как только проект попадает в продакшен.

Топ-5 проблем, которые я нахожу при аудитах

1. Отсутствие обработки ошибок

Самая частая проблема. AI генерирует «идеальный» сценарий работы, но игнорирует граничные случаи. Например, в одном проекте для e-commerce на Python AI сгенерировал функцию расчета скидки, которая падала с KeyError, если в JSON от Stripe не было поля coupon. Тысячи заказов в день — и каждый десятый вызывал 500-ю ошибку.

Как это выглядит в коде:

# vibe-код:
def apply_discount(order):
    discount = order['coupon']['value']  # упадет, если купона нет
    return order['total'] - discount

# правильный вариант:
def apply_discount(order):
    coupon = order.get('coupon')
    if coupon is None:
        return order['total']
    discount = coupon.get('value', 0)
    return order['total'] - discount

Почему AI это делает: Модели обучаются на идеальных примерах из документации. Они не «видят» реальные данные с битыми полями.

2. Слабая типизация и неявные преобразования

Второй по частоте баг. AI генерирует код на Python с динамической типизацией, но не добавляет проверок типов. В одном проекте для финансового агрегатора функция парсинга дат возвращала None для нестандартных форматов, вызывая TypeError при сравнении с datetime.

Кейс из жизни: Клиент (стартап по подписке на кофе) попросил меня разобраться, почему у 15% пользователей не списывается оплата. Оказалось, AI-сгенерированный код для расчета следующей даты платежа использовал datetime.now() без временной зоны, а Stripe API требовал UTC+0. Разница в 3 часа приводила к пропуску платежей.

3. Игнорирование кэширования и лимитов API

Vibe coding проекты часто делают тысячи API-запросов туда, где достаточно одного. Я видел проект, который при каждом открытии страницы дергал Telegram API для проверки статуса пользователя. При 5000 пользователей в день — 5000 запросов, хотя можно было кэшировать на минуту. Telegram API начал возвращать 429 Too Many Requests через 2 часа после запуска.

Решение: Внедрите Redis или простое in-memory кэширование. AI-модели редко предлагают это по умолчанию, потому что в обучающих примерах обычно нет контекста нагрузки.

4. Проблемы с безопасностью

Это страшно. Я нашел в vibe-коде проектах:
- SQL-инъекции (AI использует f-строки для запросов вместо параметризованных)
- Хранение API-ключей в коде (вместо переменных окружения)
- Отсутствие валидации входных данных (любой может отправить {'role': 'admin'})

Конкретный пример: В проекте для внутреннего дашборда AI сгенерировал эндпоинт /user?id=1, который возвращал данные любого пользователя. Без аутентификации. Без проверки прав. Просто SELECT * FROM users WHERE id = {id}.

Как исправить: Всегда добавляйте слой валидации и используйте ORM с параметризованными запросами. Никогда не доверяйте AI генерацию запросов к базе.

5. Отсутствие тестов и мониторинга

Ни один из 30 проектов, которые я аудитировал, не имел unit-тестов. AI может сгенерировать тесты, если попросить, но по умолчанию он их не добавляет. В результате — любое изменение ломает функционал, и об этом узнают только от пользователей.

Мой чеклист для аудита:

Как я провожу аудит vibe-кода

Процесс простой, но эффективный:

1. Просмотр архитектуры — сначала я прошу показать общую схему. Если её нет (а в 90% случаев её нет), это уже красный флаг.
2. Сканирование ключевых мест — функции, работающие с деньгами, данными пользователей, внешними API.
3. Тестирование под нагрузкой — запускаю локально с locust или k6 и смотрю, где падает.
4. Проверка безопасности — базовые тесты на SQL-инъекции, XSS, незакрытые эндпоинты.

Результат: в среднем нахожу 12-15 критических багов на проект. После исправления — стабильность растет с 60% до 95%+

Когда vibe coding работает (и когда нет)

Я не противник vibe coding. Я за осознанное использование. Вот когда это оправдано:

• Прототипы — для проверки гипотезы за выходные
• Внутренние инструменты — для команды из 3 человек
• Одноразовые скрипты — парсинг данных, миграции

Когда vibe coding опасен:

• Fintech и платежи — любая ошибка стоит денег
• Медицина и безопасность — цена бага — жизни
• Продукты с тысячами пользователей — нагрузка вскроет все проблемы

Заключение

Vibe coding — мощный инструмент, но он не заменяет инженерную культуру. Я вижу, как стартапы экономят недели на разработке, а потом теряют месяцы на исправление багов, которые можно было предотвратить.

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

Если хотите, чтобы я посмотрел ваш vibe-код проект — пишите. Я провожу аудиты для команд от 2 до 50 человек. Первые 5 багов нахожу бесплатно.

Данные основаны на 32 аудитах, проведенных с января по июнь 2026 года. Все примеры кода — из реальных проектов с измененными названиями.