Reins Engineering — ИИ под управлением Image: AI generated

Лошадь без вожжей

ИИ-инструменты для кодирования стали быстрыми. Авторизация за 30 секунд. Оплата за 2 минуты. MVP выходит за три недели.

Через три месяца всё рушится.

ИИ «наводит порядок» в логике оплаты и меняет расчёт скидок. Запрос на рефакторинг меняет имена полей публичного API. Добавление новой функции ломает аутентификацию. Согласно исследованию Карнеги-Меллона (MSR 2026), сложность кода необратимо возрастает на 41% после внедрения ИИ-инструментов кодирования. Отчёт Google DORA Report (2025) показывает снижение стабильности доставки на 7,2% при каждом увеличении доли ИИ на 25%.

Проблема не в том, что ИИ глуп. Проблема в том, что нет вожжей.

Упряжь — это забор

Индустрия ответила «harness engineering». Линтеры, форматтеры, CI/CD, структура проекта, гайдлайны по коду. Заборы, не выпускающие агента за периметр.

Заборы не задают направление. Что бы агент ни делал внутри забора — перезаписывал существующую логику, менял типы, пропускал переходы состояний — линтер проходит. Форматтер проходит. CI проходит. Код попадает в продакшн «чистый, но неправильный».

Седло надето. Всадник в седле. Но без вожжей он держится бёдрами и через три месяца падает.

Reins Engineering

Reins Engineering — это инженерный подход, дающий ИИ-агентам детерминированные контракты и блокирующий продвижение при их нарушении.

Он состоит из трёх элементов:

1. Детерминированная обратная связь

Давайте агенту факты, а не мнения. Не «это выглядит странно», а «строка 41: несовпадение имени поля, ожидалось ‘user_id’, получено ‘userId’.» Обратная связь, не оставляющая места для sycophancy. Согласно исследованию TDAD (arxiv 2026), процедурные инструкции «применяй TDD» ухудшают регрессии (6,08% → 9,94%), тогда как предоставление конкретных тестовых файлов в контексте сокращает регрессии на 70% (6,08% → 1,82%).

2. Фиксация контрактов (Ratchet Pattern)

Когда верификация проходит — фиксируй. Верификационный код, написанный таким образом, называется ratchet code. Hurl-тесты декларируют поведение API в виде обычного текста и запускаются на каждом коммите в CI. Прошедший ratchet code нельзя удалить. Агент может свободно менять код, но не может менять поведение. Дрифт структурно подавлен.

3. Отделение решений от реализации

Три вещи, смешанные в коде — пользовательские решения, бизнес-логика, детали реализации — разделяются. Решения живут в декларативных спецификациях (OpenAPI, DDL, диаграммы состояний). Реализация свободно генерируется ИИ. ИИ не может спутать решения с деталями и перезаписать их. Выживаемость решений становится независимой от размера модели.

Эволюция

Prompt Engineering      → Скажи правильно — и заработает
Context Engineering     → Дай хороший контекст — и заработает
Harness Engineering     → Удержи структурой
Reins Engineering       → Направь вожжами

Каждый этап родился из ограничений предыдущего. Одних промптов не хватало для стабильности. Контекст не мешал агенту уходить в сторону. Заборы не предотвращали дрифт внутри периметра.

Reins Engineering — это не забор, это вожжи. Он не ограничивает свободу агента — он гарантирует, что агент доберётся до цели.

В июне 2026 года эта линия эволюции зарегистрировала ещё одно имя. Loop Engineering — перестаньте быть человеком, который пишет промпты агенту; проектируйте петли, которые сами генерируют промпты (Addy Osmani, 2026). Диагноз верен. Петли масштабируют генерацию. Но они не масштабируют вынесение вердикта. Османи сам записал слабое место — “A loop running unattended is also a loop making mistakes unattended.” По мере того как петли становятся повсеместными, узкое место мигрирует в одну точку: что вы вставляете в слот верификации петли?

Назовите этот слой verifier engineering, eval engineering или gate engineering — суть одна. Слоту вердикта петли нужен детерминированный контракт, а не LLM. Я называю это Reins Engineering. Без вожжей петли не сходятся.

80 : 20

Reins Engineering не покрывает всё. Он точно знает, что покрывает.

Deque Systems проанализировала ~300 000 проблем качества доступности на более чем 13 000 страницах (2021). 57% были полностью автоматизируемы, 23% требовали помощи ИИ, 20% мог оценить только человек. Доступность и код — разные домены, но они разделяют одну структуру: «какую долю могут оценить машины?»

Через эту призму качество кода распределяется так:

  • 57% — Территория храповика. Объявить поведение — машины судят о нарушениях без вопросов. go test, Hurl, yongol check, filefunc validate.
  • 23% — Территория упряжи. Линтеры, форматировщики, CI. Механизм детерминирован, но глубина проверки остаётся на поверхности. Они не ловят корректность поведения, но обеспечивают структуру и стиль, повышая качество генерации ИИ.
  • 20% — Территория человека. Соответствие бизнесу, UX, архитектурное направление.

Reins Engineering не заменяет упряжь. Он садится поверх неё.

Упряжь (поверхностный детерминизм)   23%
+ Храповик (поведенческий детерминизм)   57%
─────────────────────────────────
                                     80%

Люди сосредотачиваются на оставшихся 20%.

Почему большие модели — не ответ

