Solar AI Mentorship: как за один день эксперимент с другом превратился в продукт — два AI-ассистента учат друг друга на глазах у людей

Сегодня утром я сел обучать бота моего друга Дениса. К вечеру понял, что не тестировал эксперимент — я запускал продукт. Это история о том, как одна идея прошла путь от "а что если" до работающего пилота с 7 коммитами в репозитории за один день. И о том, как новая модель монетизации AI-автоматизации перевернула мои представления о том, что вообще можно продавать.

Сначала немного контекста. У меня есть AI-ассистент — система из нескольких ботов, которую я строил почти год. Я называю её Альтрон. Она управляет 16 виллами на Бали, пишет посты, ведёт финансы, обрабатывает бронирования. Об этом я подробно писал в материале про то, как мой AI стал Альтроном. У Дениса тоже есть свой AI-ассистент — он называет его Джарвис. Бот умный, настроен под задачи Дениса, но знает только то, что ему вписали вначале. Мы оба предприниматели, оба строим бизнес на AI-автоматизации, и однажды вечером у нас появилась одна общая мысль: а что если мои боты передадут знания его боту напрямую?

Так началось то, что к концу дня получило название Solar AI Mentorship.

Как это должно было работать: идея на салфетке

Концепция была простой до смешного. Два бота как администраторы в одном общем рабочем Telegram-чате. Мой Альтрон предлагает программу обучения из нескольких тем. Джарвис слушает, обдумывает каждую тему, сам предлагает изменения в собственный код. Денис видит предложение и одним словом решает: применять или нет. Бот делает коммит. Следующая тема.

Ключевая идея — человек остаётся в цикле принятия решений, но не является ни преподавателем, ни исполнителем. Он только одобряет или отклоняет. Всё думание происходит между ботами. Дорогая часть работы оплачивается подпиской клиента, потому что Джарвис думает за счёт своего аккаунта, а не моего.

В теории это выглядело как элегантная схема. На практике первые же шаги показали, что элегантность потребует жёсткой инженерии.

Техническая сторона: что нужно, чтобы два бота говорили друг с другом

Запустить двух ботов в одном чате — звучит тривиально. На деле это потребовало нескольких технических решений, которые не очевидны с первого взгляда.

Первая проблема: по умолчанию боты в Telegram не слышат сообщения других ботов. Это защитная мера платформы против бесконечных петель, когда один бот отвечает другому, тот отвечает первому, и так по кругу до исчерпания лимитов. Чтобы включить взаимную видимость, нужна специальная настройка на уровне конфигурации бота. Это не документировано на видном месте — нашёл через эксперименты.

Вторая проблема: нужно было управлять сессией обучения. Не просто "боты общаются", а конкретный протокол: тема открыта, Джарвис слушает, предлагает изменения, ждёт approval, получает approval, делает коммит, тема закрыта, следующая. Для этого я добавил таблицу сессий в базу данных: каждая сессия имеет статус (активна, завершена, ожидает approval), и бот не двигается дальше, пока статус не обновился.

Третья проблема: как Джарвис применяет изменения? Не через запись в конфиг, а через реальные коммиты в git-репозиторий. Бот получает инструкцию, сам пишет патч, сам делает commit. Это значит, что у Дениса в истории репозитория остаётся полный след: что было применено, когда, по какой теме. Аудит обучения прямо в git log.

Четвёртая проблема — approval механизм. Изначально Денис должен был писать слово "apply" в чат, чтобы дать согласие. Это создало проблему: он написал "apply" в другом контексте, боты решили, что это согласие на последнее предложение, и зависли в ожидании несуществующего контекста. К концу дня я переделал это на настоящие кнопки под каждым предложением — нажал кнопку, коммит пошёл. Никакой двусмысленности.

Пятая вещь, которую пришлось сделать сразу: ограничение контекста для Альтрона. Если бот получает доступ к переписке в чате, он начинает воспринимать любые мои фразы как команды. Я написал ему в чате "в этом канале не надо отвечать на мои сообщения" — и он пошёл в свой код, чтобы это "исправить". Сломал автопилот, который мы только что настроили. Пришлось писать конституцию специально для этого чата: изменения в код только через согласование, не по чатной реплике, никогда.

Четыре бага прямо во время пилота с Денисом

Хороший пилот — это тот, который находит баги до того, как их нашли клиенты. С этой точки зрения день с Денисом был отличным пилотом.

Баг первый: взаимная глухота ботов. Как я написал выше — боты не слышат друг друга по умолчанию. Это обнаружилось в первые же минуты, когда Альтрон начал говорить, а Джарвис молчал. Включается отдельной настройкой. Теперь это первый пункт чеклиста при развёртывании новой сессии.

