Перекрёстная проверка кода работает, когда независимая модель находит воспроизводимый риск, разработчик или другой агент ограничивает исправление, а автоматические тесты решают, принят ли результат. Совпадение мнений моделей не является критерием. Критерий задают тест, контроль безопасности, проверка сборки и доказательство релиза.
Такой цикл использовался при разработке Unlimited Skills, открытой внешней памяти навыков для агентов программирования. На момент исходного материала проект достиг v0.3.12 после архитектурной проверки двух репозиториев. Проверка подтвердила работающие меры безопасности и приватности, но также нашла пробелы. Ценность возникла не из положительной оценки, а из превращения замечаний в изменения.
Критика должна стать проверяемым утверждением
Запрос найти все проблемы часто даёт общий список рекомендаций. Полезное замечание называет компонент, сценарий отказа, доказательство, последствия и способ воспроизведения. После этого его можно выразить через падающий тест, угрозу, контроль релиза или явно описанное ограничение.
Роли стоит разделять. Автор решения понимает исходные компромиссы, но может слишком быстро защищать архитектуру. Критик замечает другие риски, но не всегда знает операционный контекст. Независимый проверяющий должен оценивать артефакт, а не уверенность участников. Материал о том, почему ИИ ошибается уверенно, показывает необходимость такой границы.
Качество проверки не следует измерять количеством комментариев. Важен переход замечания в тест, контроль, решение или документированное ограничение. Замечания о стиле можно отложить. Выход за допустимый путь, небезопасный импорт, утечка данных или ложное сообщение об успехе требуют немедленного разбора.
Очередь замечаний нужно сортировать по последствиям и воспроизводимости. Сначала исправляют проблемы, которые дают доступ к чужим данным, обходят границы пути, нарушают целостность артефакта или делают проверку ложноположительной. Затем рассматривают надёжность и эксплуатацию. Улучшения удобства не должны вытеснять дефекты доверительной границы.
Замечания превращаются в небольшие релизы
В исходном цикле версии v0.3.10, v0.3.11 и v0.3.12 вышли в тот же день. Журнал изменений Unlimited Skills фиксирует отдельные шаги: обнаружение навыков из плагинов, доставку контракта маршрутизации в глобальную память и нативный плагин Claude Code с хуком SessionStart.
Небольшой релиз проще проверить. У него должна быть одна задача, ограниченный набор файлов, регрессионный тест и путь отката. При параллельной работе нескольких агентов необходимо заранее назначить владение компонентами, чтобы одно исправление не отменило другое.
Перед объединением полезно сверить точный набор изменений с заявленной задачей. Новая зависимость, широкий рефакторинг или изменённый формат данных требуют отдельного обоснования. Проверяющий должен видеть не только зелёный тест, но и то, что тест относится к найденному риску, а пакет собран из проверенного состояния репозитория.
Пакет изменения удобно строить из пяти частей:
- Наблюдение: какой отказ воспроизведён и где находится доказательство.
- Граница: какой компонент и поведение разрешено менять.
- Приёмка: какой тест или запрос должен пройти.
- Ограничение: какие утверждения релиз пока не подтверждает.
- Квитанция: какой артефакт, версия и результат проверки получены.
Квитанция нужна, потому что агент способен написать убедительный отчёт о несуществующем успехе. Правила против выдуманных фактов ИИ-агентов применимы и к разработке: статус принимают только по воспроизводимому результату.
Детерминированные хуки поддерживают процесс
Некоторые требования нарушаются, потому что зависят от памяти модели в каждой новой сессии. Хук переносит обязательное действие в исполняемый путь. Официальная документация хуков Claude Code описывает SessionStart как событие, которое срабатывает при начале или возобновлении сессии и может загрузить необходимый контекст.
В Unlimited Skills v0.3.12 такой механизм доставлял контракт маршрутизации при старте. Общий принцип шире конкретного продукта. Если контекст, форматирование, проверка безопасности или релизный запрос обязательны, их нужно выполнять автоматически и тестировать. Текстовая инструкция остаётся полезной, но не заменяет механизм.
Поведение при сбое тоже должно быть задано заранее. Информационная подсказка может безопасно пропуститься и оставить разработку доступной. Проверка, которая защищает публикацию или изменение данных, должна блокировать действие. Нельзя выбирать режим только по удобству, он зависит от цены ошибочного допуска.
До повышения автономности команда должна пройти три теста готовности к внедрению ИИ: определить задачу, источник истины и проверку результата. В разработке это означает репозиторий, тестовый стенд, критерии приёмки и ответственного за выпуск.
Практический вывод: несколько моделей расширяют поиск ошибок, но право изменить статус дают только независимые доказательства.
Частые вопросы
Это процесс, в котором независимая модель формулирует воспроизводимые замечания, автор вносит ограниченные изменения, а тесты проверяют результат.
Другая модель может оспорить допущения автора и найти иной класс ошибок. Каждое её замечание всё равно нужно воспроизвести и проверить.
Оно называет компонент, сценарий отказа, доказательство, последствия и критерий приёмки. Общая рекомендация без воспроизведения не готова к релизу.
Нет. Хук гарантирует загрузку контекста или запуск действия, но его собственное поведение и итоговый продукт всё равно требуют тестов.
Чтобы спроектировать такой цикл для вашей команды, закажите консультацию по ролям, тестам, релизным воротам и журналу результатов.
