EnglishРусский Map

Культ vibe coding - это безумие

title
Культ vibe coding - это безумие
type
summary
summary
Брэм Коэн о том, почему отказ читать код от ИИ превращает dogfooding в культ, и о своём цикле аудит-обсуждение-исполнение
tags
ai-agents, software-quality, vibe-coding
created
2026-04-07
updated
2026-07-29
lang
ru
translation_of
cult-of-vibe-coding
source_updated
2026-07-29
translated
2026-09-01
translator
lllm/antigravity/gemini-3.7-flash-medium

Брэм Коэн (создатель BitTorrent) утверждает, что "vibe coding" - намеренный отказ заглядывать в сгенерированный ИИ код - это dogfooding, доведённый до уровня культа. Поводом послужила утечка исходного кода Claude Code от Anthropic, который оказался полон дублирования и избыточности. По мнению Коэна, команда попросту считала чтение собственной кодовой базы жульничеством.

Чистый vibe coding - это миф

Коэн отмечает: даже самые убеждённые приверженцы vibe coding всё равно вносят человеческий вклад. Они направляют ИИ человеческим языком. Они выстраивают инфраструктуру: файлы планов, навыки, правила, каркасы фреймворков. Без этой структуры машина работает плохо. Заявление о том, что "под капотом нет никакого человеческого участия", разбивается о реальность.

В утёкшей кодовой базе Claude одни и те же вещи были реализованы и как агенты, и как инструменты - очевидное дублирование, которое заметил бы любой, кто прочитал бы код. Но читать код было нельзя по правилам. Полагалось вести лишь "туманные беседы с машиной о том, чем она занята".

Как на самом деле эффективно использовать ИИ

Коэн описывает свой ежедневный рабочий процесс, и он бесконечно далёк от подхода "руки прочь". Шаблон состоит из трёх фаз:

Фаза 1: Аудит и наблюдения. Смотрите в код. Реально читайте его. Начинайте диалог с конкретных наблюдений: "Давай проверим кодовую базу на недостижимый код". "От этой функции у меня кровь из глаз". ИИ плохо замечает беспорядок сам по себе. Он не скажет вам: "Эй, тут спагетти-код, давай я приберусь". Но если ткнуть его в бардак носом, он отлично наведёт порядок.

Фаза 2: Обсуждение до полного взаимопонимания. Используйте режим Ask (или аналоги), чтобы разобрать примеры, объяснить логику и - что критически важно - поправлять ИИ, когда он угоднически соглашается с ошибками. Именно здесь происходит основная работа. Вы не пишете код, но берёте на себя всю интеллектуальную нагрузку: разбираете пограничные случаи, формулируете правила, принимаете решения о том, что и куда должно относиться.

Коэн приводит конкретный пример из утечки Claude: "Здесь полно вещей, реализованных одновременно и как агенты, и как инструменты. Давай пройдёмся по ним, составим полный список, посмотрим на примеры, а я скажу, что должно быть агентами, а что - инструментами. Мы обсудим это и выработаем общие правила. Затем проверим весь список, разложим по категориям, перенесём то, что оказалось не в том типе, а для того, что есть в обоих видах, вычитаем обе версии и объединим в один документ, взяв лучшее из каждой".

Фаза 3: Исполнение. После достаточного количества итераций - когда новые мысли у вас закончились, а ИИ перестал выдавать глупости, - поручите ему составить план и написать код. На этом этапе он "летит вперёд", потому что все странные пограничные случаи уже разобраны. Со стороны кажется, будто всё сделано с одной попытки (one-shot). Но это не так: основную работу забрала подготовка.

Коэн считает, что такой процесс вполне укладывается в дух vibe coding. Вы читаете код, но даёте исключительно "высокоуровневые, концептуальные, абстрактные идеи о том, как решать задачи". Весь текст кода пишет исключительно машина.

Плохой софт - это осознанный выбор

Главный тезис Коэна: ИИ не порождает плохой софт. Плохой софт порождает отказ от дисциплины и строгости. Так было и до ИИ: "Всю прошлую неделю я орал на монитор, разбираясь с библиотекой, которую написали переоценённые мешки с костями вообще без помощи ИИ".

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

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

Как это связано с другими темами

Паттерн "аудит - обсуждение - исполнение" по сути представляет собой human-in-the-loop, применённый к качеству кода, а не к безопасности. Человек не подтверждает каждое отдельное действие: он задаёт направление и критерии, а затем отдаёт исполнение ИИ на откуп в масштабе.

Наблюдение Коэна о том, что ИИ "очень плохо замечает спагетти-код сам по себе", перекликается с логикой byzantine-fault: ИИ не станет помечать собственный результат как ошибочный. Чтобы выявить отклонение от стандартов качества, нужен внешний валидатор - человек, читающий код.

Мысль о том, что качество софта остаётся решением человека независимо от инструментов, связана с individual-engineer-agency - разрывом между тем, на что способен повлиять отдельный инженер, и системным результатом.

Брайан Кантрилл в "The Peril of Laziness Lost" формулирует ту же мысль философски: цикл Коэна "аудит - обсуждение - исполнение" - это ровно та "добродетельная лень", которая рождает чёткие абстракции, то есть сложная предварительная мыслительная работа, которую LLM пропускают.

Теоретический анализ Джеймса Беннетта приходит к тому же выводу с другой стороны: узкое горлышко разработки - не скорость генерации кода, а сущностная сложность (спецификация, проектирование, тестирование концептуальных конструкций), и инструменты, ускоряющие лишь написание кода, упираются в арифметику Брукса. Пример Коэна с утечкой Claude Code также занимает центральное место в аргументации Беннетта.

agentic-coding-fatigue смотрит на это с операционной точки зрения: даже если заставлять себя читать каждую строчку сгенерированного кода, дневной лимит супервизора составляет около половины обычного рабочего дня. Цикл аудита, обсуждения и исполнения у Коэна верен, но 0xsid подчёркивает: крутить его можно лишь ограниченное число часов в день, пока не притупится критическое мышление.

Острее всего полемика выражена с vibe-engineering (claude-is-not-a-compiler): там принимается тезис Коэна о том, что решения по качеству остаются за человеком, но фаза аудита как способ этого добиться отвергается - человек принимает решения на всех уровнях, почти не заглядывая в код, а чтение заменяется поиском расхождений между независимо созданными реализациями (differential-spec-analysis). Утверждение Коэна о том, что "ИИ очень плохо замечает спагетти-код сам по себе", - это ровно то, против чего играет данный метод, опрашивая нескольких агентов вместо одного.

how-do-we-stop-vibe-coding исходит из того же диагноза, но предлагает обратное решение. Клос согласен, что ментальная модель кодовой базы деградирует, а эссе с планом агента скрывает грядущие изменения, однако считает чтение кода неверным лекарством. Его ответ - вынести архитектуру в отдельную структуру, которую можно автоматически проверять по коду, чтобы аудит происходил без необходимости открывать файлы вручную.

agentic-coding-is-a-trap добавляет структурный взгляд: сама роль супервизора держится на навыках, которые размываются в процессе надзора за агентом - skill-atrophy-supervision-paradox. Предложенный Коэном цикл - одна из немногих защитных мер, сохраняющих нужные навыки, поскольку на этапе аудита человек продолжает читать код, а не просто одобрять его.