Как превратить первую версию кода в расходный материал
Авторы: Кирилл Гончаров, Сергей Адамов (BusinessPad)Представим ситуацию. Вы настроили ИИ-агента и за две недели собрали с его помощью новый продукт — например, систему согласования заказов. В ней менеджер создает заказ, финансист его проверяет, руководитель согласовывает, после чего запускается доставка. Система работает, и пользователи могут пройти весь процесс от начала до конца. Но вдруг выясняются детали, которые сложно было предусмотреть заранее: оказалось, что перед отправкой заказа руководителю нужна дополнительная проверка, а заказы дороже 100 000 рублей должен подтверждать директор.Вы открываете код, чтобы внести эти изменения, и сталкиваетесь с проблемой. Требование об обязательном согласовании крупных заказов директором прописано сразу в трех местах: в интерфейсе, серверной части и инструкции для ИИ-агента. При этом формулировки отличаются, и непонятно, какая из них правильная. Если поменять лимит в одном месте, остальные продолжат функционировать по-старому: интерфейс не выведет на экран уведомление о согласовании с новым человеком, сервер пропустит крупный заказ без директора, а ИИ-агент будет подсказывать пользователям прежний порядок работы. Чем больше появляется новых требований, тем сложнее понять, где находятся связанные с ними правила, что нужно изменить и не нарушит ли эта правка работу других частей системы.Из этого часто делают вывод, что с помощью вайб-кодинга нельзя строить серьезные продукты. Я предлагаю свежий взгляд — не требовать идеального кода от первой версии продукта, а параллельно с разработкой создавать полное описание сервиса. Далее расскажу, что оно дает, как его составить и где хранить. Читать далее