Как я выстроил ролевой пайплайн в Claude для разработки
Автор попробовал делать сайт с помощью Claude и быстро понял: одного промпта хватает только для простых задач. Когда проект стал расти, пришлось выстраивать отдельный пайплайн с ролями, проверками и передачей контекста между шагами.
Почему обычного чата оказалось мало
Осенью 2025 года автор, который раньше занимался базами данных и не писал фронтенд, решил собрать сайт с помощью ИИ. Сначала общение с моделью шло в формате обычных чатов: он описывал задачу, а затем уточнял, как именно её реализовать. Но на практике модель нередко понимала постановку не так и делала не то, что было задумано.
Проект задумывался не абстрактным, а прикладным: это была CRM для знакомых, работающих в прокате машин и обучении вождению. Позже в системе появилось и второе направление — для аэроклубов. Для реализации выбрали Django: по словам автора, этот вариант оказался проще и понятнее, чем стек с сильной нагрузкой на фронтенд.
Как из чатов выросли роли и документы
Сначала автор формулировал бизнес-требования и архитектуру, а потом использовал эти документы как основу для реализации. Однако в Gemini он столкнулся с тем, что модель плохо работала с документами: могла неправильно вносить изменения и перезаписывать часть текста. После этого он попробовал несколько консольных агентов и особенно выделил Codex CLI — тот не только выполнял задачи, но и помогал осваивать команды вроде ripgrep.
Неудачный опыт с рефакторингом стал поворотным моментом. Когда автор попытался унифицировать общие ресурсы для машин, инструкторов и площадок, Codex отчитался о готовности, но по факту почти ничего не изменил. После нескольких кругов он понял, что разрозненное промптирование не даёт нужного контроля. Тогда и появилась идея разложить работу на роли: архитектор, планировщик, кодер и ревьюер. Позже к ним добавился менеджер, и запуск стал автоматическим.
Что даёт такой пайплайн на практике
Новая схема нужна автору не ради красоты, а чтобы заранее понимать, что именно делает модель на каждом этапе. Сначала роль архитектора продумывает решение, затем планировщик определяет, какие файлы надо менять, потом кодер вносит изменения, а ревьюер проверяет результат. В конце всё снова проходит через контроль, чтобы убедиться, что изменения действительно соответствуют задаче и их можно занести в Git.
Сейчас через этот пайплайн проходят не все задачи, а только те, где важно оставить понятный след изменений. Один из примеров — внутренний проект Tooling, где переработка ядра идёт через такую схему, потому что потом эти изменения разносятся по зависимым репозиториям. По сути, автор собрал для себя более надёжный способ работать с ИИ там, где важны порядок, проверяемость и повторяемость.