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

В одном из прошлых постов я рассказывал про сервис подбора редукторов и приводов для запорной арматуры.

Недавно у этого кейса появилось продолжение. Заказчик попросил добавить в подбор новый тип продукции - переходники между разными типами присоединения. Для сервиса это означало возможность подобрать редуктор через переходник, если прямого подходящего исполнения нет. Заказчик показал таблицу переходников и обозначил основной тип присоединения редукторов, на который нужно ориентироваться при подборе переходника.

Из объяснения я понял, что для рассматриваемых редукторов в подборе нужно использовать именно основные типы присоединения, а остальные варианты в новой логике не учитывать. На уточняющий вопрос: “В подборе используем только основные типы присоединения?” - получил подтверждение.

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

На основании этого я реализовал новую логику и отправил результат.

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

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

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

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

Здесь же заказчик быстро получил рабочую реализацию, увидел её на практике, уточнил требование - и в тот же день получил исправленный вариант.

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