ПостОшибка, которую одобрили все

Ошибка, которую одобрили все Интересную ситуацию сегодня анализировал. Есть продукт, где LLM интегрирована практически в каждый этап пайплайна. Сегодня обнаружилась занятная история: — на этапе разработки допустили ошибку — на QA эту ошибку покрыли автотестом как правильное поведение — code review с LLM тоже ничего не нашёл — в итоге весь пайплайн успешно прошёл, а LLM на каждом этапе при наличии спеки провалидировала результат и пропустила дальше Я начал раскручивать цепочку назад, чтобы понять, где именно появилась ошибка. И в итоге дошёл до самого начала — ТЗ. Изначальная задача была про обработку заказов. Заказы приходят из внешнего мира через шину, мы их сохраняем и маппим под структуру нашего сервиса. Никакой классификации заказов в первоначальном ТЗ не было. Задачу сделали, написали тесты, всё работает. Через некоторое время прилетает маленькая задача со скудным ТЗ: забыли учесть, что через ту же шину приходят ещё и возвраты, поэтому у товарных позиций возврата нужно проставлять соответствующий статус. И вот здесь начинается самое интересное. Из контекста предметной области довольно логично следует, что возврат — это не просто другой статус товарной позиции. Нужно ещё разобраться с тем, что сейчас на продажу и возврат создаются отдельные заказы. Но в ТЗ этого нет. Разработчик увидел простую задачу и практически полностью делегировал её LLM. А LLM сделала ровно то, что попросили: проставила статус. Code review с LLM прошло — противоречий ТЗ нет. QA написал автотесты — и они тоже проверяют ровно то поведение, которое описано в ТЗ. В итоге получился прекрасный комбайн, где каждый этап что-то валидирует, всё зелёное, все довольны — а система делает неправильную вещь 😁 И самое интересное: рой агентов здесь, скорее всего, тоже ничего бы не изменил. Можно поставить одного агента писать код, второго — тесты, третьего — ревьюить, четвёртого — проверять соответствие спеке. Они могут идеально проверить друг друга и коллективно приехать ровно туда, куда их отправила неправильная или неполная постановка. Можно делегировать написание кода, автотестов, ревью, приведение ТЗ к единой структуре и ещё кучу механической работы. Но нельзя ментально выйти из процесса. Кто-то всё равно должен понимать контекст на каждом этапе и проверять не только «соответствует ли результат ТЗ», но и задаваться вопросом: а правильную ли проблему мы вообще сейчас решаем? И после таких историй я ещё меньше понимаю рассказы в духе: «сижу PM/CTO, запустил рой агентов, они там сами разработали продукт, а я иногда смотрю на результат». Без человека, который действительно погружён в контекст, такой рой может оказаться просто очень эффективным способом быстро и качественно сделать не то 😁 В общем, интересный сегодня был анализ. А ещё я был на созвоне в кафешке, после созвона оставил наушники на столе и спокойно ушёл. Потом тоже анализировал свою беспечность и пытался найти, на каком этапе пайплайна произошла ошибка. Но тут, в отличие от истории выше, root cause так и не нашёл))