Разработчики, которые работают с ИИ-агентами на постоянной основе, рано или поздно замечают одну и ту же проблему: агент, начавший двигаться в сторону решения X, будет уточнять X, защищать X и искать аргументы за X. Это не дефект конкретной модели — это системное свойство любого LLM, работающего в одной сессии. Контекст накапливается, инерция растёт, дистанция исчезает.
Паттерн двух окон решает эту проблему через разделение ролей. В одном окне — агент-архитектор, чья задача сводится к критике: он читает ТЗ, ищет противоречия, задаёт уточняющие вопросы и не пишет ни строчки кода. Системный промпт настраивается явно на скептицизм. В другом окне — агент-разработчик, который работает с кодовой базой: читает репозиторий, ведёт многошаговые рефакторинги, правит файлы, взаимодействует с инструментами через MCP-серверы, терминал и git. Между двумя окнами нет общего контекста — и это намеренно: каждый агент смотрит на задачу свежо.
| Окно | Модель (пример) | Задачи | Чего не делает |
|---|---|---|---|
| Архитектор | GPT-5.5 (высокое мышление) | Ревью ТЗ, поиск противоречий, уточняющие вопросы, критика архитектуры, свежий взгляд при дебаге | Не пишет код, не имплементирует |
| Разработчик | Claude Code | Чтение кодовой базы, рефакторинги, правка файлов, работа с инструментами (git, терминал, MCP) | Не критикует ТЗ, не задаёт архитектурных вопросов |
Автор паттерна использует Claude Code в роли разработчика и GPT-5.5 в режиме высокого мышления в роли архитектора. Выбор объясняется разным «характером» моделей по умолчанию: GPT-5.5 в режиме высокого мышления берёт паузу и разбирает проблему подробно, тогда как Claude Code склонен к быстрому «понял, делаю». Впрочем, схема работает и на одной модели — два экземпляра Claude с разными системными промптами дают сопоставимый результат.
Окно архитектора настраивается на скептицизм: ревьюит ТЗ, ловит противоречия, задаёт уточняющие вопросы — и не пишет код.
Практически окно архитектора закрывает несколько сценариев. Главный — ревью ТЗ до начала реализации: размытые acceptance criteria («система должна работать быстро» — насколько быстро?), противоречия между секциями, забытые сценарии ошибок, вопросы «что если null?» и «что если двое одновременно?». Агент-разработчик в той же роли работает мягче — он оптимизирован на то, чтобы помочь сделать, и чаще латает дыры в ТЗ догадками вместо того чтобы остановиться и спросить. Второй сценарий — выход из дебаг-тупика: когда час ушёл на одну логическую ветку гипотез и она не работает, описание проблемы в чистое окно архитектора без накопленного контекста часто даёт угол, который в первом окне не рассматривался. Третий — критика архитектурных решений на уровне словесного описания подхода, до написания кода.
Схема не универсальна. На рутинных задачах — утилитные скрипты на час, понятные тесты, мелкие правки в существующих фичах, эксплоративный код на этапе «попробовать-выкинуть» — накладные расходы на координацию двух агентов превышают пользу. Координация занимает 5–10 минут на цикл: автор передаёт информацию между окнами вручную, не прокидывая переписку целиком. На крупной задаче это время растворяется; на мелкой — ощутимо.
Стоимость схемы — две подписки или удвоенные токены. По оценке автора, она окупается одной поломкой в продакшене, которую архитектор поймал на этапе ТЗ. Следующий логичный шаг, который он пока не тестировал, — третье окно с ролью «безопасника» или «продуктовика»: первый смотрит на систему с позиции «как это сломать», второй спрашивает «а зачем это вообще нужно».
