Abstract

AI Audit Kit можно описать как переносимый standard operating framework для AI-assisted security and reliability auditing. В отличие от типичного сценария, где агент получает один длинный prompt, находит часть проблем и теряет связность уже на следующем шаге, этот подход формализует полный цикл работы с дефектами: от первичного аудита до triage, orchestrated fixing и независимой повторной проверки.

Основное достоинство проекта заключается не в объёме исходного кода, а в том, что он задаёт контракт процесса. Findings превращаются в артефакты, исправления идут батчами, прогресс фиксируется в tracking-документе, а каждая важная правка проходит reviewer loop. За счёт этого AI перестаёт быть только генератором идей и становится частью воспроизводимого инженерного контура.

1. Постановка задачи

У практического AI-аудита есть повторяющаяся проблема: качество результата сильно зависит от конкретной сессии, контекста окна, случайного prompt engineering и терпения оператора. Даже если агент нашёл реальные баги, дальше возникает несколько системных слабостей:

  • findings не нормализованы и остаются внутри чата;
  • severity и приоритеты не собраны в единый backlog;
  • исправления плохо масштабируются, когда дефектов десятки или сотни;
  • нет независимого механизма, который проверяет полноту каждого fix;
  • процесс трудно перенести на другой репозиторий без переписывания workflow почти с нуля.

AI Audit Kit решает именно эту задачу: не "как попросить модель поискать баги", а "как сделать AI-аудит повторяемым и эксплуатационно пригодным".

2. Метод

Проект задаёт четырёхфазный цикл:

Phase 1: Audit
Phase 2: Triage
Phase 3: Fix Pipeline
Phase 4: Review and Hardening

В фазе Audit агент проходит кодовую базу и сохраняет каждую проблему как отдельный markdown-репорт с полями для severity, категории, location, root cause, impact, reproduction и suggested fix. Это простое решение, но оно критично: находка становится не эфемерным фрагментом ответа модели, а полноценной единицей работы.

В фазе Triage репорты агрегируются в TRACKING.md, где видно общее число находок, распределение по severity и текущий статус обработки. Этот слой нужен для планирования и для наблюдаемости: без него массовый AI-аудит распадается на несвязанные эпизоды.

В фазе Fix Pipeline баги группируются в батчи по файлам, доменам и репозиториям. Дальше каждый шаг исполняется последовательно: implementer делает исправление, пишет тесты, запускает quality gates и создаёт commit, а reviewer анализирует именно этот commit и возвращает формальный verdict.

Фаза Review and Hardening закрывает то, что не должно зависеть от локального успеха отдельного шага: прогон полного набора проверок, spot-checking и финальную валидацию результата.

3. Архитектурное преимущество

Ключевая инженерная идея AI Audit Kit состоит в разделении ролей и артефактов.

Во-первых, репорт о баге отделяется от исправления. Это означает, что audit и remediation больше не смешиваются в одном ответе модели.

Во-вторых, implementer и reviewer отделены друг от друга. Один агент делает fix, другой оценивает полноту исправления и качество тестового покрытия. Это снижает риск ложного чувства завершённости, которое характерно для одноагентных сценариев.

В-третьих, весь процесс оставляет после себя материальные артефакты:

  • bug reports;
  • tracking dashboard;
  • step logs;
  • review verdicts;
  • fix iteration logs.

Именно это делает проект ближе к operational standard, чем к набору prompt templates.

4. Почему это лучше ad hoc prompt engineering

Разовый prompt может быть полезен на маленьком репозитории, но плохо переносится на большую систему. Чем больше codebase, тем заметнее становятся три фундаментальные проблемы.

Первая проблема связана с потерей состояния. Модель может найти полезные defects, но уже на следующем шаге оператору приходится вручную восстанавливать контекст, заново выбирать приоритеты и решать, какие находки совместимы в одном fix batch.

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

Третья проблема связана с воспроизводимостью. Большинство "удачных" AI-аудитов не являются переносимыми: другой разработчик, другой репозиторий или даже другая неделя работы требуют фактически пересобрать метод заново.

AI Audit Kit убирает эти три класса проблем за счёт формализации структуры процесса.

