Совет — зная это, вы уже можете командовать
В уроке 3 мы научились предотвращать дрифт с помощью Hurl-тестов и Git. До 50 эндпоинтов этого достаточно. Но при росте масштаба возникает новая проблема. Вы просто сказали “приведи в порядок”, а ИИ принял ваши решения за детали реализации и перезаписал их.
Ключевой принцип: вынесите решения за пределы кода. В коде ваши решения (“этот столбец — целочисленный”) смешаны с деталями (имена переменных, обработка ошибок). ИИ не различает их. Если решения объявлены в отдельной спецификации, ИИ не может их перезаписать.
Установка yongol:
Агенту: “npx skills add park-jun-woo/yongol установи”
Создадим функцию Login декларативно:
Агенту: “Объяви функцию Login как SSOT”
ИИ автоматически создаст спецификацию API, схему БД, поток сервиса, политику авторизации, тестовые сценарии.
Агенту: “Запусти yongol validate и доведи до 0 ошибок”
При ошибках ИИ исправит сам. 287 правил перекрёстно проверяют 10 спецификаций. Когда все отметки зелёные — готово к генерации кода.
yongol сейчас поддерживает только проекты на Go. Однако принцип — вынести решения за пределы кода и ловить противоречия перекрёстной проверкой — не зависит от языка. А Hurl-тесты из урока 3 уже работают с любым языком.
Быстрый старт
Установите yongol skill:
Агенту: “npx skills add park-jun-woo/yongol установи”
Агенту: “Объяви функцию Login как SSOT”
ИИ создаст 5 файлов: specs/api/openapi.yaml, specs/db/users.sql, specs/service/auth/login.ssac, specs/policy/authz.rego, specs/tests/scenario-login.hurl.
Агенту: “Запусти yongol validate specs/”
0 errors — успех.
Намеренно создадим противоречие:
Агенту: “Переименуй поле email в mail в OpenAPI”
Агенту: “Запусти yongol validate specs/”
Ошибка: “В OpenAPI — mail, в DDL — email.” В одном слое это не ошибка. При перекрёстной проверке двух слоёв — противоречие видно.
Агенту: “Исправь ошибку validate”
ИИ выровняет имена. Снова validate. 0 errors.
Почему нужно командовать именно так
10 SSOT — каждый отвечает за одну область
yongol разделяет решения ПО на 10 декларативных спецификаций (SSOT: Single Source of Truth). Каждая спецификация отвечает за одну область.
Вам не нужно запоминать эти названия. По ролям они интуитивны:
Определяющие данные: features.yaml (каталог функций), manifest.yaml (настройки проекта), SQL DDL (модель данных), sqlc (запросы БД)
Определяющие поведение: OpenAPI (контракт API), SSaC (поток сервиса), Mermaid stateDiagram (переходы состояний)
Проверяющие: OPA Rego (политики авторизации), Hurl (тестовые сценарии)
Определяющие экран: STML (фронтенд)
10 — кажется много? Три факта снимают страх. Во-первых, 8 из 10 — отраслевые стандарты. yongol создал только SSaC и STML. Во-вторых, вам не нужно их учить — ИИ знает. В-третьих, yongol пока только для Go, но принцип универсален.
operationId — ключ, пронизывающий все слои
Одно имя связывает все 10 спецификаций. operationId — это замковый камень (keystone), как камень на вершине арки, держащий всю конструкцию.
Введя operationId ExecuteWorkflow, вы видите полную картину функции — от API-спецификации до схемы БД, политики авторизации, переходов состояний, реализации функций и тестовых сценариев — на одном экране.
yongol validate — 287 правил ловят противоречия
Решения распределены по 10 файлам — значит, возможны противоречия между ними. yongol validate проверяет ~287 правилами все связи между 10 SSOT. Уникальная ценность — перекрёстная проверка между слоями, которую существующие инструменты не делают.
Бенчмарк: ZenFlow — 32 эндпоинта за 69 минут
Реальное измерение. ZenFlow — мультитенантный SaaS для автоматизации рабочих процессов. Скорость не замедлялась при добавлении функций. Первая функция — 13 минут, одиннадцатая — 4 минуты. 47 Hurl-запросов проходили на каждом этапе.
Почему более крупная модель — не ответ
Проблема не в интеллекте модели, а в среде. Код как среда не различает решения и реализацию. yongol меняет среду — переносит объект редактирования ИИ с кода на декларативную спецификацию.
Не более крупная модель, а более точная структура — вот ответ.
Итоги
- В коде смешаны решения и детали. ИИ их не различает — это корень дрифта.
- Решения выносятся за пределы кода. 10 SSOT, каждый отвечает за одну область.
- operationId — замковый камень. Одно имя пронизывает 10 слоёв.
- 287 правил ловят противоречия между слоями.
- Модель 4,5B тоже сходится к 0 ошибкам. Не IQ модели, а точность обратной связи определяет результат.
Связанные статьи
Полный курс Reins Engineering
| Урок | Название |
|---|---|
| Урок 1 | Как командовать ИИ |
| Урок 2 | Как не доверять ИИ |
| Урок 3 | Нерушимое приложение |
| Урок 4 | Решения — за пределы кода |
| Урок 5 | ИИ на поводьях |
| Урок 6 | Прошёл — зафиксировал |
| Урок 7 | Как обратить лесть |
| Урок 8 | Фабрика агентов |
| Урок 9 | Автоматизация за пределами кода |
| Урок 10 | Закон данных |
Источники
- Бенчмарк ZenFlow — 69 минут, 32 эндпоинта, 14 таблиц, 47 Hurl-запросов. 11/11 этапов пройдены
- Эксперимент yongol agent — Grok 4.3 (0 ошибок с первой попытки), Gemini 2.5 Flash (0 ошибок за 1 итерацию), Gemma4 4.5B (0 ошибок за 1 итерацию)
- yongol validate — 287 правил, перекрёстная проверка 10 SSOT
- Сравнение объёма кода SaaS — SSOT 12 500 строк vs код реализации 100 000 строк (сжатие контекста ~10x)