Самый рабочий паттерн в работе с AI-агентами на код — два окна. Одно с архитектором/проверяющим, второе с разработчиком. Можно собрать на одной модели: Claude в обоих окнах с разными системными промптами и сессиями. Можно смешать — у меня сейчас Claude Code в окне разработчика и GPT-5.5 в режиме высокого мышления в окне архитектора. Модель важна меньше, чем разделение ролей.
Почему один агент почти всегда хуже двух, что делает каждое из окон, и где этот паттерн избыточен.
Почему один агент — это плохо
Любой LLM-агент, посаженный в одну сессию, накапливает инерцию. Если он начал двигаться в сторону решения X, он будет уточнять X, защищать X, искать аргументы за X. Свежий взгляд оттуда не получишь. У него нет дистанции.
Вторая проблема — характер «помощника». Большинство агентов оптимизированы на то, чтобы делать то что попросили. Не задавать лишних вопросов. Не сомневаться вслух. Это удобно, когда задача типовая. Это больно, когда вы передали агенту ТЗ с дырой и он уверенно её обходит.
Решение простое: разнести роли по двум окнам.
Паттерн «архитектор + разработчик»
В одном окне сидит агент, чья задача — критиковать, уточнять, ревьюить ТЗ, ловить противоречия. Он не пишет код. Он не имплементирует. Он спрашивает «а вот тут что должно произойти». Системный промпт настроен на скептицизм.
В другом окне — тот кто реально работает с кодом. Читает репо, делает многошаговые рефакторинги, правит файлы. Этот агент должен быть быстрый и предметный, а не задумчивый.
Между окнами — я. Прокидываю ТЗ от архитектора к разработчику, ошибки и неожиданности — обратно. Никакого общего контекста между двумя агентами нет. И это не баг, а фича: каждый смотрит свежо.
Конкретно у меня сейчас:
Окно разработчика — Claude Code (он быстрый в работе с инструментами и кодовой базой)
Окно архитектора — GPT-5.5 в режиме высокого мышления (он подробнее разбирает текст и не торопится делать)
Может быть и Claude + Claude. Знаю людей, кто так делает: одна сессия настроена системным промптом на «ты архитектор, ничего не имплементируй, только критикуй и уточняй», вторая — обычный Claude Code. Работает.
Что делает окно архитектора
1. Ревью ТЗ до начала работы
Главное и самое окупающееся применение. Я пишу ТЗ — на проект, на задачу, на рефакторинг. Кидаю в окно архитектора с инструкцией «прочитай, найди дыры, противоречия, скрытые предположения, забытые edge cases».
Что регулярно ловится:
размытые acceptance criteria («система должна работать быстро» — а быстро это сколько?)
противоречия между пунктами в разных секциях
скрытые предположения про инфраструктуру
забытые сценарии ошибки и параллельных запросов
недостающие ответы на «что если null?», «что если timeout?», «что если двое одновременно?»
Окно разработчика (Claude или другой) в той же роли работает мягче. У него тренировка на «помочь сделать», и он чаще пытается подлатать ТЗ догадками вместо того чтобы остановить и спросить.
2. Уточнение размытых требований
Когда я сам не до конца понимаю, что хочу — окно архитектора задаёт уточняющие вопросы лучше, чем окно разработчика. Не один-два, а пять-шесть, ровно по тем пунктам где у меня туман.
Окно разработчика чаще делает рабочую гипотезу и идёт делать. Это удобно, когда задача типовая. Это больно, когда задача нестандартная и моя гипотеза неправильная.
3. Критика архитектурных решений
Кидаю не код, а словесное описание подхода. «Я думаю сделать через X, потому что Y». Прошу разобрать минусы, риски, альтернативы.
Получаю обычно три-четыре пункта, из которых один — реально неприятный. Не «эта технология хуже», а «вот что произойдёт через полгода когда вырастет нагрузка». Это та критика, которую от занятого делом разработчика получить сложнее — он умеет в код, но в долгосрочные последствия архитектурных решений хуже.
4. Свежий взгляд когда разработчик зациклился
Знакомый сценарий: ушёл с агентом-разработчиком в дебаг, час ковыряем гипотезу, не работает. Берём следующую гипотезу из той же логической ветки. Снова не работает. Я в плену контекста. Агент в плену моего контекста.
Сваливаю проблему в окно архитектора голым описанием: вот код, вот ошибка, вот что я уже пробовал. Без двух часов нашей переписки в окне разработчика. Архитектор часто заходит с угла, который мы не рассматривали.
Не магия. Просто чистый старт.
5. Альтернативные формулировки текста
Если в проекте есть тексты для людей — переписка с клиентом, лендинг, сложное объяснение нетехническому стейкхолдеру — окно архитектора даёт более качественные варианты. У окна разработчика, особенно после длинной кодовой сессии, стиль становится плотным и техническим.
Прошу три варианта в разной тональности. Получаю варианты, которые реально различаются, а не три перифраза одного и того же.
6. Метаобсуждение «а нужно ли это вообще»
«Стоит ли вообще делать эту фичу?». «Не пытаемся ли мы решить не ту проблему?». Эти вопросы окно разработчика задаёт редко — он по умолчанию помогает делать то что просили. Окно архитектора, особенно с настройкой на скептицизм, чаще включает сомневающегося.
Иногда раздражает. Иногда сильно экономит время и деньги.
Что делает окно разработчика
Чтобы не звучало как «архитектор главнее». Не главнее. Просто роль другая.
Окно разработчика тащит большую часть работы:
чтение кодовой базы и навигация по ней
многошаговые рефакторинги, где нужно держать в голове 20 файлов
точечные правки в большом контексте без потери общей картины
работа с инструментами через MCP-серверы
терминал, git, файловая система — всё что требует выполнения, а не размышлений
Архитектор сюда не лезет. У него и среды для этого может не быть — если это веб-чат, у него нет ни git, ни доступа к файлам.
Когда брать одну и ту же модель в оба окна, а когда смешивать
Claude + Claude работает, если у вас уже есть подписка и не хочется заводить вторую. Главное — разные системные промпты и явное разделение «это окно для архитектора, это для разработчика».
Смешанная схема (у меня — Claude Code + GPT-5.5) выигрывает за счёт того, что у моделей разный «характер» по умолчанию. GPT-5.5 в режиме высокого мышления реально берёт паузу и ковыряет проблему. Claude Code в той же роли всё равно немного склонен к «понял, делаю». Но это вопрос индивидуальный — зависит от настроек и опыта.
Универсального ответа нет. Сначала попробуйте Claude+Claude. Если архитектор всё равно тянет вас имплементировать вместо того чтобы критиковать — пробуйте другую модель в его роли.
Когда схема не нужна
Не каждый день и не на каждой задаче. Если задача типовая — рутинный CRUD, ясное требование, понятный edge case — двойная проверка только тормозит.
Я не отдаю в окно архитектора:
утилитные скрипты на час
понятные тесты
мелкие правки в существующих фичах
эксплоративный код на этапе «попробовать-выкинуть»
В этих случаях overhead на координацию двух агентов больше пользы.
Цена
Если коротко — две подписки или удвоенные токены. На моём объёме работы окупается одной поломкой в проде, которую архитектор поймал на этапе ТЗ. Такие случаи бывают регулярно.
Время на согласование тоже есть. Я не передаю агентам переписку друг друга, передаю себя как посредника. Это занимает 5-10 минут на цикл. Если задача мелкая — это ощутимый процент. На крупной задаче — растворяется.
Что в итоге
Связка работает потому что у двух окон с разными ролями ловятся разные ошибки. Окно разработчика хорошо в том чтобы быстро делать. Окно архитектора хорошо в том чтобы остановить и спросить «а ты точно?».
Если у вас сейчас один агент, и он в роли разработчика — попробуйте поднять второе окно с того же или другого LLM, настроить системным промптом на критику, и пропустить через него ближайшее ТЗ. Скорее всего он что-то найдёт.
И теперь ловлю себя на мысли: а если добавить третье окно? Какая роль ещё не закрыта в схеме? Безопасник, который смотрит на всё глазами «как это сломать»? Или продуктовик, который спрашивает «а зачем»? Пока не пробовал. Похоже, скоро попробую.