Дело · AO-2026ОсьЛист 01

AUDITOR

Мы ломаем код тестами и показываем, что упало, где и почему — не «кажется ок», а факт.

Заметка на полях

Ваш AI написал код. А кто проверит, что он работает правильно?

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

Проверить код Как это работает

Код можно вставить прямо сейчас. Позже можно подключить репозиторий и проверять изменения автоматически.

E-01checkout/charge.ts · двойное списаниеfail
E-02auth/session.ts · обход токенаfail
E-03api/orders.ts · гонка записиretest

Суть

Лист 02 / 02

AI умеет писать код. Но доверять ему на слово — плохая идея.

Мы пытаемся сломать код тестами и показываем результат: что упало, где и почему.

Штамп вердикта

Не „кажется ок“, а „вот что сломалось“.

Что мы делаем

Не просто читаем код. Генерируем тесты, гоняем нагрузку и пытаемся сломать.

Контур проверки: сигнал → тест → запуск → воспроизведение → evidence. Мнение модели само по себе не считается доказательством.

01
Находим сигнал
Отмечаем места, где логика, доступ или гонка могут дать сбой. · STATIC ANALYSIS
02
Генерируем тест
Собираем сценарий: параллельные запросы, крайние платежи, повторный доступ. · TEST GEN
03
Запускаем и давим
Прогоняем сценарий, включая нагрузку и таймауты — не «смотрим глазами». · RUN / LOAD
04
Воспроизводим
Если падает — повторяем. Нужен стабильный сбой, а не разовый глюк. · REPRODUCE
05
Фиксируем evidence
Показываем, что сломалось, при каком входе и чем это подтверждено. · EVIDENCE

Почему не спросить AI

Можно просто спросить AI: «Всё нормально?»

Мнение AI

Можно. Но это всё равно мнение той же системы, которая написала код. Без проверки «на деле» это похоже на самооценку.

Мнение · без доказательства

Проверка Auditor

Генерируем тест, запускаем, пытаемся воспроизвести. Падает — видно где и почему. Не уверенный тон модели, а повторный результат.

Факт · можно повторить

Пример

Интернет-магазин и списание денег

AI написал функцию списания с баланса. На первый взгляд всё работает: товар купили, деньги ушли. Но при двух быстрых запросах подряд и под несколькими клиентами баланс можно списать дважды. Для покупателя это баг. Для бизнеса — потеря денег.

Auditor не «предупредил на глаз». Он сгенерировал сценарий, прогнал гонку и подтвердил проблему. Ниже — демо-лист (не live-аудит).

Лист проверки

Лист проверки · демо

Человеческий итог сверху. Технический лог — ниже, вторично.

ДЕМО · НЕ LIVE

ID	Где	Сигнал	Статус	Ср.
F-042	оплата → списание	деньги можно списать дважды	ПОДТВЕРЖДЕНО	high
F-043	запрос к базе	данные склеиваются небезопасно	ПОДТВЕРЖДЕНО	high
F-044	сессия пользователя	подозрительно долгое окно доступа	ПОДОЗРЕНИЕ	med

Что показали тесты

ДЕМО · НЕ LIVE

Двойная покупкаОШИБКА912 мсбаланс ушёл ниже нуля
Гонка · 8 клиентовОШИБКА1.4 сдва списания на один заказ
Подмена idОШИБКА184 мсзапрос принял чужие данные
Обычная покупкаОК61 мсодного «счастливого» сценария мало

Нагрузка и гонки

Auditor давит на код — не ограничивается статическим просмотром.

Ниже — демо-кейсы: как выглядит проверка, когда важны параллельность, повторные запросы, платежные края и регрессия после AI-правки. Это иллюстрации метода, не live-цифры.

Метод · не «AI думает, что плохо»

01
Генерируем тест
Сценарий строится под риск: гонка, IDOR, платёж, таймаут.
02
Запускаем
Тест идёт в исполнение — одиночный прогон и повтор под давлением.
03
Воспроизводим
Сбой должен повториться. Иначе это остаётся подозрением.
04
Evidence
В отчёте — вход, шаг, результат. Не уверенный тон модели.

Демо-кейсы проб

ДЕМО · НЕ LIVE

