Comments 5
У нас на Next.js похожая история, только не пять кнопок, а три хука useCredits с разной логикой инвалидации кэша, потому что агент каждый раз писал новый вместо того чтобы найти старый. Слайсы по фиче спасают, но без физической границы (index.ts с ограниченным экспортом плюс eslint-boundaries) агент всё равно рано или поздно тянет импорт из внутренностей соседнего слайса, просто потому что так короче.
Про «так короче» — подпишусь: агент всегда идёт по пути наименьшего числа токенов, поэтому граница-соглашение не работает в принципе, работает только граница-проверка. У меня это правило feature-public-api в dependency-cruiser: импорт из внутренностей соседа краснеет ещё в pre-commit, и агент сам перекладывает код. eslint-boundaries делает то же самое — важно лишь, чтобы граница была фактом статического анализа, а не пунктом в CLAUDE.md.
Согласен на все сто, граница-проверка единственное что реально работает. Когда вводили eslint-boundaries на существующий проект, первый прогон выдал больше 300 нарушений разом. Пришлось неделю держать правило на warn вместо error и чинить пачками по слайсам, иначе синьоры бы просто выключили линтер в первый же день. feature-public-api из dependency-cruiser выглядит строже, у меня eslint-boundaries иногда пропускает динамические импорты, надо проверить.
Полезные прикладные советы по ии-разработе frontend.
Действительно, без структуры даже с ИИ проект быстро превращается в хаос. Особенно на фронте, где легко получить кучу дублей и огромные компоненты. Проверки и правила тут реально нужны.
Пятая кнопка за вечер. Архитектура фронтенда под контекст LLM