Обсуждая ее с коллегами по цеху и просто неравнодушными к сфере программирования и ведения бизнеса — поймал вопрос, ответом на который я решил поделиться
«Как в таких подходах выглядит проектирование на уровне бизнеса и функциональности?»
В статье упоминается PRD — Product Requirement Document. Обычно он содержит:
• цель продукта или конкретной фичи
• персонажи (user perёsonas)
• user stories и use cases
• бизнес-метрики и KPI
• обязательные и желательные требования
• экраны, мокапы, диаграммы
То есть вполне классический артефакт, который связывает бизнес и разработку
В vibe-кодинг лично я все еще верю слабо, будто нас пытаются снова откатить от ООП к функциональному программированию.
В статье сами авторы упоминают две основные проблемы этой истории:
1. Один и тот же запрос к ИИ может дать разные результаты
2. Проверка результатов ИИ может занять больше времени, чем экономия на разработке
Коллега Вадим Митякин метко подметил:
Они открыли проблему, а не выход из положения. Они просто уперлись в ограничения вайбкодинга и думают, вот сейчас рванут. В тексте путают разработчика, инженера и архитектора и проблема простая, что языков для инженера и архитектора в ИТ нет. А все что есть это кривые наброски выраженного прикладного опыта с попытками прикрутить туда системный подход, и такая архитектура становится просто инженерными системными требованиями, а не архитектурой.
Это и есть фундаментальная развилка: vibe coding не решает задачу проектирования, он только меняет точку входа в систему. Но системного языка для архитектора по-прежнему нет.
И добавлю от себя: использование ИИ в vibe coding создаёт когнитивную перегрузку. Объём идей и вариантов огромный, а чтобы это переварить, нужно ещё больше времени и компетенции. Без понимания результата — это не работа, а рулетка и я абсолютно солидарен с Вадимом в этом мнении. Сегодня — блестящий агент, завтра — идиот.