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

Быстрый запуск почти всегда оставляет после себя уборку

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

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

Если продукт уже принимает деньги, самая дорогая фича может оказаться той, которую вы вовремя удалили.

За неделю можно снести 80 рабочих деревьев Git, 260 веток и закрыть 2 сервиса. Это не косметика. Удаление меняет продукт: 9 пользователей получили возвраты и уведомления. Значит, любое упрощение надо проводить с пониманием последствий для людей, платежей и обязательств.

Отдельная ловушка - метрики и инструменты, которые существуют только потому, что когда-то их добавили. Система сбора ошибок занимала 34 ГБ шумных данных и ни разу не дала полезного сигнала. Данные не равны наблюдаемости. Если сигнал не помогает принять решение или найти проблему, он превращается в стоимость хранения и лишний шум.

Зелёные тесты не отменяют ручную проверку продакшена

Тесты показывали зелёный статус, но рабочие движки за 2 недели были перезапущены 6 раз. Причина оказалась в сторожевом процессе. На машине с русской локалью `awk` прочитал счётчик токенов `1.4e+07` как единицу. Процесс решил, что живая генерация на 260 Вт зависла, и останавливал её прямо посреди ответа пользователю.

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

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

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

Инфраструктурный сервис растит процессы, а не только код

Один продукт можно собрать, выложить и наблюдать по отзывам. У инфраструктурного сервиса другая физика. У него много входов: собственные GPU, внешние модели, платежи, ключи, лимиты, песочницы, интеграции. И ещё больше выходов: боты, пайплайны и продакшены пользователей, которые зависят от его работы.

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

После рубежа примерно в 100 активных пользователей в неделю одному человеку уже трудно удерживать весь объём. Это не универсальная цифра для каждого проекта. Но она хорошо показывает момент, когда архитектурная сложность становится и организационной.

Люди нужны в разных контурах:

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

Деньги после первых платежей стоит вкладывать в людей и ясность

Когда появляются платежи, возвраты, SLA, B2B-обязательства и пик в 200 запросов в секунду, продукт выходит из режима демо. ИИ остаётся сильным рычагом, но сам бизнес возвращается к обычной инженерии: надёжности, поддержке, инфраструктуре и договорённостям с клиентами.

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

Полезно зафиксировать это правило в рабочем документе:

ATLAS PANEL полезна там, где команде нужно собрать процессы и ответственность в одном рабочем контуре. Но сама панель не заменит владельца процесса. Сначала нужен ответ на простой вопрос: кто увидит проблему и что сделает, пока остальные спят.