Writing

Frontend

Как я ИИ-шаблон для разработки пилил

Недавно нужно было решить амбициозную задачу: создать шаблон для фронтенд-проектов, чтобы вайбкодить было удобно и небольно, если подробнее то:

  1. Единый формат оформления всех проектов, то есть использование общего UI-kit
  2. Возможность быстро набросать дизайн/перенести через MCP Figma его в код
  3. Типизация и разделение, архитектура должна была быть простой и понятной
  4. ИИ должна тратить минимальное количество токенов на допустимые проверки - все должно быть прописано в правилах для экономии и исключения возможных галлюцинаций

Начну с самого начала - UI Kit

Поиск UI-Kit

Здесь я выделил следующие дополнительные критерии

  1. Бесплатный шаблон Figma с компонентами
  2. Tailwind - для гибкости, ИИ его хорошо понимает

Найти обычный UI-kit на tailwind не проблема, но чтобы с ним в комплекте и Figma шла довольно тяжело

Из вариантов оставался shadcn/obrastudio - они полностью привязали ui-kit к дизайн токенам, внесли переменные в фигме и даже сделали плагин для переноса в CSS. После всего этого поиски продолжать было бессмысленно и я начал переносить shadcn-ui-kit в отдельный ui для возможности обогащения своими компонентами если прийдется. Засунул в story-book, обернул в приватный пакет npm для Gitlab и UI-kit готов

На выходе получили:

  1. Свой UI-Kit, макеты компонентов в Figma
  2. Возможность дообогащения
  3. Легкое использование в формате npm-пакета

UI-Kit готов, следующим вопросом был сам шаблон

Подбор шаблона

Строить архитектуру в формате FSD или атомарного дизайна не хотелось первоначально по-нескольким причинам:

  1. Сложный вкат для разработчиков
  2. Возможность галлюцинаций от ИИ
  3. Ненужные абстракции из-за небольшого размера проектов

Единственное что действительно рассматривалось - FEOD, но решение пришло само собой, когда я смог описать всю нужную мне структуру в одно предложение: “Делим логику по страницам использования, общую кладем в переиспользуемую папку и все”

Большинство компонентов и так в UI-ките, кастомных компонентов будет не так много - тогда зачем усложнять? Проекты повторюсь заточены под средние размеры, поэтому громоздить что-то на ровном месте очень уж не хотелось

Да и любому ассистенту кода будет работать с этим намного проще и меньше времени/токенов уйдет на разбирательства куда класть очередной JSON-чик

Структура выбрана, подходим к концу

Ограничение через типы и навыки

Структура хорошо, но этого мало, нужно ограничить возможность написания плохого кода “подручными” инструментами, берем:

  1. TypeScript, Zod - для типизации
  2. Eslint, Prettier - для красоты кода
  3. .husky - чтобы не напортачить перед тем как залить код

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

Из новых инструментов - появляется папочка “skills”, с markdown файлами о том каких правил придерживаться с работой по тем или иным вопросам

Все skills были взяты у жесткого адепта Vue - antfu

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

Примерный итог прикрепляю на скрине работы с Codex:

https://ibb.co/wFPvjwJW

Краткий итог

Может я уже чуть и запоздал с такими штуками, но как опытом действительно хотелось поделиться

Работая с таким шаблоном действительно чувствуешь себя архитектором кода, а не просто разрабом. Попробуйте сделать что-то такое и для себя, надеюсь, вы получите от этого удовольствие!