P-01
Гонка в авторизации
Два одновременных логина / обновления сессии. В одиночном запросе всё «ок», под concurrency — ломается.
Проба
N параллельных POST /session · одинаковый refresh
Evidence
Одна сессия получила чужой контекст; повтор прогона дал тот же сбой.
ВОСПРОИЗВЕДЕНО
P-02
IDOR под повторными запросами
Пользователь A перебирает id чужих заказов. Один раз может «не заметить»; серия запросов вскрывает дыру.
Проба
Повтор GET /orders/{id} с чужими id
Evidence
Ответ 200 с данными другого владельца; зафиксирован путь и тело ответа.
ПОДТВЕРЖДЕНО
P-03
Платёжный край
Двойной клик, нулевая сумма, повтор webhook. Обычная покупка проходит — крайние случаи нет.
Проба
Двойное списание · amount=0 · повтор callback
Evidence
Баланс ушёл дважды / принят нулевой платёж; сценарий повторён.
ПОДТВЕРЖДЕНО
P-04
Нагрузка и таймаут
Под умеренной нагрузкой эндпоинт начинает висеть или отдавать 5xx. В ручной проверке «всё быстро».
Проба
Серия запросов · лимит ожидания · обрыв по timeout
Evidence
Часть запросов не уложилась в лимит; лог шага и код ответа в evidence.
СБОЙ ПОД НАГРУЗКОЙ
P-05
Регрессия после AI-правки
Модель «починила» баг. Старый тест зелёный, соседний сценарий — красный. Без повторного прогона это не видно.
Проба
Тот же suite до/после патча · соседний кейс
Evidence
Новый патч закрыл одно и открыл другое; оба прогона в отчёте.
РЕГРЕССИЯ

Методика

Как проверяем код, который написал AI

Это не общий чеклист из учебника. В аудите используется рабочая методика проверки сгенерированного кода: что смотреть в первую очередь, какие тесты собирать и когда считать проблему подтверждённой.

Собрано практиком · fullstack · ~20 лет в разработке

01
Сначала поведение, потом красота кода
Смотрим, что система делает на реальных входах: оплата, доступ, гонки, повтор запроса. Аккуратный стиль без проверки поведения для AI-кода недостаточен.
02
Тест под риск, а не «на всякий случай»
Сценарий строится вокруг конкретной угрозы или сбоя. Цель — воспроизвести поломку, а не набрать формальное покрытие.
03
Повтор до evidence
Один странный прогон — ещё не вывод. Нужен повторяемый результат: вход, шаг, ответ. Иначе остаётся только подозрение.
04
Правка AI — снова через тот же контур
После исправления моделью прогоняем связанный suite ещё раз. Иначе легко закрыть одно и открыть соседнее.

Коротко: аудит идёт по инженерной схеме «найти → проверить тестом → воспроизвести → зафиксировать», а не по уверенности модели в своём же коде.

Что проверяем

Что может пойти не так?

Безопасность
Можно ли украсть данные или сделать то, что нельзя?
SECURITY
Логика и платежи
Считает ли код правильно на краях: ноль, двойной клик, повтор webhook?
LOGIC
Доступ
Не видит ли пользователь чужие заказы при серии запросов (IDOR)?
AUTHORIZATION
Гонки и нагрузка
Держится ли код, когда запросы идут параллельно или упираются в таймаут?
CONCURRENCY / LOAD
Ошибки
Падает ли система на пустых данных, сбоях, странных вводах?
ERRORS
Регрессия после AI
Не сломала ли «правка» модели соседний сценарий, который раньше работал?
REGRESSION

Для бизнеса

Вы не обязаны разбираться в коде.

Достаточно понимать итог: можно ли доверять результату AI перед запуском к клиентам.

Видите подтверждённые проблемы простым языком
Понимаете риск до релиза, а не после жалоб
Можете показать разработчику конкретный провал, а не «мне кажется»
Не нужно становиться инженером, чтобы принять решение

Для разработчиков и фрилансеров

Для тех, кто пишет код с AI каждый день.

Быстрая вторая проверка перед тем, как отдать работу клиенту или влить в основную ветку.

Вставили фрагмент — получили проверяемый результат
Меньше ручного «а вдруг сломается»
Удобно приложить к отчёту клиенту: вот что нашли и подтвердили
Технические детали остаются, но сначала — ясный итог

До и после

