Инверсия в разработке продуктов
Я много кручусь в контексте компаний клиентов и в последние месяцы вижу любопытный сдвиг
Раньше, если нужна внутренняя автоматизация, это почти всегда отдельный продукт. Свой бэкенд, база, деплой, интерфейс
Когда появились LLM и открыли новый класс задач автоматизаций, архитектурной ничего не поменялось – просто обмазали все Structured Output, ретраями, мониторингами. И воткнули в свой детерминированный пайплайн
А сейчас вижу, как некоторые команды отказываются от такого подхода.
Почему? Об этом чуть позже. Сначала о том, что берут взамен:
- Codex/CC/OpenCode как оркестратор на VPS
- папка с настроенными http://AGENTS.md/, скриптами обработки данных и скиллами-коннекторами к внешним источникам (гугл таблицы, тг, crm)
- Cron джоба, которая запускает агента по таймеру или заход руками в агента и запуск задачи текстом вместо кнопок в UI
А в еще более кардинальной форме это вообще агент прям на устройстве юзера с настроенными Automations/Routines
———
Получается забавная инверсия:
Если раньше в базе были детерминированные блоки, на которые сбоку лепилась LLMка, то теперь, наоборот, в базе лежит гибкий AI агент, дергающий детерминированные скрипты, на ходу подстраиваясь под результаты вызовов
Не код вызывает LLM, а LLM вызывает код (с) gpt
———
А теперь, мои мысли, почему это происходит:
Первое: гибкость выполнения
Если агент видит, что данных не хватает, он может сам пойти в gmail, notion, джиру, crm, аналитику – куда дали доступ. Не обязательно заранее прокладывать пути в пайплайне
Второе: гибкость изменения
Чтобы изменить процесс, часто достаточно поменять instruction-файл, prompt, список tools или небольшой локальный скрипт.
Третье: самообучение
Если агент столкнулся со сложностями, но обошел их (обязательно попутно отправив warning в нужный тг чат), то можно попросить его запомнить новый подход. Он сам обновит релевантные скиллы.
И даже само это обновление можно тоже зашедуллить (но такого я еще вживую не видел)
Ну и главное, четвертое: низкий порог входа
Не нужно уметь кодить, деплоить, мигрировать. В итоги сейлзы, маркетологи, менеджеры сами собирают автоматизации, на которые раньше приходилось месяцами ждать разработчиков.
———
Лодка дегтя – не везде такой подход имеет смысл.
Ред флаги для него:
- у системы много пользователей
- есть shared state (но можно выносить вовне)
- нужна строгая воспроизводимость
- высокая частота запуска или требования к latency
- все контракты давно стабильные
Ну и наоборот, гринфлаги:
- входные данные плавают
- нужно принимать решения по ситуации
- источники меняются
- правила часто переписываются
- человек раньше делал это руками, потому что "ну там надо посмотреть по контексту"
Короче, если задача похоже на конвейер, то в таком переходе не много смысла. А если похоже на работу оператора/ассистента, то есть
tl;dr:
Раньше, чтобы автоматизировать процесс, нужно было сначала превратить его в жесткий алгоритм.
Сейчас часть процессов можно автоматизировать раньше – на стадии, где они еще не до конца формализованы
