Я вже давно використовую такий підхід, хоча я девопс, а не розробник мікросервісів: CLAUDE.md (чи AGENTS.ms) містить тільки універсальні правила та індекси (посилання) на інші .md файли. Кожен проект має свій PROJECT.md і грузиться тільки і якщо я зараз працюю з цим проектом. Так я уникаю дублювання і context bloating. Втім, в моєму випадку йдеться не про monorepo, і кількість репозиторіїв росте, тому зараз я все перевожу на MCP сервер, де реєструються різні проекти кожен зі своїми правилами, на додаток до універсальних дефолтних і вони підтягуються тільки тоді, коли потрібно. Так я взагалі позбавляюсь локальних .md файлів у репах. Тепер в мене в кожному репо дуже мінімалістичний агентс.мд що містить перелік обов’язкових mcp серверів та кілька специфічних інструкцій для даного репозиторію, все інше живе у відповідному проекті внутрішнього MCP.

Якось так. Поки що це все працює дуже непогано.

Чувак, ти в натурі бот. Просто тупо копіпастиш маркетинговий булшіт про клауд нейтів креп. Це навіть коментувати западло, ти явно не в темі. Мабуть один з тих самих сертифікованих кубернетс макак, які крім своєї пісочниці нічого не бачили.

Я цим вже 20 років займаюсь і прусь з таких як ти, хто впевнений, що крім кубернетсуі терраформу нічого не існує, і що усім потрібен «динамічний скейлінг», меш і всі інші хайпові приблуди,які на рівному місці створюють купу нових проблем не вирішуючи по суті жодних, длявирішення яких вони й створювались. А навіть якщо воно дійсно треба, то є речі в рази менш проблемні ніж те, у що перетворили кубер. Просто смузіхльоби про них не знають.

І заплатити такому, хто знає як, буде дешевше в рази, чим переплачувати за overengineered AWS certified bullshit.

Зараз? Та завжди можна було. Наймаєш одного-двох досвідчених системних інженерів, і вони тобі розгортають і підтримують все, що треба на bare metal, без всякого ШІ, кубернетсів (непотрібних в 99% юз кейсів), тощо, і все буде працювати, в рази дешевше, без зайвих нервів, витрат і хайпу.

Але ж це не модно, так ніззя, люде не поймуть :D

А, ну якщо про ці «правила» мова, тоді єдиний вихід це локальна модель, перенавчена згідно ваших вимог.

«Правила» зашиті в в конкретний чатбот або агента, а не в модель. Модель це як бекенд з API, вся обробка промптів і редактура відбувається на рівні «фронтенда», чатбота чи агента. Напишіть свій, підключіть до будь якої моделі на свій смак і будете повністю контролювати всі «правила».

Ніхто не забороняє вам вести логи сессій, можна навіть зберігати їх зрізи разом з комітами коду в системі контролю версій. Я так і роблю, наприклад (але додаю все в гітігнор, бо над проектом працюють інші люди та їх агенти теж). Я майже весь час (і токени) витрачаю на планування роботи агента, генерація коду, тестів та тестування (особливо в асинхронному режимі з субагентами) займає мінімум часу. Всі архітектурні рішення, виявлені помилки, недокументована поведінка сторонніх API, розроблені мною safeguard protocols, тощо, фіксується в PROJECT.md, session.md, тощо. Ну і в memory самого агента. А як інакше?

Ті, хто жаліється на те, що сгенерований код виходить з під контролю, імовірно не зробили нічого, щоб керувати складністю проекту і фіксувати рішення, не вміють планувати. Агенти та моделі тут ніпричому. Схоже, що нити про technical debt та жонглювати іншими базвордами їм простіше, ніж вмикати власний мозок.

Нарешті допис на тему АІ без води і хайпу, все по ділу. Автору респект, гарне summary.