✍️ Ранее писал, как мы уперлись в проблему воронки:
пользователь открывает меню - и не добавляет в корзину. Одна из гипотез - пользователь не справляется с тягостью выбора из сотен позиций. Мы решили проверить, как AI-ассистент, сократив выбор, поможет пользователю дойти до целевого действия - покупки.

Перед проверкой влияния на конверсию мы пошли в короткий тест на одну неделю с небольшой выборкой пользователей. Изучали поведенческие паттерны, проверяли стабильность системы, вычисляли среднее число запросов до добавления в корзину.

Мы смотрели на:

• Поведенческие паттерны клиентов
• На каком запросе чаще всего происходит добавление в корзину
• Следили за метриками здоровья продукта
• Считали, сколько будет стоить продукту содержание ассистента

По сути, мы тестировали не фичу — мы тестировали ее экономику. Важно было заранее понять, влезаем ли мы в юнит-экономику до запуска полномасштабного эксперимента.

📊 После этого запустили основной A/B-тест, он идет 3 недели и раскатан на 100% пользователей — соответственно, доступен половине (50%). Основная цель эксперимента - проверить влияние на конверсию.

И вот здесь становится интереснее: почти сразу зафиксировали полезный инсайт.
У пользователей есть повторяющийся запрос, который логично упаковать в отдельную категорию. Так и сделали. Готовим запуск новой категории на основе реального поведения, а не ощущений.

❔ Почему 3 недели?
• Потому что нам нужна статистическая устойчивость
• Нужно собрать достаточный объем данных
• И отделить реальный эффект от шума короткого периода

⏳ После завершения теста мы не будем сразу масштабировать. Закладываем ~пару недель на анализ результатов

Будем считать:

• Сколько фича фактически заработала
• И во сколько она фактически нам обошлась
• Как повлияла на юнит-экономику
• Какие сценарии развития окажутся наиболее перспективными

⚠️ Скорее всего, ассистент останется в проде. Даже если его метрики окажутся ниже наших ожиданий, ведь в нем зарыта функциональность для развития на годы вперед. Возможно, потребуется менять модель взаимодействия с ним по мере развития ассистента, если текущий эксперимент покажет не лучшие результаты. Придется переобучать пользователей, которые привыкнут к ассистенту только подбора блюд.

AI здесь не эксперимент ради эксперимента. Это новый рабочий слой продукта.
И мы пока только формируем внутрикомандное представление о том, что именно будет находиться в этом слое

💡Последние полгода на Инициативных Комитетах обсуждаем инициативу командной подписки на AI-инструменты. Бюджет небольшой - примерно стоимость одного middle-разработчика в год

Изначально инициатива называлась «Подписка на Cursor». Мы рассматривали Cursor как основной инструмент и думали, скорее, о компенсации расходов разработчиков на agentic-tools, а не о развитие инженерной культуры. Но по мере обсуждения отказались от привязки к конкретному решению

Сейчас ориентируемся на бюджет около $50 в месяц/рабочее место. Идея в том, чтобы дать команде возможность экспериментировать и сравнивать подходы: IDE-ассистенты, CLI, агентские режимы, API для внутренних ботов и прочее

📈 Сначала обоснование строили через рост эффективности
Строили финансовую модель. Пытались говорить про ускорение отдельных этапов разработки. Приводили реальные примеры вайбкодина в нашем продакшене

🔄 Но быстро уперлись в проблему: ИИ может ускорять только отдельные этапы разработки. Но часть выигрыша съедается сопровождением - проверки, правки и прочее. Обещать системный рост эффективности через ИИ оказалось слишком рискованно

И главное - такая аргументация формирует опасные ожидания у управляющей компании

🔀 Поэтому мы поменяли подход. Теперь мы не обосновываем ИИ как инструмент ускорения разработки. Мы рассматриваем его как инвестицию в инженерную зрелость команды

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

🛠 Три недели на Claude Max — и Cursor мне больше не нужен

Шла третья неделя использования Claude Max(20x) по подписке, и, впервые за полгода, я не проплатил подписку на Cursor. Пока мы прорабатывали инициативу ИИ Просвещения в компании, я перепробовал кучу подходов и инструментов. Как и писал выше — от идеи тащить корпоративный Cursor мы отказались почти сразу

🔍 Cursor — хороший инструмент. Мультимодели из коробки, широкие возможности. Но всё, что он делает — он делает вокруг оболочки VS Code, которая мне просто не нравилась. В итоге висела проплаченная подписка, идеи я прорабатывал в ChatGPT, а когда нужно было жёстко по-вайбкодить — открывал Cursor, но редко упирался даже в их приземлённые лимиты

