Попросить нейросеть написать калькулятор или небольшой сайт довольно просто. Но попробуйте таким же способом создать приложение с личными кабинетами, базой данных, уведомлениями и десятками экранов. Через некоторое время выяснится, что одинаковые функции разбросаны по разным файлам, исправление одной ошибки ломает другую, а ИИ уже плохо понимает, как устроена программа, которую сам помогал писать.
С подобными трудностями сталкиваются и начинающие пользователи ChatGPT, и разработчики, которые активно применяют Cursor, Codex или Claude Code. Чем больше проект, тем важнее контролировать его структуру и изменения. Разберём, как организовать разработку с ИИ, какие задачи поручать агенту и что делать, чтобы приложение можно было поддерживать и расширять спустя месяцы.
Почему просьба написать всё приложение целиком плохо работает
Современные ИИ-агенты способны создавать множество файлов, запускать тесты и выполнять довольно сложные задачи. Например, Cursor Agent умеет самостоятельно исследовать проект, редактировать код и выполнять команды в терминале.
Но возможности инструмента ещё не гарантируют хорошую организацию проекта. Если запросить сразу весь сервис, модель вынуждена самостоятельно принимать множество решений: как хранить данные, разделять модули, обрабатывать ошибки, организовать доступ пользователей и связывать интерфейс с сервером.
Когда требования определены лишь в общих чертах, результат может оказаться непоследовательным. Например, одна страница обращается к серверу через общий модуль API, другая вызывает fetch() напрямую, а третья вообще использует временные данные.
С ростом проекта появляются дополнительные проблемы:
- Дублирование кода. Похожие функции создаются в разных местах, поскольку ИИ не нашёл или не использовал существующую реализацию.
- Случайные изменения. При добавлении новой возможности агент затрагивает рабочие компоненты, которые менять не требовалось.
- Несогласованные решения. Разные части приложения используют отличающиеся форматы данных и подходы к обработке ошибок.
- Сложное тестирование. После большого изменения непонятно, какая часть кода вызвала неисправность.
- Потеря контекста. В новой сессии нейросеть не обязательно получает прежние договорённости и историю технических решений.
Поэтому для большого приложения полезно сначала определить архитектуру и последовательность разработки. В официальном руководстве Cursor планирование рекомендуется для сложных задач, затрагивающих несколько файлов или компонентов.
При этом размер проекта определяется сложностью его устройства, количеством взаимосвязанных функций и требованиями к надёжности. Приложение из тысячи строк с запутанными зависимостями иногда труднее поддерживать, чем значительно более крупную, но хорошо организованную программу.
Как разделить приложение на модули и спроектировать архитектуру
Модульная архитектура предполагает разделение программы на части с понятными задачами и правилами взаимодействия. Например, интерфейс отвечает за отображение данных, серверная логика проверяет правила работы приложения, а отдельный модуль занимается доступом к базе данных.
Представим, что мы разрабатываем с нейросетью сервис учёта заявок на ремонт оборудования. Пользователь создаёт заявку, указывает описание неисправности, а сотрудник меняет её статус.
Такой проект можно разделить следующим образом.
| Модуль | За что отвечает |
|---|---|
| Интерфейс | Формы, список заявок, отображение статусов и сообщений. |
| API | Приём запросов от браузера и выдача ответов. |
| Бизнес-логика | Проверка данных, правила изменения статусов, ограничения операций. |
| Хранение данных | Создание, чтение и обновление записей в базе. |
| Тесты | Проверка правил работы приложения и взаимодействия компонентов. |
Например, если используется React с TypeScript и сервер на Python с FastAPI, структура может быть такой:
repair-app/
├── frontend/
│ └── src/
│ ├── components/
│ ├── pages/
│ └── services/
├── backend/
│ └── app/
│ ├── api/
│ ├── models/
│ ├── services/
│ └── db/
├── tests/
├── README.md
└── AGENTS.mdЭто пример возможной структуры, а не обязательный шаблон для любого веб-сервиса. В зависимости от сложности проекта папки можно объединять или разделять иначе.
Главное, чтобы у каждой части была понятная ответственность. Например, если пользователь нажимает «Создать заявку», интерфейс отправляет запрос через модуль API, сервер проверяет поля и сохраняет запись в базе. Такой порядок позволяет менять внешний вид формы, не переписывая правила хранения данных.
Особенно важно заранее согласовать формат обмена данными. Если интерфейс ожидает поле status, а сервер возвращает request_state, приложение может работать неправильно даже при отсутствии ошибок в отдельных модулях.
Поэтому до реализации полезно зафиксировать названия полей, допустимые значения, адреса API и форматы ошибок. Для HTTP API можно использовать спецификацию OpenAPI.
Не стоит, однако, создавать десятки абстрактных модулей для программы с тремя функциями. Архитектура должна соответствовать реальной сложности проекта.
Как разрабатывать большой проект с ИИ по этапам
После выбора архитектуры нужно определить последовательность работ. Для этого удобно использовать небольшие этапы, каждый из которых заканчивается проверяемым результатом.
На примере сервиса заявок план может выглядеть так:
- Основа проекта. Создать структуру каталогов, настроить запуск интерфейса и сервера, подключить инструменты проверки кода.
- Модель данных. Определить поля заявки, допустимые статусы и правила сохранения в базе.
- Серверный API. Реализовать создание и получение заявок, обработку неправильных данных.
- Пользовательский интерфейс. Создать форму и список заявок, подключить их к работающему API.
- Управление статусами. Добавить изменение статуса с проверкой разрешённых переходов.
- Завершение первой версии. Проверить основные сценарии, обработку ошибок и подготовить инструкцию запуска.
Регистрацию, распределение прав и уведомления можно запланировать отдельно, если они не требуются для первой учебной версии. При этом приложение без авторизации нельзя считать готовым к публичному многопользовательскому использованию.
Как формулировать задачу агенту? Вместо просьбы «Создай весь сервис заявок» используйте запрос с ограниченной областью работы.
Изучи структуру проекта и утверждённое техническое задание. Реализуй создание заявок в серверной части.
Используй существующие модули API и базы данных. Не меняй клиентский интерфейс и не устанавливай новые библиотеки без согласования.
Добавь тесты для корректного запроса, пустого описания и неправильного статуса. Выполни доступные проверки и перечисли изменённые файлы. Если тесты не запускались, сообщи об этом.
Так агент получает конкретную задачу, ограничения и критерии готовности. После выполнения можно проверить код и переходить к следующему этапу.
Для больших изменений в Cursor предусмотрен Plan Mode. Агент сначала изучает проект и формирует план, который пользователь может проверить до начала изменений. В актуальном интерфейсе режим можно выбрать через переключатель режимов или клавиши Shift+Tab.
В Codex аналогичный процесс можно организовать с помощью файла плана и последовательных задач. В примере OpenAI отдельные этапы сопровождаются проверками и фиксацией результатов.
Полезное правило для разработки: каждый этап должен завершаться работоспособной частью приложения. Если после добавления API перестали проходить тесты, лучше разобраться с причиной до создания новых экранов.
Как использовать Git и контролировать изменения нейросети
При работе над большим проектом система контроля версий Git становится особенно полезной. Она сохраняет историю изменений и позволяет вернуться к предыдущему состоянию кода.
Коммит представляет собой зафиксированную версию выбранных файлов. Ветка позволяет разрабатывать новую функцию отдельно от основной версии проекта.
Например, перед добавлением фильтра заявок можно создать новую ветку:
git switch -c feature/request-filterПосле работы агента проверьте, какие файлы изменились:
git status
git diffЕсли изменения соответствуют задаче и проверки пройдены, добавьте нужные файлы в коммит:
git add frontend/src/
git commit -m "Add request filtering"
Это пример команд. Перед выполнением git add проверьте содержимое файлов, чтобы случайно не включить посторонние изменения или секреты. В руководстве Git подробно описаны фиксация изменений и работа с историей проекта.
Не следует объединять в один коммит создание новой функции, полную переработку дизайна и обновление всех зависимостей. Если после такого изменения появится ошибка, искать её источник станет сложнее.
Для более крупных задач используют запросы на слияние изменений (pull request). Перед объединением ветки можно просмотреть разницу между версиями, запустить тесты и провести проверку кода.
У Cursor также есть контрольные точки (checkpoints), позволяющие отменять изменения агента. Но согласно документации Cursor, они хранятся локально и работают отдельно от Git. Для постоянной истории проекта лучше использовать полноценную систему контроля версий.
Что проверить после работы ИИ:
- Изменены только файлы, необходимые для текущей задачи.
- Новые функции используют существующие модули, если это предусмотрено архитектурой.
- Сохранена совместимость с уже работающими возможностями приложения.
- Автоматические тесты действительно запускались и завершились успешно.
- В репозиторий не попали пароли, токены или другие секретные данные.
Если агент изменил слишком много файлов, попросите объяснить необходимость каждого изменения. Нередко часть правок можно исключить, сохранив исходную задачу.
Технический долг при вайб-кодинге: как вовремя остановить накопление ошибок
Вайб-кодинг позволяет создавать программы преимущественно через текстовые запросы. Пользователь описывает желаемый результат, оценивает работу приложения и просит нейросеть внести изменения, иногда почти не изучая исходный код.
Для прототипов такой способ может быть полезен. Проблемы начинаются, когда на основе временных решений продолжают строить всё более сложную систему.
Например, сначала нейросеть создаёт форму с временным массивом данных. Затем добавляет сохранение в localStorage, позже подключает сервер и базу данных. Если старые механизмы не удалить, в программе могут остаться несколько способов хранения одних и тех же записей.
Подобные накопленные проблемы называют техническим долгом. Это последствия технических решений, из-за которых дальнейшая разработка и сопровождение требуют дополнительных усилий.
При программировании с ИИ технический долг может проявляться следующим образом:
- Одна и та же логика существует в нескольких функциях с небольшими отличиями.
- Компонент интерфейса одновременно отвечает за отображение, запросы к серверу и обработку данных.
- В проекте остаются неиспользуемые библиотеки, старые файлы и временные решения.
- Новые функции требуют изменений в большом количестве несвязанных модулей.
- Исправления добавляются поверх предыдущих исправлений без устранения исходной причины ошибки.
Для уменьшения технического долга используют рефакторинг, то есть изменение внутренней организации кода с сохранением его внешнего поведения.
Например, если пять компонентов самостоятельно выполняют одинаковый запрос к серверу, можно вынести эту логику в общий модуль. Но перед рефакторингом желательно иметь тесты, которые проверяют существующее поведение.
В рекомендациях GitHub Copilot для сокращения технического долга отдельно отмечаются небольшие задачи, контроль изменений и проверка тестов после рефакторинга.
Чтобы проект не становился всё труднее поддерживать, полезно регулярно проводить небольшую ревизию:
- Проверьте, нет ли повторяющихся функций и неиспользуемых файлов.
- Определите компоненты, которые выполняют слишком много разных задач.
- Выберите одну конкретную проблему и создайте для неё отдельную задачу.
- Подготовьте тесты, фиксирующие текущее правильное поведение.
- Попросите ИИ выполнить ограниченный рефакторинг и проверьте результат.
Не нужно переписывать всё приложение каждый раз, когда архитектура перестаёт нравиться. Иногда достаточно удалить одну лишнюю зависимость, объединить повторяющийся код или уточнить интерфейс между двумя модулями.
Если проект уже стал слишком запутанным, начните с инвентаризации. Попросите агента составить карту модулей, найти дублирование и предложить план исправлений без изменения исходников. Затем выбирайте небольшие задачи и выполняйте их последовательно.
Для долгой разработки с ИИ полезно хранить техническое задание, описание архитектуры и постоянные инструкции проекта в отдельных файлах. Например, AGENTS.md можно использовать для правил работы агента, а ARCHITECTURE.md для описания основных модулей. Это поможет следующей сессии начинаться с тех же технических договорённостей.
Вопросы и ответы
Можно ли создать большое приложение полностью с помощью ИИ?
ИИ-агенты могут писать значительную часть кода большого приложения, создавать тесты и работать с несколькими модулями. Для надёжной разработки необходимы техническое задание, контроль архитектуры, проверка изменений и регулярное тестирование.
Как разрабатывать большой проект в Cursor?
Начните с описания требований и структуры проекта. Для сложных задач используйте Plan Mode, проверяйте план перед реализацией, разделяйте работу на этапы и просматривайте изменения через Git. После каждого этапа запускайте необходимые тесты.
Как правильно разделить проект с нейросетью на модули?
Выделите основные задачи приложения: интерфейс, работу с API, бизнес-логику, хранение данных и тестирование. Определите ответственность каждой части и правила обмена данными. Конкретное разделение должно соответствовать сложности проекта.
Почему ИИ постоянно переписывает работающий код?
Возможные причины: недостаточный контекст, слишком общая задача или отсутствие ограничений на изменения. Указывайте нужные файлы, сохраняйте правила проекта и просите агента не затрагивать несвязанные компоненты. Проверяйте итоговую разницу версий.
Зачем использовать Git при программировании с ИИ?
Git сохраняет историю проекта, позволяет сравнивать изменения и возвращаться к предыдущим версиям. Отдельные ветки помогают разрабатывать новые функции, не затрагивая основную рабочую версию приложения.
Что такое технический долг при вайб-кодинге?
Технический долг возникает, когда временные или неудачные решения усложняют дальнейшую разработку. При вайб-кодинге он может накапливаться из-за дублирования функций, лишних зависимостей и исправлений без анализа причин. Сократить его помогают тестирование и рефакторинг.
