Шизофрения LLM: как одна модель работает архитектором, разработчиком и ревьювером

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

Это не теория и не маркетинг. Это практический опыт, который я накопил, работая с LLM в роли «вайбкодера» — человека, который управляет агентами, а не пишет код руками. Ниже — поваренная книга: как собрать из одной модели труппу с разными личностями (архитектор, разработчик, ревьювер, тестировщик), как работают скиллы и почему процесс должен жить в файле, а не в голове, зачем большим задачам планы и записанные решения — и рецепт первого шага, для которого не нужно писать ни строчки: труппа умеет строить себя сама. Доступно, без энциклопедии — за один кофе.

Как одна модель становится труппой

Секрет в том, что современные LLM — это не один «интеллект», а, по сути, бесконечное множество потенциальных личностей, которые активируются контекстом. Один и тот же набор весов может вести себя как опытный архитектор, если дать ему правильную систему-промпт, или как придирчивый ревьювер, если попросить его найти ошибки. Это не магия, а следствие того, как модели обучаются: они впитывают паттерны из огромного количества текстов, включая код-ревью, архитектурные обсуждения и баг-репорты.

В моём проекте я использую четыре роли: архитектор, разработчик, ревьювер и тестировщик. Каждая роль имеет свой системный промпт, который задаёт поведение, цели и стиль. Архитектор проектирует структуру, разработчик пишет код, ревьювер ищет баги, тестировщик проверяет сценарии. Все они — одна и та же модель, но в разных «режимах». Это позволяет избежать проблемы «слепых пятен», когда автор кода не видит собственных ошибок.

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

Почему одна модель может быть и автором, и критиком?

Многие задаются вопросом: как одна и та же нейросеть может одновременно писать код и находить в нём ошибки? Ответ кроется в архитектуре трансформеров. Когда модель получает роль ревьювера, она активирует другие нейронные пути, чем когда она пишет код. Разные инструкции приводят к разным распределениям внимания. В результате модель действительно «видит» код под другим углом. Это похоже на то, как человек, надев очки другого диоптрия, замечает детали, которые раньше упускал.

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

Предыстория и контекст

Идея использования LLM в качестве «виртуальной команды» возникла не на пустом месте. Уже несколько лет существуют инструменты вроде GitHub Copilot, которые помогают писать код, но они работают в режиме «один на один». Проблема в том, что модель, которая пишет код, часто не замечает собственных ошибок — это как если бы программист сам себя ревьюил, но без свежего взгляда.

В 2024–2025 годах появились фреймворки для мультиагентных систем, такие как AutoGen, CrewAI и другие. Они позволяют создавать команды агентов, но часто требуют сложной настройки и интеграции. Мой подход проще: я использую один API-вызов к LLM, но с разными системными промптами. Это работает на любой модели, которая поддерживает системные сообщения, включая GPT-4, Claude и отечественные аналоги.

Важно понимать, что это не просто «игра в роли». Когда модель получает роль ревьювера, она активирует другие нейронные пути, чем когда она пишет код. Это связано с тем, как трансформеры обрабатывают контекст: разные инструкции приводят к разным распределениям внимания. В результате модель действительно «видит» код под другим углом.

Как это работает на практике?

На практике это выглядит так: я создаю файл с описанием проекта (например, project.md), где записаны цели, архитектура и требования. Затем я запускаю агента-архитектора, который читает файл и выдаёт план. План сохраняется в отдельный файл (plan.md). Разработчик читает план и пишет код, сохраняя его в src/. Ревьювер читает код и план и выдаёт список багов. Тестировщик запускает код и проверяет сценарии.

Все эти шаги можно автоматизировать с помощью скрипта, который поочерёдно вызывает API с разными промптами. Важно, чтобы каждый агент имел доступ только к своим файлам — это предотвращает «загрязнение» контекста. Я использую простую файловую структуру: context/ для общих документов, work/ для артефактов каждого агента.

Технические подробности: скиллы и файлы

Скиллы — это наборы инструкций, которые можно подключать к агентам. Например, скилл «архитектор» содержит правила проектирования: модульность, обработка ошибок, масштабируемость. Скилл «ревьювер» — чеклист для поиска багов: утечки памяти, гонки, необработанные исключения. Скиллы хранятся в виде текстовых файлов, которые подставляются в системный промпт.

Почему процесс должен жить в файле, а не в голове? Потому что LLM не имеет постоянной памяти между вызовами. Если вы не запишете план, следующий агент не будет знать, что делать. Файлы — это единственный способ передать состояние между агентами. Кроме того, файлы позволяют отслеживать прогресс и возвращаться к предыдущим шагам.

Я использую простую систему: каждая задача — это директория с файлами task.md, plan.md, review.md, tests.md. Агенты читают и пишут в эти файлы. Это делает процесс прозрачным и воспроизводимым. Если что-то пошло не так, вы всегда можете посмотреть, что сделал каждый агент.

Какие скиллы нужны для разных ролей?

Для архитектора скилл включает принципы SOLID, паттерны проектирования, управление зависимостями. Для разработчика — стандарты кодирования, работу с Git, написание юнит-тестов. Ревьювер должен знать типичные ошибки: null pointer, утечки памяти, проблемы с конкурентностью. Тестировщик — сценарии edge case, нагрузочное тестирование, проверку безопасности. Эти скиллы можно комбинировать и расширять по мере необходимости.

Кого затронет и как

Этот подход будет полезен разработчикам, которые хотят ускорить разработку, но не готовы полностью довериться одному агенту. Он также интересен командам, которые работают удалённо и хотят автоматизировать рутинные задачи. Для бизнеса это означает снижение затрат на найм и увеличение скорости выпуска фич.

В России и СНГ этот подход особенно актуален, потому что многие компании ищут способы сократить издержки. Использование LLM в качестве «виртуальной команды» может быть дешевле, чем наём нескольких разработчиков. Однако важно помнить о рисках: модель может ошибаться, и нужен человек, который контролирует процесс.

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

Какие риски и ограничения у этого подхода?

Главный риск — потеря контроля. Если вы полностью доверитесь агентам, они могут нагенерировать код, который работает, но имеет скрытые проблемы. Поэтому важно оставлять за собой финальное ревью. Также стоит помнить о стоимости API-вызовов: чем больше агентов, тем выше расходы. Но при грамотной настройке экономия на времени и ошибках перевешивает.

Что будет дальше

Я планирую расширять свою систему: добавлять новых агентов (например, аналитика безопасности), улучшать скиллы, интегрировать с CI/CD. В ближайшем будущем ожидаю, что мультиагентные подходы станут стандартом в разработке. Уже сейчас появляются инструменты, которые автоматизируют создание таких трупп.

Один из самых интересных сценариев — «самособирающаяся команда». Я работаю над тем, чтобы архитектор мог сам создавать скиллы для других агентов, основываясь на требованиях проекта. Это позволит полностью автоматизировать процесс настройки.

Итог

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