Фронтенд показывает действие, бэкенд выполняет его: агенты меняют оба слоя одной задачи

Фронтенд отвечает за поля, подсказки, кнопки и сообщения об ошибках. Макет описывает их вид. Разработчик превращает изображение в экран, который реагирует на действия.

Запрос полей через GraphQL требует согласованной схемы и проверки прав на сервере.

Бэкенд выполняет серверную операцию. Он определяет, кто отправил анкету, проверяет ответы и записывает их. По результату экран показывает успех или ошибку.

Поля могут хранить введённое до закрытия вкладки. Для кабинета нужен другой результат: пользователь возвращается и получает свои ответы из хранилища.

В карте нашей машины фронтенд и бэкенд выделены отдельно. Это карта устройства vibecoding.ru. Наличие обоих слоёв ещё не доказывает, что конкретная функция работает.

Кнопка отправляет запрос с ответами. Сервер сообщает, принята ли запись. Правила такого обмена называют контрактом API: экран и сервер одинаково понимают результат.

До разработки согласуйте, какие данные отправляются и когда сохранение считается успешным. Иначе экран сообщит «Готово» раньше записи или неправильно поймёт отказ.

Спрятанную кнопку можно обойти прямым запросом. OWASP рекомендует проверять право на каждое обращение к серверу: кто именно и какую запись может изменить.

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

При постановке задач агенту задайте результат: «Сохранить анкету и увидеть ответы после повторного входа». Инженер определит изменения экрана, сервера и проверок.

Клиентского кейса для этой статьи у нас нет. Инженер ведёт машину агентов на vibecoding.ru; кабинет служит примером своего продукта, без обещания клиентских сроков.

Агент подготовит правки формы, сохранения и тестов. Инженер решает, где хранить ответы, кто вправе их читать и как совместить новые поля со старыми данными.

В курсе агентной разработки урок «Одиннадцать шагов одной задачи» разбирает сдачу от задачи до проверки и выпуска. Сообщение «код готов» ещё не означает, что задача принята.

Проверка типов в TypeScript даёт ранний сигнал о несовместимом изменении до запуска приложения.

Показ формы проверяет начало пути. Ошибки бывают между экраном и сервером и после выпуска. В нашей машине поломки превращаются в правило следующей проверки.

С руководителем проходят обычный путь: заполнить, сохранить, закрыть, войти снова. Демонстрация заканчивается сохранёнными ответами, а не галочкой возле кнопки.

Инженер проверяет отказные пути. Чужую анкету нельзя менять прямым запросом, а при обрыве связи нельзя обещать успех. Это вопрос ответственности за ошибки.

Playwright рекомендует тестировать видимое поведение: для анкеты это ответы после открытия. Серверные тесты отдельно подтверждают права и правила записи.

«Сверстать анкету» описывает экран. «Сохранить ответы и вернуть при следующем входе» описывает функцию. Добавьте права, ошибки и повторы из таблицы приёмки.

Макет ещё не отвечает на вопросы о хранении и доступе. До оценки сроков разработки спросите, какие серверные операции уже работают, а какие предстоит создать.

Попросите инженера показать путь сдачи задачи. Руководитель подтверждает полезный результат; инженер проверяет технические условия и работу после выпуска.

Если непонятно, какие условия поручить инженеру, начните с теста для руководителя. Результат поможет обсудить следующий шаг с исполнителем.

В подписке на разработку тариф «Один проект» стоит 250 000 ₽ в месяц (проверено 8 октября 2026).

Инженер ведёт агентов от изменения экрана до серверной операции в рамках согласованной задачи клиента.

Один поток означает одну задачу в работе; следующая ждёт в очереди. Объём функции и условия сдачи согласуют до старта.

1. Закажите результат от действия на экране до сохранённой записи.

2. Согласуйте права, ошибки и повторы до изменения обоих слоёв.

3. Примите сохранение через повторный вход, а не через галочку.

4. Поручите инженеру общую проверку и повтор основного пути после выпуска.