ИИ ускоряет разработку. Что это меняет для бизнеса?

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

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

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

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

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

Так выглядит возможное ускорение: меньше времени на подготовку подходящего кода и повторяющихся проверок. Оно не гарантировано для каждой задачи. Если модель предложила несовместимое решение, не учла устройство проекта или внесла лишние изменения, время на разбор и исправления может съесть выигрыш.

Поэтому полезный промежуточный результат — функция, прошедшая проверку, а не количество созданных файлов. На обсуждении этапа команда может показать, какие части уже работают, что удалось сделать быстрее и что ещё мешает завершить задачу.

Запрос «сделайте оформление дилерского заказа» оставляет много неопределённости. У одного клиента действует договорная цена, у другого — скидка на группу товаров. Некоторым разрешена отсрочка платежа. Для заказа с просроченной задолженностью может требоваться решение менеджера.

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

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

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

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

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

Есть и другая причина задержек: команда ждёт ответа, считать ли заказ принятым до подтверждения из 1С. Дополнительная генерация кода этот вопрос не решает. Нужны согласованное правило и понятный статус для покупателя.

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

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

Практический вопрос на встрече звучит так: «Что сейчас определяет дату запуска — оставшаяся реализация, исправления, проверка обмена или решение с нашей стороны?» Ответ показывает, куда направить усилия, чтобы выигрыш от ИИ дошёл до работающей функции.

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

Если модель решила запрещать заказ при любом неоплаченном счёте, она может написать тест, который подтверждает именно такой запрет. Тест пройдёт. Ошибку обнаружит сценарий дилера с действующей отсрочкой, если ожидаемый результат взят из правил компании. Поэтому основу проверки составляют согласованные требования, а не только поведение уже написанной программы. GitHub также указывает на необходимость проверки результатов работы ИИ-агентов.

Для нашего заказа команда и заказчик заранее определяют несколько сценариев:

Это примеры требований к конкретному проекту, а не готовые настройки любой конфигурации 1С. Способ реализации и технические проверки определяет команда.

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

В план этапа входит время на этот цикл. Это не обещание отсутствия любых будущих ошибок: для обнаруженных замечаний и сопровождения отдельно определяют порядок работы. Но выявленное несоответствие исходной задаче нужно довести до решения в рамках согласованных обязательств, а не просто перенести за дату сдачи.

Может стать дешевле, если ИИ сокращает общее время работы над задачей — вместе с проверкой и исправлениями. Быстро написать код недостаточно: если потом его долго переделывают, экономии может не быть.

Например, команда оценила создание формы заказа и её проверку в 30 часов. С ИИ справилась за 20 часов, выполнив те же требования. При оплате фактически затраченного времени и одинаковой ставке заказчик заплатит меньше. При заранее согласованной фиксированной цене сумма останется прежней, если стороны не договорились иначе. Возможное ускорение стоит обсуждать ещё при расчёте предложения.

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

Перед согласованием сметы задайте три вопроса:

• Что именно вы сделаете быстрее с ИИ и учтено ли это в цене или сроке?
• Входит ли в цену тестирование формы заказа и исправление ошибок — например, если заказ не отправляется или в 1С попадают неверные цены и количество?
• Если бюджет вырос, какие конкретно работы добавились и зачем они нужны?

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

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