В целом, с LLM удобно и вести исследования различных предметных областей как таковых.

К примеру, в процессе данной работы обнаружилось, что любой метод работы (компетенцию) можно разложить на:
- Ядро метода (K), которое не меняется от проекта к проекту. Пример: «Разворачиваем Gitlab-CI в общем», «знание Ansible»
- Контекстно-зависимые методы (S) — то же самое с репликацией, отказоустойчивостью и резервными копиями. Здесь можно много развивать в любую сторону — это по своей сути system analysis + system design. Написать пайплайн легко — берешь, читаешь туториал и пишешь. А вот вписать его в контекст проекта (количество команд, отзывчивость пайплайна, его надежность, комплаенс по секретам, мониторинг пайплайнов) — это уже совсем другое.
- Внесервисные методы — заказчик часто не может качественно сформулировать запрос на услугу. Например, сколько ему времени хранить резервные копии, или сколько ему нужно диска под данные. Нужно ему в этом помочь, а может быть и убедить что нужно сделать так, а не иначе, т.е. транслировать потребности в требования.

И все эти методы по своей природе разные — одно это знание инструмента, второе это насмотренность и знание архитектуры, третье это умение коммуницировать и выгружать из соседней команды чего они хотят на самом деле.

По аналогии можно декомпозировать и другие объекты