Совет — зная это, вы уже можете командовать
Код структурирован (урок 8), система структурирована (урок 9). Осталось — данные. Данные — самое опасное. Ошибки в коде ловят тесты, ошибки системы — /health. Ошибки данных — никто не замечает. Обнаруживают через 3 месяца в квартальном отчёте.
Агенту: “Не JSONB — создай схему с явными столбцами и ограничениями. amount > 0, status — только допустимые значения.”
Агенту: “Импортируй этот Excel в БД. Ограничения DDL должны соблюдаться. Строки с нарушениями — в отдельный файл с отчётом.”
Агенту: “Измени DDL и пройди yongol validate. Создай миграцию, при провале — откат.”
Вам как человеку без навыков БД достаточно решить “что хранить”. “Телефон должен начинаться с 010”, “email уникален” — эти решения на естественном языке агент переведёт в DDL.
Почему нужно командовать именно так
Данные портятся раньше кода
Ошибка в коде → тест ловит. Ошибка в системе → мониторинг ловит. Ошибка в данных → никто не замечает. Обнаруживают через 3 месяца: “почему выручка отрицательная?”
4 условия Agent Operable Data
1. Схема объявлена — DDL как контракт данных. Типы, ограничения, связи явны. CHECK (amount > 0), status IN (‘pending’,‘confirmed’,‘shipped’) — ИИ не нужно угадывать.
2. Преобразования проверяемы. Правила маппинга декларативны, инварианты до/после проверены.
3. Источник и время отслеживаются. source, created_at, created_by в каждой записи.
4. К изменениям данных применяется храповик. DDL → validate → миграция (up + down) → staging → production (одобрение).
Схема — это закон, который я устанавливаю
Принцип урока 5 “ограничение = контракт” прямо проявляется в данных. БД имеет схему. Схема определяет что валидно. NOT NULL, FOREIGN KEY, CHECK — ограничения, которые невозможно обойти.
Закон — не 正義 (справедливость), а 定義 (определение).
Схема без данных — закон без общества. Данные без схемы — общество без закона.
Один паттерн, разные домены
| Урок 8: Код | Урок 9: Система | Урок 10: Данные | |
|---|---|---|---|
| Читаемо? | filefunc | /health | DDL |
| Проверяемо? | go test + tsma | CI/CD + хелсчек | Ограничения БД + Rego |
| Обратимо? | git revert | откат образа | migration down |
| Прогресс сохраняется? | session.json | Terraform state | история миграций |
Всё — одна структура: объяви, проверь, зафиксируй, сохрани.
Видение: от “сделай приложение задач” до “сделай SaaS управления заказами”
| Урок | Что изучили | Результат |
|---|---|---|
| 1 | Вайб-кодинг | “Скажи — получишь код” |
| 2 | Почему ломается | Дрифт, потеря контекста, лесть |
| 3 | Как предотвратить | Hurl, Git, CI/CD |
| 4 | Барьер 200 эндпоинтов | yongol — декларативный SSOT |
| 5 | ИИ на поводьях | Reins Engineering: 3 столпа |
| 6 | Зафиксировать и дальше | Ratchet Pattern |
| 7 | Обратить лесть | IFEval — обратная связь → сходимость |
| 8 | Структурировать код | filefunc + tsma |
| 9 | Структурировать систему | 4 условия Agent Operable System |
| 10 | Структурировать данные | Схема = закон |
Код → Система → Данные. Один принцип во всех трёх доменах.
Объяви, проверь, зафиксируй, сохрани. Решения — человек, реализация и проверка — машина. Не власть человека, а власть закона.
Скажи — получишь. Не только код, но и систему, и данные. Для этого нужны поводья, рельсы и закон. Проектирование этих поводьев, рельсов и закона — это Reins Engineering.
Связанные статьи
Полный курс Reins Engineering
| Урок | Название |
|---|---|
| Урок 1 | Как командовать ИИ |
| Урок 2 | Как не доверять ИИ |
| Урок 3 | Нерушимое приложение |
| Урок 4 | Решения — за пределы кода |
| Урок 5 | ИИ на поводьях |
| Урок 6 | Прошёл — зафиксировал |
| Урок 7 | Как обратить лесть |
| Урок 8 | Фабрика агентов |
| Урок 9 | Автоматизация за пределами кода |
| Урок 10 | Закон данных |
Источники
- E.F. Codd, “A Relational Model of Data for Large Shared Data Banks” (1970)
- OPA / Rego — декларативная валидация бизнес-правил
- yongol DDL → sqlc — перекрёстная проверка от схемы до типобезопасного кода
- Принцип верховенства закона (Rule of Law) — проверяемость, определённость нарушения, принудительность