Привет! Продолжаем серию статей-туториалов по видео Александра Сербула, руководителя больших данных, высоконагруженных систем и машинного обучения в компании Битрикс24.
Видео и статьи записаны и написаны специально для вайбкодеров без технического бэкграунда, которые хотят создавать надёжные веб-приложения. В туториалах мы будем использовать ИИ-агента для работы с приложениями на React — Claude Code.
Сами не программируем — всю работу проводит ИИ-агент, а мы пишем запросы и контролируем результат.
В прошлых статьях мы развернули сайт в интернете на сервере Битрикс24. Сегодня начнём разбирать тему автотестов: специальные программы, которые проверяют другие программы на работоспособность. С автотестами разработчик может добавлять новые возможности в программу и сразу увидит, если новый код сломал то, что уже работало.
ИИ-ассистент работает похожим образом. Он добавляет новые вещи, но не проверяет, не сломалось ли что-то в старых. Поэтому надо ему об этом сказать.
В статье посмотрим, как это работает и выглядит. Во второй части статьи переведём проект на TypeScript, чтобы часть ошибок обнаруживалась ещё до запуска сайта.
Что сделаем и о чём расскажем сегодня
У нас есть IT-проект. Он несложный и служит только для учебных целей — мы показываем, как работать с агентом, чего ожидать и какие команды давать.
В статьях мы поэтапно добавляем вещи, которые есть в настоящих рабочих проектах: возможность вносить изменения, готовые сборки для публикации в интернете, развёртывание на сервере.
Следующий шаг на сегодня — сделать разработку ещё надёжнее. Сначала добавим автотесты, которые будут проверять работу страниц после изменений. Затем поэтапно переведем проект с языка JavaScript на TypeScript, чтобы находить часть ошибок ещё до запуска приложения.
Что понадобится
Ниже — описание всех программ, которые нужны для получения такого же проекта, как у нас. Но устанавливать их все отдельно до работы необязательно: достаточно написать агенту первый промпт, и он сам установит всё необходимое, если дать ему доступ.
Какие программы использует наш проект:
Node.js для сборки сайта. Скачать можно на официальной странице: nodejs.org.
Git Bash понадобится пользователям Windows: через него можно запускать команды из статьи. Скачать на официальной странице: git-scm.com/download/win
На macOS и Linux те же команды выполняются во встроенном терминале.Язык программирования Python не нужен для самого сайта, потому что сайт написан на другом языке, JavaScript. В этой статье мы переведём егона TypeScript.
Но Python полезен при разработке: ИИ-ассистент часто пишет на нём небольшие вспомогательные скрипты и быстро проверяет идеи. Скачать: python.org/downloads.Для деплоя в интернете нужен сервер. Мы используем серверы платформы вайб-кодинга Битрикс24 Вайбкод. Для их использования (и для большинства других серверов) нужна платная подписка или собственный сервер.
Некоторые основные термины, которыми мы будем пользоваться
Это цикл статей о создании фронтенд-проекта на React.
Есть несколько основных терминов и технологий, которые появляются в нашем проекте. Если вам интересно, что это такое, вот краткий словарь-глоссарий:
Словарь терминов // спойлер
Сайт — это набор связанных между собой страниц в браузере. На сайте пользователь может читать информацию, нажимать кнопки, переходить между разделами и выполнять другие действия. Сайт состоит из страниц, интерфейсных элементов и кода.
Фронтенд — это только видимая часть сайта или веб-приложения. То есть страницы, кнопки, меню, формы для заполнения, с которыми может взаимодействовать пользователь — это всё фронтенд.
Бэкенд — внутренняя часть сайта или веб-приложения, которая не видна пользователю напрямую. Бэкенд отвечает за данные, регистрацию, вход, сохранение настроек. Например, когда пользователь отправляет форму на сайте, фронтенд только показывает эту форму, а бэкенд принимает данные и решает, что делать с ними дальше.
Компонент — отдельная часть интерфейса, из которой собирается страница. Компонентом может быть кнопка, карточка товара, всплывающее окно. Разработчик может использовать один и тот же готовый компонент в нескольких местах сайта.
JavaScript — язык программирования, который помогает делать страницы интерактивными. Благодаря JavaScript сайт может реагировать на действия пользователя, например открывать меню или показывать уведомления.
TypeScript — это расширение JavaScript, которое добавляет более строгую проверку кода. Это помогает раньше находить ошибки и делает проект понятнее, даже для ИИ-агента.
React — это инструмент для создания интерфейсов из готовых компонентов. Он помогает разработчику описать, из каких частей состоит страница и как она должна меняться при действиях пользователя.
Vite — технология для запуска и сборки фронтенд-проекта. Vite помогает быстро открыть проект на компьютере во время разработки, а потом подготовить его к публикации.
Tailwind нужен для настройки внешнего вида интерфейса. С его помощью разработчик устанавливает для компонентов отступы, цвета, размеры, шрифты и другие визуальные свойства.
API — набор команд, через которые одна программа управляет возможностями другой.
Репозиторий — папка проекта, размещённая в системе хранения кода, например на GitHub.
Скрипт — файл кода с последовательностью команд, которые выполняются автоматически.
Порт — условный номер канала, через который программа принимает обращения внутри сервера. В нашем случае Nginx слушает порт 3000.
// Спойлер — На какой стадии проект сейчас и как его повторить
Мы работаем с агентом Claude во вкладке Code:
Ниже перечисляем все запросы к агенту с пояснениями, чтобы довести чистый проект примерно до того состояния, в котором он находится сейчас у нас.
Промпт 1. Создаём основу проекта
Создай минимальный пустой сайт на React, Vite и Tailwind CSS. Подключи компоненты shadcn/ui. TypeScript пока не используй — мы добавим его отдельно.
Промпт 2. Добавляем навигацию и форму заявки
Веб-приложение может содержать разные элементы интерфейса. Чтобы лучше понимать, что вообще можно добавить на свой сайт, мы сделали для вас сайт с визуальной библиотекой самых популярных фронтенд-компонентов shadcn/ui. Посмотреть это можно по адресу: app-117900122a91.vibecode.bitrix24.tech/. Выглядит примерно так:
Выбрав компоненты для своего сайта, их можно запросить у Claude обычным языком:
Добавь компонент Menubar с разделами «Главная», «О компании» и «Заявка».
На странице «Заявка» создай форму с помощью компонента Form. После отправки формы показывай окно Dialog с подтверждением.
Промпт 3. Ваша кастомизация. Превращаем каркас в полноценный сайт
На этом этапе нужно описать тематику проекта, название компании, содержание страниц, язык интерфейса и требования к оформлению. В нашем примере это сайт студии JRPG-игр Tojita-Hon-Games.
Преобразуй текущий проект в сайт японской компании Tojita-Hon-Games, которая занимается разработкой JRPG-игр.
Подбери бесплатное изображение для фона. Добавь на главную страницу раздел с сотрудниками компании: для каждого сотрудника укажи имя, должность, возраст и краткую биографию, а также добавь фотографию из бесплатного источника.
Подбирай изображения, фон и цвета так, чтобы текст оставался хорошо читаемым. Весь текст на сайте должен быть на русском языке.
Промпт 4. Настраиваем сборку готовой версии сайта
Сборка сайта — это готовая версия проекта, подготовленная для запуска и публикации.
Во время разработки сайт состоит из исходных файлов, которые разработчику и агенту удобно редактировать. Команда сборки обрабатывает их, объединяет нужные части, уменьшает размер файлов и создаёт отдельную папку с готовым сайтом. Потом эту папку загружают на сервер.
Настрой процесс сборки проекта для публикации. После создания сборки запускай её локальный предпросмотр в браузере.
Промпт 5. Создаём документацию проекта
Команда ниже создаёт файл CLAUDE.md с основными сведениями о проекте. Ассистент сможет использовать его в следующих сессиях, чтобы учитывать структуру проекта, команды запуска и принятые правила работы.
/init
Промпт 6. Готовимся к деплою в режиме чтения
Даём агенту указания подготовиться и собрать всю информацию, чтобы сразу сделать работу максимально правильно.
Будем разворачивать статический сайт на платформу Битрикс24 Вайбкод. Изучи процесс по документации https://vibecode.bitrix24.tech/v1/me и по дополнительной инструкции https://github.com/AlexanderSerbul/vibecoders-front-ui-gallery/tree/main/deploy.Ключ для чтения: vibe_api_ВАШ_КЛЮЧ
Скопируй папку deploy из этого репозитория в проект, задай имя приложения <имя-проекта> и выбери самый дешёвый тариф сервера, которого достаточно для статики. Сам деплой пока не запускай.
Промпт 7. Деплой и публикация
После предыдущего промпта стоит проверить тариф, который выбрал агент. Потом можно давать команду к деплою:
Выполни деплой: собери проект, создай сервер, залей статические файлы и опубликуй сайт. Перед платными и публикующими действиями запроси подтверждение и выведи итоговый адрес.
Промпт 8. После следующих правок — обновление опубликованного сайта
Деплой — это фиксация, слепок кода на момент публикации. Сервер отдаёт ровно те файлы, что мы залили, и сам не обновляется, когда мы правим проект дальше. Поэтому, когда мы заменим что-то в коде, на живом сайте изменения отобразятся не сразу. Чтобы правки попали в интернет, нужно пересобрать и залить заново.
Проверь текущие изменения локально на дев-сервере, затем выполни повторный деплой на тот же сервер, чтобы опубликовать актуальную сборку.
Промпт 9. Создаем репозиторий и первый коммит
Подключи Git к проекту, проверь .gitignore и создай первый коммит.
После следующих изменений используем один и тот же запрос для добавления коммитов:
Сохрани текущие изменения отдельным коммитом.
Промпт 10. Проверяем историю версий
Покажи историю коммитов.
Промпт 11. Отправляем проект на GitHub
Сначала нужно зарегистрироваться на GitHub и создать там пустой репозиторий — как это сделать, мы описали в предыдущей статье. Затем нужно скопировать адрес репозитория и передать агенту:
Подключи проект к этому репозиторию и отправь туда все коммиты:
<ссылка на репозиторий>
Промпт 12. Готовимся к деплою в Галактику
Скопируй в проект скрипт deploy-galaxy.sh из папки deploy:
https://github.com/AlexanderSerbul/vibecoders-front-ui-gallery/tree/main/deploy
Изучи инструкцию и подготовь проект к размещению статического сайта в Галактике Битрикс24 Вайбкод. Сам деплой пока не запускай.
Промпт 13. Деплоим приложение в Галактику
Поменяй имя приложения на <имя-проекта>-galaxy-v1 и разверни сайт в Галактике.Перед платными и публикующими действиями запроси подтверждение. После завершения проверь результат и выведи адрес опубликованного сайта.
После новых правок — обновление опубликованного сайта
Проверь текущие изменения локально, затем выполни повторный деплой, чтобы опубликовать актуальную сборку в том же приложении.
Что такое автотесты
Это специальные проверки, которые автоматически запускают программу, выполняют заранее заложенные разработчиками действия и сравнивают результат с ожидаемым.
Вот пример: на сайте есть форма заявки. Автотест может открыть страницу, заполнить поля, нажать кнопку отправки и проверить, появилось ли сообщение об успешной отправке. Тест будет делать это после каждого нового изменения в приложении. Если в какой-то момент разработчик добавил новые возможности (например, сделал новую страницу с информацией о компании), и эти новые возможности сломали форму заявки, автотест это покажет. Тогда нужно остановить процесс разработки и найти причину ошибки — а после этого можно продолжать улучшать приложение.
Обычно для важных функций создают несколько сценариев. Проверяют не только правильные действия пользователя, но и возможные ошибки: пустые поля, неправильный адрес электронной почты, слишком длинный текст. Раньше всё это занимало много времени: тесты нужно было самостоятельно продумывать, писать и обновлять вместе с приложением. Разработчики нередко откладывали эту работу, особенно в небольших проектах. При ограниченных сроках сначала делали приложение, а проверки проводили вручную или вообще не добавляли тесты.
ИИ-агенты сильно упрощают эту работу. Они могут быстро изучить проект, предложить основные сценарии, создать тесты и помочь исправить найденные ошибки. Но результат пока что всё равно нужно контролировать.
Один из примеров пользы автотестов — история базы данных SQLite. Её создатель Ричард Хипп сказал, что около года работал по 60 часов в неделю, добиваясь почти полного покрытия программы тестами по строгим стандартам, применяемым в авиационных системах. После этого команда перестала получать отчеты об ошибках от разработчиков Android, а серьёзные проблемы практически не появлялись ещё восемь или девять лет.
Конечно, SQLite — крайний пример: сейчас перед выпуском SQLite выполняются сотни миллионов проверок на разных операционных системах и типах процессоров. Обычному небольшому сайту не нужно такое количество тестов.
Главное — понять принцип: один раз настроенные проверки многократно повторяются после каждой правки и помогают обнаружить ошибку раньше, чем ее заметят пользователи.
Добавляем браузерный тест
Что мы попросим агента:
Добавь браузерные тесты для проверки базового функционала каждой страницы. Создавай такие тесты и для всех новых страниц проекта.
Предположительно, после такого запроса агент создаст для каждой страницы тест, который будет имитировать действия обычного пользователя в браузере. Что он будет делать:
Откроет страницу в браузере
Проверит, что она загрузилась без ошибок.
Найдёт основные элементы: заголовки, кнопки, ссылки и формы.
Выполнит базовые действия. Например, перейдёт по ссылке или отправит форму.
Сравнит полученный результат с ожидаемым.
Все тесты можно запускать одной командой после изменений в проекте. Если новая правка сломает одну из страниц, тест завершится с ошибкой и покажет нам, где появилась проблема.
При создании новой страницы агент должен будет добавить для нее отдельный базовый сценарий. Но если просто написать «добавляй тест для новых страниц», постоянных гарантий это не даст. Лучше попросить агента также записать правило в CLAUDE.md.
Что сделал агент на самом деле:
Теперь разберём весь ответ, включая то, что не уместилось на скриншоте.
Агент настроил полноценные браузерные проверки с помощью инструмента Playwright. Он запускает браузер Chromium, открывает сайт и выполняет действия примерно так же, как обычный пользователь.
Всего ИИ сделал 17 тестов. Они проверяют, что все страницы открываются по прямым ссылкам, отображают нужные заголовки и не вызывают ошибок в браузере. Отдельные тесты проверяют навигацию, кнопку «Назад», переключение темы, формы, диалоговые окна, FAQ, карусель и графики.
Перед проверкой Playwright автоматически запускает локальную версию сайта. Все тесты выполняются одной командой, и мы сами тоже можем попробовать запустить её в терминале:
npm run test
Все новые страницы попадают в базовую проверку автоматически.
Агент сам записал правила работы с тестами в CLAUDE.md — но, скорее всего, потому что до этого мы уже просили его записывать правила в этот файл. Если в вашем проекте CLAUDE.md ещё нет, агент вряд ли создаст его сам. Можно в любой момент попросить создать файл этот агента или попросить обновить существующий. Актуализировать файл лучше регулярно.
Вводим правило запуска тестов перед коммитами и деплоем
Теперь добавим ещё одно правило запуска тестов перед всеми важными действиями — то есть до коммита и деплоя:
После каждого изменения запускай тесты, связанные с затронутой функциональностью. Перед коммитом и деплоем запускай полную проверку проекта: линтер и все браузерные тесты.
Коммит и деплой разрешены только при успешном завершении обеих проверок. Если линтер или тесты не проходят, остановись, исправь проблему и запусти проверку повторно.
После проверки сообщай краткий результат: какие команды выполнены, сколько тестов прошло и остались ли ошибки или предупреждения.
Добавь это правило в CLAUDE.md.
Ответ агента:
Разбираем, что это значит.
Claude объединил линтер и браузерные тесты в единое обязательное правило проверки, которое записал в CLAUDE.md. Оно должно учитываться и в следующих сессиях — будем надеяться, так и будет.
После изменений агент запустит только подходящие проверки: линтер для измененных файлов и тесты для затронутой функции. Например, после изменения формы он должен проверить именно сценарии этой формы, а не запускать все 17 тестов.
Перед коммитом и деплоем проверка становится полной. Агент должен выполнить две команды:
npm run lint
npm run test
Коммит или публикация разрешены только если линтер завершился успешно и все тесты прошли. Если тесты выдадут ошибку, агент должен остановиться, исправить проблему и повторить проверку. Отключать правила линтера или пропускать тесты без объяснения нельзя.
После каждого запуска агент будет кратко сообщать результаты работы.
Текущую правку он не проверял, потому что изменился только файл CLAUDE.md, а в проекте нет тестов для документации. Линтер Markdown тоже не проверяет.
Смотрим, как выглядят коммит и деплой
Даём команду зафиксировать состояние проекта:
Cделай коммит и задеплой
Проверки прошли успешно, деплой и коммит — тоже:
JavaScript и TypeScript
JavaScript — основной язык веб-разработки. Он отвечает за действия на странице: кнопки, формы, загрузку данных и изменение интерфейса.
Изначально JavaScript создавался для небольших сценариев внутри браузера, но постепенно на нём начали разрабатывать крупные приложения. Язык оказался очень гибким, но эта гибкость одновременно стала источником многих проблем.
Одна из главных особенностей JavaScript — динамическая типизация переменных и значений. В одной и той же переменной может находиться число, а затем строка, объект или пустое значение. Из-за этого JavaScript может автоматически совершать неверные преобразования и выполнять неожиданные действия. Поэтому этого некоторые ошибки остаются незаметными до запуска конкретного сценария. Например, приложение может нормально открываться и проходить основные проверки, но сломаться, когда пользователь введёт необычные данные.
Посмотрите на код ниже. Понимать его не надо, главное написано в комментариях: функция ожидает значение, которое можно умножить на число, но JavaScript не проверяет тип заранее. Строку "10" он автоматически преобразует в число, а для строки "текст" вернёт NaN — специальное значение, означающее, что вычисление не дало корректного числа.
function double(value) {
return value * 2;
}
double("10"); // JavaScript сам превратит строку в число
double("текст"); // результат -- NaN: корректное число получить не удалось
TypeScript появился как расширение JavaScript с проверкой типов данных. В нем можно заранее указать, какие данные принимает функция. Поэтому на нём уже такой ошибки не будет:
function double(value: number) {
return value * 2;
}
double(10); // правильно
double("10"); // ошибка будет видна еще до запуска
Короче: TypeScript помогает раньше находить ошибки, упрощает работу с большими проектами и делает код понятнее.
Поэтому дальше мы попросим перенести весь проект на него.
Переезжаем на TypeScript
Давайте спросим у агента, что он думает:
Полезно ли будет перевести наш проект на TypeScript?
Claude говорит, что это хорошая идея и момент для этого подходящий:
Но добавляет, что для небольшого проекта это необязательно и что это скорее инвестиция — на тот случай, если мы захотим расширять проект дальше.
Начнём поэтапный процесс миграции:
Начинай поэтапный переход на TypeScript
Пока Claude работает, можно посмотреть на изменения в коде. Даже если не разбираться, что означает каждое изменение, это может быть интересно. Для этого нужно нажать кнопку Diff. Красным обозначено то, что удалено, зелёным — всё новое:
Мы попросили перевести сайт на TypeScript в 3 этапа и каждый раз отчитываться о том, что сделано. Вот как проходила миграция.
Этап 1. Настраиваем TypeScript и переводим данные
Сначала агент установил TypeScript и добавил конфигурацию, которая позволяет временно использовать в одном проекте файлы JavaScript и TypeScript. Это нужно для поэтапной миграции: проект не приходится переписывать целиком за один раз. После этого часть исходного кода уже можно писать на TypeScript, а оставшиеся файлы временно сохранять на JavaScript. Перед запуском TypeScript-код все равно преобразуется в JavaScript.
Также появилась такая команда:
npm run typecheck
Она запускает компилятор TypeScript в режиме проверки. Это программа, которая формирует файл для запуска кода приложения. В режиме проверки компилятор читает код и сообщает о несоответствиях, но не создаёт новые файлы и не запускает приложение.
После этой предварительной настройки агент перевёл файлы с данными и вспомогательными функциями — небольшими общими операциями, которые используются в разных частях проекта: например, объединение CSS-классов или обработка значений. Миграция началась с наиболее простого слоя: файлов без интерфейса, кнопок, форм и разметки React.
После переименования файлов агент перезапустил dev-сервер, и закоммитил изменения.
Этап 2. Переводим основу приложения
На следующем этапе агент перевёл точку входа и основную оболочку сайта:
Точка входа — файл main, с которого начинается запуск React-приложения.
Оболочка — компонент App, который собирает основные части сайта. Это меню, переключатель темы и открываемые страницы.
В коде появились описания типов для параметров компонентов, событий и данных. Это правила TypeScript, которые сообщают компилятору, какие значения ожидаются в конкретном месте программы. Например, можно указать, что компонент принимает название страницы как строку, обработчик нажатия как функцию, а тему оформления только как значение light или dark. Эти описания существуют только во время разработки и исчезают после преобразования TypeScript в обычный JavaScript.
Затем агент начал переводить локальные компоненты интерфейса. В проекте использовались компоненты shadcn/ui (мы рассказывали про них в самой первой статье), но их исходный код находился внутри самого проекта. Поэтому эти файлы тоже нужно было перевести на TypeScript.
Этап 3. Переводим все оставшиеся файлы
На последнем этапе агент перевёл на TypeScript все страницы и оставшиеся компоненты интерфейса: формы, диалоговые окна, меню, календарь, карусель, графики и другие элементы.
То есть агент не переписывал приложение заново. В большинстве случаев он сохранял существующую логику, переименовывал файлы из .jsx в .tsx и добавлял описания типов там, где TypeScript не мог определить их самостоятельно. Расширение .jsx используется для React-компонентов на JavaScript, а .tsx — для React-компонентов на TypeScript.
Например, для формы он указывал:
Какие значения хранятся в ее полях.
Какие параметры получает компонент.
Какое событие происходит при отправке.
Какие данные возвращают календарь, карусель или библиотека графиков.
Для сторонних библиотек агент не менял их внутренний код. Он только использовал предоставленные ими типы, чтобы TypeScript понимал, какие данные принимают их компоненты и что они возвращают.
После устранения последних ошибок агент выполнил полную проверку типов, сборку, линтер и все браузерные тесты. После успешного результата агент сохранил изменения отдельным коммитом и отправил их на GitHub.
Что в итоге: сайт продолжил работать как раньше, но теперь TypeScript может находить многие несоответствия еще до запуска приложения.
Что дальше
В этой статье мы сделали сразу две большие работы: добавили автотесты и перевели сайт с JavaScript на TypeScript. Раньше обе задачи занимали кучу времени у разработчиков: нужно было вручную переписывать файлы, описывать типы, искать ошибки, отдельно создавать сценарии проверок. ИИ-агент очень ускоряет и упрощает такую работу.
Дальше приложение можно продолжать развивать — настроить автоматическую проверку перед публикацией, добавить мониторинг ошибок, подключить серверную часть, авторизацию, базу данных. В следующих частях поработаем с этим: разберём, что ещё можно передать агенту и как контролировать результат для должного уровня качества.