There are parallels to the “rapid application development” push of the 90’s. Visual Basic, Tcl/Tk, Python with Tkinter, HyperCard; all of them promised shortening the development cycle and democratizing computing. Code was interpreted rather than compiled, dynamically typed rather than statically, and a lot of batteries were included.

It sorta worked, and sorta didn’t. I’m seeing no evidence that this round is different. LLMs allow coding via natural language and assuming a lot of context that is typical to human conversation, but a lot of coding is delving into nuance, which is going to be work, no matter the tool.

Every time I see a post about something built with vibe coding, it reminds me of myself at age 12 making a really basic screensaver in GWBASIC.

All the excitement I felt because it was new to me, but it was really just a very basic toy not a real piece of software.

Meanwhile there were seasoned pros who could probably do amazing things even with GWBASIC. But that was more in spite of it than because of it.

> a lot of coding is delving into nuance

this is the core issue. The best language we have for specifying this nuance is still programming languages, not English

Moving up from ASM -> C -> Python we're mainly abstracting over performance and implementation details, not functionality.

Here thouhg, in making the next jump from the high level Python to an English-specified LLM output we're trying to abstract over functionality. This doesn't work. It's flawed from the start

RAD & the rise of VB6 was much more measured in promises, and much more concrete in what it delivered. We wrote an awful lot of VB^ and Foxpro code, much of it quite valuable almost all of it terrible quality - but that didn't matter as much.

Vibe coding promises the world, and behold fails to deliver.

I have already vibe-coded countless number of scripts and two side projects that were on my "list" for years, these projects would have never seen the light of day if not for Cursor. That's the whole point.

The fact that they could be "vibe coded" means that they (or something similar) probably already existed, but you just didn't know they did.

No, there's a very very long tail of tasks that are too niche for a proper tool to exist for but it would be annoying effort to figure out yourself.

My most recent example of this: write a script to delete all git branches that point to HEAD.

Go ahead see how long it takes you to figure out the command for that, because it took me under 60 seconds with AI.

This is the learning to fish problem. If you understand git well, a solution isn't very hard (eg, rev-parse each branch and compare to the rev-parse of the current branch and deleting if they match). If you don't understand git well, you shouldn't be turning into a script-kiddy pasting in whatever the AI spits out and hoping that it works.

> eg, rev-parse each branch and compare to the rev-parse of the current branch and deleting if they match

Yeah now go and do that in under 60 seconds.

You seem to be a bit confused. I understand Git very well. But AI can simply do this much faster than I could.

You are using "script-kiddy" as an ad hominem rather than making an argument with proper justification. "script-kiddy" refers to website vandalism and cracking. That has nothing to do with using AI to learn what rev-parse does.

Learning about `git rev-parse` through documentation and learning about `git rev-parse` through AI fundamentally have the same outcome at the end of the day: you have learned how to use `git rev-parse`.

I’m using it as a pejorative (not an ad hominem) for people who blindly trust unknown code because they don’t have any real understanding. It’s a shortcut for a whole, well-known and obvious argument about the danger of playing with things being your understanding.

http://www.catb.org/jargon/html/S/script-kiddies.html

If you are using AI to learn, understand, and verify what it spit out, by definition, you aren’t a script kiddy. My argument was about how you use AI rather than a commentary on if you should.

> Learning about `git rev-parse` through documentation and learning about `git rev-parse` through AI fundamentally have the same outcome at the end of the day: you have learned how to use `git rev-parse`.

But with a non-zero chance of hallucination.

If you learn many things that way the chance grows to 100%.

Your method still requires a script though

But the amount of time saved because one could vibe code it rather than search through Google’s terrible results is immense and a benefit in and of itself.

Maybe. But anytime I take on the task to automate something, it was a nice opportunity to check how others do it, what other things the program can accomplish.

The decision to automate is already done, no need to rush through it.

