Подрядчик использует ИИ при доработке продукта: что согласовать до старта
Руководитель сервиса просит изменить уведомление о переносе записи. Клиент должен сразу видеть новое время. Подрядчик планирует подготовить доработку с помощью ИИ. Но уведомление может быть связано с расписанием исполнителя, отменой записи и сообщением оператору. Команде нужно объяснить эти связи инструменту и самой принять решение о результате.
Сценарий условный. Он помогает разобрать дополнительную подготовку именно при использовании ИИ: какие сведения передать, какие исключения отметить и кто остановит работу при недостатке данных.
ИИ получает фрагмент задачи. Команда отвечает за целую систему
Разработчик, давно работающий с продуктом, может помнить, что перенос записи влияет на календарь исполнителя и очередь поддержки. ИИ-помощник узнаёт это только из доступных ему файлов, описания, примеров и инструкций. Команда решает, какие сведения относятся к изменению, актуальны ли они и что инструменту разрешено менять.
Перед получением полезного предложения нужно собрать контекст из действующего поведения сервиса, правил бизнеса, кода, ограничений интеграций и уже принятых решений. Затем проверить согласованность сведений. Устаревшая инструкция способна направить работу в неверную сторону.
В исследовании 2025 года Jiang и Nam рассмотрели файлы правил в 401 открытом репозитории. Авторы обнаружили сведения о проектах, соглашения команды, инструкции и примеры. Работа описывает содержание этих файлов; она не измеряет улучшение результата после их добавления.
Авторы CAFE(S) предлагают оценивать контекст по ясности, выполнимости, соответствию реальному проекту, отсутствию лишнего и безопасности. Это концептуальная рамка 2026 года, а не эксперимент о сроках. Для заказчика её смысл в вопросе: из каких проверенных сведений команда собрала задачу для ИИ и кто заметит пробел?
Передать весь проект инструменту недостаточно
В задаче «отправить новое время клиенту» нет ответа на вопросы об уже отправленном подтверждении, занятом слоте исполнителя и ручном переносе оператором. Часть правил может жить в коде, часть — в настройках сервиса, часть — в рабочей процедуре поддержки. Инструмент способен предложить правдоподобное изменение на основе неполной картины.
Команда описывает участок работы: когда запись считается перенесённой, кто запускает перенос, где хранится новое время, какие уведомления действуют при исключениях. Эти ответы нужны и обычному разработчику. При работе с ИИ добавляется отдельный шаг: выбрать проверенные сведения для инструмента, отметить неизвестное и не позволить предположению стать правилом продукта.
Границы одной доработки можно закрепить четырьмя пунктами:
Контекст: в каких случаях меняется запись и какие операции затрагивает уведомление.
Граница: какие сообщения и статусы можно менять, а какие операции должны сохранить прежнее поведение.
Ответственный: кто уточняет противоречивое правило и принимает решение.
Признак готовности: какие сценарии должен пройти клиент, исполнитель и оператор.
Заказчик подтверждает деловые правила, включая исключения. Подрядчик превращает их в задание, ограничивает доступ инструмента и проверяет результат в продукте. У Qtim есть услуга развития действующего продукта; описание услуги не доказывает применение ИИ командой.
Что происходит, когда контекста не хватает
Команда может остановиться до изменения кода. Допустим, оператор переносит запись вручную, но сервис не фиксирует причину. Инструмент не должен придумывать правило уведомления по соседним файлам. Команда уточняет у владельца процесса, требуется ли сообщать причину клиенту, и продолжает после ответа.
ИИ способен подготовить несколько вариантов реализации, пока спорное бизнес-правило остаётся без ответа. Позднее технически собранное уведомление может противоречить реальной процедуре. Команде нужно отделить подтверждённые условия от догадок ещё до проверки кода.
Не каждая деталь продукта должна попасть в запрос или доступ инструмента. В CAFE(S) безопасность названа одной из характеристик контекста. Конкретный режим работы с данными зависит от продукта и выбранного инструмента. Ответственного за доступ определяют до старта.
Автор результата остаётся в команде
Заказчик ожидает согласованный результат: перенос отражается в нужных сценариях, соседние операции работают, изменение можно сопровождать. Команда проверяет предложенное решение, объясняет его уместность для продукта и выпускает по своему процессу. Детальная техника проверки кода — отдельный вопрос; здесь важна ответственность за решение с участием инструмента.
Исследователи IBM в 2025 году опросили две группы разработчиков компании, всего 669 человек, и провели 15 пользовательских тестов. Они обсуждают владение и ответственность за сгенерированный код. Самоотчёты сотрудников IBM не устанавливают условия другого проекта.
Рецензируемый эксперимент, опубликованный в 2026 году, не выявил систематической разницы в последующей доработке кода, созданного с ИИ и без него, в пределах своих заданий. Участники работали с одной Java-системой в конце 2024 года. Этот результат не делает любой AI-код плохим или безопасным. Способ создания кода не заменяет приёмку конкретного изменения.
Почему обещание скорости не превращается в скидку
В трёх полевых экспериментах Microsoft Research 2025 года доступ к помощнику сопровождался ростом числа завершённых задач. В первом исследовании METR опытные участники выполняли задачи на знакомых открытых проектах дольше с ИИ. Позднее METR сообщил о проблемах с интерпретацией новой оценки из-за отбора участников и задач.
Работы измеряли разные инструменты, среды и показатели. Ни одна не рассчитывает срок или стоимость доработки условного сервиса. В оценке заказа остаются понимание действующих правил, подготовка контекста, проверка результата и выпуск. Генерация фрагмента кода составляет лишь часть этой работы.
Что остаётся у заказчика после разговора об ИИ
Для изменения уведомления команда и заказчик согласуют один участок: когда перенос завершён, какие сообщения меняются, кто разрешает спорные случаи и по каким сценариям принимают результат. После этого команда выбирает инструмент. При обратном порядке ИИ вынужден работать с вопросами, на которые никто не ответил.
Правило для заказчика: обсуждать способ работы после того, как команда назвала проверенный контекст изменения, границы для ИИ и человека, ответственного за итог. Применение ИИ не снимает с подрядчика ответственность за выпущенную доработку.
Конкретный участок и его ограничения можно обсудить с командой Qtim до оценки реализации.
