Claude و Ralph: نهجان لبناء DatePicker معقد مدعوم بـ AI في تطوير المنتجات

История с DatePicker в этой статье важна не сама по себе, а как модель выбора, который сегодня делает почти любая продуктовая команда: просить нейросеть быстро накидать рабочий интерфейс или сначала построить систему, в которой AI будет писать код внутри заранее заданных правил. На примере доступного календарного компонента для React авторы показывают, что спор идет не о том, какая модель умнее, а о том, кто в процессе управляет сложностью — инженер или случайность. Первый путь авторы называют AI-драфтингом.

Логика простая: берется подробный промпт, опирающийся на рекомендации WAI-ARIA APG, и отдается модели вроде Claude. На выходе получается почти готовый DatePicker, который действительно закрывает большую часть задачи на старте. Но затем всплывают проблемы, которые редко видны в красивом первом ответе.

Слепое следование спецификации может конфликтовать с поведением реальных скринридеров, обработчики вроде onBlur и onClick начинают спорить между собой и вызывают визуальные сбои, а тонкие настройки доступности, например режим озвучивания изменений через aria-live, невозможно угадать без живого тестирования. В итоге команда получает не столько законченную архитектуру, сколько удачный черновик, который потом приходится вручную стабилизировать. Второй путь — системный инжиниринг.

Здесь AI не выдают задачу в стиле «сделай DatePicker», а помещают в жестко спроектированный производственный контур. Авторы использовали автономного агента Ralph-подхода на базе codex cli и маленькой модели, но ключевой элемент был не в модели, а в окружении. В рабочую директорию агенту подкладывали PRD с фиксированными требованиями, набор атомарных задач в tasks.

json и системные правила, которые запрещали отклоняться от целевой архитектуры. Среди обязательных условий были controlled-only API, полная клавиатурная навигация и корректная ARIA-разметка. После каждого шага код проходил внешний контур проверки: юнит-тесты и a11y-проверки через Vitest и Playwright, сборку Vite и контроль типов TypeScript.

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

Это дороже на входе: нужно написать требования, декомпозировать работу, настроить верификатор и потратить больше токенов. Зато стоимость изменений со временем падает. Если нужно добавить новую функцию или исправить алгоритм, изменения вносятся в конкретный слой, а не размазываются по всему компоненту.

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

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

Отсюда и практический вывод: быстрый драфтинг хорошо подходит для MVP, прототипов, хакатонов и одноразовых утилит, где важнее скорость, чем долгосрочная поддержка. Системный подход оправдан там, где компонент станет частью дизайн-системы, ядра продукта или долгоживущего проекта. Что это значит на практике: AI уже умеет резко ускорять создание интерфейсов, но главная развилка проходит не между моделями, а между режимами работы команды.

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