В 12 прогонах ChatGPT и Claude получили одно неполное ТЗ на интеграцию интернет-магазина со складской WMS и за минуты выдали подробные спецификации. Проблема не в качестве текста: нейросеть в аналитике заполняла пробелы решениями о повторах запросов, дублях и обработке сбоев — хотя такие правила должны согласовываться с бизнесом и логистическим партнёром.
Эксперимент провёл Tech Lead Сергей Прощаев; об этом сообщает Habr / Карьера. Условие было нарочно коротким: магазин отправляет заказы на склад партнёра, а тот возвращает статусы отгрузки и остатки. Две модели тестировали с двумя вариантами запроса: в первом их просили сразу подготовить спецификацию, во втором — сначала перечислить вопросы заказчику и партнёру. Каждый вариант запускали трижды в новых чатах: всего получилось 12 ответов 18 октября 2026 года. ChatGPT на бесплатном тарифе отвечал за полторы-две минуты, Claude Opus 5.5 в режиме High — за шесть-семь.
До запусков автор зафиксировал 14 обязательных тем для аналитика: от возможностей WMS и источника истины по остаткам до идемпотентности, изменения API, мониторинга и владельца ошибок. Затем каждый ответ оценивался по трём вариантам: модель спросила о теме, приняла решение без оговорки или вовсе её пропустила. Такой порядок важен: критерии появились до результатов, а не были собраны задним числом под удачные цитаты.
Модели не стали бездумно выдумывать интерфейс партнёра. Все 12 прогонов уточнили, что именно умеет WMS. Также каждый раз поднимались вопросы об источнике остатков, объёмах, допустимой задержке и отмене заказа. Но самые рискованные расхождения оказались в инженерной части, где правдоподобный шаблон легко принять за согласованное требование.
Например, ChatGPT в варианте без явного требования сначала задавать вопросы ни разу из трёх не уточнил правила идемпотентности, порядок событий и владельца ошибок. Claude во всех трёх таких прогонах самостоятельно задал схему повторов при недоступности WMS: от минуты до часа, затем — каждый час в течение суток. Это разумная заготовка, но не нейтральная. Если запрос к WMS оборвался, магазин не знает, создан ли заказ: одного ключа дедупликации на своей стороне недостаточно, нужен механизм у партнёра или способ проверить результат операции.
Похожая ловушка возникает с поздними событиями и статусами. Правило «не понижать статус» может выглядеть здоровой инженерной практикой, но без согласованной версии состояния или другого механизма оно не гарантирует правильный порядок событий. А срок повторных попыток — это уже не только настройка очереди. От него зависит, сколько заказ может висеть без передачи на склад, когда подключать поддержку и что обещать покупателю. В спецификации, собранной LLM, подобные решения обычно оказываются среди JSON-примеров и таблиц ошибок, а вопросы о них — в финальном разделе, который разработчик может не дочитать.
Явная инструкция «сначала задай вопросы» заметно улучшила картину. У ChatGPT число случаев, когда модель спросила по спорным темам, выросло с 24 до 42 из 42; у Claude — с 32 до 38. Но вместе с этим ChatGPT стал выдавать в среднем 66 вопросов за прогон вместо восьми. Для команды это уже не компактный список неопределённостей, а анкета, которую заказчик и внешний партнёр с высокой вероятностью отложат до лучших времён.
Самым слабым местом оказалось изменение контракта. В девяти прогонах трёх групп вопрос о том, что делать при обновлении API партнёра, прозвучал лишь дважды, а в пяти случаях тема не появилась вовсе. Архитектурная формула про отдельный адаптер полезна, но не отвечает на вопросы о сроке предупреждения, поддержке старой версии и ответственном за коммуникацию. Именно так интеграции часто ломаются не в день запуска, а после безобидного переименования поля в пятницу вечером.
Для команд вывод практичный: нейросеть в аналитике полезна как генератор черновика и каталога вопросов, но не как автор требований по умолчанию. В готовой спецификации стоит отдельно требовать раздел «Допущения» с источником и владельцем каждого решения, а перед передачей в разработку вручную проверять недоступность WMS, дубли, порядок событий, смену контракта и разбор инцидентов. Следующая полезная метрика для таких инструментов — не длина документа и не число разделов, а доля решений, которые команда успела заметить и подтвердить до первого релиза.