5. Реальное использование на закрытом большом проекте

Сильнее всего ценность AI Audit Kit видна не на учебном репозитории, а в реальной работе над большим закрытым multi-repo проектом. По состоянию на 1 апреля 2026 года этот стандарт используется там как действующий рабочий контур, а не как демонстрационный шаблон.

Практический процесс устроен следующим образом.

Сначала большая кодовая база была разрезана на десятки функциональных зон анализа. Затем аудит проходил несколькими итерациями, в каждой из которых параллельно запускались отдельные агенты на разные module groups. После каждого прохода findings собирались в стандартизированные markdown-репорты и сводились в общий tracking-документ.

В текущем живом прогоне этот контур уже охватил 33 module groups и cross-cutting concerns, прошёл через 4 audit iterations и использовал 24 agent invocations для системного разбора codebase. Результатом стали сотни findings по security, reliability, correctness и observability. Это важно не как маркетинговая цифра, а как подтверждение того, что подход выдерживает не один локальный кейс, а длительную работу на большой системе.

Дальше вступает в действие fix pipeline. Для критичных и high-priority дефектов запускаются отдельные orchestrator scripts. Они работают не в режиме "пусть агент попробует что-то починить", а в режиме последовательных шагов:

  1. берётся batch связанных багов;
  2. implementer читает bug reports и релевантный код;
  3. implementer делает fix, пишет тесты и проходит quality gates;
  4. создаётся commit;
  5. reviewer анализирует именно этот commit и возвращает структурированный verdict;
  6. если fix неполный, шаг уходит на следующую fix-итерацию.

Что особенно важно, reviewer loop в реальном использовании действительно ловит дефекты, которые implementer пропустил на первом проходе. В логах текущего запуска видно, что отдельные high-severity шаги проходили несколько review iterations, прежде чем verdict становился PASS. То есть независимая проверка здесь не декоративна, а функциональна.

6. Эмпирические наблюдения

По реальному использованию можно сделать несколько практических выводов.

Первое наблюдение: на больших codebase основная ценность AI возникает не на этапе первичного нахождения единичной ошибки, а на этапе нормализации большого объёма findings в единый pipeline.

Второе наблюдение: reviewer loop окупается. Даже сильный implementer регулярно оставляет неполные fixes, недостаточно строгие тесты или локально корректные, но концептуально дырявые решения.

Третье наблюдение: tracking и пошаговые логи радикально повышают управляемость процесса. Когда шаг зависает по таймауту, даёт partial result или не проходит review, это становится видимым immediately, а не обнаруживается случайно через несколько коммитов.

Четвёртое наблюдение: переносимость достигается не за счёт универсального "магического" prompt-а, а за счёт минимального набора стабильных артефактов и правил orchestration.

7. Ограничения подхода

AI Audit Kit не отменяет необходимость финальной инженерной валидации. Он не гарантирует, что каждый найденный баг будет автоматически и идеально исправлен, и не освобождает команду от принятия архитектурных решений.

У подхода есть и операционные ограничения:

  • качество зависит от способности модели читать и удерживать реальный кодовый контекст;
  • большие шаги могут упираться во время исполнения и budget limits;
  • quality gates должны быть заранее понятны и воспроизводимы;
  • security- и auth-related fixes всё ещё требуют внимательного human review.

Иными словами, проект не заменяет старшего инженера, но значительно повышает его пропускную способность.

8. Заключение

Главное преимущество AI Audit Kit состоит в том, что он переводит AI-аудит из режима импровизации в режим стандартизированного инженерного процесса.

Это особенно важно там, где кодовая база велика, дефектов много, а исправления должны быть не просто быстрыми, но ещё и наблюдаемыми, проверяемыми и переносимыми между проектами. В этом смысле AI Audit Kit полезен не как "набор файлов для работы с агентом", а как operational framework для системного bug discovery и orchestrated remediation.

Именно поэтому проект ценен: он фиксирует не только что агент должен делать, но и как этот процесс должен быть устроен, чтобы результат можно было повторить, проверить и масштабировать.

Репозиторий проекта: ascorblack/ai-audit-kit