Parts of it could probably already exists in the LLM's corpus, but being able to join them together to build new things is what makes "vibe coding" so useful.

Even though, from personal experience, at scale it still falls apart

What the end product is depends on the specific parts chosen and the way they're put together

Just because the parts are available doesn't mean every possible combination of them has already been made

Not if you know the field really well, I talk to my users.

IDK, there are a lot of little chores that I find needing done that previously would have been ten minutes of research and cli fiddling that are a prompt and copy paste now.

It doesn't feel that different but it is a little faster

If you don't understand what the copy/paste is actually doing, you shouldn't be script-kiddying it in your project. If you do understand, then the AI is just quickly writing what you already intended.

If you are having to understand something you didn't understand, it's probably taking a bunch of time to read and verify what the script does. This can be a good learning experience and reveal unknown unknowns, but probably isn't a massive speedup.

This seems false to me. I vibe code shell scripts all the time. I understand what it's doing perfectly, but it would have taken me ages to look up all the bash syntax and get it all correct. Is it one square bracket pair around if statements, or two?

You are in the category I mentioned that already know the answer and are using AI to write the code you already understand faster. This is rather different from “vibe coding” in my opinion.

I think it is somewhat similar to the emergent translation capabilities, it doesn't need to have trained on a translation of a text to do one of it. But it does need good coverage of the area.

If you could throw your endless todo list of side projects at an LLM, and can see at least some of them implemented overnight effortlessly, why not? You can still take credit because you had the idea in the first place and went through the effort to write it down and describe it well enough to be achievable. It's definitely more fun especially if you have limited hobby coding time.

If you're fine with running them blindly and having one of those scripts recursively remove your home directory, then sure. Otherwise it's very much not a zero effort affair. More like overseeing an overconfident overenthusiastic amphetamine-doped junior developer (or running his output blindly and hoping for the best).

I really do feel like we're living in completely separate worlds, so many people are very enthusiastic about LLMs, and every time I try them, they leave me completely disappointed.

Biking isn’t difficult, but you’ll still travel more with a car.

Now imagine if your car didn’t have a steering wheel or pedals, but instead you had to explain to it where to go and it would misunderstand you 60% of the time.

I would say Claude misunderstands about 10% of the time once you know how to prompt it.

Only when the road permits it for that type of car. And if it’s a common road, it’s better economically to build a a train (framework, library) than to use a car (code generation). Then you could use a bycicle (short burst of code) for the parts that matter.

It is, takes much less energy.

> Vibe coding is now a burgeoning tech movement. Will it last? Only time will tell.

Was this vibe-blogged?

'Vibe coding' is here to stay and the future of software development is assistant-led interfaces. I pair program daily with Claude Code on a distributed systems & a handful of other apps as needs arise. Most of my work is puppeteering, as well as careful directing. & I can't sit blindly, but we're producing valid software at pace I've never experienced in my career; with additional bandwidth to do some leisure activities in real time without losing productivity, vibing.

We really need to lock down semantics here, but I wouldn’t describe what you’re doing as vibe coding.

Seems like we’re need a term for something between basic tab autocomplete and purely vibing without glancing at the code. If only to have separate conferences in 2-3 years.

My thoughts exactly reading these comments. Generating scripts is a very good use for LLMs, but I was under the impression that vibe coding generally referred to building whole products with just prompts. It’s a very different beast to do a small script (or a todo app) than to do a relatively more complex application.

Most of what I do is prompting. It feels vibey because I can do whatever I want while the agent works

"Vibe Coding" is not pair-programming with a LLM assistant, using it an intelligent auto-complete, with a human driving the structure and design of the code. The term was original meant to describe "Doing the entire program from an empty file by prompting, accepting all the code as-given, and repeating until it works."

> and the future of software development is assistant-led interfaces

Citation needed.

After a week of trying to vibe cdk code, then sitting down in 4 hours to do the whole thing myself I can confirm. While it is now a good tool to combat fatigue, research and prototype, it still struggles with context switching, arid knowledge domains and long-feedback-loop systems

My best workflow to date is to generate snippet of code when you know a lot of the domain, but don’t want to go through the docs. Especially with languages like python. Even then, you get nonsensical stuff. But it can be great for quickly locating source material in the docs. Kinda like looking at a reference implementation to get the technique.

But it is slower than someone that is knowledgeable about the library and languages unless you don’t care about correctness.

It is overrated.

I tried three times, just for fun, to start a decent-sized projects from start to finish without interventions. All failed. The AI can't seem to have far enough horizon to see the projects to completions.

AI needs a super well defined scoped, for example: an IDE companion or logo generator or writing a specific Class implementation, to thrive.

I enjoy using LLMs for code assistance, but every time I've tried to vibe code, even with the newest models (including Gemini 2.5 Pro) and the latest tools (like Codex and Claude Code, which everyone raves about) the results have ranged from bad to middling. After all the raving on Gemini 2.5 Pro I tried again and it wrote horrendous code, seemed like it didn't understand the language (Lua) at all and went off on its own tangents doing things I didn't ask for. I think I'll wait until it gets much better before I try again.

Also, why is it so hard for LLMs to generate code without stupid comments everywhere? I don't want to see // frobincate followed by thing.frobnicate(). Even when I include clear, strict instructions they'll ALWAYS generate comments like that. It pisses me off.

You must be doing it wrong since Anthropic's CEO has claimed that in 12 months, nearly all code will be written by AI.

Wasn't this 12 months ago?

It was two months ago, and the prediction was 90% of code written by AI in 3-6 months, and ~100% in 12 months. Maybe he will be right but in a cursed monkey's paw sense where the amount of high quality code stays about the same, but that becomes a rounding error compared to the amount of barely functional spaghetti code being churned out by agents.

Similarly ~100% of written word will probably be penned by LLMs soon if not already, but that doesn't necessarily mean the writing is any good, only that LLMs can type really fast for pico-pennies on the dollar.

It’s more about the qty of minutes/hours AI can crunch information for you, reducing the context switching or loss of context. A lot of the back and forth will go away, replaced with prompt and planning skills needing to be more specific, for long complex runs as needed, then clean up short runs based on UAT and QA inspection after.

Vibe coding is definitely problematic for someone who isn't a strong coder, aka me. Recently for fun, I used ChatGPT to code a python script to scrape another news site and render it in the style of HackerNews.