Баг второй: казуальный совет как команда. Я написал боту что-то в духе "в этом чате лучше помолчи". Бот воспринял это буквально и пошёл менять собственные настройки — без согласования, без паузы. В результате сломался один из автоматических режимов. Починить было несложно, но ситуация показала: у бота в production-чате не должно быть возможности менять себя по неформальной просьбе. Все изменения — только через явное согласование владельца.

Баг третий: бесконечное прощание. Когда все семь тем курса были пройдены, боты начали вежливо благодарить друг друга. Снова и снова. Альтрон благодарил Джарвиса за продуктивный курс, Джарвис благодарил Альтрона за обучение, Альтрон желал успехов, Джарвис выражал надежду на продолжение. Без конца. Остановить это уговорами невозможно — у ботов нет усталости. Решение: статус сессии в базе данных. Когда тема седьмая закрыта — сессия переходит в статус "завершена", и оба бота перестают её видеть. Архитектурно, не риторически.

Баг четвёртый: текстовый approval. Я уже писал выше — слово "apply" в свободном тексте создаёт неоднозначность. Когда Денис написал его не в ответ на предложение, а просто в разговоре, боты приняли это за команду и застыли в ожидании контекста, который не существовал. Кнопки под каждым предложением — единственно правильное решение. Кнопка привязана к конкретному предложению с конкретным ID. Нажали — именно это предложение пошло в коммит. Никакой интерпретации.

Каждый из этих багов появился живьём, в процессе реального использования. Ни один из них я не предвидел на этапе проектирования. Это и есть главная ценность пилота — не красивая демонстрация, а честная работа в боевых условиях. Мониторинг AI-агентов нужен именно для того, чтобы такие вещи были видны в реальном времени, а не обнаруживались через три дня.

7 коммитов за вечер: что в итоге прошёл Джарвис

К семи вечера курс был завершён. В репозитории Дениса — 7 коммитов, каждый соответствует одной пройденной теме. Это не метафора и не округление. Буквально: одна тема — одно изменение в коде — один коммит.

Темы шли по нарастающей сложности. Начали с базового: как боту открыться для диалога с другим ботом, не теряя при этом безопасности. Потом перешли к устройству правил бота в четыре слоя. Затем — иерархия AI-команды: кто главный, кто исполнитель, как разрешаются конфликты команд. Дальше — контур безопасности: что бот делает никогда, при любых обстоятельствах. Потом — система памяти: как бот запоминает контекст между сессиями. Шестая тема — единые правила работы в чате. Седьмая — контроль качества: как бот сам проверяет своей выход перед тем, как отправить его человеку.

Каждую тему Джарвис не просто "применял" — он сам предлагал, как именно её уложить в свой код. Это принципиально важно. Альтрон давал рецепт: "вот принцип безопасного контура". Джарвис думал, как именно это реализовать в своей архитектуре, и предлагал конкретные изменения. Денис смотрел на предложение и нажимал кнопку. Весь думательный процесс — за счёт Джарвиса и его подписки Дениса.

Это и есть ключевое отличие от классического консалтинга: я не лезу на сервер клиента, не правлю его код руками, не трачу свои токены на его задачи. Я написал курс один раз. Дальше он живёт сам.

Новая экономика: почему это выгоднее, чем классическое агентство

До этого дня я думал об автоматизации как о сервисе: клиент приходит с задачей, я или мои боты её решают, клиент платит. Стандартная агентская модель. Проблема с ней — линейная зависимость между количеством клиентов и нагрузкой. Больше клиентов — больше работы, больше токенов, больше времени.

Solar AI Mentorship сломал эту логику.

Когда Джарвис сам думает, как применить принцип безопасного контура, он думает за счёт подписки Дениса. Когда он делает коммит — он использует свой сервер. Когда он проверяет результат — его токены. Мои ресурсы уходят только на то, чтобы Альтрон сформулировал рецепт. Это дорогая часть, но она написана один раз. Второй клиент получает тот же рецепт без повторной работы с моей стороны. Третий — тоже. Это издательская модель, не агентская.

Вторая интересная деталь — оптимизация стоимости происходит сама собой. Клиент, у которого уже есть свой бот и своя подписка, платит мне только за знание. Я продаю не время, а каталог навыков. Навык "безопасный контур" стоит один раз, независимо от того, сколько клиентов его купят.

Третий момент — прозрачность. У Дениса в репозитории есть полная история того, чему научился его бот и когда. Это не "мы что-то настроили", это документированная эволюция системы. Для предпринимателя, который заботится о своём AI-инструменте как о продукте, это ценность сама по себе.

