Разработчик публикует полную архитектурную спеку бота для самопознания в мессенджере MAX — до первой строчки кода. Центральный тезис: LLM в умном AI-продукте — не самый важный компонент. Важнее event core и Stability Engine. Если это звучит контринтуитивно, значит вы строили AI-продукты по стандартному шаблону.
Контекст
Рынок AI-коучей, «AI-психологов» и ассистентов по саморазвитию растёт, но под капотом почти везде одна и та же конструкция: промпт «веди себя как коуч», пара условий на кнопки, последние N сообщений в контексте — и молитва, что модель не начнёт галлюцинировать диагнозы. Состояние — в лучшем случае Redis с TTL на сутки. История — summary, который модель сгенерировала сама.
Классические инструменты самопознания не лучше. MBTI и соционика статичны: прошёл тест раз, получил четыре буквы, дальше сам. Они не обновляются, не видят динамику, не учитывают контекст. Психотерапия работает, но месяцами и дорого. ÆON Map System — попытка закрыть этот зазор через систему с семислойным профилем, который строится из событий, а не из промптов.
Особенность проекта — публичность с самого начала. Репозиторий открытый, YAML-спека на 700 строк лежит там до первого коммита. Разработчик честно обозначил цель: потом будет видно, где архитектура выдержала, а где разбилась о реальность.
Аналитика
Ключевой паттерн здесь — разделение ответственности между LLM и детерминированным кодом. LLM решает: как сформулировать живой следующий вопрос, как интерпретировать свободный текст, как написать финальный текстовый профиль. LLM не решает: когда назначать карту профиля, когда остановить сессию из-за кризиса, когда разблокировать следующий слой, что такое «достаточная уверенность». Всё это — детерминированный код с тестами и зафиксированными инвариантами.
Event sourcing в AI-продуктах решает проблему, которую большинство команд игнорирует: объяснимость. Когда профиль — это read model поверх append-only event log, любой вывод можно проследить до конкретного ответа пользователя. «Откуда взялся этот вывод обо мне?» — вопрос, на который большинство AI-инструментов не могут ответить честно. Это не архитектурная красота ради красоты — это доверие к продукту, которое монетизируется в retention.
Отдельно стоит паттерн Safety Gate. Rule-based проверка на кризисные маркеры до вызова LLM — правило, применимое к любому AI-продукту, где пользователь может оказаться в уязвимом состоянии. Платить токены за детекцию суицидальных мыслей через стохастическую модель — это одновременно плохая этика и плохая экономика. Детерминированный классификатор с отдельными тестами дешевле, надёжнее и аудируем.
Кейсы применения в бизнесе
B2B-SaaS стартап. Если вы строите AI-продукт с пользовательским профилем — онбординг, персонализация, рекомендации — заложите event sourcing с самого начала. Стоимость: пара дней архитектурного дизайна. Выигрыш: возможность объяснить любое поведение системы, патчить логику без потери истории, пересобирать профиль при смене алгоритма. Командам из трёх-пяти разработчиков это реально и не требует сложной инфраструктуры — хватит append-only таблицы в PostgreSQL.
Корпорация с legacy. В крупных компаниях AI-ассистенты часто деградируют до поиска по базе знаний плюс GPT-ответ. Паттерн Stability Engine — разделение «что решает LLM» и «что решает детерминированный код» — применим и здесь. Начните с аудита: какие решения вашего AI-ассистента имеют побочные эффекты или высокую ставку ошибки? Эти решения нужно выводить из зоны LLM в явный код с логированием и тестами.
SMB и локальный бизнес в КР/СНГ. Если вы используете ChatGPT или Claude для автоматизации клиентского взаимодействия — проверьте, есть ли у вас хотя бы минимальная memory layer. Большинство Telegram-ботов «помнят» только последние 10 сообщений. Добавить простой event log в PostgreSQL — задача на один день, и она кардинально меняет качество диалога: бот перестаёт переспрашивать одно и то же и начинает работать как ассистент, а не как поисковик.
Кейсы в личной жизни
Разработчик. Паттерн «спека до кода, инварианты до фич» применим к любому pet project. Попробуйте перед следующим проектом написать 10 доменных инвариантов — утверждений вида «это никогда не должно происходить». Это займёт 2-3 часа и сэкономит недели отладки. Property-based тесты на эти инварианты (в Python — Hypothesis, в JS — fast-check) дают уверенность другого уровня: 1000 случайных сценариев вместо одного.
Контент-мейкер и исследователь. «Публичная разработка» с реальной архитектурной рефлексией — сильная контентная ниша. Этот пост собирает аудиторию, которая потом становится первыми пользователями и бета-тестерами. Если вы строите что-то интересное — документируйте решения до кода, а не после. Это дисциплинирует мышление и создаёт контент одновременно.
Студент или начинающий PM. ÆON Map System — хорошая учебная модель для понимания разницы между event sourcing и state machine, между read model и write model. Репозиторий открытый, YAML-спека на 700 строк — редкий пример документации до кода. Разбор этого проекта даст больше практического понимания архитектуры, чем большинство курсов.
Как применить сегодня
- Проведите аудит своего AI-продукта: перечислите решения, которые принимает LLM. Выделите те, что имеют side effects или высокую ставку ошибки — и перенесите их в детерминированный код с явными тестами.
- Добавьте rule-based Safety Gate до любого LLM-вызова в продуктах, где пользователь может находиться в уязвимом состоянии: словарь маркеров + лёгкий классификатор. Это не только этично — это дешевле токенов.
- Попробуйте event sourcing для хранения пользовательских данных: append-only таблица в PostgreSQL с полями
session_id,event_type,payload,created_at. Профиль — проекция над этим логом, которую можно пересобрать. - Напишите property-based тесты на ключевые инварианты системы. В Python — Hypothesis, в JS/TS — fast-check. Начните с трёх инвариантов и ста итераций — увидите дыры, которые на обычных примерах не видны.
- Посмотрите на открытую спеку проекта (aeon-max-bot.vibepp.yaml) как на шаблон для своей архитектурной документации: домен → инварианты → события → архитектура → код.