Четыре круга промптов не сработали: разработчик собрал конвейер из пяти ИИ-ролей

До пайплайна автор работал с моделями в формате чатов и вручную переносил выжимки из одного треда в другой. Осенью 2025 года он взялся делать сайт с помощью ИИ. В декабре появилась первая версия пайплайна (цепочки шагов, где каждый передаёт результат следующему, как на конвейере), в январе к ней добавились пятая роль и автоматический запуск.

Четыре круга рефакторинга не изменили ничего

Проект был прикладным: CRM (система учёта клиентов и заказов) для знакомых, которые занимаются прокатом машин и обучением вождению. Позже в ней появилось второе направление, для аэроклубов. Автор выбрал фреймворк Django на Python, потому что Python ему показался читаемым. Совет он получил после исследований с Gemini, по его воспоминаниям, версии 2.5 Pro.

Gemini, по словам автора, плохо справлялся с документами: вносил неверные правки и перезатирал текст. За месяц он перепробовал консольные ИИ-агенты (программы, которым даёшь задачу в окне терминала, а они сами правят файлы проекта). Больше всего ему понравился Codex CLI.

В ноябре автор начал рефакторинг, то есть переделку кода без изменения его работы, чтобы формы для машин, инструкторов и площадок использовали общий код. Codex отчитался, что всё готово, но поменялись только имена. Повторные запуски в новых чатах дали тот же итог, и после четвёртого круга автор бросил попытки.

Модель что-то делает, а что именно сделано, я понимаю только в конце. : Автор колонки, разработчик баз данных

Что нового: пять ролей и проверка чужой моделью

Все роли работают с одним документом, координирующим артефактом (КА), то есть общим планом задачи. За план отвечает архитектор, у остальных ролей свои результаты:

• Архитектор продумывает, что делать и как. Эту роль вели модели GPT-5 в Codex.
• Планировщик определяет, какие файлы менять, и набрасывает черновик кода. Роль появилась, когда автор спросил у модели, кого не хватает между архитектором и кодером.
• Кодер вносит изменения.
• Ревьюер проверяет работу. Эту роль выполняла GLM в Claude Code, так автор укладывался в лимиты подписок.
• Менеджер появился в январе и запускает остальные роли автоматически, без ручного переключения консолей.

Отдельный шаг, проверка решений другой моделью. Выводы GPT-5 автор перепроверял в Claude моделями Sonnet и Opus. Деталь показательная: разделение ролей выросло не из теории, а из лимитов подписок и тогдашней репутации моделей. Тогда считалось, что Sonnet хорошо пишет код, а GPT в Codex вдумчиво рассуждает.

В феврале появились «золотые пути» (golden paths). Это короткие рецепты вида «для типовой формы открой эти документы, от 3 до 5 штук, в них описано состояние системы». Их предложила роль архитектора после разбора статьи OpenAI.

Честная оговорка: формы к единому коду автор так и не свёл, только довёл до понятной одинаковости. Через пайплайн он пропускает лишь изменения, после которых должен остаться след.

Как повторить схему без навыков программиста?

1. Перед работой попросите модель изложить план и то, как она поняла задачу, и согласуйте его до старта.
2. Разбейте задачу на шаги: продумать, определить, что меняется, сделать, проверить.
3. Отдайте результат на проверку другой модели и верните замечания исполнителю.
4. В конце сверьте итог с исходной постановкой и сохраните его. Автор заносит результат в Git, систему хранения версий файлов.

Подойдут ли российские модели?

Из доступных в РФ аналогов, YandexGPT и GigaChat. Автор их не использовал, его набор: Gemini, Codex CLI, Claude Code и GLM. Как российские модели справятся с ролями архитектора или ревьюера, в материале не проверяется.

Что делать с этим прямо сейчас, по ролям

Автору Дзена. Не доверяйте модели проверять саму себя. Черновик статьи пишет одна нейросеть, сверку фактов с источником делает другая.

Маркетологу. Автор прямо пишет: подход «запустил, дал промпт, готово» работает, пока решение не нужно развивать, поддерживать или делать командным. Если ИИ в отделе используют несколько человек, нужен общий план задачи, а не личные чаты.

Предпринимателю. Заказывая разработку с ИИ, спросите подрядчика, кто проверяет результат и какой моделью. Ответ «модель сама отчиталась» в этом кейсе означал четыре круга без изменений.

Что чаще всего спрашивают про ролевой пайплайн?

Нужно ли уметь программировать?

Автор пришёл из баз данных, фронтенд не писал и Python, по его признанию, так и не изучил. Пайплайн он собирал как раз потому, что сам не мог проверить каждый шаг.

Зачем вторая модель, если первая уже отчиталась?

Codex сообщил, что рефакторинг готов, хотя код почти не изменился. Отчёт исполнителя не заменяет проверку со стороны.

Пропускать через пайплайн каждую задачу?

Нет. Автор ведёт через него только изменения, которые расходятся по другим проектам и должны оставить след. Мелочь быстрее сделать в обычном чате, а всё, что потом придётся поддерживать, стоит пускать через роли и проверку.