Разработка веб-приложения для мероприятий с помощью Claude

1. Введение

Чтобы осуществить цифровую трансформацию соревновательных мероприятий, проводимых офлайн между командами, я самостоятельно разработал и реализовал веб-приложение. В этом приложении участвующие команды покупают ресурсы за виртуальную валюту, создают результаты работы и соревнуются за очки, реагируя на изменения условий в реальном времени. Ранее эти мероприятия проводились с использованием бумажных журналов и ручных вычислений, поэтому ошибки организаторов напрямую отражались на результатах. Участники также не могли в реальном времени проверять состояние своих ресурсов. Испытав эту неэффективность на собственном опыте, я начал проект с вопроса: «Если это система такого масштаба, неужели я не смогу самостоятельно сделать её как следует?»

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

В этой статье основное внимание уделяется не техническим деталям проекта, а тому, как я использовал Claude в качестве партнёра по разработке на протяжении всего процесса. С практической точки зрения я хотел бы поделиться тем, как сотрудничество с ИИ повлияло на реальную продуктивность в ситуации, когда мне в одиночку приходилось заниматься всем — от планирования и проектирования до реализации, отладки и развёртывания.

2. Обзор проекта

Во frontend используются React и TypeScript, backend состоит из бессерверных функций на основе Next.js API Routes, а база данных представляет собой бессерверный PostgreSQL. Из-за практического ограничения на количество доступных бессерверных функций на платформе развёртывания я на раннем этапе решил группировать API по предметным областям, а не по отдельным функциям. Само это проектное решение было принято в ходе обсуждений с Claude после сравнения нескольких альтернатив и стало важной отправной точкой, определившей общую структуру проекта.

3. Принципы сотрудничества с Claude

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

«Вместо попыток получить идеальный ответ с первой попытки в конечном итоге оказалось быстрее потратить время на повышение точности вопросов».

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

4. Примеры сотрудничества из реальной практики

4.1 Обсуждение проектирования: совместная систематизация области структурных изменений

В исходной модели данных одна сущность одновременно содержала информацию о принадлежности и принадлежащих активах. Однако по мере уточнения реальных требований стало необходимо разделить понятия «кто участвует в деятельности» и «кто владеет активами». Такой тип структурных изменений цепной реакцией затрагивает всю связанную логику запросов и системы разрешений. Вместо того чтобы сразу просить Claude изменить код, я сначала попросил его «помочь составить список файлов и логики, на которые повлияет это изменение». Последовательно применяя полученный список, по одному пункту за раз, я смог выполнить миграцию без пропусков и конфликтов. Этот опыт показал мне, насколько важно сначала совместно нарисовать «карту», а уже затем поручать ИИ выполнение.

4.2 Адаптация к последним версиям библиотек: сокращение разрыва между документацией и фактическим поведением

Библиотека планирования, добавленная для планирования событий, как раз претерпела обновление до новой мажорной версии, из-за чего возникли ситуации, в которых ранее известный способ использования отличался от фактического поведения. В таких случаях я предоставлял Claude как сообщения об ошибках, так и используемую версию, а затем шаг за шагом разбирал различия между API, описанным в официальной документации, и его фактическим поведением. Такой подход оказался особенно эффективным для тонких, но критически важных деталей, таких как расположение конфигурации триггеров, указание условий отмены и преобразование часовых поясов. При работе с новейшими технологиями важно учитывать, что между моментом, когда знания ИИ были получены, и фактически последней версией может существовать разрыв. Активный обмен журналами ошибок и информацией о версиях существенно повлиял на скорость решения проблем.

4.3 Пошаговая отладка: сначала симптомы, вывод — позже

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

4.4 Когда проводить рефакторинг: выделять повторяющийся элемент при его появлении в третий раз

