Разработка с ИИ: как поставить задачу и проверить результат

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

Обновлено 8 сентября 2026 года. В материале описан подход к работе; универсальные коэффициенты ускорения и снижения числа ошибок не заявляются.

Сначала — задача и критерии готовности

До написания кода стоит определить пользователя, его действие и ожидаемый результат. Для формы заявки это обязательные поля, способ доставки сообщения, ответ при ошибке и подтверждение успешной отправки. Для CRM — роли сотрудников, статусы и правила изменения данных.

Такую задачу удобнее проверять, чем просьбу «сделать современный сайт». Конкретные критерии помогают выбрать объём первой версии и увидеть, что пока не входит в работу.

Где можно применять ИИ

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

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

Почему генерация кода не завершает работу

В документации GitHub рекомендуется проверять и тестировать код, созданный Copilot. Автоматический ответ или ревью не заменяют проверку поведения приложения.

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

Пример: учёт заявок на mangust.dev

В доработке формы мы разделили открытие окна, клик по контакту и успешную отправку. Событие успешной заявки вызывается после подтверждения принимающего сервиса. Ошибку сети или отказ API проверяем отдельно: они не должны выглядеть в аналитике как принятый запрос.

Это пример проверяемого результата. Можно показать код, условия срабатывания и проверки. Обещание «ИИ уменьшил ошибки на определённый процент» потребовало бы отдельной методики и данных за сопоставимые периоды.

Как обсуждать сроки и стоимость

Срок зависит от состава страниц, интеграций, готовности материалов, ограничений существующей системы и согласований. Ускорение отдельной операции не означает такое же сокращение всего проекта.

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