Или пример того, что будет, если роль пакетного менеджера доверить AI.
Короткий ответ — используйте шаблоны.
Шаблон — это общий каркас, на основе которого можно разрабатывать другие проекты с уникальной бизнес логикой.
Шаблон — это не обязательно Open Source. Проекты вполне могут быть размещены в отдельном закрытом репозитории компании. Но! По умолчанию руководство и сотрудники компании должны помнить и понимать, что данный шаблон разрабатывается с применением облачных моделей, соответственно, быть готовы к копированию, утечке или публикации.
В итоге получается разделение:
с шаблонами работаем в облаке
для внутренних проектов применяем корпоративные инструменты
Вроде всё просто.
Единственный сложный момент — как развивать шаблон в долгосрочной перспективе?
Что, если шаблон невозможно упаковать в библиотеку, как в таком случае переносить изменения?
Доверить роль пакетного менеджера AI.
Пример из личного опыта.
pytest-hardware-template — шаблон для тестирования сетевого, лабораторного, встраиваемого и другого физического оборудования.
Копируете проект.
Адаптируете под собственные нужды с помощью скилла "adapt-internal-infrastructure".
Когда появляется нужное вам обновление, переносим коммит или отдельный функционал шаблона с помощью скилла "adapt-template-change”.
Как оказалось на практике, сегодня даже небольших локальных моделей достаточно для качественного переноса. Если ранее вы уже внесли изменения в проект, в случае конфликта, агент предложит варианты, как адаптировать изменения. Чем больше модель и меньше объем изменений, тем лучше. Чем более отчетливо, но недвусмысленно и коротко сформулированы правила архитектуры в AGENTS.md, тем меньше вопросов ОТ агента и К агенту возникнет в будущем.
Останется только соблюдать данные правила архитектуры самому разработчику :)
Кстати, про архитектуру.
Проект pytest-hardware-template изначально задумывался НЕ как библиотека, а именно как универсальный шаблон.
Но в процессе разработки стали видны части, которые в будущем, когда установится публичный API, удобно перенести в отдельную библиотеку.
Как минимум, поможет сохранить токены и время.
Поэтому для разработчиков шаблона и проектов, созданных на его основе, в документации добавлено специальное решение об архитектуре и возможной публикации в виде библиотеки.
Да, да, да...
Наконец-то!
Пора задать тот самый вопрос.
“Алексей, новый проект, шаблоны, звучит модно и современно. Но что делать с легаси?”
Проводить аудит проектов.
Где есть смысл и возможность — выделять части для работы с облачными моделями.
Где нет либо смысла, либо возможности — подумать еще раз.
Да, это нелегко.
Иногда даже сама процедура согласований публикации в Open Source небольшой части кода может занять месяцы.
Пример из личного опыта.
yaml-test-params — библиотека для динамической генерации тестовых параметров из файлов конфигурации YAML.
Проект изначально был небольшим вспомогательным модулем, примерно на 200-300 строк кода. Процедура согласования заняла месяц. В итоге получилась библиотека.
Стоит ли игра свеч?
Из приведенных выше примеров основное преимущество, которое давали облачные модели — идеи, фичи, варианты архитектуры, которые приходили в диалоге с моделью.
Хорошо, когда знаешь, что спросить.
Но когда образ функционала только вертится в мыслях, приходится искать, перебирать варианты.
Как показывает моя собственная практика, сочетание большого размера моделей и встроенных поисковых движков облачных провайдеров AI дает ощутимую разницу, ради которой стоит пересматривать и процессы внутри компании, и архитектуру проектов.
Возможно, даже что-то переписать с нуля.