На твоих токенах — бесплатно

ИИ-аудит твоего проекта — прямо в редакторе

Автоматика ловит паттерны, а ИИ понимает смысл кода: находит логические дыры, мёртвые заглушки и кнопки, которые ничего не делают. Запусти npx @nouve/vibe-audit — агент проведёт аудит по нашей методике, а платформа соберёт из результата визуальный отчёт и шер-карточку.

npx @nouve/vibe-audit

Одна команда в папке проекта — дальше ИИ-агент сделает всё сам.

Бесплатно, на твоих токенахКод никуда не отправляетсяОтчёт и шер-карточка за пару минут

так проходит ИИ-аудит

$ npx @nouve/vibe-audit

✓ методика загружена с платформы

> Прочитай .vibe-audit/PROMPT.md и выполни аудит по нему

агент читает файлы проекта…

• 4 прохода: архитектура · доступ · следы ИИ · отчёт

✓ готово — ссылка на визуальный отчёт:

audit.nouve.design/r/ab12cd

Три шага

В папке проекта запусти команду

npx @nouve/vibe-audit

Вставь одну строку в Claude Code или Cursor

Прочитай .vibe-audit/PROMPT.md и выполни аудит по нему

Агент сам отправит результат — получишь ссылку на отчёт и шер-карточку

Код проекта никуда не отправляется: на платформу уходит только JSON находок — из него собирается отчёт.

Что видит ИИ, чего не видит автоматика

Архитектура по смыслу

Три компонента, делающие одно и то же; бизнес-логика, размазанная по UI; god-файлы. Автоматика видит симптомы, ИИ — причину.

Логика безопасности

Эндпоинт проверяет «залогинен ли», но не «его ли это запись» (IDOR). Права только на фронте. Путь пользовательского ввода до базы.

Следы генерации

Заглушки «// TODO: implement», моки, выглядящие как настоящие данные, кнопки без обработчиков, комментарии, не совпадающие с кодом.

Отчёт как у нас

Вердикт словами, топ проблем по влиянию, «что уже хорошо» и план из фикс-промптов — та же схема, что в серверном аудите.

пример находки

Так выглядит проблема, которую видит только ИИ

Автоматика проверяет паттерны. Смысл кода — чья это запись, живая ли кнопка, зачем этот god-файл — понимает только ИИ.

до релизаapp/api/orders/[id]/route.ts

Эндпоинт /api/orders/[id] проверяет, что пользователь залогинен, но не что заказ принадлежит именно ему.

Любой авторизованный пользователь откроет чужой заказ, поменяв id в адресе (IDOR) — утекут чужие данные и деньги.

Талон на починкуapp/api/orders/[id]/route.ts

В app/api/orders/[id]/route.ts добавь проверку владельца: после аутентификации сверяй order.userId с id текущего пользователя и возвращай 404, если не совпало. Сделай так во всех ручках, работающих с записями по id.

Почему так нельзя

«Залогинен» ≠ «имеет право»: каждую запись по id проверяй на принадлежность владельцу.

Методика аудита (промпт открыт)

Промпт живёт на платформе и версионируется — пакет всегда получает актуальную методику. Вот текущая версия:

Методика аудита (промпт открыт)

Ты — аудитор вайбкод-проектов: строгий в диагнозах, доброжелательный в подаче. Проверь проект в текущей папке и составь отчёт о готовности к продакшену. Читатель отчёта не умеет читать код — объясняй по-человечески, без жаргона (термин можно в скобках после объяснения).

Проведи четыре прохода:

1. АРХИТЕКТУРА И СТРУКТУРА. Изучи дерево файлов и ключевые модули. Определи: какая архитектура здесь угадывается и соответствует ли она размеру проекта; есть ли смешение слоёв (запросы к данным прямо в UI, бизнес-правила в обработчиках); есть ли компоненты/функции, делающие одно и то же под разными именами (смысловые дубли); есть ли god-файлы, которые делают всё сразу. Предложи план рефакторинга из 3–5 шагов, отсортированный по эффекту.

2. ЛОГИКА БЕЗОПАСНОСТИ. Для каждого эндпоинта/серверного действия, которое меняет данные: проверяется ли не только «пользователь залогинен», но и «эта запись принадлежит ему» (иначе это IDOR — чужие записи можно менять без спроса). Проверь, нет ли прав, которые существуют только на фронтенде (кнопка скрыта, а API открыт). Проследи путь пользовательского ввода до базы/файловой системы/HTML: есть ли на пути валидация. Найденные в коде ключи оцени по смыслу: это плейсхолдер, публичный ключ по замыслу — или настоящий секрет не на месте.

3. СЛЕДЫ ГЕНЕРАЦИИ. Найди: заглушки и функции, возвращающие моки, которые выглядят как настоящие данные; UI-элементы, которые ничего не делают (кнопки без обработчиков, формы без отправки); компоненты, которые никогда не рендерятся; комментарии, не соответствующие коду рядом; смешение стилей (два HTTP-клиента, три способа управления состоянием).

4. ОТЧЁТ. Собери всё в один отчёт строго в таком порядке: (1) Вердикт первой строкой — «Выпускать нельзя: сначала почини N вещей» или «Можно выпускать, но на этой неделе сделай N пунктов» — решение, не оценка. (2) Топ-5 проблем по влиянию; каждая в формате: что случилось (просто) → чем грозит (конкретное последствие для владельца) → срочность (до релиза / на этой неделе / когда-нибудь) → готовый фикс-промпт для ИИ-редактора с указанием файлов → микро-урок одной строкой, почему так нельзя. (3) Блок «Что уже хорошо» — обязательно, минимум 3 пункта. (4) План действий: упорядоченный список «скопируй промпт 1 → проверь → промпт 2 → …».

Жёсткие правила: каждая находка обязана указывать существующий файл (и строки, где возможно) — находки «по ощущениям» не пиши; не выдумывай проблем ради количества — если категория чистая, так и скажи; запрещены формулировки «как известно», «очевидно», «любой разработчик знает»; тон — помогающий взрослый, не экзаменатор.

Как это сочетается с проверкой по ссылке

так выглядит отчёт

Аудит по ссылке — быстрый рентген: секреты, уязвимости, открытая база, типовые ошибки. 2 минуты, ничего ставить не надо.

Проверить по ссылке

На твоих токенах — бесплатно

ИИ-аудит — глубокий осмотр изнутри: смысл кода, логика доступа, качество архитектуры. Работает в твоём редакторе на твоих токенах, код никуда не отправляется.

Сначала быстрая проверка?

Вставь ссылку на GitHub — за две минуты получишь скор и первые находки.

Проверить по ссылке