Больше свободы ИИ-агентам - строже автоматические проверки: React 19 и ESLint 10
Чем активнее ИИ-агенты участвуют в разработке, тем важнее становятся понятные и неизбежные ограничения. Постепенно им можно поручать всё больше: запускать облачные машины для типовых задач, самостоятельно менять конфигурацию проекта, готовить коммиты и сообщать о завершении работы. Такой подход заметно ускоряет разработку, однако цена ошибки тоже растёт.
Основная проблема обычно не в том, что агент пишет неработоспособный код. Гораздо чаще он создаёт слишком много лишних изменений, допускает небольшие опечатки, нарушает соглашения проекта или случайно затрагивает соседнюю функциональность. Поэтому в проектах нужны детерминированные guardrails - проверки, которые одинаково срабатывают при каждом коммите и после каждого отчёта агента "задача выполнена".
К таким механизмам относятся тесты, pre-commit hooks, форматтеры и линтеры. Они превращают абстрактные требования в простой результат: проверка пройдена или нет. Небольшие коммиты дополнительно помогают быстрее определить место, где появилась проблема. Есть и менее предсказуемые инструменты - например, skills и подходы вроде un-slop, - но они пока развиваются быстрее, чем формируются устойчивые практики их применения.
Почему переход на ESLint 10 оказался проблемным
Линтинг React 19 ESLint 10 стал отдельной задачей после обновления самого ESLint. В нескольких React-приложениях миграция остановилась на `eslint-plugin-react`: в ESLint 10 были удалены устаревшие API контекста правил, а версия `eslint-plugin-react@7.37.5` заявляла поддержку только до ESLint 9 включительно.
В результате запуск конфигурации под ESLint 10 завершался ошибкой. Проблема была зарегистрирована 7 февраля 2026 года и к 23 августа всё ещё оставалась открытой более полугода. Pull request с исправлением, созданный 30 июля, также не был принят.
Ждать обновления не хотелось: требовалась строгая автоматическая проверка React-кода с поддержкой новой версии ESLint. Поэтому появился пакет `@ternaus/eslint-plugin-react` - самостоятельно развиваемое продолжение плагина, рассчитанное на React 19 и ESLint 10. Подробности подхода и история сокращения набора правил описаны в материале о настройке линтинга React 19 на ESLint 10.
Узкая матрица совместимости
Пакет создавался под реальные проекты, поэтому его поддержка намеренно ограничена:
- React - 19 и новее;
- ESLint - 10;
- Biome - от 2.5.8;
- Node.js - версии 22.13, 24 или 26;
- ESLint - только flat config.
React 18, ESLint 9 и конфигурации формата `.eslintrc*` не входят в поддерживаемую матрицу. Такой подход уменьшает количество вариантов поведения и упрощает сопровождение.
В используемых проектах форматирование и основная часть проверок выполняются Biome. Он анализирует JavaScript, TypeScript, JSX, DOM и значительную часть типичных React-конструкций. ESLint при этом оставлен для задач, которых нет в Biome: проверок фреймворка и отдельных особенностей поведения React 19.
Конфигурация выросла из нескольких действующих проектов на Next.js и React, включая Albumentations.ai, sportscategory.info и my-roots.me. В них используются Next.js 16, React 19, TypeScript, ESLint 10 с плоской конфигурацией, Biome с набором `all`, Yarn 4 и Node.js 22, 24 и 26.
Как из 102 правил осталось 11
Исходный проект на момент ответвления экспортировал 104 модуля правил. В наборе `all` было включено 102 правила, ещё два считались устаревшими. В пресете `recommended` находилось 22 правила, но `react/no-unsafe` был отключён вручную, поэтому фактически применялось 21.
Однако переносить весь набор не имело смысла. Дублирование проверок ухудшает производительность, усложняет конфигурацию и создаёт риск противоречивых предупреждений. Если Biome уже надёжно выявляет ту же проблему, повторная проверка ESLint не добавляет пользы.
Правила распределили по нескольким категориям:
- всё, что уже проверяет Biome, удаляется из ESLint-плагина;
- форматирование, именование, структура файлов и командные соглашения остаются в Biome или конфигурации проекта;
- эвристики, которым нужны сведения обо всём проекте или полноценная типовая информация, исключаются, если они дают ненадёжные результаты;
- проверки React 18, старой конфигурации ESLint, обходов для парсеров и устаревших API убираются.
В итоге из большого набора сохранились 11 правил. Они отвечают именно за те случаи, где проверка действительно полезна и дополняет Biome, а не повторяет его работу. Исходный репозиторий, история Git, лицензия MIT и сведения об авторах были сохранены, но дальнейшее развитие пакета ведётся независимо.
Что проверяет сокращённый набор
Оставшиеся правила ориентированы на корректность React 19 и потенциально опасные сценарии. Их задача - не навязать разработчику определённый стиль, а поймать дефекты, которые могут привести к неправильному поведению компонентов, неожиданным эффектам или проблемам во время выполнения.
Это важное различие для любой конфигурации ESLint для React проекта. Линтер не должен превращаться в коллекцию субъективных предпочтений. Чем точнее правило связано с реальной ошибкой, тем выше вероятность, что разработчики и ИИ-агенты будут воспринимать его как полезное ограничение, а не как формальный шум.
При подключении пакет можно использовать вместе с flat config ESLint 10 и Biome. Biome отвечает за форматирование и универсальные проверки, а ESLint - за узкую область React-специфичных рисков. Для Next.js важно учитывать версию фреймворка и порядок подключения конфигураций: сначала задаются базовые параметры, затем добавляются правила React и исключения для файлов, где проверка неуместна.
Такой инструментарий особенно полезен в автоматизированных pipeline. Агент может подготовить код, запустить локальные проверки и исправить замечания до создания pull request. В CI те же правила становятся независимым барьером: даже если агент сообщил об успешном выполнении задачи, проект не примет изменения, нарушающие обязательные ограничения.
Когда пакет лучше не использовать
Узкая специализация одновременно является преимуществом и ограничением. Пакет не подойдёт проектам на React 18, старых версиях ESLint или `.eslintrc`-конфигурации. Также он не заменяет универсальный набор правил, форматтер и типовую проверку TypeScript.
Если команда не использует Biome, часть привычных проверок придётся настроить отдельно. В проекте со сложной архитектурой и потребностью анализировать типы могут понадобиться специализированные инструменты, например TypeScript-aware правила. В таких случаях не стоит включать все доступные проверки автоматически: лучше заранее определить, какую именно ошибку ловит каждое правило и кто отвечает за конкретный класс проблем.
Практический эффект для разработки с агентами
Жёсткий линтинг не ограничивает автономность ИИ-агента, а делает её безопаснее. Агент получает свободу в выборе способа решения, но итоговый код должен пройти объективные проверки. Это позволяет постепенно расширять его полномочия, не превращая каждую операцию в ручное согласование.
Полезно разделять проверки по времени запуска. Быстрые правила и форматирование выполняются перед коммитом, более дорогие тесты - в CI, а проверки сборки и интеграционного поведения - перед выпуском. Такой каскад уменьшает задержки и одновременно сохраняет необходимый уровень контроля.
Важно также не превращать линтер в единственный барьер. ESLint не заменяет тесты, ревью, проверку зависимостей и ограничения доступа к инфраструктуре. Но в связке с ними он эффективно ловит значительную часть механических ошибок - особенно тех, которые ИИ-агенты способны размножать в большом количестве.
Итоговая идея проста: чем больше свободы получает агент, тем яснее должны быть правила, которым он обязан следовать. В случае React 19 и ESLint 10 разумнее использовать небольшой, точный набор проверок, чем бездумно переносить сотню правил. Такой баланс снижает шум, упрощает сопровождение и делает автоматическую проверку кода React действительно полезной частью инженерного процесса.
