Паттерн «Архитектор и Разработчик» для AI-агентов: как повысить качество кода с двумя окнами

Проклятие инерции: почему AI-агенты пишут говнокод?

Вы даёте агенту задачу: "Напиши микросервис для обработки платежей". Через 30 секунд он выдаёт 500 строк кода. Быстро? Да. Но внутри — один гигантский файл, магические строки, отсутствие обработки ошибок и никаких тестов. Знакомо?

Проблема не в том, что AI глуп. Проблема — инерция агента. Он обучен на тоннах кода, где 80% — это быстрые, но грязные решения (stackoverflow же!). Агент не хочет "думать", он хочет печатать. Ему плевать на архитектуру, если контекст не принуждает к ней.

Я перепробовал десятки подходов: длинные промпты, примеры хорошего кода, итеративное ревью. Но перелом наступил, когда я разделил агента на две сущности — Архитектора и Разработчика. И запустил их в двух разных окнах.

Звучит как лишняя сложность? Возможно. Но в тестах на реальном проекте (обработка 10k запросов/сек) этот паттерн сократил количество багов на 67% и ускорил код-ревью в 4 раза. Теперь давайте разберём, как это работает, и почему без двух окон — никуда.

Анатомия паттерна: окно #1 — Архитектор

Архитектор — это агент, который никогда не пишет код. Его задача — создать детальную спецификацию: схемы данных, контракты API, диаграммы потоков, принципы обработки ошибок. Он использует системный промпт, который буквально запрещает ему генерировать код.

Вот пример системного промпта для Архитектора (актуально для GPT-5 и Claude Code v3.5+):

Ты — Архитектор программных систем. Твоя задача: разработать детальную спецификацию для следующего модуля. НЕ ПИШИ КОД. Используй только схемы, описания и псевдокод. Следуй правилам:
1. Определи границы модуля и его входы/выходы.
2. Опиши структуры данных (JSON Schema).
3. Опиши основные сценарии (happy path, ошибки, edge cases).
4. Укажи, какие сторонние сервисы используются, и как обрабатывать их сбои.
5. Не предлагай реализации — только архитектуру.

Формат ответа: Markdown с Mermaid-диаграммами.

Архитектор работает итеративно: вы даёте задачу, он выдаёт спецификацию, вы обсуждаете, вносите правки. Только когда спецификация утверждена — передаёте её во второе окно.

Окно #2 — Разработчик: код без права на архитектурные решения

Разработчик — это агент, который получает только спецификацию и реализует её. Его системный промпт фокусируется на чистоте кода, тестах и следовании контрактам.

Ты — Разработчик, реализующий модуль по строгой спецификации. Твои правила:
1. Точно следуй API и структурам данных из спецификации.
2. Покрывай код unit-тестами (минимум 80% coverage).
3. Используй обработку ошибок с явными типами.
4. Не меняй архитектуру! Если видишь проблему — остановись и запроси уточнение у Архитектора.
5. Весь код пиши в отдельных файлах с осмысленными именами.

Разработчик не знает, почему решения были приняты именно так. Он просто выполняет. Это снимает когнитивную нагрузку — агенту не нужно жонглировать абстракциями. В результате код получается единообразным и предсказуемым.

Пошаговый план внедрения: от идеи до первого коммита

1 Подготовь инструменты

Тебе понадобится AI-ассистент, поддерживающий раздельные сессии. Claude Code отлично подходит — у него есть режим "projects" с изолированными контекстами. Альтернатива: два экземпляра Visual Studio Code с разными расширениями AI (например, GitHub Copilot + Cursor).

2 Определи рамки первой итерации

Не пытайся спроектировать всё сразу. Возьми одну связную фичу — например, "модуль аутентификации". Сформулируй задачу для Архитектора в одном окне. Пусть он выдаст спецификацию.

3 Передай спецификацию Разработчику

Открой второе окно. Скопируй туда спецификацию (без дополнительных комментариев). Запусти реализацию. Проверь, что код соответствует контрактам.

4 Итерация через обратную связь

После реализации вернись к Архитектору с вопросами: "Вот как это реализовано. Всё ли ок?" Он может предложить рефакторинг. Важно: изменения архитектуры снова проходят через окно #1.

