AI / качество
AI написал интерфейс: что обязан проверить человек
Правдоподобный интерфейс может быть небезопасным, недоступным и хрупким. Финальная проверка — не недоверие к AI, а нормальная инженерная ответственность.
Сначала поведение
Пройдите сценарий как пользователь: мышью, клавиатурой, на узком экране и с медленной сетью. Проверьте повторную отправку формы, пустые данные, длинные имена, ошибку API и возврат назад. AI часто реализует счастливый путь и оставляет края неявными.
Смотрите не только на результат, но и на источник состояния. Дублирование server state в локальном state, эффекты для вычисляемых значений и нестабильные ключи могут не проявиться на демонстрации, но ломают приложение под нагрузкой.
Безопасность и зависимости
Особое внимание требуют innerHTML, URL-параметры, markdown, postMessage, localStorage и любые данные пользователя. Неэкранированная строка в HTML sink создаёт риск DOM XSS. Для сложного HTML нужны проверенная sanitization-политика, CSP и, где применимо, Trusted Types.
Каждая новая зависимость должна существовать, быть поддерживаемой и действительно необходимой. Проверяйте lockfile, advisory database и лицензию. AI способен предложить пакет с похожим названием или добавить крупную библиотеку ради функции в десять строк.
Accessibility не проверяется скриншотом
Нужны семантические элементы, доступные имена, правильный порядок заголовков, заметный focus, достаточный контраст и управление клавиатурой. Автоматический scanner найдёт часть проблем, но W3C подчёркивает: ни один инструмент не способен самостоятельно подтвердить полное соответствие требованиям доступности.
Проверьте хотя бы форму без мыши и послушайте ключевой сценарий через screen reader. Модальное окно должно удерживать фокус, ошибки — связываться с полями, а динамические сообщения — объявляться корректно.
Производительность и итоговый diff
Проверьте размер bundle, количество запросов, шрифты, изображения и работу на слабом устройстве. Типичная AI-ошибка — добавить библиотеку, анимацию или client-side rendering без измеримой пользы. Сравнивайте показатели до и после, а не верьте оптимистичному описанию.
Наконец, прочитайте diff целиком. Там не должно быть случайного форматирования всего проекта, отключённых правил линтера, секретов, закомментированных обходов и правок конфигурации, которые не относятся к задаче. Маленький понятный diff остаётся лучшей формой контроля.