Антон Фокин

Правильный способ считать такие вещи: сравнивать не с идеальным мониторингом, а с тем, что было раньше — то есть с тишиной до первой жалобы клиента. На этом фоне пара ложных срабатываний в месяц — приемлемая цена. Но у ИИ-дежурного есть отказ, который страшнее ложной тревоги: молчание. Ложный сигнал вы увидите и отбросите, а вот если агент перестал проверять (упал крон, кончился баланс, сменился формат логов) — система выглядит здоровой ровно так же, как когда всё правда хорошо. Поэтому у любого сторожа должен быть свой сторож: heartbeat, который алертит на отсутствие проверок, а не только на найденные проблемы. Плюс синтетическая проверка — раз в сутки подкидывать заведомо сломанный сценарий и убеждаться, что дежурный его поймал. Без этих двух вещей нельзя отличить «проблем нет» от «наблюдение сломалось»

Самое сложное в таких сервисах не качество модели, а цена ошибки, которая асимметрична. Ложное «вода» на осмысленном тексте бьёт по ученику, ложное «понимание» на пустом тексте бьёт только по репутации сервиса — и первое переживается несопоставимо тяжелее. Отсюда практический вывод: калибровать порог надо не на максимум общей точности, а на минимум ошибок первого рода, даже ценой того, что часть воды проскочит. И честно показывать не вердикт, а уверенность: «низкая уверенность, нужна проверка учителем» — рабочий ответ, а «3 из 10» без пояснения превращается в приговор без апелляции. Если система в образовании выносит оценку, у неё обязана быть процедура обжалования, иначе первый же громкий несправедливый случай похоронит доверие ко всему инструменту, даже если он в среднем прав в 90% случаев

Каскад решает падения, но незаметно меняет экономику и качество, если за ним не следить в разрезе провайдеров. Один общий график «всё работает» прекрасно скрывает, что 40% трафика уже месяц уходит на резервную модель, которая дороже втрое и отвечает заметно слабее. Минимум метрик с первого дня: доля запросов, стоимость и p95 отдельно по каждому провайдеру плюс алерт на смену профиля, когда резерв стал основным. Второй подводный камень — идемпотентность на переключении. Если первый провайдер успел выполнить побочное действие (записал в базу, отправил сообщение), а таймаут случился на чтении ответа, слепой фоллбэк повторит это действие. Для чистой генерации текста неважно, для агентов с инструментами — источник дублей, который потом ловят месяцами

Спор почти всегда идёт о технологии, а решают его две скучные цифры. Облако выигрывает при неравномерной нагрузке (пики, рост, эксперименты) и в маленькой команде — вы платите за то, чтобы не нанимать людей под железо. Своё железо выигрывает при стабильно высокой утилизации: если вы месяцами держите ровные 70%, то платите облаку за воздух. Плюс исходящий трафик — egress в облаках убивает экономику быстрее, чем это закладывают на старте. Горизонтально масштабируется и то, и другое, разница не в возможности, а в цене за единицу и в том, кто дежурит ночью. Практический критерий вместо холивара: посчитайте реальную утилизацию за последние полгода и стоимость исходящего трафика. Обычно после этих двух цифр спор заканчивается сам — причём у разных проектов в разные стороны

Раздувание — следствие одной привычки: в файл инструкций пишут реакцию на каждый разовый инцидент. Агент один раз сделал не то — появилась строка «никогда так не делай». Через полгода это 400 строк, половина описывает ситуации, которые больше не воспроизводятся, а модель следует длинному списку заметно хуже, чем короткому. Рабочий фильтр перед добавлением любого правила: можно ли выразить это проверкой вместо просьбы? Если да — тест, линтер, хук на коммит, защищённые от записи файлы. Инструкция это просьба, которую можно не прочитать или потерять в глубине контекста; проверка это граница, которая срабатывает всегда и не зависит от длины файла. В инструкциях стоит оставлять только то, что автоматизировать нельзя: контекст проекта, архитектурные принципы, логику принятых решений

Впечатляющая цифра, но для инженерной аудитории она неполна без второй половины: 54 задачи в прод за сутки — это здорово, если через месяц не пришлось откатывать пятнадцать из них. Скорость вывода — метрика тщеславия, если рядом не стоят DORA-показатели качества: change failure rate (сколько изменений привело к инцидентам) и время восстановления. ИИ-инструменты реально ускоряют конвейер, вопрос в том, за счёт чего: если за счёт автоматизации рутины при сохранении всех гейтов (ревью, тесты, канареечный деплой) — это настоящее ускорение; если гейты «оптимизировали», потому что «ИИ же проверил», — это кредит, который прод вернёт с процентами. Из статьи хотелось бы увидеть именно это: что за задачи (типовые мелкие или значимые изменения), какие контрольные точки прошёл каждый деплой и что с инцидентами после. Без этого «54 за сутки» читается как «мы очень быстро едем» без указания, есть ли тормоза

Хороший список, добавлю принцип, по которому его стоит приоритизировать: self-service работает, только если построен от реальных обращений в поддержку, а не от представлений команды о «полезных фичах». Простой метод: выгрузите тикеты за квартал, сгруппируйте по темам — верхние пять групп и есть то, что должно решаться в кабинете в один клик. Обычно это скучные вещи: скачать закрывающие документы, поменять тариф, посмотреть, за что списалось, отвязать карту — а не красивые дашборды, которые никто не открывает. Мы когда делали кабинет для ScanWow (подписочный маркетплейс 3D-моделей), ровно так и шли: история скачиваний и повторное получение архива закрыли самый частый сценарий обращений — «скачал, потерял, дайте снова»: https://qtim.pro/projects/scanwow. И вторая половина правды: ЛК снижает нагрузку на поддержку только там, где сценарий доведён до конца без человека. Полурешение («заявка на смену тарифа через кабинет, дальше менеджер») не разгружает поддержку — оно просто добавляет ещё один канал входа тех же тикетов

И не надо — статья не про SEO вообще. Если у вас покупают и без него, значит канал уже есть, вопрос только в том, что происходит с заказом дальше: остаток, срок, ПВЗ. Об этом и текст)

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

Плюсы понятные: не платишь за логистику площадки, товар лежит на своём складе, его же можно продавать в других каналах и не дублировать остатки. Проблема в том, что витрина остаётся маркетплейсовой — срок и «в наличии» покупатель видит там, а выполняете вы. И если остаток на складе живёт в одной системе, заказы с площадки — в другой, а курьер/ПВЗ вообще в третьей, то разрыв вылезает не на дизайне карточки, а на статусе и сроке: обещали завтра, отгрузили через неделю. Дальше это уже не «неудобно клиенту», а просрочки, отмены и просадка в выдаче.

Поэтому я бы смотрел на это как на смену требований к учёту, а не как на скидку от площадки. Своя доставка окупается, если у вас есть актуальный остаток в одном месте, реальные сроки по зонам, а не средние по больнице, и обмен статусами с площадкой без ручных выгрузок.

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

Валерий, отличный тест — забираю формулировку про гигиену. Добавлю оговорку, которая всплывает почти на каждом проекте: этот критерий работает и внутри самой «стройки». Даже когда решили строить с нуля, строят не всё — ядро пишут руками, а гигиену (плеер, платежи, кабинет) собирают из готовых блоков. По сути конструктор живёт внутри стройки, и это нормально.

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