Паттерн прост: два отдельных окна LLM-агента с разными системными промптами и без общего контекста между собой. В одном — агент, который ничего не имплементирует, только критикует ТЗ, ловит противоречия и задаёт неудобные вопросы. В другом — тот, кто реально работает с кодом, файловой системой, git и MCP-серверами. Посредник между ними — человек. Именно это отсутствие общего контекста — не баг, а суть паттерна.
Контекст
Любой LLM-агент, работающий в одной длинной сессии, накапливает инерцию. Начал двигаться в сторону решения X — будет уточнять X, искать аргументы за X, защищать X. Дистанции нет. Плюс большинство агентов оптимизированы под характер «помощника»: делать что попросили, не сомневаться вслух, не задавать лишних вопросов. Это работает на типовых задачах и становится проблемой, когда ТЗ дырявое — агент уверенно обходит дыры вместо того, чтобы остановить и спросить.
Паттерн «два окна» появился как практический ответ на это. Автор описывает свою текущую связку: Claude Code в окне разработчика (быстрый, предметный, работает с инструментами), GPT-5.5 в режиме высокого мышления в окне архитектора (берёт паузу, ковыряет проблему, не торопится). Но разделение ролей важнее выбора модели — Claude + Claude с разными системными промптами тоже работает, и многие так и делают.
Паттерн не новый для командной разработки — пара «архитектор + разработчик» существует десятилетиями. Новое здесь: это теперь можно реализовать в одиночку, за одним ноутбуком, с двумя браузерными вкладками и разными системными промптами.
Аналитика
Реальная ценность паттерна — асимметрия ролей. Окно разработчика хорошо оптимизировано под выполнение: читать кодовую базу, держать в голове 20 файлов, делать многошаговые рефакторинги. Окно архитектора хорошо в другом — в том, чтобы остановить и спросить «а ты точно?». Ревью ТЗ до начала работы, поиск скрытых предположений про инфраструктуру, забытых сценариев ошибки, размытых acceptance criteria — всё это окно разработчика делает мягче, потому что его тренировка на «помочь сделать» берёт верх.
Отдельный кейс — дебаг в замкнутом круге. Час с агентом в одной логической ветке, гипотеза за гипотезой — не работает. Причина: оба (человек и агент) в плену одного контекста. Сброс в окно архитектора голым описанием — без двух часов переписки — даёт чистый старт и часто выводит на угол, который не рассматривался. Не магия, просто отсутствие accumulated bias.
Паттерн окупается по простой логике: если архитектор поймал дыру в ТЗ до начала имплементации — сэкономлено от нескольких часов до нескольких дней. На большом проекте один такой случай покрывает стоимость второй подписки за месяц. Overhead на координацию — 5–10 минут на цикл — на мелких задачах ощутим, на крупных растворяется.
Кейсы применения в бизнесе
B2B-SaaS стартап. Продуктовый менеджер или CTO пишет ТЗ на новую фичу и прогоняет его через окно архитектора перед передачей в разработку. Агент ловит неопределённые acceptance criteria, противоречия между секциями и забытые edge cases. Результат: меньше итераций в спринте, меньше «а, я думал, вы имели в виду другое».
Корпорация с legacy. При рефакторинге старого модуля окно архитектора анализирует архитектурные риски словесно — без кода — и указывает на долгосрочные последствия: «вот что произойдёт через полгода при росте нагрузки». Окно разработчика берёт выверенный план и работает с кодовой базой. Снижается вероятность технического долга нового поколения.
SMB и локальный бизнес в КР/СНГ. Небольшая команда (1–3 разработчика) без выделенного тимлида или архитектора может компенсировать этот пробел двумя окнами. Системный промпт на скептицизм для окна архитектора — это буквально «играй роль старшего разработчика, который не даст тебе сделать плохо». Стоит дополнительной подписки ($20–50/мес) и экономит одну поломку в проде.
Кейсы в личной жизни
Разработчик-фрилансер. Перед началом проекта прогоняет ТЗ клиента через архитектора: «найди дыры, противоречия, скрытые предположения». Получает список уточняющих вопросов к клиенту до старта — и приходит на созвон подготовленным, а не обнаруживает проблемы на третьей неделе работы.
Контент-мейкер или копирайтер. Окно архитектора отлично генерирует три варианта текста в разной тональности — они реально различаются, а не перифраз. После длинной кодовой или рабочей сессии стиль окна разработчика становится плотным и техническим; переключение на второе окно даёт другой регистр.
Студент или стажёр. При написании курсовой или технического задания окно архитектора задаёт пять-шесть уточняющих вопросов именно там, где у автора «туман». Это лучше, чем попытка угадать и сдать непроработанный текст. Попробуй системный промпт: «ты строгий рецензент, задавай вопросы только там, где неясно, ничего не добавляй от себя».
Как применить сегодня
- Открой два окна с Claude (или одно Claude, одно GPT — неважно). В первом системный промпт: «Ты архитектор. Не имплементируй ничего. Только задавай уточняющие вопросы, ищи противоречия, скрытые предположения и забытые edge cases». Второе — обычный Claude Code или рабочий агент.
- Ближайшее ТЗ — любое, даже на час работы — пропусти сначала через окно архитектора. Посмотри, что он найдёт. Скорее всего, что-то найдёт.
- При дебаге в замкнутом круге — опиши проблему голым текстом в архитектора: код + ошибка + что уже пробовал. Без истории переписки с разработчиком. Это даёт чистый угол.
- Для архитектора не нужна модель с инструментами и MCP. Веб-чат достаточен — у него нет задачи трогать файлы.
- Схема не нужна на типовых задачах: CRUD, мелкие правки, эксплоративный код «попробовать-выкинуть». Overhead на координацию там больше пользы.