Вавилонская башня вайб-кодинга: общий язык разработчиков исчезает, а стройка продолжается

Автор эссе замечает, что часть программ, написанных методом вайб-кодинга, меняется отчасти случайным и неожиданным образом, это напомнило ему картину Брейгеля «Вавилонская башня» с её нарочито хаотичной стройкой. Библейскую историю обычно читают как притчу о гордыне и о том, почему люди перестали понимать друг друга. Но, по мнению автора, это в той же мере история о единстве, которое делает возможным технический прогресс.

В библейском тексте строители сначала осваивают технологию, «наделаем кирпичей и обожжём огнём… и стали у них кирпичи вместо камней, а земляная смола вместо извести», а затем берутся за цивилизационный проект: «построим себе город и башню, высотою до небес». Но когда Господь оценивает происходящее, его тревожат не кирпичи: «один народ, и один у всех язык… и не отстанут они от того, что задумали делать». Источник силы строителей, координация: общий язык позволяет им объединить труд в то, что ни один из них не построил бы в одиночку. Бог не отнимает у людей кирпичи или знание о том, как их делать, он отнимает способность понимать друг друга, и стройка останавливается.

Автор переносит эту метафору на разработку программного обеспечения. Идея о том, что ИИ-инструменты позволяют писать более амбициозный код, верна на уровне отдельного человека: с агентом разработчик становится значительно продуктивнее. Но крупные программные проекты никогда не упирались только в скорость, с которой один человек пишет код, они упираются в то, насколько хорошо люди согласовывают своё понимание системы. «Общий язык» программного проекта, это не английский и не Python, а разделяемое понимание того, что означают его концепции, где проходят границы, какие инварианты важны, кто чем владеет и почему система устроена именно так. Это знание редко записано в одном месте: оно живёт в документации и коде, но также в код-ревью, разговорах, спорах и в самом опыте объяснения своих изменений другому человеку.

До появления агентов это общее понимание поддерживалось трением: чтобы изменить чужой слой хранения данных, разработчику обычно приходилось читать чужой код, задавать вопросы и согласовывать изменения с другой командой. Это было медленно, и часть этой медлительности была потерей времени впустую, но не вся: часть трения была именно механизмом, через который понимание одного человека становилось пониманием другого, а оба заодно проверяли, совпадают ли их представления о системе.

Агенты убирают большую часть этого трения. Один человек может попросить агента добавить OAuth, другой, кеширование, третий, переписать базу данных с нуля и заодно перекрасить интерфейс в розовый цвет; каждое изменение по отдельности выглядит разумным, код компилируется, тесты проходят, а объяснения агент выдаёт по первому запросу. При этом никому из них не обязательно разговаривать друг с другом или усваивать ту часть общей модели системы, которую раньше пришлось бы освоить. Автор напоминает свою давнюю мысль: «агенты не чувствуют боли, боль чувствуют только люди», агенты позволяют действовать в тех частях системы и кодовых базах, где раньше были бы нужны другие люди, которые со временем сменяли бы друг друга.

Наблюдая за крупными, разросшимися проектами в стиле вайб-кодинга, автор видит: кодовые базы становятся «Вавилоном» не потому, что люди не могут общаться, а потому, что им больше не нужно это делать. У каждого разработчика есть неутомимый переводчик, агент, который может объяснить любой угол «башни» и внести любое локальное изменение по запросу. Изменения продолжают попадать в код, даже когда архитектурный язык, который позволял бы людям рассуждать о системе сообща, исчезает.

Ключевое отличие от библейского сюжета: там потеря общего языка останавливает стройку, а в разработке с ИИ-агентами стройка продолжается уже после того, как общее понимание разрушено. Именно отсутствие немедленного сбоя делает ситуацию тревожной и дезориентирующей: башня не падает, поэтому потеря остаётся незамеченной. Она просто продолжает расти.

Ключевые факты

Автор сравнивает вайб-кодинг с Вавилонской башней Брейгеля: библейского Бога тревожат не кирпичи и не знания строителей, а их общий язык, источник координации и силы.
«Общий язык» программного проекта, это разделяемое понимание концепций, границ, инвариантов и зон ответственности; раньше его поддерживало трение, необходимость читать чужой код и согласовывать изменения с другими командами.
ИИ-агенты убирают это трение: разные люди параллельно просят агентов добавить OAuth, кеширование или переписать базу данных, код компилируется, тесты проходят, но разработчикам больше не нужно разговаривать друг с другом.
Автор напоминает свою мысль «агенты не чувствуют боли, боль чувствуют только люди»: агенты позволяют действовать в частях системы, где раньше требовались бы другие люди.
Главный вывод эссе: в отличие от библейской истории, где потеря общего языка останавливает стройку, в ИИ-разработке стройка продолжается уже после того, как общее понимание разрушено, и поэтому потеря остаётся незамеченной.

Почему это важно

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

Кому это важно

В первую очередь, инженерным руководителям и тимлидам, которые расширяют использование ИИ-агентов на большие кодовые базы с несколькими владельцами и командами; разработчикам, которые полагаются на агентов при изменениях за пределами своей зоны ответственности (чужой слой хранения данных, чужой сервис); менеджерам, которые оценивают, как ИИ-инструменты меняют не только скорость, но и структуру совместной работы над сложными системами.

Как это применить

Эссе не предлагает готового инструмента, но подсказывает практический вывод: раз агенты убирают трение, которое раньше вынуждало людей синхронизировать понимание системы, это трение стоит воссоздавать сознательно, сохранять код-ревью между владельцами разных частей системы, явно документировать инварианты и границы, не считать «код компилируется, тесты проходят» признаком того, что команда по-прежнему одинаково понимает архитектуру.

Можно ли доверять

Это личное эссе-размышление на блоге автора (lucumr.pocoo.org), опубликованное 13 июля 2026 года и получившее заметный отклик на Hacker News, 396 очков и 177 комментариев. Материал не содержит эмпирических данных, исследований или ссылок на сторонние источники: это авторская аргументация через библейскую притчу и картину Брейгеля, а не проверяемое исследование. Аналогия выстроена последовательно и опирается на первоисточник (текст истории о Вавилонской башне цитируется напрямую), но остаётся личной интерпретацией, а не измеримым выводом.

Риски и подводные камни

Главный риск, о котором пишет автор, отсутствие раннего сигнала: команда может долго не замечать, что общее понимание архитектуры утрачено, потому что видимых поломок нет. Отдельный риск, сама метафора эффектна, но не предлагает конкретных инженерных практик противодействия, кроме самого наблюдения; читателю придётся самостоятельно перевести идею в конкретные меры (ревью, документация, границы ответственности). Стоит учитывать и то, что это мнение одного разработчика, а не результат изучения множества команд или проектов.

«Башня не падает, и поэтому мы не замечаем, что потеряно. Она просто продолжает расти.»

— из эссе на lucumr.pocoo.org, 13 июля 2026