Коротко
Продуктовый дизайнер описывает, как с помощью Claude Code создал планировщик «Котомка» и затем укрепил его против двух проблем: непоследовательного интерфейса и потери данных при синхронизации. Главный вывод — AI ускоряет написание кода, но стабильность обеспечивают измерения, проверяемые правила и тесты, за архитектурные решения при этом отвечает человек.
Контекст
Автор — продуктовый дизайнер с более чем шестилетним опытом в SaaS, который в одиночку разрабатывает планировщик жизни по методу PARA. Большую часть кода пишет Claude Code, а автор ставит задачи, проверяет результат и выбирает решения. В проекте есть веб- и мобильная версии, синхронизация между устройствами и интеграции с Google и Apple Calendar.
Главное
- Стек: Next.js 16 с App Router (фактически SPA), React-контекст, LocalStorage, сервер синхронизации и интеграций, Postgres на Neon, Vitest, React Testing Library, e2e-тесты, husky и Conventional Commits.
- Аудит интерфейса scripts/ui-audit.ts проверил 3089 элементов на 36 экранах и показал разброс стилей у компонентов одинаковых ролей.
- Автор ввёл токены в globals.css и заменил около 90 произвольных значений размеров и цветов. ESLint запрещает новые исключения; мобильные значения заданы внутри токенов через @media.
- Для tailwind-merge расширили конфигурацию: без регистрации кастомных text-токенов функция могла считать их цветами и удалять как конфликтующие классы. На это добавили отдельный тест.
- Токен text-field задаёт 14px на десктопе и 16px на мобильных устройствах. Его применили к 12 финансовым полям, чтобы iOS не увеличивал масштаб страницы при вводе.
- Контекст Claude Code сократили с 951 строки всегда загружаемых инструкций до 117 строк на момент реорганизации; ещё 8 файлов правил загружались по маскам путей. Позднее автозагрузка выросла до 157 строк, а число файлов правил — до 13.
- Генератор инвентаря компонентов выявил важность ручной проверки: три из четырёх проверенных описаний, созданных AI, оказались неточными.
- PreToolUse-хук запрещает AI создавать новые примитивы в src/components/ui/. Проверка npm run ui-audit:check сравнивает аудит с вручную обновляемым эталоном и останавливается при появлении нового значения.
- При синхронизации нашли гонку: ответ push мог сбросить флаг изменений, появившихся во время запроса. Исправление сбрасывает флаг только если состояние не изменилось с момента отправки; аналогичный гард добавили для обработки 409.
- При двух вкладках нормализация данных создавала новый объект, из-за чего проверка ссылок запускала обратную отправку и цикл обновлений. В тестовом сценарии за 60 секунд серверная версия росла с 5 до 9; после исправления оставалась 5.
- Для ускорения синхронизации отказались от WebSocket и SSE: клиент раз в 2 секунды запрашивает GET /api/state/version и загружает полный снимок, только если версия изменилась. Pre-commit-проверки занимают около 13 секунд; e2e выполняются в CI.
Как сделано
Для UI автор сначала измерил фактический разброс стилей, а затем стандартизировал размеры и цвета токенами и перевёл компоненты на варианты и размеры без изменения публичного API. Правила для Claude Code разделил на короткое постоянно загружаемое ядро и файлы в .claude/rules/, подключаемые по путям. Маски проверяет check-rules-globs.ts, а состав контекста — команда /context. Новые примитивы блокирует хук, а гвард аудита не позволяет незаметно добавлять новые стили.
Результаты
Разброс UI по итогам аудита заметно сократился и, по словам автора, перестал увеличиваться благодаря гварду. Исправлены три сценария потери или лишней перезаписи данных: ввод во время push, цикл обновлений между вкладками и восстановление локальных изменений после повторного открытия. Интервал проверки синхронизации уменьшили с 15 до 2 секунд; автор сообщает, что на проде обновления стали ощущаться мгновенными. Быстрые pre-commit-проверки занимают около 13 секунд.
Ограничения
Автор не приводит численных итогов аудита после стандартизации, статистики ошибок до и после исправлений, измерений задержки синхронизации или затрат на инфраструктуру. Сценарий двух вкладок проверяли в тестовом харнессе с фейковым сервером, а не на реальном проде; для живого теста потребовалась бы отдельная база. Сравнение 117 и 951 строк инструкций — наблюдение одного проекта, а не контролируемый эксперимент. Правила со временем снова разрослись. AI-описания компонентов оказались ненадёжными без проверки человеком.
Что взять себе
- Сначала измеряйте несогласованность интерфейса, а затем закрепляйте дизайн-систему токенами, тестами и автоматическими проверками.
- Не рассчитывайте, что AI будет помнить длинные инструкции: держите ядро коротким, подключайте узкие правила по необходимости и проверяйте, что маски действительно совпадают с файлами.
- Для конкурентных обновлений явно задавайте инварианты и тестируйте гонки на старом коде: внешне зелёный тест может быть ложным из-за общей среды или неочищенных обработчиков.
- Просите AI сначала диагностировать проблему, а не сразу менять код; технические альтернативы и последствия для архитектуры всё равно нужно оценивать самостоятельно.
- Проверяйте сгенерированные AI документацию и инвентари: уверенный, но неточный текст может закрепить ошибочные решения.
Читать оригинал, если…
Откройте оригинал, если нужны детали реализации скриптов, хуков и тестов, а также полный ход разбора ошибок синхронизации.