Alpesh Pawar: нужны не новые AI-функции, а лучшее продуктовое мышление

Alpesh Pawar опубликовал это эссе в издании CodeToDeploy на Medium в мае 2026 года. Центральный тезис знаком каждому, кто просматривал бэклог, полный запросов на AI-функции: новизна — не постановка задачи. Команды, начинающие с логики «AI умеет X, значит давайте добавим X», как правило, создают то, что хорошо работает в демо, но ломается в продакшене, — обычно потому, что никто не назвал, какое трение должна устранять функция, для какого конкретного пользователя и при каких условиях.

В статье рассматривается типичный сбой, который стал более распространённым по мере удешевления AI-инструментов: скорость создания AI-функций обгоняет способность пользователей им доверять. Когда функция выдаёт непостоянные или непредсказуемые результаты — а LLM-функции часто именно так и работают — пользователям нужны чёткие модели понимания того, когда она работает, а когда нет. Если продуктовая команда не встроила эти защитные механизмы в дизайн, пользователи либо избегают функцию, либо винят продукт, когда она даёт сбой.

Паруар предлагает фильтр из четырёх шагов для оценки до начала разработки. Во-первых, переформулировать запрос на функцию как пользовательскую проблему — если не получается, функция не готова к спецификации. Во-вторых, рассмотреть, решит ли ту же проблему правило-ориентированная система или более простой UI: если да, накладные расходы на LLM могут быть неоправданны. В-третьих, заранее определить режимы сбоя: когда модель выдаёт неверный ответ, понимает ли это пользователь и может ли исправить ситуацию? В-четвёртых, установить критерии успеха через пользовательские результаты, а не точность модели.

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

Паруар пишет с позиции full-stack-разработчика, поэтому статья наиболее полезна для PM, тесно работающих с инженерными командами и нуждающихся в общем словаре для оценки реализуемости AI-функций. Это не стратегическая дорожная карта высокого уровня, а фильтр качества для отдельных решений по функциям — полезное дополнение к capability-first продуктовому мышлению.