Практикум: проверяем замечание до публикации¶

Пример к статье «Почему замечания ИИ-ревью нужно проверять». Повтор создаёт дублирующий резерв, если склад выполнил первую операцию, но её ответ потерялся.

Запуск¶

С установленным uv выполните из корня репозитория сайта:

cd docs/blog/lab/2026-09-13-ai-code-review-should-not-be-fully-autonomous
uv run --no-project --python 3.13 python reproduce.py before
uv run --no-project --python 3.13 python reproduce.py after
uv run --no-project --python 3.13 python test_review.py

Если оболочка останавливается после неуспешной команды, запускайте воспроизведения отдельно. before намеренно завершается с кодом 1, печатает calls=2, reservations=2 и нарушает утверждение об одном резерве. after завершается успешно с calls=1, reservations=1. Все семь тестов должны пройти: они проверяют как наблюдаемую ошибку исходной реализации, так и исправление.

Используются только Python 3.13 и стандартная библиотека. uv может загрузить Python, если его нет в кеше; самому примеру не нужны сеть, Docker, провайдер модели и токен доступа. Он не публикует комментарии и не запускает mr-review.

Условия и ограничения¶

Метод warehouse.reserve(order_id) принадлежит адаптеру приложения. По условиям примера каждый принятый вызов создаёт новый резерв: защиты от повторов по номеру заказа нет. Таймаут возможен до и после записи. WarehouseStub намеренно воспроизводит оба положения сбоя и хранит вызовы и резервы в памяти. Он моделирует ход выполнения, но не проверяет настоящий HTTP-транспорт, БД или складской сервис.

reserve_with_retry выполняет не больше двух попыток. После потери ответа вторая попытка может создать ещё один резерв, даже если вызывающий код увидит успех. reserve_once делает одну попытку и превращает TimeoutError в ReservationOutcomeUnknown, сохраняя номер заказа и причину. Успешный результат и посторонние ошибки обрабатываются как раньше.

Неопределённый результат не означает неудачное резервирование. Вызывающему коду нужен процесс проверки статуса или сверки состояния; безусловный повтор этого исключения уровнем выше снова создаст риск дубликата. Сам этот процесс, надёжная идемпотентность и конкурентные вызовы находятся за пределами примера. Для настоящего ревью сначала нужно выяснить договорённости принимающего сервиса.

Проверки¶

Тесты охватывают обычный успех, дубликат после потери ответа, предел в две попытки, исправленное поведение при таймауте до и после записи, успешный результат и постороннюю ошибку доступа. Они не оценивают качество ИИ-модели: замечания в статье служат примерами для разбора.

Файлы¶

• reservation.py: реализации до и после исправления по результатам ревью.
• warehouse_stub.py: управляемые исходы и записи побочных эффектов.
• reproduce.py: одна проверка единственного резерва для обеих реализаций.
• test_review.py: семь исполняемых проверок замечания и исправления.