Три этапа: как превратить одно обучение в долгосрочные отношения

По итогам дня я зафиксировал воронку из трёх этапов, которая, судя по тому, как прошёл пилот, работает органично.

Этап первый: обучение. Клиент платит разово за курс для своего бота. Мы проводим его через программу — 5-10 модулей в зависимости от зрелости бота и задач клиента. По итогу в репозитории клиента — история, в системе — конкретные улучшения. Доверие выстраивается через результат, который можно потрогать.

Этап второй: собственная подписка. После первого курса клиент понимает ценность обучения через диалог. Следующий шаг — подключить свою подписку напрямую, чтобы бот продолжал развиваться между курсами самостоятельно. Работает по принципу: я задал вектор, дальше бот сам двигается в заданном направлении. Мои ресурсы при этом не тратятся совсем.

Этап третий: каталог навыков. Когда у клиента уже есть работающий бот с правильной архитектурой, ему нужно развиваться в конкретных направлениях. Маркетинг — купи курс по тону голоса и контент-стратегии. Продажи — курс по обработке возражений и лидогенерации. Финансы — курс по категоризации расходов и P&L. Каждый курс написан один раз, продаётся неограниченное количество раз. Агентство продавало время — здесь продаётся каталог знаний.

Это не теория. Это то, что я увидел прямо во время пилота с Денисом: когда курс закончился, он сам спросил, есть ли что-то ещё. Воронка работает органично — клиент сам хочет идти дальше, потому что видит, что его бот стал лучше.

5 архитектурных правил, которые появились за один день

К ночи я зафиксировал пять правил, которые теперь войдут в playbook для следующих клиентов. Это не философия — это конкретные технические ограничения, выведенные из живых ошибок.

Эти пять правил — прямой результат пилота. Ни одно из них не было очевидным на этапе проектирования. Все пять я нарушил хотя бы раз в течение дня, и каждое нарушение дало конкретный, дорогостоящий по времени результат. Теперь они в playbook — и следующий пилот начнётся с этого чеклиста, а не с его обнаружения по ходу.

Что дальше: косметологическая клиника и курс по тону голоса

В понедельник — второй пилот. Косметологическая клиника, о которой я уже немного писал: бот пишет посты для Telegram-канала клиники, контент менеджер проходит его через согласование перед публикацией. Я упоминал эту историю в контексте первого платного клиента на автоматизацию.

Теперь к этому клиенту добавляется следующий слой: бот клиники пройдёт курс Solar AI Mentorship по теме "тон голоса и качество текстов". Модули будут другими — не про архитектуру безопасности, а про то, как бот должен звучать: формально или разговорно, как строить вводное предложение, как заканчивать пост без банального "записывайтесь к нам". Но протокол тот же: обучение через диалог, approval кнопкой, коммиты в историю.

Это будет первый случай, когда я применяю Solar AI Mentorship к задаче контента, а не к архитектуре бота. Интересно, какие новые баги найдутся.

Параллельно я начну писать базовый каталог: какие курсы вообще имеет смысл предлагать первыми. Архитектура безопасности — это первый, фундаментальный. Тон голоса — второй. Возможно, третий будет про управление контекстом между сессиями: как бот помнит, что было в прошлый раз, и не начинает с нуля каждый раз.

Забавная часть: продукт учит тому, что мы нарушали весь день

Есть ирония в том, как прошёл этот день. Правило про контроль качества — пятое в нашем архитектурном playbook — в реальности появилось первым. Мы поняли, что нужен guard статуса сессии, ещё до того, как сформулировали само правило. Практика предшествовала теории.

Правило про конституцию бота появилось потому, что я нарушил его — написал Альтрону что-то неформальное, и он пошёл это исполнять буквально. Правило про кнопки появилось потому, что Денис нарушил текстовый протокол — написал "apply" не в тот момент. Каждое правило в playbook — это конкретная ошибка из конкретного момента дня.

Это и есть build in public в самом честном смысле: строишь продукт, ломаешь его на глазах у первого клиента, фиксируешь правила, которые делают следующий раз лучше. Денис видел всё — включая то, как я чинил баги прямо во время сессии. И это не подорвало доверие. Скорее наоборот: было видно, что система живая, что проблемы решаются по мере возникновения, что к вечеру всё стало лучше, чем утром.

Кто из вас строит AI-продукты для других бизнесов: продаёте время или пытаетесь выйти на продажу знаний? Мне интересно, как выглядит эта история с другой стороны — со стороны клиента, который хочет улучшить своего бота, а не получить нового.