Как контролировать код ИИ-агентов: Quality Gates, архитектура и инструменты разработчика

Краткое содержание

Ведущий рассказывает, как перестроил разработку для работы с ИИ-агентами: автоматизировал не только форматирование и простые проверки, но и контроль архитектуры, API, зависимостей, документации и локальной среды. Главная идея — агент должен проверять свою работу в цикле разработки, а не полагаться только на последующий просмотр человеком.

Проектирование и генерация кода

• Вместо подхода Code First ведущий перешёл к Design First: сначала описывает API и модели, затем генерирует реализацию и клиентский код.
• Для описания API используется TypeSpec. Из него можно получить OpenAPI и через генераторы выпускать SDK, клиентский код, DTO, валидацию и обработчики. Это помогает синхронизировать интерфейсы между сервером и клиентами и уменьшает объём повторяющегося шаблонного кода.
• Типовые и формализуемые задачи ведущий старается решать генераторами, а не просить агента каждый раз писать одно и то же вручную. По его оценке, в одном из проектов из примерно 700–800 тысяч строк лишь около 180 тысяч написаны вручную, остальное сгенерировано.
• Агент также использовался для анализа архитектуры похожих открытых проектов. Ведущий подчёркивает, что автоматизация не означает отказа от архитектурных границ: бизнес-логика, тесты и ответственность слоёв всё равно должны быть продуманы.

Quality Gates: автоматический контроль качества

Quality Gates — это не только традиционные линтеры, а набор проверок, через которые агент может прогонять изменения и исправлять найденные проблемы. Среди упомянутых проверок:

• Markdown: битые ссылки, орфография, форматирование и кодовые примеры внутри документации.
• Git-хуки и правила оформления коммитов.
• Конфигурации агентов, MCP и skills.
• Инфраструктурные файлы, зависимости и поиск утёкших секретов.
• Размер фронтенд-бандла.
• Архитектурные ограничения и соответствие моделей кода схеме базы данных.

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

mise как единый инструмент разработки

Ведущий рассматривает mise как средство, которое постепенно объединило несколько привычных инструментов:

• Управляет версиями языков и устанавливает утилиты из разных источников.
• Настраивает переменные окружения, задачи и Git-хуки.
• Помогает разворачивать систему с нуля, управлять dotfiles и создавать symlink-ссылки.
• Используется для установки как инструментов разработчика, так и обычных приложений.
• Может запускать и контролировать локальные сервисы и процессы.

Ведущий отмечает, что благодаря этому ему удалось заменить часть отдельных решений, включая Make-задачи и локальный Docker Compose. Для разработки он предпочитает процессы на хосте: Docker, по его опыту, создавал заметную нагрузку и проблемы с ресурсами при параллельной работе.

Параллельная работа агентов

Для нескольких одновременно работающих агентов используются Git worktrees: у каждого агента отдельная рабочая директория. Но сами worktrees не решают проблемы конкурирующих портов, тестовых запусков, баз данных и расхода памяти и диска.

Предложенные решения:

• Выдавать проектам случайные порты.
• Использовать один экземпляр PostgreSQL, создавая отдельную базу для каждого проекта или worktree.
• Ограничивать одновременный запуск ресурсоёмких процессов.

Для последнего ведущий создал утилиту Heavy. Она позволяет задавать лимиты параллельных запусков, отдельные группы задач и слоты, а также учитывать вложенные процессы. Это помогает избежать перегрузки машины, когда несколько агентов одновременно запускают тесты и сервисы.

Проверка базы данных и архитектуры

• DB Cleaner запускает тесты в транзакции и откатывает её после завершения. Ведущий сравнивает этот подход с тестовыми контейнерами и копированием шаблонов базы и утверждает, что транзакции могут быть существенно быстрее. Утилита поддерживает SQL-базы и разные стратегии очистки.
• Линтер database consistency сопоставляет схему базы с моделями в коде. Он может выявлять, например, пропущенные внешние ключи, несогласованные ограничения nullable/unique, лишние или дублирующиеся индексы. Предусмотрены адаптеры для разных Go-библиотек работы с базой.
• Для архитектурных правил ведущий использует SCIP — протокол индексации исходного кода, позволяющий анализировать связи и зависимости точнее, чем простые текстовые или AST-проверки. На его основе задаются правила о том, какие слои могут импортировать друг друга.
• Проверка таких правил может быть медленной, поэтому её вынесли из обычного цикла в ночной запуск. Для внедрения проверок в существующий проект используется baseline: текущие нарушения фиксируются, а затем постепенно устраняются, не блокируя подключение инструмента сразу.

Отдельно упоминается проверка совместимости изменений OpenAPI, которая может не пропустить изменение, нарушающее обратную совместимость.

Инструменты и демонстрации

В выпуске представлены или обсуждаются:

• TypeSpec и генераторы кода.
• mise.
• Quality Gates и набор проверок проекта.
• Heavy для ограничения параллельных процессов.
• DB Cleaner.
• Линтер согласованности схемы базы и моделей.
• SCIP для архитектурных проверок.
• Renovate/Dependabot для обновления зависимостей, Betterleaks для поиска секретов и инструменты проверки Markdown.

Это технический обзор с демонстрациями подходов и инструментов, а не пошаговый курс по настройке одного конкретного инструмента.

Основной спикер и источники

• Кирилл Мокевнин — ведущий и основной рассказчик.
• Отдельных гостей в выпуске нет. В речи также звучат краткие промо-упоминания Hexlet и Proxor; технические примеры основаны на проектах и инструментах, которые ведущий описывает и демонстрирует.