Два способа создания доступного DatePicker'а с помощью AI: 80/20 в пользу AI или системное проектирование с агентом

Введение: почему DatePicker стал тестовым полигоном для AI-разработки

В июне 2026 года мир frontend-разработки вновь обратил внимание на, казалось бы, рутинную задачу — создание календаря для выбора даты (DatePicker). Однако за этим скрывается нечто большее: два принципиально разных подхода к использованию AI в программировании. Один — быстрый и грязный (80/20 в пользу AI), второй — системный, с участием агентов, проектирующих архитектуру.

Какой из них выбрать? Зависит от контекста: нужно ли вам прототипирование за 10 минут или production-ready компонент с доступностью (accessibility) для тысяч пользователей? Разберём оба подхода на основе недавнего обсуждения в профессиональном сообществе Источник.

Эта статья предназначена для разработчиков уровня Junior+ и Middle, которые уже знакомы с основами JavaScript и React, но хотят понять, как AI меняет процесс разработки компонентов. Если вы только начинаете — не пугайтесь: все термины будут пояснены.

Способ 1: 80/20 в пользу AI — быстрый прототип с минимальным контролем

Что это значит?

Подход «80/20» означает, что 80% кода генерируется AI (например, GitHub Copilot, Claude или GPT-4o), а 20% — это ручная доводка: исправление багов, адаптация под конкретную дизайн-систему, добавление accessibility-атрибутов. В случае с DatePicker'ом это выглядит так:

1. Вы пишете промпт: «Создай React-компонент DatePicker с выбором диапазона дат, поддержкой клавиатурной навигации и ARIA-атрибутами».
2. AI выдаёт готовый код на TypeScript с использованием, например, date-fns для работы с датами.
3. Вы вставляете его в проект, тестируете вручную, правите стили и добавляете недостающие aria-labels.

Результат: что получается на практике

Как показал эксперимент, опубликованный на Habr, AI-сгенерированный DatePicker часто выглядит хорошо визуально, но проваливает тесты на доступность. Например:

• Проблема с фокусом: AI забывает добавить tabIndex для календарных ячеек, из-за чего пользователи скринридеров не могут перемещаться по дням.
• Отсутствие ролей: Не добавляется role="grid" или role="gridcell", что критично для WCAG 2.1.
• Локализация: AI часто хардкодит названия месяцев на английском, игнорируя Intl.DateTimeFormat.

Тем не менее, для внутреннего прототипа или MVP такой подход оправдан. Вы получаете рабочий компонент за 10–15 минут вместо 2–3 часов ручного кодирования.

Пример кода (сгенерированный AI, требует доработки)

// Упрощённый пример AI-сгенерированного DatePicker
import { useState } from 'react';
import { format, addMonths, subMonths } from 'date-fns';

function DatePicker() {
  const [currentMonth, setCurrentMonth] = useState(new Date());
  const [selectedDate, setSelectedDate] = useState(null);

  return (
    <div>
      <button onClick={() => setCurrentMonth(subMonths(currentMonth, 1))}>←</button>
      <span>{format(currentMonth, 'MMMM yyyy')}</span>
      <button onClick={() => setCurrentMonth(addMonths(currentMonth, 1))}>→</button>
      {/* Здесь AI часто пропускает ARIA-атрибуты */}
    </div>
  );
}

Проблема: Нет aria-live для объявления смены месяца, нет role="grid" для сетки дней. Пользователь скринридера не поймёт, что месяц изменился.

Когда использовать?

• Хакатоны и прототипы
• Личные pet-проекты
• Быстрая проверка гипотезы дизайна

Способ 2: Системное проектирование с агентом — архитектура прежде всего

Что меняется?

Второй подход — это не просто генерация кода, а полноценное проектирование системы с помощью AI-агента, который анализирует требования, генерирует архитектурную документацию, а затем поэтапно создаёт компоненты. Здесь AI выступает не как генератор строк, а как ассистент архитектора.

Как это работает на практике:

