Vibe coding is when you don't review the code at all. If you're using LLMs to help you write code but you're actually reviewing what they produce (and iterating on it) that's not vibe coding any more.

This battle is almost certainly lost already, but dammit I'm gonna keep fighting anyway!

Salty version: https://bsky.app/profile/simonwillison.net/post/3ll2rtxeucs2...

> Feels like I'm losing the battle on this one, I keep seeing people use "vibe coding" to mean any time an LLM is used to write code

> I'm particularly frustrated because for a few glorious moments we had the chance at having ONE piece of AI-related terminology with a clear, widely accepted definition!

> But it turns out people couldn't be trusted to read all the way to the end of Andrej's tweet, so now we are back to yet another term where different people assume it means different things

I found out this anti-pattern where a newly coined term loses its definition as it spreads more widely is called "semantic diffusion": https://simonwillison.net/2025/Mar/23/semantic-diffusion/

> 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

That sums up vibe coding, imo.

The article talks about code quality with vibe coding, but I think that misses the point. The real problem is code knowledge. When a vibe coder inevitably needs to debug something, if they have no idea what any of the code does, or why it is the way it is, they are not going to have a good time.

Sure they can copy paste the error into the LLM and hope for the best, but what happens when that doesn’t fix it? I’ve already had to spend hours at work tracking down bugs that ending up being in there because someone just blindly accepted the code an LLM wrote, I fear it’s only going to get worse.

I asked ChatGPT for help, and it was quite helpful.

However, its code was really verbose, and fairly “messy.” Even though it worked, it didn’t work well.

I used it as guidance for training myself in the tech, and developed an approach that is far better. I had to learn the tech, and refactored the code example in a pretty major way.

Maybe some of the other tools are better, but I haven’t gotten any code that I would even consider shipping; pretty much exactly like my experience with Stack Overflow, for years.

"Vibe-coding" as it is defined, throws away all the principles of software engineering and adopts an unchecked approach into using AI generated code with "accept all changes" then duct-taping it with more code on top of a chaotic code architecture or none (single massive file) and especially with zero tests.

The fact is, it encourages carelessness and ignores security principles just to make it acceptable to create low quality and broken software that can be hacked very easily.

You can spot some of these "vibe-coders" if they believe that they can destroy Docusign in a day with Cursor + Claude with their solution.

Who's going to tell them?

The whole point of AI agents is to eventually get good enough to do this stuff better than humans do. It's okay to dogfood and test them now and see how well they do, and improve them over time.

Software engineers will eventually become managers of AI agents. Vibe coding is just version 0.1 pre-alpha of that future.

Boilerplate… is bad, right? If our languages were more elegant, we’d need less of it. It is necessary because things don’t have sane defaults or sufficient abstraction.

In particular, if the AI is able to “guess” what boilerplate you wanted, that boilerplate ought to be knowable beforehand (because the AI is not actually guessing, it is a deterministic set of rules where you type things and programs come out; it is a programming language, albeit a weirdly defined one).

I will say in terms of fixing boilerplate or doing tedious work it's a godsend. The ability to give it literally garbage formatted content and return something relatively structured and coherent is great. Some use cases I find:

- Rapidly prototype/scaffold a new feature. I can do what takes me hours/days in magnitudes of less time and saving my brain energy lol. 90% of it is usually garbage, but I just need a PoC or direction and I can sniff out what approach doesn't work (goes with the above of not doing too much at at time)

- App typically has a lot of similarly structured sections that can't be DRY for whatever reason. Fix in one area, feed to LLM how to solve the problem and then apply it to X number of other sections. Boom, edits 20 files and saves me tedious hours of doing it manually and potentially screwing it up.

- Run logs and sections of code in an initial bug to see if I'm missing something obvious up front. Helps dive into the right areas.

- Transform garbage content into something else when I can't be bothered to write a complicated regex or script for.

