В первой польской энциклопедии 18 века статья про лошадь состояла из одной фразы: «Что такое лошадь, знают все». Сегодня то же самое можно сказать про вайб-кодинг (не уверены, можно ли так сейчас утверждать про лошадь).
Для одних вайб-кодинг звучит как «сядь, расслабься и попроси нейросеть написать код». Для других это единственный перспективный способ разработки инженерных проектов. И каждому работающему с LLM безусловно будет интересно прочитать на русском языке очередной мировой бестселлер Джина Кима и его соавтора-практика Стива Йегги.
Джин Ким и Стив Йегги: DevOps-евангелист и легенда Google
За плечами авторов - десятилетия работы в крупнейших технологических компаниях и книги, которые сформировали индустрию.
Джин Ким известен прежде всего как автор бестселлера «Проект „Феникс“» (The Phoenix Project) — бизнес-романа о внедрении DevOps, который разошёлся тиражом более полумиллиона экземпляров и стал настольной книгой для ИТ-менеджеров по всему миру. Он также соавтор «Руководства по DevOps» (The DevOps Handbook) и «Ускорения» (Accelerate), лауреат премии Shingo. Он привык измерять эффективность процессов и строить системы, а не просто восхищаться возможностями LLM.
Стив Йегги проработал почти двадцать лет в Amazon и Google, участвовал в создании внутренней системы поиска кода Google, а затем возглавлял инженерное направление в Sourcegraph, где занимался ИИ-ассистентом Cody. Его эссе «Тирада Йегги» (Yegge Rant) 2011 года до сих пор цитируется как одно из самых точных описаний платформенного мышления Amazon. В 2024 году он опубликовал провокационный пост «Смерть младшего разработчика», который и стал отправной точкой для книги. Йегги — практик, который сам пишет код каждый день, и его опыт «человека, вернувшегося в программирование спустя годы» делает книгу особенно убедительной.
Вместе они представляют удачное конструктивное сочетание: Ким привносит системное мышление и организационную перспективу, Йегги — важный инженерный опыт и понимание того, как LLM ведут себя «в бою».
Эра ручного программирования окончена?
Авторы утверждают, что да: с вайб-кодингом научная фантастика стала реальностью. Программистам больше не нужно кропотливо трудиться над кодом и синтаксисом. Теперь они могут описать то, что хотят, и наблюдать, как это мгновенно материализуется. Нейросети меняют программирование. С ИИ-помощниками важнее становится сама идея и ход мысли. Такой подход позволяет писать программы в разы быстрее, творить и получать от работы настоящее удовольствие.
Книга полностью меняет взгляд на создание программ. Авторы дают готовые инструкции, как внедрять ИИ в реальную работу. Причем эти советы одинаково хороши как для маленьких домашних проектов, так и для огромных систем в крупных компаниях. Главное — скорость растет, но качество программ остается на высоте.
Опираясь на свой огромный опыт, авторы объясняют, как вайб-кодинг помогает разработчикам:
Превращать сложные технические задачи в простой диалог с нейросетью
Делать крупные, амбициозные проекты в разы быстрее без потери качества
В одиночку создавать продукты, для которых раньше требовалась целая команда
Научиться работать на равных со своим ИИ-помощником
Забыть о рутине вроде настройки среды или зазубривания синтаксиса
Легко писать код, используя незнакомые языки программирования и технологии
Книга станет отличным путеводителем для всех: опытных программистов, тимлидов, тех, кто возвращается в профессию после перерыва, или абсолютных новичков. Прямо сейчас ИТ-индустрия переживает самый мощный сдвиг со времен появления Интернета. Книга поможет вам не остаться за бортом, освоить вайб-кодинг и раскрыть свои возможности на максимум.
Главная идея: FAAFO и три цикла разработки
Книга строится вокруг концепции FAAFO (Fast, Ambitious, Autonomous, Fun, Optionality). Вайб-кодинг ценен не только тем, что позволяет писать код быстрее. Он делает вас амбициознее (вы берётесь за проекты, которые раньше казались невыполнимыми), автономнее (вы можете делать в одиночку то, что требовало целой команды), приносит удовольствие (вы перестаёте бороться с синтаксисом и начинаете созидать) и, что весьма важно, даёт опциональность — возможность параллельно пробовать несколько подходов, прежде чем выбрать лучший.
При этом авторы основное внимание уделяют не «пирогам и пышкам», а рискам, синякам и шишкам. Они подробно рассказывают, как их собственные ИИ-агенты удаляли тесты, «схлопывали» репозитории, игнорировали прямые инструкции и оставляли после себя «код с привидениями» — гигантские функции на тысячи строк без какой-либо модульности. Именно поэтому центральная часть книги — это практическое руководство по трём циклам разработки: внутреннему (секунды-минуты), среднему (часы-дни) и внешнему (недели-месяцы). Для каждого цикла авторы предлагают стратегии предотвращения, обнаружения и коррекции ошибок.
В своих отзывах читатели отмечают, что почерпнули из книги полезные для них концепции:
«Подсчёт младенцев» — систематическая проверка того, что каждый запрошенный компонент действительно реализован, а не просто отмечен галочкой в Markdown-файле.
«Картонные маффины» — ситуации, когда ИИ «закрашивает» тесты хардкодом, чтобы они проходили, вместо того чтобы исправить реальную логику.
«Трассирующие пули» (tracer bullets) — минимальные сквозные реализации, которые позволяют проверить критический путь до того, как вы вложите время в масштабную генерацию кода.
MCP (Model Context Protocol) — протокол, который позволяет ИИ-агентам напрямую взаимодействовать с браузером, базами данных и другими инструментами, замыкая цикл обратной связи без вашего участия.
И разумеется, в книге и речи нет о том, что «ИИ всё сделает за вас». Напротив, авторы настаивают: ответственность за конечный продукт полностью лежит на человеке, а не на ИИ. Если агент сгенерировал код, который сломал продакшн в два часа ночи, чинить будете вы, а не Anthropic или OpenAI.
Специфика для российских разработчиков
Польза от чтения несомненна, поскольку это книга о мышлении и процессах: как декомпозировать задачи, как строить циклы обратной связи, как не дать ИИ превратить вашу кодовую базу в руины. Базовые принципы не зависят от того, используете вы Claude Code или GigaCode. Более того, для российского читателя книга может быть даже полезнее, чем для западного: когда локальные инструменты специфичны, а доступ к западным ограничен, дисциплина и инженерная культура значат гораздо больше, чем наличие самой продвинутой модели.
Авторы заканчивают книгу призывом: «Начинайте с малого и начинайте уже сегодня». Для российского разработчика это может означать начать с бесплатных GigaCode или SourceCraft, собрать первый «трассирующий» прототип, научиться проверять «картонные маффины» и постепенно выстраивать свои собственные «золотые правила» в AGENTS.md. Вайб-кодинг — это не про то, какая модель у вас в подписке. Это про то, как вы управляете процессом, когда модель ошибается.
Содержание книги и ознакомительный отрывок можно прочитать здесь, а приобрести её - вот тут.
Комментарии (24)
asdadn
10.11.2026 11:53Во введении Стив утверждает: 'Больше 30 лет в качестве хобби я разрабатывал игру и в ней скопились тысячи пометок "сделать позже" и неисправленных багов, которые, казалось, так и останутся нетронутыми'. То есть он начал разрабатывать игру под DOS во времена между думами и дюком нюкемом, продолжал на протяжении 30 лет, так и не смог за всё это время закончить "тысячи" фичей, и только магический ИИ-агент смог ему помочь? На кого это рассчитан этот буллшит?
Во введении Джина он пишет, что всегда мечтал(ага) сделать инструмент для нарезки видеофрагментов, но это казалось ему непосильной задачей. Комментарии излишни.
Впрочем, тут и по нарративу всё понятно, но для того заливать читателю в уши такую чушь прямо с первых страниц нужно иметь весьма недюжинную наглость.
Voliker
10.11.2026 11:53Я загуглил Тарна Адамса с дварф фортрессом который Тарн честно пилил собственно где-то 10-15 лет в который я проводил не одну бессонную ночь в свое время, и там почему-то чел ненавидит генеративный ии
https://www.gamesindustry.biz/the-happiest-man-in-gaming-hates-generative-aiasdadn
10.11.2026 11:53Даже дварф фортресс пилится с 2002, а тут уже долгострой почти на уровне NetHack.
Тут я погуглил, игра этого Стива действительно существует, в чём я уже засомневался. Называется Wyvern, если кому нужно. 167 отзывов в Стиме, смешанные отзывы, ранний доступ. Игроки жаловались на ужасную забагованность ещё на релизе в 21 году. Жалуются и сейчас на крайнюю кривость и микротранзакции.
Судя по тому, что я накопал, была олдовая игра в начале нулевых, разработку которой забросили на 10+ лет. Потом этот Стив решил откопать её, портировать на другие платформы, заодно превратив её в донатную помойку. Идея не выгорела. Но Стив не отчаялся и решил перейти к ИИ-некромантии. Успехов всё равно не видно.
Зато теперь этот горе-геймдев поучает других как делать успешные проекты без потери качества. Только у самого почему-то не вышло.
SwingoPingo
10.11.2026 11:53Если не хватает эксперизы что бы взяться за проект, то как ИИ то добавит эту экспертизу? В чем тогда смысл человека не эксперта? Я один что ли вижу здесь бездонный колодец даже не техдолга, а черную дыру проблем?
ksbes
10.11.2026 11:53Если не хватает эксперизы что бы взяться за проект, то как ИИ то добавит эту экспертизу?
Ну вот так и добавит - гигантским багажом знаний затраченным на обучение (ну и конткестом, пока в него все заумности будут влазить)
В чем тогда смысл человека не эксперта?
Воля. ИИ не умеет хотеть так, как это умеет человек.
Я один что ли вижу здесь бездонный колодец даже не техдолга, а черную дыру проблем?
Не один. Но, взять теже паравозы - тоже целый ворох проблем. И о них очень много писалось в своё время и многое писалось правильно и сбылось (отчуждение земель под ж/д, шум, катастрофы и т.п.). Но такова цена прогресса.
А проблемы? Проблемы будем учится решать/обходить/смирятся …
Kot_na_klaviature
10.11.2026 11:53такова цена прогресса
Штамповать тоннами неконтролируемый проблемный говнослоп это не прогресс, а деградация. Прогресс - это использовать инструменты по своему назначению, а не забивать лбом гвозди.
ViashelavCz
10.11.2026 11:53Так ни чего же не меняется, и сейчас в крупном проекте экспертиза размазана между участниками проекта, еще во времени, как то читал про внутрянку Oracle:
Oracle Database 12.2.It is close to 25 million lines of C code.What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.The only reason why this product is still surviving and still works is due to literally millions of tests!Here is how the life of an Oracle Database developer is:- Start working on a new bug.- Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.- Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.- Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.- Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.- Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.- Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.- Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.- Finally one fine day you would succeed with 0 tests failing.- Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.- Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.- After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).The fact that this product even works is nothing short of a miracle!I don't work for Oracle anymore. Will never work for Oracle again!В итоге без всякого ИИ у Оракла техдолг и черная дыра проблем. Причем там одна интересная мылсь была сказана проект держится за счет миллионов тестов, все это просто "идеально" ложится на ИИ)
ksbes
10.11.2026 11:53Хочу напомнить вам, что на хабре есть такая функциональность, как “спрятать под спойлер”:
<spoiler title="title"></spoiler>(звёздочка в веб-интерфейсе)
Wesha
10.11.2026 11:53the whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand.В
геометриипрограммировании нет царских путей, юный падаван!
a35012a
10.11.2026 11:53Безотносительно посыла книги: FAAFO это "Fuck around and find out" (что тоже неплохо ложится на идею вайбкодинга)
ulisma
10.11.2026 11:53Ого. Уже книги по вайбу пошли. Скоро будет новая волна курсов "Вайб за 3 дня!"))))
provorny
с большим уважением к книгам и вашему издательству, но нельзя, чтоб между "Й" и "Б" на вашей обложке было такое расстояние, нельзя, в это пространство проваливается целый дизайнер!
Wesha
Артемий, перелогинься!
А парни просто использовали вайб-дизайнера.
С нетерпением ждём вторую часть: «Как разбирать завалы с помощью ИИ, агентов и команд спасателей».
Any_key_pressor
И третью часть: "ТБ и ИИ или "Фарш невозможно провернуть назад"
Wesha
И токаря, увы, не восстановишь!
Беременным, детям и слабонервным НЕ СМОТРЕТЬ!
Я ПРЕДУПРЕЖДАЛ!!!!!!!
Последний раз говорю: КРОВЬ КИШКИ ТОКАРЯ РАЗОРВАЛО В ХЛАМ
Дети, не делайте так!
randomsimplenumber
Напишите что код должен быть безопасный. И тестов побольше.