Аудит MVP, созданного с помощью ИИ
Создали MVP с помощью ИИ? Поможем проверить код, архитектуру и готовность к реальному запуску. Вы быстро получили работающий продукт — мы покажем, что в нём оставить, что исправить до первых платящих пользователей и что заменить, чтобы развивать его уверенно.
- Доступы и роли
- Секреты
- Тесты
Что такое аудит кода, написанного с помощью ИИ?
Это проверка приложения, собранного с Cursor, Claude Code, Lovable, Bolt, Replit или похожими инструментами, перед запуском или ростом. Смотрим то, что легко пропустить при быстрой сборке: кто видит чьи данные, где лежат ключи, проверяет ли API владельца записи, есть ли тесты главного сценария, воспроизводимы ли сборка и деплой. Итог — карта рисков, решение «оставить / исправить / заменить» по модулям и план следующего этапа.
Кто обращается
Основатель, собравший MVP сам
Продукт сделан в Lovable, Bolt или Replit, первые пользователи уже есть или вот-вот появятся. Нужно понять, можно ли открывать регистрацию и принимать оплату.
Разработчик с Cursor или Claude Code
Код пишется быстро, но посмотреть со стороны некому: нет старшего коллеги, который проверит доступы, схему данных и деплой.
Команда без Senior-разработчика
Несколько человек развивают продукт, архитектурные решения принимались по ходу. Перед ростом нужен независимый взгляд и понятный порядок работ.
Перед инвестором или новым подрядчиком
Инвестор, новая команда или технический партнёр спрашивает, в каком состоянии код. Нужна картина с доказательствами, а не оценка «на глаз».
С какими вопросами приходят
Можно ли запускать MVP, если код почти весь написан ИИ?
Способ написания кода сам по себе ничего не говорит о его качестве. ИИ-ассистенты уверенно пишут типовой код, но могут пропустить то, что не видно в интерфейсе: проверку прав на сервере, правила доступа к таблицам, хранение ключей. Аудит отвечает на вопрос конкретно для вашего приложения.
Видит ли один пользователь данные другого?
Проверяем модель ролей, правила доступа в базе (например, RLS в Supabase и PostgreSQL) и проверку владельца объекта в каждом API-маршруте с идентификатором — на тестовом стенде, тестовыми учётными записями.
Ключ лежит в коде фронтенда — это опасно?
Зависит от ключа. Публичный ключ Supabase или Firebase рассчитан на браузер — при условии, что правила доступа настроены. Секретный ключ сервиса, платёжного провайдера или LLM-API в браузере — уже проблема. Каждый найденный ключ разбираем отдельно.
Ассистент ломает что-то при каждой правке — всё переписывать?
Обычно нет. Чаще помогают тесты на главный сценарий, понятные границы модулей и миграции схемы. Решение «оставить / исправить / заменить» принимаем по модулям, а не для продукта целиком.
Что реально проверяем
пунктов
- Аутентификация и авторизация: роли и проверка прав на сервере, а не только в интерфейсе
- Доступ к данным: правила базы (RLS и аналоги), проверка владельца объекта в API
- Секреты: ключи в клиентском коде, в репозитории и его истории, разделение окружений
- API: валидация входных данных, обработка ошибок, лишние поля в ответах
- Зависимости: известные уязвимые, заброшенные и подозрительные пакеты
- Схема базы данных: миграции, ручные правки, бэкапы
- Архитектура: дублированная логика, неочевидные связи модулей, устаревшие API в сгенерированном коде
- Тесты: покрыт ли главный сценарий и ловят ли тесты реальные поломки
- Сборка и деплой: воспроизводимость, переменные окружения, откат, базовые операционные риски
Признаки, что пора проверить
Ни один из них не означает, что продукт плохой. Но каждый — повод посмотреть внимательнее до роста нагрузки и платежей.
Нет тестов
Каждую правку проверяете вручную, и всё равно что-то ломается в другом месте.
Непонятно, кто видит данные
Правила доступа к таблицам не настраивали или настроили так, «чтобы заработало».
Ключи на клиенте
Ключи API лежат во фронтенде или в .env-файле, который попал в репозиторий.
Всё держится на одном человеке
Как устроен продукт, знает только автор — и история его переписки с ассистентом.
Сборка и релизы непредсказуемы
Деплой проходит со второй попытки, локально работает, на сервере — нет; после релиза ломается старое.
Схема базы менялась вручную
Таблицы правились в панели, миграций нет, повторить базу на новом окружении сложно.
Форматы проверки
Три ориентира объёма. Конкретный состав подбираем под продукт после брифа.
Quick Review
Быстро понять главные риски перед показом пользователям или инвестору.
- Роли и доступы в ключевых сценариях
- Секреты в коде и репозитории
- Правила доступа к данным (RLS и аналоги)
- Самые важные исправления — коротким списком
Результат: короткий отчёт — главные риски и границы проверки
Не входит: широкое покрытие кода, детальный разбор тестов и архитектуры.
MVP Review
MVP перед открытием регистрации, оплатой или первыми платящими клиентами.
- Всё из Quick Review
- API: валидация и проверка владельца объекта
- Тесты главного сценария
- Сборка, деплой, переменные окружения
- Схема базы и миграции
Результат: карта рисков, «оставить / исправить / заменить» по модулям, roadmap
Не входит: pentest, нагрузочное тестирование, исправления.
Deep Audit
Продукт с пользователями и платежами перед ростом, инвестициями или передачей другой команде.
- Всё из MVP Review
- Архитектура и границы модулей
- Зависимости и цепочка поставки
- Бэкапы и восстановление
- Логи, мониторинг, операционные риски
Результат: отчёт в двух уровнях — для владельца и для команды — с roadmap
Не входит: pentest, сертификация, обещание отсутствия уязвимостей.
Стоимость определяется после брифа и согласования объёма. Форматы — ориентиры, а не фиксированные тарифы: состав уточняем под ваш продукт.
Что вы получите
Карта рисков
Находки с доказательствами: серьёзность и уверенность — раздельно, что не проверялось — сказано прямо.
«Оставить / исправить / заменить»
Решение по каждому модулю: что работает и трогать не нужно, где хватит точечной правки, что проще заменить.
Roadmap следующего этапа
Список точечных исправлений по приоритету и рекомендации, как продолжать разработку с ассистентом безопаснее.
Пример находок
Так выглядят находки в отчёте. Продукт вымышленный; такие ошибки типичны для быстро собранных приложений, но встречаются и в коде, написанном вручную.
Резюме для владельца
- Объект: вымышленный сервис онлайн-записи на занятия, собранный в Lovable и доработанный в Cursor — React, Supabase (PostgreSQL, Auth), Edge Functions. Формат — MVP Review.
- Принимать оплату пока не рекомендуем: таблица клиентов читается через публичный ключ без входа в систему (F-01). Исправление точечное.
- Интерфейс и большинство компонентов — оставить. Слой доступа к данным — исправить. Ручные правки схемы — заменить миграциями.
- Первый шаг: F-01, F-02 и F-03 — до приёма платежей; F-04 и F-05 — до подключения второго разработчика.
F-01CRITICALПубличный ключ базы открывает таблицу клиентов: RLS-политики не включеныДоступ к данным · RLS
- Что наблюдали
- Приложение обращается к Supabase из браузера с публичным (anon) ключом — так и задумано платформой. Но для таблиц clients и bookings Row Level Security выключен, и запрос с этим ключом возвращает все строки.
- Доказательство
- Экспорт схемы вымышленного проекта; на тестовой копии запрос без входа в систему вернул все записи тестовых клиентов.
- Влияние на бизнес
- Имена и телефоны всех клиентов доступны любому, кто откроет инструменты разработчика в браузере. Юридические и репутационные последствия утечки.
- Рекомендация
- Включить RLS на всех таблицах с пользовательскими данными, написать политики «пользователь видит только свои записи», проверить их тестами под разными ролями.
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P0 — до приёма платежей · S
- Ограничения
- Проверены таблицы из схемы на дату проверки; хранилище файлов — по выборке.
F-02HIGHСекретный ключ платёжного провайдера попал в клиентский бандлСекреты
- Что наблюдали
- Переменная с префиксом VITE_ содержит секретный ключ платёжного провайдера. Сборщик встраивает такие переменные в JavaScript, который скачивает браузер.
- Доказательство
- Поиск по собранному бандлу тестовой сборки и конфигурация сборки; значение ключа в отчёте скрыто.
- Влияние на бизнес
- Ключ позволяет обращаться к платёжному API от имени вашего аккаунта — создавать операции и читать данные транзакций.
- Рекомендация
- Перевыпустить ключ, перенести вызовы платёжного API на сервер (Edge Function или API-маршрут), в клиенте оставить только публичный ключ.
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P0 — до приёма платежей · S–M
- Ограничения
- Ключ не использовался для запросов к провайдеру — это вне объёма; права ключа оценены по документации провайдера.
F-03HIGHФункция отмены записи не проверяет, чья это записьAPI · проверка владельца
- Что наблюдали
- Edge Function cancel-booking принимает booking_id и работает с сервисным ключом, который обходит RLS; принадлежность записи текущему пользователю не проверяется.
- Доказательство
- supabase/functions/cancel-booking/index.ts, строки 12–30 (вымышленные); на стенде тестовый пользователь A отменил запись тестового пользователя B.
- Влияние на бизнес
- Любой зарегистрированный пользователь может отменять чужие записи — потерянная выручка и доверие клиентов.
- Рекомендация
- Вызывать функцию с токеном пользователя вместо сервисного ключа или явно сверять владельца записи с пользователем из токена; добавить тест на чужую запись.
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P0 — до приёма платежей · S
- Ограничения
- Проверены функции записи и отмены; административные функции — по выборке.
F-04MEDIUMНет тестов сценария «записаться → оплатить → получить подтверждение»Тесты
- Что наблюдали
- В репозитории есть несколько сгенерированных unit-тестов для функций форматирования; главный пользовательский сценарий не покрыт, CI тесты не запускает.
- Доказательство
- Каталог tests/ и конфигурация CI вымышленного проекта.
- Влияние на бизнес
- Любая правка — вручную или ассистентом — может незаметно сломать запись или оплату; поломку первыми обнаружат клиенты.
- Рекомендация
- Зафиксировать текущее поведение e2e-тестом главного сценария и интеграционными тестами правил доступа; запускать их в CI на каждый pull request.
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P1 · M
- Ограничения
- Качество существующих unit-тестов оценено выборочно.
F-05MEDIUMСхема менялась вручную в панели, миграции отстают от базыБаза данных · миграции
- Что наблюдали
- В базе есть столбцы и индексы, которых нет в каталоге миграций; часть изменений вносилась вручную через панель управления.
- Доказательство
- Сравнение экспорта схемы с каталогом supabase/migrations; часть расхождений команда подтвердила устно.
- Влияние на бизнес
- Нельзя надёжно поднять копию базы для тестов или нового окружения; откат изменений схемы — только вручную.
- Рекомендация
- Снять текущую схему как базовую миграцию, дальше менять схему только миграциями через репозиторий; описать процедуру восстановления.
- Уверенность · воспроизведение
- MEDIUM · INDICATED
- Приоритет · трудоёмкость
- P1 · M
- Ограничения
- Восстановление из бэкапа не проверялось: в формат MVP Review это не входило.
Демонстрационный образец. Продукт, проект, код, пути и данные вымышлены. Серьёзность (severity) — последствия с учётом вероятности; уверенность (confidence) — насколько доказан факт. S / M / L — относительный класс трудоёмкости, а не оценка в часах.
Самостоятельная проверка, консультация или аудит
Не всегда нужен аудит. Иногда достаточно самопроверки или одного разговора с инженером.
| Критерий | Самопроверка | Консультация | Аудит |
|---|---|---|---|
| Когда подходит | Хотите понять, с чего начать | Есть конкретный вопрос: стек, доступы, схема данных | Нужна картина рисков продукта перед запуском или ростом |
| Кто смотрит код | Вы сами | Инженер InterLAB — по контексту и безопасным фрагментам | Инженер InterLAB — репозиторий в согласованном объёме, доступ только на чтение |
| Результат | Список того, что проверить первым | Варианты решения, компромиссы и следующие шаги | Карта рисков с доказательствами, «оставить / исправить / заменить», roadmap |
| Стоимость | Бесплатно | После брифа и согласования объёма | После брифа и согласования объёма |
Самопроверка не заменяет аудит: она подсказывает, куда смотреть, но не видит ваш код.
Как передать доступ безопасно
Код открываем только после NDA и согласования объёма. До этого достаточно описания.
- 01
Не присылайте код через форму или WhatsApp
Форма и мессенджер — только для короткого описания задачи. Исходники, пароли, ключи и токены через них не передавайте.
- 02
Сначала NDA и объём
NDA — по вашему шаблону или шаблону InterLAB. Фиксируем, какие модули и окружения проверяем и что остаётся вне объёма.
- 03
Отдельный доступ только на чтение
Пригласите в репозиторий отдельную учётную запись с правами только на чтение, по возможности временную. Свой логин передавать не нужно.
- 04
Тестовый стенд вместо production
Правила доступа проверяем на копии проекта с тестовыми данными. Активные проверки работающего продукта — только с вашего письменного согласия.
- 05
Секреты остаются у вас
Ключи для аудита не нужны. Если секрет найден в коде, в отчёте он скрыт, а перевыпустить его рекомендуем сразу.
- 06
Отзыв доступа
После передачи отчёта вы отзываете выданные права, и мы сверяем это вместе.
Канал передачи отчёта и срок хранения материалов определяются договором.
Следующий шаг
Можно начать самостоятельно — с самопроверки и уроков библиотеки.
Как проходит аудит
- 01
Короткий бриф
Что за продукт, на чём собран, есть ли пользователи, платежи и персональные данные, что беспокоит. Только описание — без кода и ключей.
- 02
Формат и объём
Quick Review, MVP Review или Deep Audit: фиксируем модули, окружения и то, что вне объёма. Стоимость — после согласования объёма.
- 03
NDA и доступ на чтение
NDA по вашему или нашему шаблону, доступ к репозиторию — только на чтение. Данные реальных клиентов не нужны.
- 04
Проверка
Ручной разбор кода и конфигурации, проверка правил доступа тестовыми учётными записями на стенде. Каждая находка — с доказательством.
- 05
Карта рисков и решение по модулям
Находки с серьёзностью и уверенностью, «оставить / исправить / заменить» по модулям, roadmap следующего этапа.
- 06
Дальше — на ваш выбор
Исправить своими силами, передать отчёт другой команде или заказать стабилизацию у InterLAB отдельным договором.
Оценим проект до старта разработки
Опишите задачу в форме ниже — ответим в течение рабочего часа и предложим следующий шаг: созвон, разбор или оценку.
С чем приходят
Неважно, где собран продукт: проверяем итоговый код, схему данных и конфигурацию. Инструменты называем, чтобы было понятно, с чем к нам обращаются: они ускоряют разработку, но у быстрой сборки есть типичные слепые зоны.
- Cursor
- Claude Code
- Lovable
- Bolt
- Replit
- v0
- GitHub Copilot
- Windsurf
Типичный стек AI-собранного MVP
Чаще всего это React или Next.js на фронтенде и BaaS-платформа вместо собственного бэкенда. У каждой платформы свои правила доступа — их и проверяем в первую очередь.
Supabase, Firebase, PostgreSQL, Next.js, React, Node.js, Vercel, Netlify
Вопросы про аудит AI-собранного MVP
Нет. Способ написания кода сам по себе ничего не говорит о качестве: ассистенты хорошо справляются с типовыми задачами. Риски возникают там, где решение требует контекста, которого у ассистента не было, — права доступа, секреты, схема данных, поведение при сбоях. Их и проверяем.
Стоимость определяется после брифа и согласования объёма: она зависит от формата, числа модулей, наличия платежей, персональных данных и интеграций.
Нет. Для оценки достаточно описания: на чём собран продукт, какие роли, есть ли платежи и персональные данные. Код открываем только после NDA и согласования объёма — через доступ только на чтение.
Нет. Это обзор кода и конфигурации с доказательствами в согласованном объёме — не тест на проникновение, не сертификация и не обещание, что уязвимостей нет. В отчёте прямо сказано, что проверено, а что нет.
Общий технический аудит — для действующих продуктов любого происхождения, с широким набором доменов: архитектура, производительность, интеграции, legacy. Аудит AI-собранного MVP сфокусирован на рисках быстрой сборки: доступ к данным, секреты на клиенте, проверки на сервере, тесты и воспроизводимость деплоя.
Рекомендации учитывают ваш процесс: тесты, которые ловят поломки после правок, правила для репозитория, порядок ревью изменений. Цель — чтобы вы двигались так же быстро, но с меньшим риском.
Можно, отдельным договором. Но отчёт самодостаточен: по нему может работать ваша команда, фрилансер или другой подрядчик — заказывать исправления у InterLAB не обязательно.
Разборы по теме в блоге
Смежные направления
Покажем, что в MVP оставить, а что исправить
Расскажите, на чём собран продукт и что беспокоит, — без кода, ключей и паролей. Предложим подходящий формат проверки.
- Первый короткий разговор бесплатный — выбираем формат работы
- NDA — по вашему или нашему шаблону
- Стоимость — после брифа и согласования объёма