We have had a steep learning curve in prompt preparation (what we're doing is certainly not engineering), but Claude Code is now one-shotting viable PRs in our legacy codebases that are, well, good.

Saying LLMs are only good for boilerplate acceleration is so far from my experience that it sounds absurd.

But it's the wrong perspective. Think instead what a self driving car is to someone who cannot drive. It doesn't matter if it sometimes disengages to have an operator step in or can only handle basic local trips. It's a total game changer. AI is unlocking computers for people who have never written a line of code in their life.

This isn’t a movement or a manifesto. I’m not trying to coin a term or draw a line in the sand. I just want to articulate something I care about, now that AI-assisted coding is becoming so common.

The phrase “vibe coding” already is a "thing", if not well defined. It’s been tossed around to describe a casual, improvisational approach to programming with AI tools. Sometimes it’s playful and exploratory - which is fine in personal, low-stakes settings. But when vibe coding crosses into production software or educational tools without critical thought and human review, it can become actively harmful.

I’ve seen definitions of vibe coding that outright celebrate not reading the generated code. Or that dismiss the need to understand what the code does — as long as it runs. That’s where I draw a hard line. If you’re unwilling to engage with what you’re building, you’re not just missing the point — you’re potentially creating brittle, inscrutable systems that no one can maintain, not even you.

It’s the kind of anti-intellectual aversion to thinking for yourself that leads you to Vibe Code a CyberTruck of an app: an aggressive, self-satisfied, inexplicably pointy prison piss pan.

It plows along mindlessly — overconfidently smashed, shot at, and shattered on stage, problems waved off with “a little room for improvement” and “we’ll fix it in post”; then it’s pushed straight into production, barreling under “Full Self-Delusion” mode through crowds of innocent bystanders, slamming at full Boring speed into a tunnel painted on the face of a cliff, bursting into flames, and finally demanding a monthly subscription to extinguish itself.

Vibe Coded CyberApps are insecure thin-skinned auto-crashing cold-rolled steel magnets for hackers, bots, vandals, and graffiti artists.

It’s the kind of city planning where you paint a tunnel directly onto the side of a cliff, floor it like Wile E. Musk, and trust that the laws of physics — or software engineering — will graciously suspend themselves for you.

It's where you slap a “FREE TOLL” sign on a washed-out bridge and call it a feature, not a bug.

By contrast, what I’m calling “craft coding” is about intentionality, comprehension, and coherence. It’s about treating code as something more than a means to an end — something worth shaping with care. That doesn’t mean it’s always elegant or beautiful. Sometimes it’s messy. But even when it’s messy, it’s explainable. You can reason about it. You can teach with it. You can read it six months later and still understand why it’s there.

Craft coding doesn’t require you to be an expert. It requires you to care. It’s a mindset that values:

Understanding what your code does.

Naming things clearly.

Keeping code, comments, and documentation in sync.

Being able to explain a design decision — even if that decision is "this is temporary and kind of gross, but here’s why".

Leaving the campsite cleaner than you found it.

Craft coding has been around a long time before AI-assisted coding. I've been fortunate to read the code of and work with some great Craft Coders. But in order to learn from great Craft Coders, you've got to be willing and eager to read other people's code and documentation, not repelled and appalled by the notion.

But vibe coding has also been around since before the time of LLMs. Tools like Snap! (and before that, Logo) encouraged exploratory, playful, improvisational approaches to programming.

Kids learn a lot by poking around and building things with little upfront planning. That’s not a bad thing — in fact, it’s a great on-ramp to coding. Snap! supports a kind of vibe coding that’s deeply aligned with constructionist education: learning by making, reflecting, iterating.

The same vibe exists in educational simulations like Factorio, SimCity/Micropolis, and The Sims — call it vibe space industry, vibe city planning, vibe architecture, or vibe parenting. You drop some zones, throw up some walls, dig out a swimming pool, tweak a slider, pop out some babies, see what happens. It’s empowering and often inspiring.

But you don’t want to live in a city you vibe-mayored in SimCity, with a vibe-tunneled Boring Company loop, or ride a vibe-planned HyperLoop, or board a vibe-engineered rocket operating under “Full Self-Delusion” mode, held together with PowerPoint and optimism, headed for a Rapid Unscheduled Disassembly.

The road from vibe coding to craft coding is a natural one. You start by exploring. Then you get curious. You want to understand more. You want your code to be shareable, readable, fixable. You want to build things you’re proud of, and that others can build on.

This is especially relevant now because AI-assisted coding is amplifying both the good and the bad. Tools like Cursor and Copilot can accelerate comprehension, or they can accelerate incoherence. They can help you learn faster, or help you skip learning entirely. It depends on how you use them.

But used with intention, LLMs can support craft coding, as a "coherence engine" rather than a "chaos reactor". They can serve as a kind of coherence engine — helping you align code with documentation, keep multi-dialect implementations in sync, and build multi-resolution natural language explanations of your design. They’re not just code generators. They’re context managers, language translators, spaghetti groomers, diff explainers, OCD style critics, grammar police, relentless lint pickers, code and documentation searchers and summarizers, and conversation partners. And if you treat them that way — as tools to reinforce clarity and coherence — they can be an extraordinary asset.

So this isn’t about gatekeeping. I’m not saying vibe coders aren’t welcome. I’m saying: if you’re interested in the practice of craft coding — in learning, building, and maintaining systems that make sense — then you’ll probably want something more than vibes.

And if you’ve got a better name than “craft coding,” I’m all ears. But what matters isn’t the name. It’s the practice.

Yes some of the current AI coding tools will fail at some use cases and tasks, but some others tools might give you good results. For example, Devin is pretty bad at some trivial frontend tasks in my testing, but cursor is way better.

I have good success with web development and JavaScript in particular, on several large codebases.

I also built my own AI coding and eval tools that suits my needs, though cursor has largely replaced the AI coding tool that I built.

As you say, by the time you specify everything, you've written the code.

https://berthub.eu/articles/posts/how-tech-loses-out/

Then remember when we said tests should be the specs?

Then we said the end users are the specs?

All of them can be construed as a joke in our erratic search for the correct way to write software without those $150k developers that seem to be the only ones getting the job done, assuming they have a competent management hierarchy and stock options incentives.

[1] We have a waterfall software and I wonder whether Crockford’s license “JSON should be used for good, not evil” was meant for me

I worked at [insert massive retailer here] a few years ago and this mindset is still very much alive.

Last time i was at a faang my org also had offices in one of those “low-income countries”. So in a way we haven’t stopped.

Also, depending on how you define “low-income” then up to two thirds of the organisation i worked in was in a low-income country.

Giga-projects with 50k, 100k, 500K, lines of code are going to get decimated. By and large these programs are written to capture large audiences by offering a massive feature set. But how often is any one user ever actually needing those 100k LOC?

If LLMs can start nailing 5K LOC projects pretty reliably, and the technical moat cleared away (i.e. using an IDE to run code). Software businesses are going to see a collapse in users as people just churn out bespoke single task software for their own use case each day.

If you think it's fine because you can't prompt Gemini "Create an excel clone", you are doing the equivalent of drawing a robot with a vinyl record player in 1950 and calling it "Entertainment of the future!". In a world with functional robots, portable vinyl players for it to play music make no sense.

There are a few kinds of developers: good, bad, slow and fast. Everyone wants to be a good developer but a fast and bad developer is worse than a slow and bad developer because they end up doing so much damage.

Your end users will eventually notice how long bugs take to get fixed, how long and how often outages occur, and how long it takes to get new functionality into your software.

But beyond your end-users, you likely have competitors: and if your competitors start moving faster, build a reputation of dependability and responsiveness, your business WILL suffer. You will see attrition, your CAC will go up, and those costs get absorbed somewhere: either in less runway, less capex/opex (layoffs), higher priced or all of the above. And that’s an entire domain AI isn’t (yet) suited to assist.

There’s no free lunch.

How easy it is to maintain and extend does absolutely matter, in a world where software is constantly growing and evolving and never "finished"

Yes. But the first kind of quality is enabled with the second kind.

Until we live in a faultless closed loop[1], where with AI "the entire application can be rewritten just as easily as making a small change." you still need the second kind.

[1] and it's debatable if we ever will

Moreover, I suspect the second kind of quality won't completely go away: a smart machine will develop new techniques to organize its code (making it "neat and clear" to the machine), which may resemble human techniques. I wouldn't bet much on it, but maybe even, buried within the cryptic code output by a machine, there will be patterns resembling popular design patterns.

Brute force can get results faster than careful planning, but brute force and planning gets results faster than both. AI will keep being optimized (even if one day it starts optimizing itself), and organization is presumably a good optimization.

Furthermore: LLMs think differently than humans, e.g. they seem to have much larger "context" (analogous to short-term memory) but their training (analogous to long-term memory) is immutable. Yet there are similarities as demonstrated in LLM responses, e.g. they reason in English, and reach conclusions without understanding the steps they took. Assuming this holds for later AIs, the structures those AIs organize their code into to make it easier to understand, probably won't be the structures humans would create, but they'll be similar.

Although a different type of model and much smaller, there's evidence of this in auto-encoders: they work via compression, which is a form of organization, and the weights roughly correspond to human concepts like specific numbers (MNIST) or facial characteristics (https://www.youtube.com/watch?v=4VAkrUNLKSo&t=352).

From a business perspective, this is what's exciting to a lot of people. I think we have to recognize that a lot of products fail not because the software was written poorly, but because the business idea wasn't very good.

If a business is able to spin up its product using some aspect of vibe coding to test out its merits, and is able to explore product-market fit more quickly, does it really matter if the code quality is bad? Likewise, a well-crafted product can still fail because either the market shifted (maybe it took too long to produce) or because there really wasn't a market for it to begin with. Obviously, there's a middle ground here, and if you go too far with vibe coding and produce something that constantly fails or is hard to maintain, then maybe you've gone too far, but it's a balance that needs to be weighed against business risk.

An AI will be as flustered by spaghetti as a human. Or not so much flustered it will just make willy willy changes and end up in an expensive infinite loop of test failures and drunken changes to try and fix them.

Tell that to the vagus nerve in the giraffe.

> Do you think AI assisted coding has a negative impact on developer's growth?

Almost certainly. Easier to do things the easier way, but you never learn unless you do it the hard way. Maybe that won't matter -- i.e., the skills that one would've learned are now to be subsumed by AI. But as long as humans are needed, it will be necessary to build deep skills and understanding of systems, which AI coding does not seem to give us.

> Are today's juniors never gonna reach senior levels because of AI assisted coding?

Some definitely will, same as some people today get really good at programming in assembly. Almost certainly fewer will -- at least to what we today consider "senior".

> Is the need for developers gonna increase in the longterm but decrease in shortterm?

It all depends on the shape of the curve -- how far AI coding will be able to take us, and how fast.

It turns out to mostly serve the same purpose as low-code/no-code, where devs are needed to do 'serious' work and mixing the two becomes difficult? I doubt there'll be a slump at all.

It turns out to obviate the need for devs entirely, but only for certain common tasks -- or, it speeds up devs across the board by enough that significant double-digit (e.g. 40-50%) percentages of their work is now handled by AI? Then yes I expect we'll see a slump of some degree. But if it's not close to a 2x multiplier I expect we slump back to the first category, given just how much code it's clear there is still to be written.

On the other hand, though: if AI continues to advance and actually replaces developers 1-to-1 at lower cost? We're probably in for a sharp exponential and the question isn't how many developer jobs will be left, it's how long humanity has left.

Paying attention saves you energy in the long run. In the words of Gus Levy, nothing wrong with being greedy, but there's two types of greed, long term and short term; the latter is stupid.

Of course for a throwaway project it's irrelevant by definition. But the problem is in professional work you cannot get away with low effort, you're just pushing your problems to the back and they'll come back with interest. Vibe coding is simply moving your problems to other people, or to yourself at a later point in time.

For reference, Tailwind 4 will not read in config files by default (which is the older behavior) - the encouraged practice is to configure customizations directly in the CSS file where you import Tailwind itself.

This won't be 100%, but that'll be the companies who're able to hire somebody to parse the problems that arise. Without that engineer, they'll be doing what OP calls 'vibe coding', meaning they'll neither understand nor be able to fix when the whole thing blows up.