1. Этап анализа: Вы описываете агенту требования: «Нужен DatePicker для медицинского приложения с поддержкой 12 языков, строгими требованиями к accessibility (WCAG 2.1 AA) и возможностью выбора диапазона дат без перекрытия».
2. Этап проектирования: Агент предлагает архитектуру: разделение на компоненты (CalendarGrid, MonthNavigator, DateInput), выбор библиотеки (например, @internationalized/date от Adobe), план тестирования.
3. Этап реализации: Код генерируется по частям, с автоматической проверкой на соответствие стандартам (линтеры, тесты доступности).

Результаты: системный подход окупается

Согласно данным из обсуждения на Habr, DatePicker, созданный через системное проектирование с агентом, проходит тесты Lighthouse Accessibility на 95–100 баллов, тогда как AI-сгенерированный «на скорую руку» — на 60–70 баллов. Разница в трудозатратах: 4–6 часов против 15 минут, но для production-проекта это оправдано.

Пример архитектуры (сгенерировано агентом)

DatePicker/
├── components/
│   ├── CalendarGrid.tsx    // Отвечает за отрисовку дней с role="grid"
│   ├── MonthNavigator.tsx  // Кнопки переключения с aria-live
│   └── DateInput.tsx       // Поле ввода с маской и валидацией
├── hooks/
│   └── useDatePicker.ts    // Логика состояния и навигации клавишами
├── utils/
│   └── i18n.ts             // Локализация через Intl
└── tests/
    └── accessibility.test.ts  // Тесты с axe-core

Ключевое отличие: Агент автоматически добавляет aria-live для объявления изменений, aria-roledescription для календаря и поддержку клавиш ArrowLeft, ArrowRight, Home, End.

Когда использовать?

• Продуктовые проекты с пользователями
• Приложения, где accessibility — юридическое требование (например, госуслуги, медицина)
• Команды, которые хотят стандартизировать процесс разработки

Сравнение подходов: таблица

Кейс из реальной жизни: как мы выбирали подход

Представьте стартап, разрабатывающий CRM для небольших клиник. У команды из 3 фронтендеров есть 2 недели на MVP, включая модуль записи на приём с выбором даты и времени.

Первый спринт: Использовали подход 80/20 — AI сгенерировал DatePicker за 20 минут. Клиенты (врачи) смогли записывать пациентов, но жаловались, что «календарь не проговаривает даты» (скринридеры не работали). Пришлось потратить ещё 2 дня на фиксы accessibility.

Второй спринт: Для новой версии (с поддержкой 5 языков) перешли на системное проектирование. Агент проанализировал требования, предложил использовать react-aria-components (библиотека от Adobe с встроенной accessibility). Результат: компонент прошёл аудит за 1 день, вместо недели.

Вывод: Для быстрого запуска подойдёт первый способ, но если вы планируете масштабирование и поддержку — инвестируйте в системный подход.

Как ASI Biont может помочь в автоматизации выбора подхода

Если ваша команда регулярно сталкивается с выбором между скоростью и качеством, стоит задуматься об автоматизации части процессов. ASI Biont поддерживает подключение к различным AI-сервисам через API — подробнее на asibiont.com. Это позволяет, например, настроить пайплайн, где AI-агент сначала анализирует требования, а затем выбирает стратегию генерации кода.

Но даже без использования внешних платформ, понимание двух описанных подходов поможет вам принимать осознанные решения: когда можно «срезать угол», а когда нужно строить фундамент.

Заключение: не существует универсального способа

Оба подхода — 80/20 в пользу AI и системное проектирование с агентом — имеют право на жизнь. Ключевой вывод из недавнего обсуждения (июнь 2026) в том, что AI не отменяет необходимость понимания основ accessibility и архитектуры. Он лишь ускоряет рутинные операции.

• Если вам нужен DatePicker для внутреннего инструмента, который увидят 10 человек, — используйте AI-генерацию и потратьте 20 минут.
• Если компонент будет использоваться тысячами пользователей, включая людей с ограниченными возможностями, — вложите 4–6 часов в системное проектирование с агентом.

Помните: AI-агенты хороши в генерации кода, но архитектурные решения и тестирование на соответствие стандартам (WCAG, ARIA) остаются за человеком. Как минимум до того момента, пока не появятся полностью автономные агенты, способные проходить аудит accessibility без участия разработчика.

Дата актуальности: июнь 2026 года. Информация основана на публикации сообщества Habr и личном опыте разработки компонентов с использованием Claude 3.5 Sonnet и GitHub Copilot.