Как меняется путь к релизу

Без Auditor

01
AI написал код
02
Быстро глянули глазами
03
Выкатили к пользователям
04
Ловим проблемы уже в проде

С Auditor

01
AI написал код
02
Проверка ищет и воспроизводит проблемы
03
Видите, что подтверждено
04
Правите и проверяете ещё раз — потом релиз

Ваш AI написал код.

Мы пытаемся его сломать.

Потому что найти проблему до пользователей почти всегда дешевле, чем чинить её после.

AI Challenge

Сравните ответы разных AI на одной задаче

Одна постановка, одни проверки. Можно увидеть, чей код переживает тест, а чей — нет. Сейчас раздел готовится.

AI Challenge — скоро

Что получаете

Короткий итог проверки

ДЕМО-ПОДПИСИ

Найдено: Сигналы; Где код выглядит рискованно
Подтверждено: Реальные сбои; То, что удалось воспроизвести
Исправлено: Правка; Когда проблема уже доказана
Итог: Можно / нельзя доверять; Решение по фактам, не по уверенности модели

Тарифы

Проверяйте код без лишних расходов.

Начните бесплатно. Когда проектов станет больше — выберите тариф под свой объём.

Free
0 ₽
Размер проекта
≤ 3 000
Лимит / мес
3 проверки / мес
Начать
Pro
Для разработчиков
1 990 ₽/ мес
Размер проекта
≤ 15 000
Лимит / мес
100 Units
Выбрать
Team
5 990 ₽/ мес
Размер проекта
≤ 30 000
Лимит / мес
500 Units
Выбрать
Business
14 990 ₽/ мес
Размер проекта
≤ 200 000
Лимит / мес
2 000 Units
Выбрать
Enterprise
индивидуально
Размер проекта
200 000+
Лимит / мес
индивидуально
Обсудить

Проверяйте код без лишних расходов.
План	Цена	Размер проекта	Лимит / мес	Действие
Free	0 ₽	≤ 3 000	3 проверки / мес	Начать
ProДля разработчиков	1 990 ₽/ мес	≤ 15 000	100 Units	Выбрать
Team	5 990 ₽/ мес	≤ 30 000	500 Units	Выбрать
Business	14 990 ₽/ мес	≤ 200 000	2 000 Units	Выбрать
Enterprise	индивидуально	200 000+	индивидуально	Обсудить

Audit Unit — единица проверки: списывается, когда аудит реально стартует. На FREE это три проверки в месяц; на платных планах — пакет Units.

Лимит строк — максимальный размер одного проекта. Units — сколько проверок можно запустить за месяц. Это разные ограничения.

Коротко о тарифах

Что ограничивает тариф — строки или Units?: Оба. Строки задают потолок размера проекта. Units — сколько аудитов можно запустить в расчётном периоде.
Почему на FREE «проверки», а дальше Units?: На FREE лимит маленький и понятный: три проверки. На платных планах объём считается в Audit Units — одной шкалой для разных размеров проектов.
Можно ли сменить тариф позже?: Да. Начните с FREE, затем выберите план под объём. Enterprise обсуждается отдельно — без готовой формы на сайте.

Проверьте код до того, как его проверят ваши пользователи.

Проверить код

Вопросы

Коротко о главном

Мне нужно понимать программирование?: Нет. Сначала вы видите простой итог: что подтверждено и насколько это серьёзно. Технические детали можно открыть, если они нужны команде.
Чем это лучше, чем спросить у AI «всё ок»?: AI может ошибаться в оценке собственного кода. Auditor пытается воспроизвести проблему и показать факт поломки, а не уверенный тон ответа.
Можно ли проверить код прямо сейчас?: Да — можно вставить код и запустить проверку в продукте, когда форма доступна. На этом лендинге показан визуальный стенд с демо-данными.
А что с GitHub и репозиторием?: Позже можно будет подключать репозиторий и проверять изменения автоматически. Сейчас это направление развития, не обещание «уже работает».
Куда девается мой код?: Код клиента по умолчанию не используется, чтобы обучать чужие модели. Это правило продукта, а не маркетинговый лозунг.
Это для бизнеса или для разработчиков?: Для обоих. Владельцу важен понятный риск до релиза. Разработчику и фрилансеру — быстрая проверка перед сдачей работы.