Нефункциональные требования задают качество работы: агенты проверяют числа вместе с функциями

Функциональное требование описывает действие. Пользователь нажимает «Скачать отчёт» и получает нужные данные. Тест проверяет файл и права доступа.

Нефункциональное требование описывает качество или ограничение. Отчёт должен появляться за согласованное время на рабочем объёме данных и нагрузке.

Демо на пустой базе этого не доказывает. «Быстро» и «под нагрузкой» ещё не дают проверке основания отклонить результат.

Общая постановка задач агенту задаёт результат и границы. Здесь добавляем к конкретной функции проверяемое условие качества.

Порог без сценария оставляет смысл на усмотрение исполнителя. «Страница за две секунды» может означать ответ сервера или готовность формы.

Для появления основного содержимого web.dev рекомендует LCP не более 2,5 с. В эту границу должны укладываться хотя бы 75 % посещений.

Мобильные и настольные посещения считают отдельно. Один быстрый запуск на компьютере инженера не подтверждает качество для остальных.

Для отчёта меряют путь до готового файла. CTO выбирает допустимое ожидание из сценария, инженер предлагает замер. Порог LCP сюда не переносится.

Проверку поручают агенту вместе с функцией. Он готовит сценарий и данные, инженер сверяет метрику. Отказ проверки включают в условия выпуска.

В примере k6 95 % запросов должны завершаться быстрее 200 мс, а доля HTTP-ошибок должна быть меньше 1 %. Это учебный пример вендора, не норматив.

При нарушении порога k6 возвращает ненулевой код завершения. Конвейер должен учитывать этот отказ: красный значок в отчёте выпуск не остановит.

Согласованный порог защищают правила для ИИ-агентов. Исполнитель не может ослабить условие, чтобы сделать проверку зелёной.

На vibecoding.ru инженер ведёт машину агентов и принимает её работу. Своего клиентского кейса по этим требованиям у нас нет.

Наш публичный контур качества показывает устройство проверок выпуска. Истории ниже объясняют, как уточнялось условие приёмки.

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

Для размера сборки полезны оба слоя защиты. Ранний запрет опасного чтения файлов ловит причину, измерение готового пакета проверяет результат.

На /open описаны 2 685 тестов на каждом пуше плюс ревью, срез 8 октября 2026 года. Это число проверок выпуска, не доказательство любого требования качества.

Зелёный значок имеет смысл вместе с условиями прогона. Отчёт должен показывать фактическую нагрузку, объём данных и среду для той же версии кода.

Пустой прогон или меньшая тестовая база не подтверждают рабочий сценарий. Успех после прогрева кэша не заменяет проверку согласованного холодного старта.

Результат принимают отдельно от уверенности автора правки. Последствия выпуска разбираем в статье про ответственность за ошибки ИИ.

Приёмка заканчивает задачу, но не наблюдение за системой. Нагрузка вырастет, данных станет больше, зависимость начнёт отвечать иначе.

Быстрые ограничения проверяют с каждой правкой. Нагрузочный прогон повторяют в согласованные моменты, рабочий сценарий наблюдают после выпуска.

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

В уроке «Одиннадцать шагов одной задачи» нашего курса сдача встроена в порядок работы агентов. К передаче задачи добавляется след измерения.

В разработке по подписке «Один проект» стоит 250 000 ₽ в месяц, по странице на 8 октября 2026 года. Требования качества обсуждают для конкретной задачи.

Измеримые требования можно включить в задачи. Агенты под управлением инженера подготовят проверки, инженер сверит их с согласованными условиями.

На /services ночные дежурства исключены из подписки. Приёмка скорости ответа не означает обязательства круглосуточно устранять любой сбой.

Если осталось «должно работать быстро», полезно разобрать приёмку проекта. Порог и условия должны быть понятны обеим сторонам до работы.