🛑 Главная проблема Cursor — и для меня, и для программы Просвещения — в том, что он слишком легко даёт результат. Как Windows Forms в Visual Studio: создаёшь Button, переходишь в OnClick, описываешь всё поведение прямо там. Код работает — но ты не думаешь ни о парадигмах, ни об абстракциях. Cursor устроен так же — он прячет сложность за красивой оболочкой, и человек получает результат, не понимая, что именно произошло. Для обучения это антипаттерн

💡 Я не планировал переезд, просто хотел потестировать Claude. Но уже за первую неделю он стал моим персональным помощником №1. Сам помог настроить окружение, рассказал, как правильно управлять контекстом, автоматизировал несколько рабочих процессов за короткие вечерние сессии. Постепенно даже планирование переехало из ChatGPT — управление проектами и интерактивные дорожные карты в Claude Chat с лихвой перекрыли аналогичные фичи ChatGPT

⚠️ Жаль, что Anthropic вынуждены вести агрессивную финансовую политику. Использовать Claude через сторонние инструменты вроде OpenCode можно, но только через API-токен, где обычный проход по контексту проекта легко переваливает за $100

Три недели мне хватило, чтобы определиться. Одна подписка заменяет всё: ChatGPT, Cursor, китайские GLM'ки. Больше никакого зоопарка инструментов. Один ассистент - один рабочий процесс ☝️

🔍 Наблюдаемость начинается не с метрик

➡️ В феврале я подавал заявки на Saint HighLoad, одной из тем было Observability. Об этом я писал выше. Когда я в итоге сел прорабатывать собственное понимание этой темы - находки меня впечатлили, хотя казались достаточно очевидными
Моя цель на год звучала классно - любой инженер локализует проблему за 10–15 минут. Для этого нам нужна наблюдаемость в своем стандартном виде, т.е.: "Observability = Metrics + Alerts + Traces". Классика. Бери и делай... Но делай что?

🛑 Когда я сел за дорожную карту - начал буксовать. Пытался раскрутить: Как выставить правильные пороги? Какие метрики вообще являются хорошими, а от каких стоит избавиться? С метриками, кстати, понятно - наш архитектор приучил меня к очень правильному вопросу: «Какой алерт я повешу на эту метрику»
Отсюда возникает и главный вопрос - а какие алерты нас вообще интересуют? Как понять, что система работает корректно?

💡 Ответ оказался не техническим. Система работает корректно тогда, когда приносит деньги. Всё.
10–15 минут реакции - это следствие, точнее, реализуемое действие, для того, чтобы снизить потери бизнеса. Но причина в том, что мы не умеем считать потери. Когда падает сервис, никто не может сказать: «за последние 40 минут мы потеряли примерно X рублей». Только в случае полного отказа всех наших сервисов, боже дай мне сил...

❗️ Когда я переформулировал цель, и сделал целью ДК автоматизацию подсчёта потерь - ДК начала вырисовываться в моей голове, причем очень последовательными шагами. Сразу стало понятно:
• Для подсчёта потерь нужны SLI/SLO/SLA сервисов
• Для SLI нужны метрики и алерты - конкретные, привязанные к бизнес-процессам
• Для сокращения времени реакции нужны трассировки по которым можно отследить, где нарушаются эти самые SLA

Те же самые Metrics + Alerts + Traces - но теперь каждый элемент отвечает на конкретный вопрос, а не висит в вакууме

✅ Ошибка была не в инструментах, а в целеполагании. Я пытался строить наблюдаемость от инструментов к результату. Но без учета бизнес-контекста результат оставалось только высасывать из пальца. В очередной раз процессы оказались важнее технических костылей)

🔜 Дальше расскажу, с чего мы начали практически: аудит алертов и логирования. Спойлер - то, что мы нашли, нас не обрадовало

🔍 Как прошла AI Conf в Москве

Конференция собрана как «конференция развития» с 40% интерактивных форматов. Было 4 основных трека - из них я и собрал свой личный маршрут

🎤 Доклады
На доклады изначально не планировал идти - их можно посмотреть в записи. Но с утра хотелось неспешно добраться до Технограда, ознакомиться с локацией, пройтись по этажам. В итоге на один из двух утренних докладов я попал. Два открывающих доклада рассказывали об изучении китайского для AI-карьеры. Логика спикеров проста:

Промтить на родном для моделей языке и общаться с инженерами на китайских аналогах Хабра => карьерное преимущество

🧪 Мастер-классы
Сходил на несколько: Schema Guided Reasoning и Agent Observability via Langfuse. Понравился формат, спикеры и организаторы постарались сделать качественно и интересно. Но, видимо, из-за смены формата конференции не было времени на «обкатку» материала с mock-залом, оба МК не уложились в тайминги. А инструменты сугубо специализированные, чтобы начать их использовать нашей команде потребуется менять подход к работе с AI в процессах и продукте - что маловероятно сейчас

