Концепция агентмаксинга (agentmaxxing) — одновременного запуска множества ИИ-агентов для написания кода — звучит заманчиво. Кажется, достаточно дать команду, и нейросеть за час соберет готовое приложение.
Однако в подкасте Syntax разработчики Скотт Толински и Вес Бос предупреждают: без четких правил ИИ-агенты превратят ваш проект в хаос. Если у кода нет жесткой структуры, нейросеть начнет импровизировать, создавая костыли, дублируя логику и разбрасывая файлы где попало.
Чтобы этого избежать, нужно применить метод Мари Кондо к разработке: определить для каждой вещи свое уникальное место. Вот 8 архитектурных решений, которые необходимо зафиксировать на старте — вручную или в файлах конфигурации (.cursorrules, инструкции для AI-агентов), — прежде чем позволить машине писать код.
1. Схема базы данных (Database Schema)
ИИ обожает плодить лишние сущности. Он может легко создать две практически одинаковые таблицы пользователей (например, User и UserProfile), связать их костыльным хуком и синхронизировать при каждом обновлении.
Как зафиксировать: Не отдавайте проектирование БД на откуп нейросети. Спроектируйте схему самостоятельно на самом низком уровне абстракции (low-fi):
- Markdown-файлы: Просто распишите списком таблицы и поля, которые вам действительно нужны.
- Типы TypeScript: Опишите структуру данных и связи между ними.
Передайте этот слепок ИИ и попросите его не генерировать схему с нуля, а лишь подсказать, какие крайние случаи (edge cases) вы могли упустить.
2. Логика валидации данных (Validation Implementation)
Хорошая валидация — это лучший инструмент подсказки для ИИ. Если на бэкенде и фронтенде четко описано, какие данные легитимны, агенту будет намного проще написать рабочий код.
Как зафиксировать: Выберите конкретную библиотеку (например, Zod или Valibot) и зафиксируйте правила. Отличным выбором будут инструменты, поддерживающие Standard Schema — это позволит различным библиотекам в проекте общаться друг с другом без дрейфа данных (data drift) и переписывания правил валидации с нуля.
3. Общая структура роутинга (Routing Structure)
Перед тем как начнется разработка, составьте карту эндпоинтов. Без этого вы рискуете обнаружить в проекте 40 хаотичных маршрутов там, где планировалось всего 5.
Как зафиксировать: Набросайте в Markdown обычный маркированный список страниц и API-путей вашего приложения. Это поможет:
- Сразу оценить реальный масштаб и скоуп (scope) работ.
- Заранее определить, какие роуты будут публичными, какие — приватными, а какие — административными.
Важное правило: Не откладывайте авторизацию на потом
В приложениях, где есть пользователи, их ID и права привязаны практически к каждой таблице базы данных. Если вы не настроите Auth & Access Control на первом этапе, последующие миграции и добавление «прав собственности» на данные превратятся в кошмар. Авторизация должна быть внедрена одной из первых.
4. Архитектурные типы (TypeScript Types)
Помимо схемы БД, ИИ должен четко понимать, в каком виде данные циркулируют внутри приложения.
Как зафиксировать: Опишите типы для:
- Ответов API-эндпоинтов (что возвращает сервер).
- Состояния клиента (что хранится в стейт-менеджере).
- Пропсов ключевых компонентов.
5. Методология CSS (CSS Methodology)
Без строгих правил ИИ-агент начнет «вайб-кодить» (vibe coding). В одном месте он напишет инлайн-стили, в другом — использует традиционный CSS, в третьем — сгенерирует случайные классы, нарушая всю консистентность.
Как зафиксировать: Четко определите стек: например, Tailwind CSS, CSS Modules или Styled Components. Настройте линтеры (например, Stylelint), чтобы робот физически не мог отправить в репозиторий код, нарушающий методологию.
6. Библиотека UI-компонентов (UI Component Framework)
Даже с учетом возможностей современного CSS, для сложных элементов (календари, выпадающие списки, модальные окна) вам понадобится база.
Как зафиксировать: Выберите один фундамент: shadcn/ui, Radix UI (Base UI), Kuma UI или любой другой фреймворк. Заставьте ИИ использовать исключительно его элементы, чтобы интерфейс не выглядел собранным из кусочков разных приложений.
7. Способ коммуникации клиента и сервера (Client-Server Comms)
Если не задать жесткий стандарт связи, ИИ проявит излишнюю креативность: для одной задачи он создаст REST API эндпоинт, для другой — попробует внедрить RPC, а для третьей — бахнет React Server Components (RSC).
Как зафиксировать: Покажите нейросети 1–2 эталонных примера того, как в вашем проекте фронтенд общается с бэкендом. Если вы выбрали RPC или Server Actions — зафиксируйте это в правилах проекта.
8. Структура папок (Folder Structure)
Оставленный без присмотра ИИ склонен либо сваливать все компоненты в одну огромную кучу, либо создавать безумную вложенность.
Как зафиксировать: Опишите архитектуру каталогов:
- Где лежат компоненты (в одной общей папке
componentsили разбиты по фичам/маршрутам)? - Куда складывать утилиты (
utils), хуки (hooks) и типы (types)?
Если вы сами не знаете, какая структура лучше, спросите ИИ до начала кодинга: «Предложи оптимальную структуру папок для стека X и задач Y», утвердите её и зафиксируйте.
Главный вывод: Консистентность важнее стека
Переход от технологии А к технологии Б (например, с React на Svelte или от одной библиотеки валидации к другой) силами ИИ сейчас происходит удивительно легко и быстро. Но только при одном условии: если ваш текущий код консистентен.
Перевести архитектуру, написанную в одном стиле, на другие рельсы — тривиальная задача для современных LLM. Но перевести 800 страниц кода, написанных в 800 разных стилях, не сможет ни один агент. Потратьте пару часов на старте проекта, наведите порядок в «доме», и тогда агентмаксинг покажет свою максимальную эффективность.