Загрузка 0
ПОДЕЛИТЬСЯ

Мой блог

Листай вниз

Как я создавал проект с помощью Claude Code: опыт соло-разработки

Как я создавал проект с помощью Claude Code: опыт соло-разработки

Подробности изложены в материале первоисточника. Занимаясь разработкой SaaS-проекта в одиночку с активным привлечением нейросетей, я столкнулся с неожиданными трудностями. Продуктовый дизайнер должен выстраивать жесткие архитектурные рамки вокруг ИИ, чтобы код не превратился в хаос.

Первые недели работы сопровождались настоящей эйфорией: новые функции появлялись с невероятной скоростью. Однако вскоре проявились системные проблемы: интерфейс начал расползаться по элементам, а у пользователей стали фиксироваться случаи потери данных. Мой проект под названием «Котомка» представляет собой комплексный планировщик жизни по методу PARA, включающий сферы, проекты, задачи, календарь, привычки и финансовый учет. Приложение имеет веб-версию, мобильный вариант и синхронизацию с внешними календарями. В качестве технологического стека я использую Next.js 16 (App Router, работающий фактически как SPA), единый React-контекст для состояния в паре с LocalStorage, бэкенд для синхронизации, базу данных Postgres (Neon), а также Vitest, React Testing Library, e2e-тесты, husky и Conventional Commits.

Дополнительный скриншот интерфейса разработки
Элемент интерфейса проекта
Настройка конфигурации проекта
Конфигурационные файлы
Инструменты разработчика
Инструменты разработки
Параметры окружения
Параметры
Проверка кода
Иллюстрация к материалу: Как я создавал проект с помощью Claude Code: опыт соло-разработки
Системные логи
Иллюстрация к материалу: Как я создавал проект с помощью Claude Code: опыт соло-разработки
Финальный результат сборки
Сборка приложения

Часть 1. Почему AI не помнит вашу дизайн-систему

Когда я просил исправить форму на мобильном устройстве, Claude Code генерировал произвольный размер инпута, игнорируя готовый компонент. Новые экраны страдали от несоответствия заголовков. По отдельности каждое решение модели выглядело логично, но вместе они превращали проект в лоскутное одеяло из-за отсутствия явной дизайн-системы.

Реклама

Шаг 1. Измерить, а не спорить на глаз

Для решения проблемы я поручил Claude Code разработать специальный скрипт аудита scripts/ui-audit.ts. Он запускает экраны в браузере, собирает актуальные стили элементов и сортирует их по ролям, вычисляя разброс параметров вроде размера шрифта или отступов. Первый же запуск по 3089 элементам показал удручающую картину.

Шаг 2. Токены и скрытые проблемы с tailwind-merge

Далее я внедрил шкалу токенов в стилевых файлах и перевел компоненты на варианты без изменения публичного API, избавившись от хардкода. Однако вскоре табы начали смещаться. Причиной оказалась функция cn() на базе tailwind-merge, которая принимала кастомные классы текста за цвета и удаляла лишние. Проблема потребовала расширения конфигурации и введения строгого теста.

Похожая история происходила на iPhone, где финансовые инфуты вызывали зум из-за маленького шрифта. Проблему решило создание единого адаптивного токена text-field с разными параметрами для десктопа и мобильных устройств.

Реклама

Шаг 3. Оптимизация правил для искусственного интеллекта

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

Для контроля актуальности контекста я использую команду /context и вспомогательные скрипты проверки масок. Со временем объем автозагрузки неизбежно растет, поэтому регулярный аудит правил стал обязательной процедурой.

Котомка: десктопная и мобильная версии

Шаг 4. Инвентарь компонентов и проверка достоверности

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

Шаг 5. Запреты эффективнее устных просьб

Текстовые инструкции для модели часто не работают так надежно, как технические ограничения. Специальный PreToolUse-хук теперь блокирует создание несанкционированных файлов в папке UI-компонентов, а автоматический гвард сверяет состояние интерфейса с эталоном.

Гвард ловит одно новое значение font-weight у табов и перечисляет все экраны, где оно появилось

Если в коде появляется нежелательное изменение стилей, скрипт наглядно подсвечивает проблему и блокирует сборку. Благодаря этому визуальный разброс в приложении удалось взять под жесткий контроль.

Часть 2. Борьба с потерей данных при синхронизации

Архитектурно все данные пользователя хранятся в виде единого JSON-снимка с версионированием. Клиент отправляет изменения с небольшой задержкой, а конфликты разрешаются по правилу приоритета последней записи.

График изменения строк автозагрузки правил для Claude Code
Автозагрузка: 951 строка до реорганизации, 117 сразу после, 157 сейчас

Баг 1. Исчезновение текста после ввода

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

Воспроизведение в тестовом харнессе: до фикса версия 5 → 9 за минуту без единого действия, после фикса 5 → 5

Тестирование подобных гонок требует особого внимания к очистке хуков. Тесты, которые никогда не падали ошибочно при сбое, не могут считаться надежным доказательством корректности кода.

Работа UI-аудита при обнаружении изменения шрифта табов
Гвард ловит одно новое значение font-weight у табов и перечисляет все экраны, где оно появилось

Баг 2. Бесконечный пинг-понг между вкладками

В сценарии с несколькими открытыми окнами нормализация данных приводила к отправке неизмененных объектов обратно на сервер, порождая циклический рост версий. Проблема была успешно локализована и устранена на уровне нормализации стейта.

Баг 3. Вопросы скорости и сетевые оптимизации

Мне требовалась максимально быстрая синхронизация без тяжелых протоколов вроде WebSocket. Обычного легкого опроса версии раз в пару секунд и точечной подгрузки снимков оказалось достаточно для мгновенного обновления данных между устройствами.

Что я вынес из этого

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

Запреты в виде хуков надежнее любых текстовых просьб, а написанный нейросетью код и тесты требуют обязательной перепроверки человеком. Разумная организация процессов позволяет создавать качественные продукты в одиночку.

Тестовый харнесс воспроизведения багов синхронизации версии
Воспроизведение в тестовом харнессе: до фикса версия 5 → 9 за минуту без единого действия, после фикса 5 → 5

Автозагрузка: 951 строка до реорганизации, 117 сразу после, 157 сейчас

01.