«GPT-6 всё исправит.»

Не исправит. Проблема не в интеллекте модели, а в среде. Код как среда не различает решения и реализацию. Любая модель, читающая код, видит решения и детали смешанными в одном тексте.

Локальная модель в 4,5B параметров (Gemma4) с детерминированной обратной связью и примерами в контексте редактирует SSOT без ошибок. Frontier-модель, редактирующая сырой код, порождает дрифт. Разница — в структуре, не в интеллекте.

Не меняйте модель. Добавьте контракт.

Доказательства

yongol — это реализация Reins Engineering. Он перекрёстно валидирует согласованность 10 декларативных спецификаций (SSOT) по 287 правилам и генерирует код.

Бенчмарк ZenFlow — мультитенантный SaaS для автоматизации рабочих процессов. 32 эндпоинта, 14 таблиц, 47 Hurl-запросов. 11/11 этапов пройдено. Добавление функций не замедляло процесс. Существующие тесты ни разу не сломались.

Рабочий бэкенд был успешно сгенерирован локальной моделью в 4,5B параметров. Стоимость $0. Офлайн. Reins заполняет пробел, который оставляет размер модели.

Не автоматизация ревью ИИ — а автоматизация ревью кодом

Основной подход индустрии — автоматизация ревью с помощью ИИ. Один LLM генерирует код, другой LLM его ревьюит. Пьяный спрашивает пьяного друга «Я пьяный?». Уровень капитуляции перед sycophancy у frontier-моделей — 58%. Доля ложных pass у LLM-as-Judge — 36%. Умножьте вероятностную генерацию на вероятностную проверку — точность деградирует.

Reins Engineering — это автоматизация ревью кодом. LLM генерирует, детерминированный код проверяет. validate не льстит. go test не галлюцинирует. Измерение покрытия не врёт. Pass — это pass, fail — это fail.

Автоматизация ревью ИИ:    LLM → проверка LLM → лесть → ложный pass → дрифт
Автоматизация ревью кодом: LLM → проверка кодом → факты → pass/fail → сходимость

В эпоху, когда ИИ-агенты генерируют десятки строк в секунду, люди не могут читать весь код. Но делегирование ревью ИИ означает, что лесть заменяет проверку. Когда код берёт на себя механически верифицируемую часть, люди могут сосредоточиться только на решениях, которые машины не могут оценить — соответствие бизнесу, UX, архитектурное направление.

Человеческая проверка не исчезает. Уменьшается боль человеческой проверки. Что может проверить код — проверяет код. Что может проверить только человек — проверяет человек.

Упряжь без вожжей — просто забор

ИИ уже достаточно мощный. Не хватает направления.

Стройте заборы выше — и агент будет быстрее дрифтовать внутри. Возьмите вожжи — и агент побежит к цели.

Reins Engineering — структурированная детерминированная верификация для ИИ-агентов.

Независимая конвергенция

5 проектов, которые независимо друг от друга пришли к одному и тому же принципу:

  • episteme — Когнитивный control plane для ИИ-агентов от исследователя UIUC. Принуждает к созданию Reasoning Surface на уровне файловой системы перед необратимыми действиями. Тот же принцип, что и ratchet, другая реализация.
  • MagLab — Pipeline физических исследований от исследователя спинтроники KAIST. “LLMs only reason and plan. They do not compute numbers, fabricate citations, or generate figure data.” Все численные результаты производят детерминированные инструменты.
  • Manifesto — MEL для декларативного определения переходов состояний фронтенда. “Agent proposes, World verifies.” Агент только предлагает намерение; переходы состояний верифицируются детерминированно.
  • NEKOWORK — Security gate, сканирующий диффы ИИ-кода детерминированными правилами перед merge. Работает независимо от источника. LLM не судит.
  • oh-my-kamisama — Мульти-CLI дирижёр, оркеструющий Claude, Codex и Gemini. Он читает реальный git diff, а не заявления воркеров («diffs beat claims»), и объявляет задачу выполненной только после прохождения тестов проекта. Каждый запуск остаётся на диске как проверяемый артефакт — а не исчезающий чат.

Резюме: Генерация может быть вероятностной. Верификация должна быть детерминированной.

Связанные статьи

References

  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Google Cloud (2025). DORA Report 2025. cloud.google.com
  • Wang, Z. et al. (2026). “TDAD: Test-Driven Agentic Development.” ACM AIWare 2026. arxiv.org/abs/2603.17973
  • Karpathy, A. (2026). “From Vibe Coding to Agentic Engineering.” thenewstack.io
  • Deque Systems (2021). “Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues.” deque.com
  • Anthropic (2026). “Demystifying Evals for AI Agents.” anthropic.com
  • Osmani, A. (2026). “Loop Engineering.” addyosmani.com

Changelog

  • 2026-05-23: Первая публикация
  • 2026-05-27: Добавлен раздел «Независимая конвергенция» (episteme, MagLab, Manifesto, NEKOWORK)
  • 2026-05-28: Раздел «80:20» — Упряжь (23%) + Храповик (57%) = 80%, эмпирические данные Deque
  • 2026-05-31: oh-my-kamisama добавлен в раздел «Независимая конвергенция»
  • 2026-06-10: В раздел «Эволюция» добавлены абзацы о Loop Engineering — слот вердикта петли, поглощение синонимов (verifier/eval/gate engineering)