Если честно да, руками часто быстрее, особенно если компонент разовый и потом его никто трогать не будет. Весь смысл в статье как раз в этом: настройка под агента дороже на старте, а окупается только когда компонент потом живёт и меняется, а не в моменте первого написания.
Пайпа для генерации доки под каждый компонент нет, AGENTS.md собирали один раз руками, чтобы просто прощупать сам подход — не как конвейер, который штампует такие доки под любую новую задачу.
Промпт: полный текст промпта есть в статье. Весь диалог со спецификой под наш кейс по понятным соображениям прикладывать не стал :) Все важные детали в статье описаны.
Примеры: ссылки на код компонента и рабочий результат указаны в статье.
Документация: тут не понял, о чём именно речь. Если речь про ссылку на доку с целевым поведением инклюзивного компонента, то в статье она указана.
Скиллы и субагенты: ИМХО детально настроить модель по времени — около идентично написанию чернового варианта компонента (чего в целом от модели было и нужно). Поэтому цель была использовать «голый» Opus 4.7 и посмотреть, что он умеет. Кстати, вариант с более детальной настройкой модели (с субагентами, но без скиллов) — в следующей статье.
Инструменты для тестирования: Safari + VoiceOver, Chrome и Firefox + NVDA. Про скринридеры в статье также многократно упоминается.
Не только лишь все кодеры умеют клодкодить)
Согласен, не только лишь все) но тут цель была ровно обратная — посмотреть, что «голая» модель без прокачанного скилла выдаёт даже у тех, кто вроде умеет клодкодить. Получилось наглядно :)
Дело не в React как таковом, а в том, что у заказчика вся экосистема была на нём и была построена. Смешивать мух с котлетами было бы странным :)
По поводу инструмента можно много холиварить, но только по факту любым инструментом можно сделать как хорошо, так и криво. React с нормальным вниманием к a11y и React без него — это два разных результата на одном и том же стеке... Дело не в либе, а в скиллах и в том, сколько ресурсов заложили на доступность.
Подозреваю, что дело не столько конкретно в винде или в модельке, сколько в том, что модель училась на коде, где управление фокусом вообще редко тестируют скринридером... Вот и воспроизводит те же паттерны, что и в среднем по больнице.
В основном ручками :) Клод дал скелет, а вот три этапа с фокусом, датами вместо индексов и ARIA — это уже мы сами переписывали, опираясь на то, что показывал NVDA/VoiceOver. Иногда кидали в ИИ конкретный баг с трейсом и он предлагал фикс, но финально опять же в обязательном порядке прогоняли через скринридеры.
На момент написания компонента использовался Opus 4.7.
Цель была именно в том, чтобы посмотреть что умеет «голая» моделька без наворотов в специфичных кейсах (как раз инклюзия относится к такому). В целом результат ожидаемый. Гипотезы были такие: 1. Модель обучалась на кодовой базе, где большинство компонентов неинклюзивны (полностью или частично). По моему опыту тема с доступностью стала популярной на границе около ближе к 20-му году. 2. Опыт показывает, что даже если четко следовать гайдлайнам по доступности, то с разным сочетанием браузеров и скринридеров компонент может озвучиваться некорректно или не озвучиваться вообще. Поэтому уверен что Claude Opus 4.8 xhigh тоже не вывезет :)
В черновике указал «Claude» как заглушку, залип в суть и забыл про этот момент... Спасибо что подсветили, поправлю.
А вот идею с автономным циклом, который сам гоняет билд/тесты и не даёт себе проскочить дальше, пока не зелено — уже попробовали отдельно, как раз на DatePicker'е, только через Ralph‑цикл поверх codex cli с верификатором (unit‑тесты, a11y‑тесты, tsc). Как раз на эту тему написал отдельную статью, можете ознакомиться если интересно. В ней в частности сравнили подход с циклом с вайбкодингом "в лоб". Разница в стоимости ощутимая, но и в предсказуемости результата тоже.
Если честно да, руками часто быстрее, особенно если компонент разовый и потом его никто трогать не будет. Весь смысл в статье как раз в этом: настройка под агента дороже на старте, а окупается только когда компонент потом живёт и меняется, а не в моменте первого написания.
Пайпа для генерации доки под каждый компонент нет, AGENTS.md собирали один раз руками, чтобы просто прощупать сам подход — не как конвейер, который штампует такие доки под любую новую задачу.
Тут скорее цель была — посмотреть на полезность инструмента в конкретном специфичном кейсе, не более того.
Отвечу по порядку:
Промпт: полный текст промпта есть в статье. Весь диалог со спецификой под наш кейс по понятным соображениям прикладывать не стал :) Все важные детали в статье описаны.
Примеры: ссылки на код компонента и рабочий результат указаны в статье.
Документация: тут не понял, о чём именно речь. Если речь про ссылку на доку с целевым поведением инклюзивного компонента, то в статье она указана.
Скиллы и субагенты: ИМХО детально настроить модель по времени — около идентично написанию чернового варианта компонента (чего в целом от модели было и нужно). Поэтому цель была использовать «голый» Opus 4.7 и посмотреть, что он умеет. Кстати, вариант с более детальной настройкой модели (с субагентами, но без скиллов) — в следующей статье.
Инструменты для тестирования: Safari + VoiceOver, Chrome и Firefox + NVDA. Про скринридеры в статье также многократно упоминается.
Согласен, не только лишь все) но тут цель была ровно обратная — посмотреть, что «голая» модель без прокачанного скилла выдаёт даже у тех, кто вроде умеет клодкодить. Получилось наглядно :)
Дело не в React как таковом, а в том, что у заказчика вся экосистема была на нём и была построена. Смешивать мух с котлетами было бы странным :)
По поводу инструмента можно много холиварить, но только по факту любым инструментом можно сделать как хорошо, так и криво. React с нормальным вниманием к a11y и React без него — это два разных результата на одном и том же стеке... Дело не в либе, а в скиллах и в том, сколько ресурсов заложили на доступность.
Подозреваю, что дело не столько конкретно в винде или в модельке, сколько в том, что модель училась на коде, где управление фокусом вообще редко тестируют скринридером... Вот и воспроизводит те же паттерны, что и в среднем по больнице.
В основном ручками :)
Клод дал скелет, а вот три этапа с фокусом, датами вместо индексов и ARIA — это уже мы сами переписывали, опираясь на то, что показывал NVDA/VoiceOver. Иногда кидали в ИИ конкретный баг с трейсом и он предлагал фикс, но финально опять же в обязательном порядке прогоняли через скринридеры.
На момент написания компонента использовался Opus 4.7.
Цель была именно в том, чтобы посмотреть что умеет «голая» моделька без наворотов в специфичных кейсах (как раз инклюзия относится к такому). В целом результат ожидаемый. Гипотезы были такие:
1. Модель обучалась на кодовой базе, где большинство компонентов неинклюзивны (полностью или частично). По моему опыту тема с доступностью стала популярной на границе около ближе к 20-му году.
2. Опыт показывает, что даже если четко следовать гайдлайнам по доступности, то с разным сочетанием браузеров и скринридеров компонент может озвучиваться некорректно или не озвучиваться вообще.
Поэтому уверен что Claude Opus 4.8 xhigh тоже не вывезет :)
В черновике указал «Claude» как заглушку, залип в суть и забыл про этот момент... Спасибо что подсветили, поправлю.
А вот идею с автономным циклом, который сам гоняет билд/тесты и не даёт себе проскочить дальше, пока не зелено — уже попробовали отдельно, как раз на DatePicker'е, только через Ralph‑цикл поверх codex cli с верификатором (unit‑тесты, a11y‑тесты, tsc). Как раз на эту тему написал отдельную статью, можете ознакомиться если интересно. В ней в частности сравнили подход с циклом с вайбкодингом "в лоб". Разница в стоимости ощутимая, но и в предсказуемости результата тоже.
Верное замечание, спасибо! Заменил в названии и тексте
Хорошее замечание, спасибо! Речь, конечно, про DatePicker. Заменил ошибки на корректное название