Comments 6
Оч.круто расписано. Спасибо.
Очень полезная статья! Я считаю - именно такой материал и является отправной точкой будущее, где мы полностью перейдем на AI drive - полностью поддерживаю такой подход, мы своей командой действуем только так!
Незаслуженно мало внимания у этой статьи
Нужная статья. Подход чем-то напоминает BMAD, но заточенный чисто под Claude Code.
Я у себя в опенсорсной разработке своим ботом-программистом использую 6 шаблонов для популярных языков программирования JavaScript/TypeScript, Rust, Python, Go, C#, Java. Это шаблоны репозиториев с заранее настроенным CI/CD, который включает проверки линтерами (что стиль кода соответствует настроенным правилам), форматтерами (что код отформатирован так, как это того ожидается в проекте, то есть в едином стиле), тесты (unit, integration, e2e и т.п.), есть настроенный флоу для changesets с возможностью мержа нескольких версий в одну, если вдруг CI/CD сфейлился. Changesets помогают снизить количество конфликтов между Pull Requests, что позволяет сэкономить AI токены на что-то более важное. Также есть pre-commit-хуки, чтобы гарантировать, что часть проверок пройдёт ещё до того как AI или участник команды разработки попытается закоммитить код. Ну и конечно CD-часть - релизы в пакетные менеджеры/docker hub/helm и поддержка GitHub Releases.
Фактически это CI/CD для командной разработки, который гарантирует, что любой Pull Request будет соответствовать всем заданным стандартам качества.
В AI-Driven Development CI/CD это превращается добавляя одну критически важную проверку, требование чтобы все файлы с кодом и файлы документации были менее 1500 строк, если такого не сделать, то Claude Code CLI не будет способен прочитать исходный код или документацию в одном файле целиком (у него ограничение read tool в 25000 токенов на чтение за один раз), а значит он может упустить что-то при работе с ним. Это так же помогает и людям, так как маленькие файлы проще читать и поддерживать и для людей.
Зачем столько разных ролей я не очень понимаю, мне хватает одной роли AI issue solver в нашей системе и в будущем я планирую добавить роль архитектора. Если решатель создаёт Pull Request и пишет код, то архитектор будет занят исключительно постановкой задач, их декомпозицией, приёмом результатов и композицией частичных результатов в один целостный.
Так что мне лично кажется можно просто применить лучший опыт из того что мы уже всегда делали, но для AI и CI-проверки фактически выполнят роль ревьювера, и будут гарантировать что каждый Pull Request будет содержать минимум необходимых правок их будет легко читать и правки будут соответствовать необходимым стандартам качества.
https://github.com/link-assistant/hive-mind/blob/main/docs/BEST-PRACTICES.md - подробнее документ об этом у меня есть тут со ссылками на репозитории-шаблоны. Всё с открытым исходным кодом и в общественном достоянии.
Очень достойный пост. Попробовал у себя внедрить, используя opencode и локальные LLM (или big-pickle). Получается на дстойном уровне.
От себя рекомендую выделить папку для документации для агентов в отдельное место и не мешать с остальной документацией.
LLM — не один большой «мозг», а команда ролей. Как собрать AI-workflow в Claude Code и уйти от вайб-коддинга