80/20 vs AI-агент: как создать доступный DatePicker — сравнение подходов

Андрей Отинов -

Команда frontend-разработчиков из компании «Исходный код» провела эксперимент: может ли AI-агент создать production-ready компонент DatePicker для React и TypeScript с полноценной поддержкой доступности (a11y). Ответ — да, но с важной оговоркой. AI работает как часть инженерной системы, а не как генератор кода по кнопке.

Источник: Habr

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

Если вы техлид или frontend-разработчик, который оценивает, стоит ли доверять AI создание сложных UI-компонентов, вот что нужно знать о рисках и результатах каждого подхода.

Что именно произошло: эксперимент с DatePicker

DatePicker — обманчиво простой компонент. Снаружи это поле ввода, кнопка и всплывающий календарь. Внутри — keyboard navigation, управление фокусом, работа со screen reader'ами, контролируемое состояние, локализация, мобильная верстка и десятки пограничных состояний.

Команда Ильи, технического директора «Исходного кода», сравнила два подхода к созданию такого компонента с помощью AI:

  1. 80/20 — модель получает подробный запрос на основе стандарта WAI-ARIA APG, генерирует большую часть кода, остальное дорабатывается вручную.
  2. Системное проектирование с AI-агентом — сначала готовятся требования, архитектурные правила, задачи и тесты, только потом агент пишет код через итерации.

Оба подхода сработали. Разница — в том, где и как они дают сбой.

Подход 80/20: быстро, но с риском «случайной архитектуры»

Это самый очевидный путь: дать модели Claude четкий запрос на основе WAI-ARIA APG и попросить сгенерировать DatePicker. Для прототипа этого достаточно — модель знает сетку календаря, React-компоненты, ARIA-атрибуты и логику клавиатурной навигации.

Проблема начинается, когда первая версия выглядит почти готовой.

Большинство ошибок возникает не внутри отдельного элемента, а на стыках между ними:

  • Строгое следование APG может создать разметку, которая выглядит правильно, но работает с реальными screen reader'ами хуже, чем контролируемое отклонение от руководства.
  • Диалоговое окно может начать мигать из-за конфликта обработчиков onBlur и onClick.
  • Разница между aria-live="polite" и assertive в коде незаметна, но становится реальной проблемой UX, когда screen reader начинает озвучивать изменения.

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

Для прототипа это приемлемо. Для production-компонента — рискованно.

Системное проектирование с агентом: дольше, но предсказуемее

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

Этот метод опирается на документированный подход к работе с AI-агентами. Он не превращает модель в «волшебную машину для печати кода», а использует её как инженерный инструмент в рамках заданной архитектуры.

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

Сравнение подходов: что выбрать вашей команде

Критерий Подход 80/20 Системное проектирование с агентом
Время до первого прототипа Минуты Часы (подготовка требований)
Качество архитектуры Случайное, определяется исправлениями Заложено в требованиях
Риск ошибок на стыках Высокий Снижается за счет тестов
Пригодность для production Рискованно Более предсказуемо
Контроль над результатом Низкий Высокий

Что может пойти не так: скрытые риски

Даже при системном подходе остаются риски, которые стоит проверить до внедрения.

Зависимость от модели. В эксперименте использовалась Claude, но результат может отличаться на других моделях. Конкретные версии моделей и инструментов в статье не указаны, что затрудняет воспроизводимость.

Ограниченность примера. DatePicker — сложный, но не самый сложный компонент. Результаты могут не переноситься на более комплексные UI-элементы.

Отсутствие независимого тестирования. В статье нет данных о тестировании с реальными screen reader'ами и пользователями с ограниченными возможностями. Формальное соответствие APG не гарантирует реальную доступность.

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

Что проверить на этой неделе: практический чек-лист

  1. Откройте демо-версию компонента по ссылке и протестируйте с клавиатуры и screen reader'ом. Оцените, насколько поведение соответствует ожиданиям ваших пользователей.
  2. Изучите код в репозитории — посмотрите, как организована архитектура, какие тесты написаны, как обрабатываются пограничные состояния.
  3. Сравните со своим компонентом — если у вас уже есть DatePicker, оцените разницу в подходе к доступности и архитектуре.
  4. Проверьте WAI-ARIA APG — официальный паттерн DatePicker от W3C — это база, от которой стоит отталкиваться независимо от выбранного подхода.
  5. Проведите мини-эксперимент — возьмите простой компонент из вашего проекта и попробуйте оба подхода. Замерьте время, количество ошибок и усилия на доработку.

Какой подход выбрать: решение для вашей команды

Если вам нужен быстрый прототип для проверки гипотезы — подход 80/20 сработает. Но как только компонент идет в production, системное проектирование с AI-агентом дает больше контроля и предсказуемости.

Ключевой вывод из эксперимента: AI может создавать сложные доступные компоненты, но только если вы относитесь к нему как к части инженерной системы, а не как к генератору кода. Подготовка требований, архитектурных правил и тестов — это не лишняя бюрократия, а必要条件 для получения production-ready результата.

Источники

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше