This post is the spiritual successor to my other post about AI coding: AI-Generated Code is Good, Actually.
In my previous post on this topic, I asserted that AI-generated code is bad, but in the same kind of way that junior-engineer-generated code is bad, and still very useful in the right circumstances. That’s still somewhat true, but beauty is in the eye of the beholder here.
What’s “vibe coding”?
If you live your life away from spaces where people talk about writing code with LLMs a lot (please invite me over, it’s dark out here), you may be unfamiliar with the term “vibe coding”. I don’t think the phrase even existed when I wrote the last post.
Essentially, it describes writing software using AI, especially when the person doing it isn’t an experienced software engineer. This is, of course, threatening to experienced software engineers, and therefore always bad, and anyone who does it is a danger to society. That’s what LinkedIn tells me, anyways.
This is, as with all things, a matter of degrees. A newbie vibe coding a demo app for his own use, or to learn a new language/technology/etc., is almost universally not a problem, and you’d be a snob for thinking it is. A nuclear engineer vibe coding the auto-shutoff driver for the nuclear power plant he works at is definitely a problem. But the vast majority of use cases are between those two extremes.
I vibe code sometimes, and it’s pretty good
Anthropic’s Claude Code is basically a daily driver for me at this point. I can hear LinkedIn chirping from my pocket now: “But Austin, you’re a Real Engineer, you went to school and everything!” Yes, yes. But these days I find my time is at an extreme premium. I was already using LLMs to generate a lot of my code for me, but I was doing it on the web, so I was copy/pasting between my IDE and the browser. As you can imagine, it got pretty unwieldy.
Claude Code is agentic, meaning it has agency to complete tasks, not just spit out text. For my purposes, I run it from the terminal, in the repo that I’m working in. It can read the codebase at will, and it can make edits to files in that folder (and subfolders). This is suddenly a huge productivity boost: instead of copying code into the browser, telling Claude what I want it to do, and then copying out the parts I want, I can tell it what I want to do, it will read the codebase and figure out how/where to do it, and then make the edits itself.
Now, to keep true to the theme of my previous post, I don’t let it just do whatever it wants. When it wants to make changes, it gives me a diff, and I get to do a mini code review. I can either approve the changes, or reject them and tell it what I want to do differently. I have to do that a lot, but not nearly as often as you might think. (There’s also an option to skip the approval phase and let it go crazy, but I’m not that far down the well.)
You can also give it permission to run tools. I let it run commands sometimes (e.g. find), but typically I tell it no, either because I don’t trust it, or it just won’t work for whatever reason (the context is wrong, the tool isn’t installed where it thinks, etc.).
So where does this leave us?
I feel perfectly comfortable to vibe code, because a) I know what I’m doing, b) it saves me an inordinate amount of time and typing, and c) I’m not writing safety-critical code. Bugs are bad, but bugs are also inevitable in all software endeavors. Testing is as important as ever, because all coders are fallible, humans and machines alike.
There’s a universal truth that reading code is harder than writing it. This truth leads some people to believe that the “code review” method of human oversight I’m advocating is fraught with peril. I’ll answer that the way I answer many technical problems: just git gud. (I’m half-joking, but I have found that doing things this way has also vastly improved my ability to spot bugs on spec.)
So, don’t vibe code your way to nuclear meltdown, and don’t use AI to replace knowing what you’re doing, and you may become that 10x engineer LinkedIn has been promising me exists forever.