По мере роста числа функций на разных экранах начали неоднократно появляться похожие шаблоны интерфейса — фильтры, обработка загрузки и диалоговые окна подтверждения. Каждый раз мы с Claude оценивали, не пришло ли время выделить этот шаблон в повторно используемый компонент. Установленным нами критерием стал «момент, когда один и тот же шаблон появляется на третьем экране». После того как этот критерий был чётко включён в наши обсуждения, изменились и ответы Claude на похожие запросы: он начал сначала упоминать возможность повторного использования. Я смог убедиться, что по мере продолжения сотрудничества с ИИ контекст, накопленный в разговорах, сам по себе отчасти выполняет функцию командного соглашения.

4.5 Сотрудничество с точки зрения code review: спрашивать об обосновании, а не только о результате

Вместо того чтобы применять предложенный Claude код как есть, я выработал привычку спрашивать, почему он выбрал именно такую структуру. Например, когда Claude предложил метод join для определённого запроса, я спросил: «Почему вы выбрали этот подход и какие есть альтернативы?» Ответы иногда выявляли более простой вариант. Это было не так уж сильно отличается от вопросов, задаваемых во время code review с коллегой-человеком. Проверка обоснования вместо безоговорочного принятия результатов, созданных ИИ, в конечном счёте оказалась важной не только для качества кода, но и для сохранения собственного понимания разработчика.

Также эффективным оказалось разбивать большой запрос на проверяемые части, а не формулировать один общий запрос. Например, вместо просьбы к Claude «создать всю функцию обмена» я разделил её на этапы: «зарегистрировать транзакцию → получить список транзакций → выполнить транзакцию». Это позволило проверять фактическое поведение на каждом этапе перед переходом к следующему и тем самым рано обнаруживать ошибки. Я понял, что способность соотносить размер результатов работы с циклом проверки столь же важна при сотрудничестве с ИИ, как и при сотрудничестве с людьми.

5. Количественный обзор проекта

Готовую систему можно обобщить в числах следующим образом. В рамках ограничений платформы развёртывания backend API был объединён в 11 файлов, которые в общей сложности обслуживают 11 предметных областей: аутентификация, организации, команды, участники, ресурсы, результаты работы, транзакции, комбинации, обменные курсы, события и журналы. База данных состоит из 20 таблиц, а frontend разделён на 9 типов экранов администратора и 5 типов экранов участников — всего 14 основных экранов. Несмотря на то что в ходе разработки модель данных была дважды существенно переработана, мне удалось соблюсти график благодаря привычке сотрудничества: сначала перечислять область изменений, а затем последовательно применять их по одному.

• Файлы API: 11 (интегрированный дизайн по доменам)

• Основные таблицы данных: примерно 20

• Конфигурация представлений: 9 представлений администратора, 5 представлений участников

• Переработка модели данных: 2 раза (① разделение структуры владения «игрок — команда — пакет», ② изменение метода покупки/продажи обменных активов на однонаправленную структуру продаж)

6. Извлечённые уроки: практические выводы из сотрудничества с ИИ

• Конкретность контекста определяет качество результата: даже при одном и том же вопросе качество результата существенно различалось в зависимости от того, были ли ограничения и контекст существующего кода предоставлены одновременно.

• «Составление карты» предшествует выполнению: для задач с широким диапазоном воздействия, таких как структурные изменения, полезно было сначала совместно систематизировать область воздействия, а не сразу запрашивать выполнение. Это помогло сократить объём повторной работы.

• Диалоги превращаются в накопленные активы: когда во время диалогов я явно формулировал замысел и обоснование решений, я мог получать согласованные результаты в последующих связанных задачах, не объясняя всё заново.

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

• ИИ скорее является партнёром по сотрудничеству, чем инструментом: производительность значительно повысилась, когда я стал относиться к ИИ как к партнёру, участвующему в процессе принятия решений и помогающему формировать общее обоснование, а не просто как к инструменту, который пишет код вместо меня.

7. Заключение

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

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

PYS