Вот одна из модных темок, которые внезапно полетели с развитием агентов: гиперкастомизация (это когда у тебя 23 клиента, и каждого ты наё*** каждому ты продаёшь базу + обёртку с доп.множеством локальных фич под видом отдельного продукта :). Конечно и раньше такое было, но крайне трудоёмко: девопс вручную резолвил конфликты при каждом обновлении ядра. И хотя внутри был огромный JSON с настройками для каждого клиента, сам код всё представлял собой говно-спагетти с миллионами проверок. А ежели ещё и микросервисы, то получался ад 23 деплоя, 23 лога, 23 апдейта зависимостей... Да и не получалось на практике столько клиентов.

Теперь же каждая надстройка живёт изолированно (не в одном коде с флагами! а отдельно физически). При обновлении ядра N-я надстройка пересобирается автоматически, AI сам решает, как наложить изменения, сам тестирует результат, а чел только проверяет и одобряет сложные кейсы.

Каждая клиентская версия - отдельная git-ветка от main.
В каждой ветке файл PATCH md (что уникального сделано для клиента).
При каждом комите в main создаётся PR из main в каждую клиентскую ветку.
Агент локально обрабатывает PR: мержит, чинит конфликты, тестирует, и более того, делает скрины UI. Дешёвый и быстрый способ верификации: вместо "скачай ветку, задеплой проект, проверь" просто смотришь картинки из браузера (принимаешь работу по визуальным доказательствам). Общение просто через тот же телеграмм.

Погуглите сами, спросите AI.

=

Ну а с ментатами в "Функциональных архитектурах", разберём это всё с точки зрения теорката: есть один базовый объект, и есть семейство морфизмов из него в клиентские объекты. Эволюция ядра -- это функториальность (апдейт базы индуцирует обновления клиентских версий не вручную, а по правилу, сохраняющему структуру, на уровне всех зависимых вариантов).
Merge/rebase формализуем коммутативной диаграммой: можно сначала обновить ядро, а потом применить клиентскую кастомизацию, а можно взять старую клиентскую версию и перенести её на новое ядро, пофиг.
PATCH md -- человеко-читаемое описание морфизма кастомизации.
Агент соответственно, категориально пытается найти корректное продолжение морфизма после изменения базы :)
Смок-чеки -- это булевы предикаты жизнеспособности, а скрины нейронка умеет распознавать, они становятся источниками тестовых признаков (базис наблюдаемых инвариантов, cвидетельства корректности морфизма).

Когда клиентов твоего псевдо-индивидуального продукта 5-10, ты ещё сможешь жить на инженерных эвристиках. А когда 50, без общей модели всё расползается. Формализация же превращает "много частных случаев" в "много экземпляров одной конструкции": ядро, формализованные вариации, автоматическая миграция и верификация производных продуктов.

Вместо O(N), где N- количество клиентов (а когда N вырастет под 20, получишь O(N^N))
имеем O(K << N) где K -- число ручных правок.

Я даже думаю, что наверно подробно для Функциональных архитектур буду это ещё долго расписывать, поэтому по многим этим темкам хочу лучших моих ментатов консультировать индивидуально.
P.S. Напишите мне кстати, товарищи ментаты, кому гиперкастомизация актуальна.