It took 21 iterations of code updates to get a working version. It isn't bad but doesn't pull the latest articles (I don't know why) and hell if I could debug it.

With experience and ADHD I learned to think in units that can be debugged separately. The experience tells me where those lines should be drawn, and the ADHD taught me to avoid creating units that are too big to fit in my head.

Wordpress already killed the low-end of the market a long time ago. 15 years ago, you were setting up wordpress sites and throwing on a simple theme for $500 or so then trying to get them to write up the copy and provide images (or upcharge for those services). Most of this was generally a loss leader with the actual profits coming from charging to manage the hosting for them.

This is the market disrupted by vibe coding and AI-generated copy/images.

These Wordpress or Wix/Squarespace sites account for MOST of the web, but only a minuscule fraction of high-paid devs. For those devs, AI just doesn't change very much because it has no idea what questions need to be asked to actually deliver what management wants let alone the ability to problem solve and deliver novel solutions to issues.

I've had a similar experience. It requires strong nerves and a lot of patience.

Semi-controversial headline but I think the point is fair. It doesn't yet produce results that meet a spec well. It's fine for scripts because if it insists you do it the bot's way, that's fine. If it uses the wrong library, whatever. And so on.

I'm going to keep shilling this until people start doing it: I'd love to see everyone who says he's vibecoded something non-trivial and posts/blogs about it start dumping and attaching his full chats to it. This would really help people to understand what's hype/exaggeration and what's real, and would help others be better at the real part.

The one time so far that I actually implemented a full feature using only vibe coding (and it wasn't trivial), I had to be very specific about what I wanted, and it was in a very widely used stack (React/NextJS), it was a very common feature (sorting, filtering, pagination on a table) and it worked beautifully.

But it felt magical the one time it happened. Every other time, I'm mostly using tab autocomplete and that works quite well too.

And when I code in Elixir, I have a 20% success rate even with small requests.

Your last sentence is a bit of a gut punch tbh - I was meaning to get more familiar with Elixir for side projects, and I’ve made a few small web apps with LiveViews. Absolutely love it, even though I don’t feel I‘ve grasped the language fully yet. But some research shows that most LLMs don’t support Elixir that well.

But since my free time is so extremely limited, it would be really nice to get better LLM and agent support. So I hope the lesser used languages and frameworks get more training love, soon. Lest we all only use Next for hobby projects in the future.

Unfortunately this is consistent for non-ultra-mainstream langs. They’re next to unusable for complex Haskell. If you want to vibe code, it’s Python/typescript/react or nothing.

I wonder how well they do for Go and Java. The first is a boring language where there's little to none chance to stray from the default. The second is verbose, but with strict rules on the syntax.

I’ve been able to create an app with Claude that I could not have made myself. I don’t understand most of the framework(react), idioms, code or the statistical methods it uses to create the results I need. My statistician coworkers verified the output. It’s a very niche analysis so very few tools exist and are usually part of a large expensive package.

I’ve been able to extend its functionality several times without it breaking, and had Claude separate all functionality as components so it’s easier to manage. I could never have done that myself.

I consider it a very good prototype although we use the tool internally on a weekly basis. If we’re going to continue using it long term, I will probably find an experienced programmer to rebuild it from scratch, and support it.

It's interesting to me how I didn't know where the "vibe coding" term came from originally, and thought someone has decided to push and hype it up really hard as an alternative approach to writing software in general. And now that I see it, it sounds way more reasonable than the way it's been spreading out of context.

I'm sure it will go down in history as some sort of intentional movement, and then someone will occasionally point out "did you know that originally this idea was never meant to be used for serious work, Andrej literally said it was only okay for throwaway weekend projects." Big not-always-good things[1] started this way — by misinterpreting something.

Of course, it's possible that in the future code written this way will actually be maintainable, performant, and secure enough that you could start trusting it, and this will morph into a legit way of writing software, but right now the hype is way ahead of what Andrej meant when he coined the term.

[1]: Examples come to mind: Agile, Scrum, Javascript (2 week project originally), there're definitely more examples.

Vibe Coding is the new offshoring - the difference is that basically anyone can do it.

This has been my conclusion as well. A lot of people complaining about the quality, bugginess and general fragility of vibe coded codebases are comparing it with their own personal, thoughtful, (and expensive!) dev process.

Having inherited a couple of hastily written but dirt cheap offshored codebases to fix, I would rather vibe code than try to untangle those garbage code bases.

Vibe coding is terrible compared to the thoughtful output of a seasoned dev, but is significantly cheaper, faster and easier to iterate on than the lowest bidder offshored. Undoubtedly most offshore coders will just vibe code anyway, so in the near term I suspect LLMs will impact these “programmers” the most.

If anything, I'd argue it's overrated by non developer and underrated by experienced developers. I just started using Claude Code 2-3 weeks ago and productivity boost has been massive, but I definitely have to stay involved.

> and productivity boost has been massive

Serious question, is this self-reported?

Yes - as I'm a one-man startup - but it's definitely real.

I would guess that for every app that was vibe coded and made $80k in revenue, there are thousands of attempts that went off a cliff or into a wall, generating $0 revenue and wasting a human’s time. So it’s just survivorship bias. Sure, it’s possible to make something useful, but you will probably fail.

I’m using AI to increase my productivity, but whenever I’ve vibe coded (not intentionally, just by getting caught up in the dumb vibes) I’ve regretted it. I’ve ended up with a tangled mess.

Unless I spend a considerable amount of time writing a wall of text to do anything beyond simple tab completion I have yet to see it save me a significant amount of time. The 1 time it helped me come up with a complex solution gets overshadowed by 10 rabbit holes of hallucinated API usage that I now have to sort out, clean up, etc.

LLM’s are very good at style transfer, like turning a piece of writing into a poem or whatever. I’ve found this to be helpful with respect to coding style as well.

E.g. I still kind of write python as if I was writing C++. So, sometimes I’ll write a for loop iterating over integer indexes and tell the LLM “Hey can you rewrite this more pythonically” and I get decent results.

This is not news for people who already know how to code. The problem is that there are tens of thousands of people who have no idea what they're doing, yet they evangelize their hollow victories to anyone willing to listen.

Worse yet, there are grifters like levelsio who will pretend like it's great because they know that's what their followers want to hear.

This is a good take. The problem is not that vibe coding is bad or worthless, it’s just that vibe coding exposes new groups of people to new kinds of risks.

Yeah. I don't care for vibe-coding on your personal project, but I would absolutely mind reviewing a PR and finding afterwards you don't have any idea of how the code works, so you can't answer any question.

Has anyone honestly had good experiences vibe coding? I mean like building any kind of application above and beyond a simple shell-like script?

Honest question here. I'd be curious too what scenarios in general folks find LLMs useful re coding.

edited: typo

It has been a huge productivity boost for me as an assistant (not full auto-pilot). Some examples: 1) add relevant indexes to my database schema (it will analyze the code and look for columns that should be indexed). 2) write a Typescript type that takes all the methods of a class and returns a new identical type but where all the return types are void. 3) (firmware development) the on_receive callback is causing a stack overflow, put the crypto operations in a separate thread. Sometimes I get a bit more ambitious and asks for "implement the following feature: ", but manually approve code changes and steer it in the right direction.