🗣 Открытые столы
Еще один живой-мастер класс, с разделением на команды: Стол по теме «Как продавать AI-фичу бизнесу». Разбивались на 7 команд с 7 разными AI-проектами, я взял ближайшую тему - AI Code Reviewer. Из-за нехватки людей в итоге объединились в 3 команды. Прорабатывали emotional map для C-Level: о чём думают, чего хотят и чего боятся CEO, CTO, CISO. Было весело, но не шибко полезно - имея опыт продавать AI-фичи бизнесу знаю: разговор всегда о бабках. О бабках через эффективность, через автоматизацию, через смену парадигмы разработки - но не через эмоции. В бизнесе вообще нет эмоций. Только деньги

🎪 Стенды
Дюжина стендов партнёров с разными активностями: розыгрыши в лотереях, викторины, игры в лего и т.д. Вооружился желанием устроить обмен опытом в офисе - гонял по стендам и собирал максимум лута, чтобы разыграть внутри своей команды. Вернулся домой с тремя пакетами

🎉 Афтерпати
Проходило на этаже со стендами, когда активности закончились. Шведский стол, алкоголь, закуски. Безалкогольное пиво для меня. Поболтал с ребятами со стендов, которые понравились больше всего, об айтишке, о технологиях, о процессах - приятный нетворкинг в конце дня. Уходя, наткнулся на неанонсированный доклад от HR, видимо, Сбера про рынок труда: «рынок сломан, чинить никто не будет» - это если кратко

Уже провели командный обмен опытом после конфы - в следующих постах расскажу о том, как это было

🧠 Уже два месяца перетряхиваю свою базу знаний в Obsidian — но главную ценность от этого нащупал лишь сейчас

Вот и я поигрался со своим Obsidian. Размышлял про какой-то локальный RAG над базой — пока размышлял, сообщество уже всё решило и выкатило в обкатку Obsidian Wiki
Есть готовые скиллы для пересборки Obsidian в «Wiki-мозг» — хотя, какой это мозг? Просто хорошо структированная база знаний, с агентами над ней. Тем не менее — с первого взгляда были отличные ощущения
На своей базе применил этот skill

🛑 Годы работы в Obsidian были колоссальной когнитивной нагрузкой. Я пытался сортировать заметки при заведении — не справлялся, поэтому раз в пару месяцев убирался и никогда не заканчивал дело до конца. На постере это видно: в старом графе одна часть базы отслоилась от другой — куча записок, связанных между собой, но никак с основной базой

🔍 Целый вечер и 40% пятичасовых токенов Claude ушли на знакомство агентов с моими записками. Радовало, когда он спрашивал про отрывки заметок, которые я сам давно уже забыл, но о которых стоило помнить. Потом составил скоуп — где-то 120 вопросов по оборванным заметкам — сагрегировал мои ответы и собрал мой персональный граф знаний

➡️ А дальше — просто. Пишу заметки в Daily Notes, разделяю на блоки работы и личного, выделяю что-то формулярами Markdown. Раз в неделю, минут за 30–60 в выходной, запускаю сессию: «актуализируй базу по последним заметкам» — он вытаскивает свежие заметки, находит пересечения с базой, обновляет ноды графа и подкидывает новые вопросы. Никакой сортировки на входе — вот это и сняло главную головную боль

💡 Но я долго не понимал, какую ценность отсюда вытащить, кроме красиво структурированных файликов. Понял неделе на 5–6, когда тестово перегнал в базу два года истории ван-ту-ванов с сотрудниками. Теперь перед ван-ту-ваном один простой запрос даёт достаточно актуальный контекст по человеку — напоминания про мотивацию, обещания, незакрытые вопросы

⚠️ Естественно, такие манипуляции необходимо обсуждать с людьми своевременно, правда, до меня это дошло уже после. Ходил на ван-ту-ваны и заходил издалека: «Представим, что твой лид — и это точно не я — слил историю взаимодействия с тобой в LLM, чтобы улучшить опыт проведения ван-ту-ван'ов. Как ты к этому отнесёшься?»
Все дали добро. А дальше мы вместе открывали «их портрет», нарисованный LLMкой, оценивали его и полировали

✅ В целом я думал, что такая модель поможет мне именно с структурой ведения заметок, с поддержанием порядка в них. А получил помощника, в виде Агента, который помогает мне пушить мои проекты и не даёт забывать важное — и чем точнее граф отражает твою реальную загруженность, чем больше там контекста по твоим текущим проекта — тем больше от него пользы
Говорят же люди, в разных вариантах: «Ценность рождается на пересечениях — технологий, подходов, сфер»

Находка отличная. Правда, мне самому она скоро не пригодится — почему, расскажу в ближайших постах