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.

> 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.

"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.

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 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.

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

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.

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

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.

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).

Tell that to the vagus nerve in the giraffe.

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.

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.

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

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.

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

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

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.

> 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.