Everything as Code и Business as Code как операционная форма «Гелиоса»
Everything as Code и Business as Code как операционная форма «Гелиоса»
Основной тезис: as Code — не отдельный элемент онтологии «Гелиоса», а операционная форма, в которой атомы, слоты, роли, процессы, политики и метрики хранятся, проверяются, изменяются и сверяются с действительностью. Содержательная методология атомов, разведанности, ходов и кифу раскрыта в «Партии компании».
Что означает as Code
as Code не означает, что бизнес буквально превращается в программный код. Это паттерн управления сложной изменяемой системой через структурированное машиночитаемое описание желаемого состояния.
Полная реализация паттерна требует пяти свойств:
| Свойство | Смысл | Применение в «Гелиосе» |
|---|---|---|
| Декларативность | Описывается желаемое состояние, а не ручная последовательность действий | Роль, слот, процесс и политика имеют явный контракт |
| Версионность | Каждое изменение сохраняет автора, время, причину и историю | Можно восстановить действовавшую версию агента и процесса |
| Ревью | Изменения проходят обсуждение и одобрение | Управленческое решение становится Merge Request и diff |
| Автопроверка | Целостность проверяется до применения | Линтер проверяет владельцев, входы/выходы, полномочия, циклы делегирования |
| Сверка с реальностью | Желаемое состояние сравнивается с фактическим | CRM/DWH/логи показывают организационный drift |
Диагностический критерий: файлы YAML или Markdown в Git без автоматических проверок и петли сверки — это версионируемая документация, но ещё не полноценный as Code. ^everything-as-code-lecture-2026-09-10
Генеалогия паттерна
Infrastructure as Code устранил зависимость инфраструктуры от ручных действий и неявного знания операторов. Configuration as Code, Pipeline as Code, Policy as Code, Security as Code и Docs as Code распространили тот же жизненный цикл на конфигурацию, доставку, политики, безопасность и документацию.
C4 Model добавляет семантический зум, а Architecture as Code делает архитектурную модель первичной по отношению к диаграммам: схемы генерируются из сущностей и связей, а не служат единственным источником описания.
Business as Code
Business as Code переносит пять свойств на социотехническую систему: людей, AI-агентов, процессы, полномочия, данные и информационные системы.
Семантический зум
- C1: компания, клиенты, поставщики, регуляторы и внешние границы.
- C2: бизнес-домены, департаменты и крупные системы.
- C3: роли людей, специализированные агенты, сервисы и MCP-инструменты.
- C4: промпты, JSON-схемы, скиллы, политики, валидаторы и код интеграций.
Агенту выдаётся не вся корпоративная энциклопедия, а релевантный фрагмент модели на нужном масштабе. Это сокращает контекст и делает границы полномочий явными.
Связь с онтологией «Гелиоса»
as Code является носителем пяти содержательных элементов модели:
| Элемент «Гелиоса» | Что даёт as Code |
|---|---|
| Атом — задача с контрактом | Структурированное описание входа, выхода, владельца и критерия качества |
| Шкала наивности | Метаданные о достоверности, источниках и готовности к автоматизации |
| Human Slot → Neuro Slot | Версионируемая замена исполнителя при сохранении контракта операции |
| Было → стало | Diff конфигурации и сопоставление метрик до и после изменения |
| Счёт партии | Агрегация экономических и операционных результатов по территории человека и машины |
as Code не определяет, что считать атомом, как измерять достоверность или экономический эффект. Это задаёт собственная онтология «Гелиоса». Поэтому as Code — форма и жизненный цикл, а онтология — содержание. ^everything-as-code-lecture-2026-09-10
Двусторонний организационный drift
В инфраструктуре при расхождении обычно прав манифест: контроллер возвращает систему к записанному состоянию. В бизнесе источник истины нельзя назначить заранее. Возможны два исхода:
1. Манифест верен: исполнение нарушает утверждённый процесс — нужно изменить практику. 2. Реальность вернее: сотрудники обходят устаревший или ошибочный регламент — нужно подготовить обратный Merge Request к модели.
Контур сверки «Гелиоса» должен:
1. обнаружить расхождение; 2. собрать доказательства из CRM, DWH, встреч и журналов; 3. классифицировать причину; 4. предложить изменение процесса или модели; 5. провести машинную и человеческую проверку; 6. применить изменение с возможностью отката.
Автоматическое молчаливое переписывание архитектуры вероятностным агентом недопустимо.
Связь drift со шкалой наивности
Организационный drift — сигнал, что узел онтологии требует пересмотра достоверности. Например, расхождение регламента L2 с устойчивым паттерном в CRM/DWH может инициировать проверку и перевод знания к L4. Но уровень нельзя повышать только по факту обнаружения расхождения: нужны доказательства, атрибуция источников и ревью.
Где метафора ломается
Люди не являются идемпотентными ресурсами
Изменение манифеста не изменяет поведение отдела автоматически. Между решением и новым состоянием лежат коммуникация, обучение, сопротивление, мотивация и время.
Карта не равна территории
Не всё оставляет цифровой след. Доверие, неформальное влияние, эмоциональное состояние, взаимопомощь и скрытые конфликты лишь частично наблюдаемы. Модель обязана хранить границы знания и не выдавать гипотезу за факт.
Формализация имеет цену
Попытка описать каждое микродействие создаст цифровую бюрократию. Формализовать следует прежде всего то, что влияет на деньги, безопасность, ответственность, передачу работы, данные и измеримый результат.
Детерминированная оболочка вокруг вероятностных агентов
Промпт не равен политике. Критические ограничения должны обеспечиваться обычным кодом:
- права доступа;
- финансовые лимиты;
- JSON-схемы входов и выходов;
- обязательные подтверждения;
- журналирование;
- аварийный останов;
- воспроизводимость версии модели, промпта, скилла и инструмента.
LLM отвечает за понимание языка, синтез, классификацию и работу с неопределённостью; детерминированная оболочка — за запреты, контракты и контроль исполнения.
Операционная архитектура
Для реализации концепции нужны связанные слои:
1. Enterprise Knowledge Graph — сущности предприятия и отношения. 2. Манифесты в Git — роли, слоты, агенты, процессы, политики и метрики. 3. Генераторы — промпты, конфигурации, маршруты, документация и диаграммы. 4. Agent Runtime — оркестрация, MCP-инструменты, события и Human-in-the-loop. 5. Observability — трассировка решений, качество, стоимость, ошибки и бизнес-эффект. 6. Learning/Reconciliation Loop — обнаружение drift и предложения изменений через ревью.
Синтез
$$\text{Гелиос} = \text{онтология предприятия} \times \text{жизненный цикл as Code} \times \text{наблюдаемость} \times \text{агентное исполнение}$$
Практическое определение:
«Гелиос» превращает наблюдаемую реальность предприятия в версионируемую исполняемую архитектуру, а затем безопасно размещает в ней людей и AI-агентов.
Короткая инженерная формула:
Не «весь бизнес — код», а «всё, чем должны управлять агенты, должно иметь проверяемое машиночитаемое представление и связь с реальностью».
Что требует дальнейшей проверки
- [needs verification] Насколько термин Business as Code принят рынком и не создаёт ложного впечатления тотального программирования людей.
- [needs verification] Какие существующие форматы лучше подходят для единой модели ролей, процессов, политик и агентных контрактов.
- [contested] Может ли Git быть единственным источником истины для динамической компании или правильнее считать истиной связку Git + Knowledge Graph + event log.
- [open question] Как формально рассчитывать «счёт партии» без редукции человеческой ценности только к производительности.