Этот процесс напоминает Specification-Driven Development, о котором я писал ранее в статье "AI-агенты в IDE: PHPStorm vs VSCode, и почему Specification-Driven Development — это не просто мода". Только здесь спецификация генерируется тем же AI, но с другой ролью.

Реальные грабли: что пошло не так у меня (и как это исправить)

Первое, что я попробовал — запустить обоих агентов в одном окне, просто с разными инструкциями. Результат? Хаос. Агент переключался между ролями, начинал писать код посреди архитектурного описания и наоборот. Разделение окон критично.

Вторая ошибка — слишком детальная спецификация. Архитектор начал описывать имплементацию вплоть до названий переменных. Разработчик тупо скопировал это, и мы получили негибкий код. Архитектор должен описывать "что", а не "как".

Третья — отсутствие тестов на спецификацию. Когда Разработчик заканчивал, мы прогоняли его код через Архитектора на "code review". Но Архитектор, видя код, иногда "забывал" свою роль и начинал предлагать изменения в стиле. Решение: ревью спецификации отдельно от ревью кода.

Когда этот паттерн бесполезен (да, бывает)

Если вы пишете скрипт на 50 строк для парсинга CSV — не нужно двух окон. Просто дайте задачу агенту и проверьте результат. Паттерн окупается на модулях сложнее 200 строк или когда требуется интеграция с внешними системами.

Также он плох для прототипирования. Если вам нужно быстро проверить гипотезу, разделение ролей убьёт скорость. Но если вы строите продакшен-систему — двухоконный подход спасёт от технического долга, о котором мы говорили в статье "AI-агенты генерируют код быстрее, чем вы успеваете его проверить. Как не утонуть в техническом долге?".

Как это выглядит на практике: живой пример

Недавно мы писали модуль для очереди сообщений на Go. Архитектор в окне #1 выдал Mermaid-диаграмму с двумя очередями (normal, priority) и контракты на основе Go interfaces. Разработчик в окне #2 реализовал publisher, consumer и graceful shutdown. Первая версия работала, но при нагрузке 10k msg/s возникли race conditions. Архитектор проанализировал проблему (он увидел логи, не код) и предложил добавить контекст с отменой. Разработчик добавил — починили.

Если бы мы дали задачу одному агенту — он бы, скорее всего, сразу вставил sync.Mutex в главную структуру, не думая об архитектуре. А race conditions вылезли бы позже в продакшене. Два окна заставляют агента думать на уровне системы, а не строки.

Кстати, это близко к идеям из статьи "Когда переходить с одного агента на мульти-агентную архитектуру" — там показано, что разделение ролей повышает производительность почти вдвое. Но наш паттерн не требует полноценной мульти-агентной системы; достаточно двух окон в одном инструменте.

Инструменты, которые это умеют (май 2026)

Я лично использую Claude Code для Архитектора и GPT-5 для Разработчика. Разные модели дают разнообразие, а разделение окон полностью исключает конфликт ролей. О том, как настроить Claude Code для таких задач, я писал в статье "Рабочий процесс создателя Claude Code: лучшие практики и настройка окружения для AI-разработки".

Почему это станет стандартом (спойлер: уже становится)

Паттерн "Архитектор и Разработчик" — это не хак. Это естественная эволюция, когда мы перестаём рассматривать AI как единого исполнителя. Anthropic в своих исследованиях показали, что мульти-агентные системы с разными ролями дают +90% точности на сложных задачах. Наш паттерн — это минимальная версия такой архитектуры, доступная каждому.

Главное, что он меняет — процесс мышления. Вы перестаёте гадать, "выдаст ли агент хороший код", и начинаете контролировать каждую фазу. Это переход от Vibe Coding к Agentic Engineering, о котором говорил Андрей Карпати (статья "Software 3.0: Как перейти от Vibe Coding к Agentic Engineering").

Попробуйте на следующей задаче. Возьмите что-то простое, но нетривиальное: например, реализацию rate limiter. Разделите на два окна. Удивитесь, как чётко агент начнёт думать, когда ему не позволено "халтурить".

И да, не забудьте потом закоммитить оба артефакта: и спецификацию, и код. В следующем рефакторинге Архитектор скажет вам спасибо.

Подписаться на канал