If you use it as an assistant, it’s not vibe coding.

I see. I thought it just meant using agentic coding tools in general.

Claude has helped me a lot to get through my small feature backlog faster.

But if you don't review the code you're asking for hurt. It has literally written stuff like "if pending changes > 20, delete all", etc.

If left on auto pilot, it will sometimes get frustrated with bugs and start "cheating" in various ways (e.g. unsafe type casting, commenting out code/tests, etc.).

Indeed, I rarely use auto pilot. I've had to add to claude.md in one project to tell it to not use reflection or it's entire family will die, lol.

I actually think that whole "Guys I'm under attack" twitter thread series could have been an elaborate troll. That was my first thought anyway when I glanced over it..

I totally agree, most of the time the LLM is printing part of the training data. And what we tend to see are cherry-picked samples.

The other day I managed to dork the clouformation template that my llm was basing its code on from github(similar class structures) and got a better result working from that code. Also the way it will edit version files versus using the cli like with cargo/package.json is concerning, especially because its examples take no account of depreciation

It has really good use cases, I have been vibe coding some zsh scripts to automate some processes and it’s been amazing. No I don’t intend to actually learn zsh.

Agree that for scripts and simpler coding stuff it works well. For work I use just the bog standard MS Copilot (the one that is now integrated into Corporate M365/Teams), and it's been quite fantastic for just a general, well-tuned all-purpose LLM. I needed a simple API to update CSV files. A bit of googling led me to the deno-csv library, and I then pointed Copilot to the documentation, and it coded me up a working API after just a bit of back and forth.

One thing implied or embedded in Andrej Karpathy’s description, that I think explains the difference between influencers experience vs lay people’s experience, and is not propagated in others description of vibe coding, is that one of the essential pieces of vibe coding is that you can’t care too much about the outcome. Like if you have a specific feature in mind, the LLM might not understand how to generate it, so you might just have to skip it.