Аналитический дашборд для комьюнити-менеджеров — внутренний инструмент на TypeScript, Next.js и React, который агрегирует данные об активности из нескольких API — был пересобран с нуля с помощью ИИ-агента. Цель эксперимента состояла не в том, чтобы получить работающее приложение, а в том, чтобы понять, как автоматизированные инструменты справляются с контролем сопровождаемости кода, написанного ИИ.
Автор выстроила систему из нескольких «сенсоров» — инструментов, дающих агенту обратную связь на разных этапах. Во время сессии программирования работали проверка типов, ESLint, SAST-инструмент Semgrep, dependency-cruiser для анализа зависимостей между модулями, набор тестов с покрытием и инкрементальное мутационное тестирование. GitLeaks запускался как pre-commit-хук и тоже считался сенсором — он сигнализировал агенту при попытке закоммитить чувствительные данные. Те же инструменты повторно запускались в CI-пайплайне. Периодически добавлялись ревью безопасности и модульности на основе промптов, а также отчёт о свежести зависимостей.
| Сенсор | Тип | Когда запускается | Что выявляет |
|---|---|---|---|
| ESLint | Вычислительный | Во время сессии и в CI | Длина файлов/функций, сложность, типизация |
| Semgrep (SAST) | Вычислительный | Во время сессии и в CI | Уязвимости безопасности |
| dependency-cruiser | Вычислительный | Во время сессии и в CI | Нарушения правил зависимостей между модулями |
| Покрытие тестами | Вычислительный | Во время сессии и в CI | Процент исполняемого кода |
| Мутационное тестирование | Вычислительный | Во время сессии (инкрементально) | Реальная защита тестов от регрессий |
| GitLeaks | Вычислительный | Pre-commit-хук | Утечки секретов и чувствительных данных |
| AI-ревью модульности | Интерпретирующий | Периодически | Связанность, распределение ответственностей |
| Ревью безопасности | Интерпретирующий | Периодически | Соответствие AppSec-чеклисту |
Статический анализ показал себя эффективным на уровне отдельных файлов и функций. ESLint с кастомными правилами отлавливал типичные режимы отказа ИИ: слишком длинные функции и файлы, избыточное число аргументов, высокую цикломатическую сложность. Примечательно, что эти правила не входят в дефолтный пресет ESLint — их пришлось настраивать вручную. Для усиления обратной связи автор написала кастомный форматтер ESLint, который переопределяет стандартные сообщения об ошибках и добавляет к ним контекст для самокоррекции агента — своего рода промпт-инъекции прямо в вывод линтера.
Архитектурные проблемы — связанность модулей, распределение ответственностей, согласованность структуры — статический анализ не вскрывал. Здесь потребовалось ИИ-ревью модульности с полным контекстом кодовой базы. Это разграничение принципиально: вычислительные сенсоры хорошо работают с формальными правилами, но не умеют рассуждать о намерениях и архитектурных решениях.
Главным открытием стало мутационное тестирование. Этот метод намеренно вносит небольшие изменения («мутации») в исходный код — например, меняет оператор сравнения или инвертирует условие — и проверяет, упадут ли тесты. Если тест не реагирует на мутацию, значит, он не проверяет соответствующую логику. Высокое покрытие кода тестами выглядело убедительно, однако мутационное тестирование показало, что значительная часть тестов, написанных ИИ, просто исполняет код, не фиксируя его поведение. Такие тесты создают иллюзию надёжности, но не защищают от регрессий при изменениях.
Эта проблема не уникальна для ИИ-агентов: люди тоже пишут тесты с низкой мутационной стойкостью. Но когда агент генерирует и код, и тесты в одной сессии, риск возрастает — тесты могут просто отражать реализацию, а не спецификацию. Мутационное тестирование в данном случае оказалось единственным инструментом, который объективно измерил это расхождение.
Основной вывод эксперимента: автоматизация повышает доверие к коду там, где правила формальны и однозначны. Там, где нужно рассуждение о смысле — архитектура, тестовые намерения, распределение ответственностей — метрики создают опасную иллюзию контроля без реального контроля.
