Я такого рода статьи называю «байт-статьями»: берётся громкая и актуальная тема, вокруг неё создаётся конфликт, а затем на протяжении нескольких экранов доказывается очевидное.
Пока вы рассказываете, насколько опасен vibe coding, индустрия использует LLM ровно там, где они дают максимальный экономический эффект: быстро собрать MVP, проверить гипотезу, получить первые данные от пользователей и понять, стоит ли вообще инвестировать месяцы разработки в продукт.
И самое интересное - автор статьи в итоге сам с этим соглашается: vibe coding хорош для прототипов и проверки продуктовых гипотез. То есть спор в значительной степени создаётся искусственно.
Главная подмена здесь в другом. Проблема «человек не понимает архитектуру, безопасность, авторизацию, БД и эксплуатацию, но выкатывает код в production» существовала задолго до Cursor, Claude и ChatGPT. До LLM точно так же существовали джуны, copy-paste development, Stack Overflow driven development, кривые WordPress-плагины, подрядчики за три копейки и проекты без тестов, мониторинга и backup strategy.
LLM эту проблему не создала. Она лишь увеличила скорость, с которой человек способен как писать хороший код, так и совершать ошибки.
Поэтому противопоставление «vibe coding против настоящей инженерии» выглядит странно. Это вообще разные оси. Можно написать ужасный production вручную, а можно с помощью LLM построить вполне нормальную систему, если решения принимает человек, который понимает архитектуру, security, данные и эксплуатацию.
Более того, утверждение о том, что быстро созданный MVP якобы потом обязательно превращается в дорогостоящую проблему, тоже слишком категорично. Цель MVP зачастую вообще не в том, чтобы стать фундаментом системы на следующие десять лет. Его задача -максимально дёшево ответить на вопрос: «Это кому-нибудь нужно?»
Если гипотеза умерла - отлично, вы потеряли неделю, а не шесть месяцев работы команды.
Если гипотеза подтвердилась - дальше уже принимается инженерное решение: что оставить, что переписать, где провести аудит, где добавить тестирование, observability, security review и нормальную инфраструктуру.
И это может оказаться значительно дешевле, чем сначала полгода строить «правильную production-архитектуру», а потом обнаружить, что продукт никому не нужен.
Ну и отдельный штрих: примерно с середины статьи внезапно выясняется, что авторская компания как раз умеет делать всё то, чего якобы не хватает несчастному vibe coder'у: 10+ лет опыта, full cycle, security review, DevOps, аудит и прочий полный набор.
Совпадение? не думаю.
Само по себе наличие рекламы не делает аргументы ложными. Но когда сначала долго объясняют, насколько опасно делать продукт без «взрослой инженерии», а затем оказывается, что эту самую «взрослую инженерию» тебе готовы продать, статья начинает восприниматься уже немного иначе.
Поэтому реальная формула намного скучнее заголовка:
LLM не отменяет инженерную компетентность. Но инженерная компетентность совершенно не требует отказаться от LLM.
А «не отдавайте production человеку, который не понимает, что делает» - это хороший совет. Просто к vibe coding он имеет гораздо меньше отношения, чем пытается показать статья.
Я такого рода статьи называю «байт-статьями»: берётся громкая и актуальная тема, вокруг неё создаётся конфликт, а затем на протяжении нескольких экранов доказывается очевидное.
Пока вы рассказываете, насколько опасен vibe coding, индустрия использует LLM ровно там, где они дают максимальный экономический эффект: быстро собрать MVP, проверить гипотезу, получить первые данные от пользователей и понять, стоит ли вообще инвестировать месяцы разработки в продукт.
И самое интересное - автор статьи в итоге сам с этим соглашается: vibe coding хорош для прототипов и проверки продуктовых гипотез. То есть спор в значительной степени создаётся искусственно.
Главная подмена здесь в другом. Проблема «человек не понимает архитектуру, безопасность, авторизацию, БД и эксплуатацию, но выкатывает код в production» существовала задолго до Cursor, Claude и ChatGPT. До LLM точно так же существовали джуны, copy-paste development, Stack Overflow driven development, кривые WordPress-плагины, подрядчики за три копейки и проекты без тестов, мониторинга и backup strategy.
LLM эту проблему не создала. Она лишь увеличила скорость, с которой человек способен как писать хороший код, так и совершать ошибки.
Поэтому противопоставление «vibe coding против настоящей инженерии» выглядит странно. Это вообще разные оси. Можно написать ужасный production вручную, а можно с помощью LLM построить вполне нормальную систему, если решения принимает человек, который понимает архитектуру, security, данные и эксплуатацию.
Более того, утверждение о том, что быстро созданный MVP якобы потом обязательно превращается в дорогостоящую проблему, тоже слишком категорично. Цель MVP зачастую вообще не в том, чтобы стать фундаментом системы на следующие десять лет. Его задача -максимально дёшево ответить на вопрос: «Это кому-нибудь нужно?»
Если гипотеза умерла - отлично, вы потеряли неделю, а не шесть месяцев работы команды.
Если гипотеза подтвердилась - дальше уже принимается инженерное решение: что оставить, что переписать, где провести аудит, где добавить тестирование, observability, security review и нормальную инфраструктуру.
И это может оказаться значительно дешевле, чем сначала полгода строить «правильную production-архитектуру», а потом обнаружить, что продукт никому не нужен.
Ну и отдельный штрих: примерно с середины статьи внезапно выясняется, что авторская компания как раз умеет делать всё то, чего якобы не хватает несчастному vibe coder'у: 10+ лет опыта, full cycle, security review, DevOps, аудит и прочий полный набор.
Совпадение? не думаю.
Само по себе наличие рекламы не делает аргументы ложными. Но когда сначала долго объясняют, насколько опасно делать продукт без «взрослой инженерии», а затем оказывается, что эту самую «взрослую инженерию» тебе готовы продать, статья начинает восприниматься уже немного иначе.
Поэтому реальная формула намного скучнее заголовка:
LLM не отменяет инженерную компетентность. Но инженерная компетентность совершенно не требует отказаться от LLM.
А «не отдавайте production человеку, который не понимает, что делает» - это хороший совет. Просто к vibe coding он имеет гораздо меньше отношения, чем пытается показать статья.