Vibe coding, some thoughts and predictions
Эндрю Чен размышляет о феномене vibe coding — нового способа разработки, при котором программист полностью полагается на LLM (Cursor, Sonnet), не читая код. Термин ввёл Андрей Карпатый в феврале 2025. Автор делает ряд прогнозов: большую часть кода будут писать дети и подростки, а не инженеры; vibe coding эволюционирует в vibe designing с визуальной парадигмой; код станет одноразовым товаром, что снизит роль open source библиотек; узкие места сместятся с разработки на креативность и дистрибуцию. Чен предполагает, что соотношение инженеры:дизайнеры:PM (сейчас 5:1:1) изменится, а маркетинг и продажи также станут «vibe»-управляемыми через агентские интерфейсы. В конце статьи приводится подробная методика NicolasZu, который создал лётный симулятор за 3000+ промптов в Cursor, используя Grok 3 для проектирования и Sonnet 3.7 для реализации.
Vibe coding, some thoughts and predictions
Vibe coding: мысли и прогнозы
Amazing things are happening in AI code gen
В сфере AI-генерации кода происходят удивительные вещи
(above: a vibe coded flight sim from NicolasZu, created from several thousand prompts. Included his notes on his method at the very bottom)
(выше: лётный симулятор, созданный в стиле vibe coding автором NicolasZu из нескольких тысяч промптов. Его заметки о методе — в самом низу)
Vibe coding is happening, you guys
We’ve all been surprised by LLMs being good at writing/brainstorming/generating text, but along the way, we also discovered it was surprisingly good at writing code. This was first harnessed by coding co-pilot features in IDEs like Cursor, but as many of you have followed, “vibe coding” is the new thing, coined by the great Andrej Karpathy:
Vibe coding уже здесь, ребятаВсе мы были удивлены тем, насколько LLM хороши в написании и генерации текста, мозговых штурмах, но попутно обнаружилось, что они неожиданно хороши и в написании кода. Сначала это нашло применение в функциях coding co-pilot в IDE вроде Cursor, но, как многие из вас следили, появилась новая штука — «vibe coding», термин ввёл великий Андрей Карпатый:
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
Есть новый вид программирования, который я называю «vibe coding»: ты полностью отдаёшься потоку, принимаешь экспоненты и забываешь, что код вообще существует. Это возможно, потому что LLM (например, Cursor Composer с Sonnet) становятся слишком хороши. Я ещё и просто разговариваю с Composer через SuperWhisper, так что почти не прикасаюсь к клавиатуре. Я прошу самые глупые вещи вроде «уменьши padding в сайдбаре в два раза», потому что мне лень его искать. Я всегда нажимаю «Accept All», диффы больше не читаю. Когда получаю сообщения об ошибках, просто копирую и вставляю их без комментариев — обычно это всё чинит. Код вырастает за пределы моего понимания, мне пришлось бы реально долго в нём разбираться. Иногда LLM не может починить баг, и я просто его обхожу или прошу случайных изменений, пока он не исчезнет. Для одноразовых проектов на выходные это терпимо, но всё равно довольно забавно. Я строю проект или веб-приложение, но это уже не совсем программирование — я просто что-то вижу, что-то говорю, что-то запускаю, что-то копирую и вставляю, и оно в основном работает.
And of course, since this tweet from Feb 2025, we’ve seen an explosion of people playing around with all the tools to build a lot of cool things, particularly a bunch of fun little games like flight sims, tank battle games, and even first-person shooters.
И конечно, после этого твита от февраля 2025 года мы наблюдаем взрыв: люди играются со всеми инструментами и строят множество классных вещей, особенно кучу забавных маленьких игр — лётные симуляторы, танковые сражения и даже шутеры от первого лица.
So what happens next? I have a bunch of fun/random thoughts and wanted to share them:
Что же будет дальше? У меня есть набор веселых и случайных мыслей, которыми я хочу поделиться:
most code will be written (generated?) by the time rich. Thus, most code will be written by kids/students rather than software engineers. This is the same trend as video, photos, and other social media. Of course this seems surprising because today most software is being written by highly trained adults, who are generally time poor but money rich. This will change, and it means that over time, software will become dominated by youth culture the same way that social media is. Are you ready for software memes? Or memes in the form of software? It’s all coming.
we are in the command line interface days of vibe coding. For the majority of creators, vibe coding will eventually fade, and vibe designing (with a visual paradigm) will come to dominate. People ultimately think better in a GUI-like format than a CLI-like format. Thus, in vibe designing you will show the AI the design outcomes you want, and then everything else is done for you. Yes, you may end up with tools to tweak the design details for extra controllability, and provide additional mockups that then get filled in underneath with code. But maybe folks will build software without seeing or learning a programming language.
vibe coding could reduce the need for open source libraries as more code will be generated from scratch by AI. Code will be more of a disposable commodity, with less reuse, and instead generated on the fly for personalized use. It's interesting to see right now that creating a new project is easier than editing a project, because the latter requires a lot more context/complexity. Interesting dynamics if something like this continues
"trad UX" and design standards give way to post-modern/fragmented software, as millions of new vibe coders create experiences with no prior know how and new perspectives. New patterns will emerge, as TikTok/YouTube has done to film making and trad entertainment. The world will go beyond buttons and modals and scrollbars and other things. Software may become unrecognizable before it coalesces again
new bottlenecks for software. if vibe coding makes software trivial to build, then the bottlenecks shift to other places: 1) consistent creativity that stays ahead of everyone else. Anyone can write a tweet, but the best creators are the ones who consistently come up with new ideas. 2) distribution and network effects, where the first vibe coded product doesn't win, but rather the first vibe coded product that hits scale that wins
adaptive software, specified by outcomes not code. imagine products that automatically adapt based on user behavior, rather than based on the actions of the vibe coder. For example, if the vibe coder has specified that the signup funnel should easy, then after seeing users struggle with it, the software can automatically vibe code itself to improve the flow by dropping steps or adding explanatory text. Right now we are in a paradigm where PMs specify behavior that software engineers specify in code. Imagine if PMs can specify outcomes, and the software is configured to automatically adapt to hit those outcomes
this will accelerate software eating random long tail industries. Sort of like the advent of spreadsheets (aka programming for non-technical business people). Previously, you couldn't have gotten high-end software engineers excited about small/boring/slow-growth industries but now people within those industries will vibe code their way to greatness. Thus, those industries will get absorbed into the greater tech ecosystem. An accelerant to software eating the world
software dev teams will change. today, there's a ratio in a typical software co of 5:1:1 of engineers to designers to PMs. What will that ratio look like in the future? Are we still going to have the currently dominant "EPD" paradigm or will the job titles be changed significantly. There's two arguments here: One version is that the ratio of engineers will go down, because things will be lower cost to build, and more of the emphasis will be in figuring out what the hell to build. But the counterargument might be a form of Jevon's Paradox, where the cheaper it is to build software, the more engineers you might want so you can build more, faster?
marketing and sales. what does it mean to "vibe market?" or "vibe sell?" Perhaps in the same way that you can casually specify an app and an AI will vibe code it up, perhaps the same thing can happen from a marketing context. Just tell an agentic interface that you want to market your new app to kids via short form video, and it'll then go figure everything out. Hit the "execute" button and it'll go contact influencers, buy sponsored ads, and start creating customers. Same thing with a virtual sales team, but your vibe selling comes from creating outbound lists, scripts for selling, and then an interactive AI that can try to sell for you. What business functions won't be affected here?
bugs, hacks, and other bad stuff. One of the weirdest things about building software is that, yes, the coding is hard, but so is just figuring out all the complicated logic. When you work on any product of sufficient complexity, you realize there are just lots of business decisions and edge cases and weird complex situations that need to be addressed, even when it’s rare. Can a customer redeem two coupons at the same time? If a customer wants a refund, but the delivery driver has already been paid, do you refund the whole thing or just the product? There’s a million of these things. And these issues bridge into problems of security, privacy, etc too. If two people share a folder with each other, and one person deletes the folder, does the other person also get the folder deleted? Or are they just logged off? When you make the wrong decisions here, people can get very upset. Vibe coding is fun, but addressing the infinite number of edge cases in software is not. Very curious to see how products will address this in the future.
большую часть кода будут писать (генерировать?) люди, богатые временем. То есть большую часть кода будут писать дети и студенты, а не software-инженеры. Это тот же тренд, что и с видео, фото и другими соцсетями. Конечно, это кажется удивительным, потому что сегодня большая часть софта пишется высококвалифицированными взрослыми, которые в целом бедны временем, но богаты деньгами. Это изменится, и это значит, что со временем софт будет всё больше определяться молодёжной культурой — так же, как и социальные сети. Готовы ли вы к мемам в виде софта? Или к софту в форме мемов? Всё это уже идёт.мы сейчас в эпохе командной строки vibe coding. Для большинства креаторов vibe coding в конце концов отойдёт на второй план, а доминировать начнёт vibe designing (с визуальной парадигмой). Люди в конечном счёте мыслят лучше в формате GUI, чем CLI. Так что в vibe designing вы будете показывать AI желаемые дизайн-результаты, а всё остальное он сделает за вас. Да, возможно, появятся инструменты, позволяющие подкручивать детали дизайна для дополнительного контроля и добавлять макеты, которые потом будут наполнены кодом. Но, возможно, люди будут создавать софт, не видя и не изучая язык программирования.vibe coding может снизить потребность в open source библиотеках, поскольку всё больше кода будет генерироваться с нуля AI. Код станет скорее одноразовым товаром, с меньшим повторным использованием, и будет генерироваться на лету под персональные нужды. Любопытно, что прямо сейчас создать новый проект проще, чем редактировать существующий, потому что второе требует гораздо больше контекста и сложности. Интересная динамика, если что-то подобное продолжится.«традиционный UX» и дизайн-стандарты уступят место постмодернистскому и фрагментированному софту, по мере того как миллионы новых vibe-кодеров будут создавать опыты без предварительных знаний и с новыми перспективами. Появятся новые паттерны — так же, как TikTok и YouTube изменили кинопроизводство и традиционные развлечения. Мир уйдёт за пределы кнопок, модальных окон, скроллбаров и прочих привычных элементов. Софт может стать неузнаваемым, прежде чем снова сформируется в новых формах.новые узкие места для софта. Если vibe coding делает создание софта тривиальным, то узкие места смещаются в другие места: 1) последовательная креативность, опережающая остальных. Любой может написать твит, но лучшие креаторы — это те, кто стабильно придумывает новые идеи. 2) дистрибуция и сетевые эффекты, где побеждает не первый vibe-кодированный продукт, а первый vibe-кодированный продукт, достигший масштаба.адаптивный софт, определяемый результатами, а не кодом. Представьте продукты, которые автоматически адаптируются на основе поведения пользователей, а не действий vibe-кодера. Например, если vibe-кодер указал, что воронка регистрации должна быть простой, то, увидев, что пользователи с ней мучаются, софт может автоматически переписать сам себя через vibe coding, улучшая поток — убирая шаги или добавляя пояснительный текст. Сейчас мы в парадигме, где PM описывают поведение, которое software-инженеры реализуют в коде. Представьте, что PM смогут задавать результаты, а софт будет конфигурироваться так, чтобы автоматически их достигать.это ускорит поглощение софтом случайных нишевых индустрий из «длинного хвоста». Похожим образом сработало появление электронных таблиц (по сути, программирование для нетехнических бизнес-людей). Раньше нельзя было заинтересовать высококлассных software-инженеров маленькими, скучными или медленнорастущими индустриями, но теперь люди внутри этих индустрий смогут vibe-кодить свой путь к величию. Так эти индустрии будут поглощены в большую tech-экосистему. Ускоритель того, как софт поедает мир.команды разработки изменятся. Сегодня в типичной software-компании соотношение 5:1:1 — инженеры, дизайнеры, PM. Каким оно будет в будущем? Сохранится ли доминирующая сейчас EPD-парадигма или должности существенно поменяются? Здесь два аргумента: одна версия — что доля инженеров уменьшится, потому что строить станет дешевле, а упор сместится на понимание того, что вообще строить. Контраргумент — это разновидность парадокса Джевонса: чем дешевле создавать софт, тем больше инженеров нужно, чтобы строить больше и быстрее.маркетинг и продажи. Что значит «vibe-маркетить»? Или «vibe-продавать»? Возможно, так же, как вы небрежно описываете приложение и AI его vibe-кодит, то же самое можно делать и в маркетинговом контексте. Просто скажите агентскому интерфейсу, что хотите продвигать новое приложение детям через короткие видео, и он сам всё разрулит. Нажмите кнопку «execute», и он начнёт связываться с инфлюенсерами, покупать спонсорские объявления и привлекать клиентов. То же самое с виртуальной командой продаж: ваше vibe selling начинается с создания outbound-списков, скриптов продаж и интерактивного AI, который попытается продавать за вас. Какие бизнес-функции это не затронет?баги, хаки и прочая дрянь. Одно из самых странных в разработке софта — то, что да, кодинг сложен, но не менее сложно просто разобраться во всей запутанной логике. Когда работаешь над любым продуктом достаточной сложности, понимаешь, что есть масса бизнес-решений, edge-кейсов и странных запутанных ситуаций, которые нужно учитывать, даже если они редки. Может ли клиент применить два купона одновременно? Если клиент хочет возврат, а курьеру уже заплатили, возвращать всю сумму или только за товар? Таких вопросов миллион. И эти проблемы переходят и в безопасность, приватность и так далее. Если двое делят папку, и один её удаляет, удалится ли она и у второго? Или его просто отключит? Когда здесь принимаются неправильные решения, люди могут сильно расстроиться. Vibe coding весел, но разбираться с бесконечным числом edge-кейсов в софте — нет. Очень любопытно, как продукты будут это решать в будущем.
These are just a few thoughts from a weekend of research and playing with the tools, and if you have further ideas, I hope you comment and add some more ideas.
Это лишь несколько мыслей по итогам выходных, проведённых за изучением и игрой с инструментами, и если у вас есть дополнительные идеи, надеюсь, вы оставите комментарий и добавите свои.
Wait, but aren’t vibe coded apps bad?
One thing you’ll notice when play around with all the vibe coded software people are building — they are kinda bad. That is, if you didn’t know it was built in a different way, you may not be that motivated to interact with it. After all, the hyper-blocky/pixelated tank battle games are not nearly as cool as something like World of Tanks, which has been under development for 10+ years and has millions of players.
Но подождите, разве vibe-кодированные приложения не плохие?Одну вещь вы заметите, играясь с vibe-кодированным софтом, который строят люди: он какой-то так себе. То есть, если бы вы не знали, что он создан иначе, у вас не было бы особой мотивации с ним взаимодействовать. В конце концов, гипер-блочные пиксельные танковые битвы и близко не такие крутые, как World of Tanks, которая разрабатывается 10+ лет и имеет миллионы игроков.
Two points on this:
Тут есть два пункта:
First, remember what happened with the progression of images from 2D diffusion models — it’s gotten very good very fast:
Во-первых, вспомните, что произошло с прогрессом изображений из 2D диффузионных моделей — они очень быстро стали очень хороши:
And of course, the same in LLMs, video, etc. My assumption is, we are on a fast climb towards much more sophistication and complexity with AI code gen. While the current output may feel almost trivial, imagine what all this tech will look like in 5 years? In the positive case, it’ll feel like everyone has a team of 100+ engineers in their pocket, ready to build any piece of software they want.
И, конечно, то же самое с LLM, видео и так далее. Моё предположение: мы на быстром подъёме в сторону гораздо большей изощрённости и сложности AI-генерации кода. Хотя текущий результат может казаться почти тривиальным, представьте, как всё это будет выглядеть через 5 лет? В позитивном сценарии это будет ощущаться так, словно у каждого в кармане команда из 100+ инженеров, готовых построить любой софт, какой он пожелает.
And second, maybe the triviality of the output doesn’t matter. If you compare to prior content creation trends, you could argue that the photos that people post online are a lot worse than what professional photographers post. Same with YouTube videos and what a filmmaker would create. But it doesn’t matter, simply because the sheer quantity of content — that is comprehensively able to fill every niche and nuance of demand, and created by real people as the creators (not corporations), make social media dominant. The same could be said of software.
А во-вторых, возможно, тривиальность результата не имеет значения. Если сравнивать с предыдущими трендами в создании контента, можно сказать, что фотографии, которые люди выкладывают онлайн, гораздо хуже того, что публикуют профессиональные фотографы. То же с YouTube-видео и тем, что создал бы кинорежиссёр. Но это не имеет значения — просто потому, что огромное количество контента, способного покрыть каждую нишу и нюанс спроса, и созданного реальными людьми (а не корпорациями), делает соцсети доминирующими. То же самое можно сказать и о софте.
In the past, maybe you would only mobilize a team of 10 developers to build a product that could generate $1M in revenue and scale to a multi-million dollar company. Anything less would be sub-scale. But maybe now you’ll build a new software product the same as what you’d do with a capturing a iPhone video. You’ll do it for fun, and it’ll be ephemeral, and you might share it with a few people. But then you’ll move on and build the next thing.
В прошлом, возможно, вы мобилизовали бы команду из 10 разработчиков, чтобы построить продукт, способный приносить $1M выручки и масштабироваться в многомиллионную компанию. Меньшее было бы недостаточным по масштабу. Но, возможно, теперь вы будете создавать новый софтверный продукт так же, как снимаете видео на iPhone. Вы будете делать это ради веселья, оно будет эфемерным, и вы поделитесь им с несколькими людьми. А потом двинетесь дальше и построите следующее.
How vibe coding works today
For those who are ready to explore, it’s not hard. Here’s a quick video on the topic, where a simple strategy game is built quickly so you can get a feel for it.
Как vibe coding работает сегодняДля тех, кто готов попробовать, это несложно. Вот короткое видео по теме, где простая стратегия быстро собирается, чтобы вы прочувствовали процесс.
The tools are actually pretty easy to play around with and set up. I recommend Replit Agent if you want to get going quickly with a demo, but most people seem to be using Cursor.
Инструменты на самом деле довольно легко поставить и попробовать. Я рекомендую Replit Agent, если хотите быстро запустить демку, но большинство людей, похоже, используют Cursor.
Finally, I also wanted to link to NicolasZu’s recent post on how he built his flight sim game, to give you a sense for how to build something with thousands of prompts (but without coding).
Наконец, я также хотел сослаться на недавний пост NicolasZu о том, как он построил свою игру-лётный симулятор, чтобы вы получили представление, как создавать что-то с помощью тысяч промптов (но без программирования).
I don't think the secret sauce is public yet. I can give you the fundamentals
- Grok 3 to transform a game idea in a game design document
- Grok 3 to define the best stack: front & backend for your game and ambition (multiplayer? etc)
- Grok 3 to transform the game design document into an implementation plan with super easy steps
IMPORTANT: start small. You will do this kind of document for every major upgrade (like multiplayer, or mobile, or server optimization, ...)
- Cursor setup with .cursorrules to clarify your stack (based on Grok), e.g. "optimise for mobile"
- Cursor with Sonnet 3.7 to learn the GDG and the impl plan.
- to Cursor "is it clear? what are your questions" => usually ask 9-10 questions. You answer and ask him to add to the impl file
- Sonnet 3.7 to start with phase 1. Then YOU test phase 1. You are the QA here. If phase one works, Sonnet to document what he did.
- Important: New chat between each phase
- Sonnet to go with Phase 2 ("please read the GDG and what was done in step 1). Then you test, etc.
- What if the test doesn't work? prompt away to get it done.
- Stuck? Grok 3 => your github repo => generate prompt for Claude
- Super stuck? go back 1 or several commits / prompts and try different ones.
- Hyper Stuck? Think what files could be the location of the error and drag them in the chat to investigate with Sonnet Thinking
- Project bigger than 20k LOC? Ask Sonnet to create an http://architecture.md. this file will help all future prompts.
Anyway, I am at 3000+ prompts in Cursor. I really feel like I am a whisperer 😂 I jump from Sonnet 3.5 to 4o and now to 4.5 depending on nuances I know those models have. For instance, "improve my messaging" => 4.5
Не думаю, что секретный рецепт уже стал публичным. Могу дать вам основы:- Grok 3, чтобы превратить идею игры в game design document- Grok 3, чтобы определить лучший стек: фронт и бэк для вашей игры и амбиций (мультиплеер? и т.д.)- Grok 3, чтобы превратить game design document в имплементационный план с очень простыми шагамиВАЖНО: начинайте с малого. Такой документ вы будете делать для каждого крупного апгрейда (вроде мультиплеера, мобильной версии или серверной оптимизации).- настройка Cursor с .cursorrules, чтобы прояснить ваш стек (на основе Grok), например «оптимизируй под мобильные»- Cursor с Sonnet 3.7, чтобы изучить GDG и имплементационный план.- Cursor: «всё ли понятно? какие у тебя вопросы?» => обычно задаёт 9-10 вопросов. Вы отвечаете и просите его добавить ответы в имплементационный файл.- Sonnet 3.7, чтобы начать с фазы 1. Затем ВЫ тестируете фазу 1. Вы здесь QA. Если фаза 1 работает, Sonnet документирует то, что он сделал.- Важно: новый чат между каждой фазой.- Sonnet идёт на фазу 2 («пожалуйста, прочитай GDG и то, что было сделано на шаге 1»). Затем вы тестируете и т.д.- Что если тест не работает? Промптите дальше, пока не получится.- Застряли? Grok 3 => ваш github-репозиторий => сгенерировать промпт для Claude.- Сильно застряли? Откатитесь на 1 или несколько коммитов/промптов назад и попробуйте другие варианты.- Гипер-застряли? Подумайте, в каких файлах может быть локация ошибки, и перетащите их в чат, чтобы расследовать с Sonnet Thinking.- Проект больше 20k строк кода? Попросите Sonnet создать http://architecture.md. Этот файл поможет всем будущим промптам.В общем, я сейчас на 3000+ промптов в Cursor. Чувствую себя настоящим заклинателем 😂 Прыгаю между Sonnet 3.5, 4o и теперь 4.5 в зависимости от нюансов, которые я знаю у этих моделей. Например, «улучши мои сообщения» => 4.5