So what have we redefined vibe coding to mean exactly?
The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't.
Are people now using this term to mean "giving an AI agent broad tasks"?
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!
> 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 don't know if it's you and I (and some others) who are just uptight sticklers or something, but it bothers me a ton too. Same thing happening with "open source" in connection to LLMs, where suddenly some companies have decided to try to redefine the meaning, people lack the care to make the distinction.
In a dream world, each new terminology goes through an RFC to figure out a meaning we all (some of us) can agree to, so at least we can link to an angry RFC when people continue to misuse the term anyways.
Yeah that "open source" thing is SO frustrating. We have a very well established definition for what "open source" means: https://opensource.org/osd
I have a suspicion that Facebook insist on calling their open weights models "open source" because the EU AI act says "This Regulation does not apply to AI systems released under free and open-source licences" but doesn't do a good job of defining what "open-source" means! Bottom of this page: https://artificialintelligenceact.eu/article/2/
> The licence should be considered to be free and open-source also when it allows users to run, copy, distribute, study, change and improve software and data, including models under the condition that the original provider of the model is credited, the identical or comparable terms of distribution are respected.
In this wonderful future where we can leave responses longer than a tweet and have conversations longer than 30-second sound bytes, that people can understand, well at least get them understanding your point of view, even if they don't join the team. Having a succinct explanation for the sticklierness is still key though. For not letting Mark Zuckerberg co-opt the term Open Source, it's that it's not open source if I can't see why the LLM won't tell me how to make cocaine. Need to workshop that a lot so it fits on a t-shirt, but that is the gist of it.
I don't really think it's that people couldn't be bothered to read the tweet. It's that vibe coding is very good term but a niche activity. Meanwhile there's a much less niche activity that people would like a name for. I think if we want to save the term for the niche activity we'd need to invent a good one for the less niche activity.
> yeah bro, leave the easy and fun part (googling and typing code) to an AI, and let the human deal with the tedious and error-prone part (checking all the edge cases)
re: "semantic diffusion", sometime the opposite happens. Consider "meme" which was once very general and is now much more specific. "semantic speciation"?
It's as if the culture wants a certain level of specificity for a phrase and if you start too far from it, it'll ignore your wishes and drift to that level anyway.
So the issue you're taking with 'thing is crap' is not 'thing is not crap', but 'you have redefined thing to be reviewed and held to standards and then called it crap'? And so, what, if we just accept it as it is, it's not crap? Or it is, but it everyone knows it (do they?) so it's not worth calling crap?
Well, let's be clear: the original definition was actually the one that Simon describes here, and there's no ambiguity around that fact since it came from one specific tweet where Andrej Karpathy laid out a definition for the term quite directly:
"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. ... 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 ... 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. ..."
So yes, "not reading the code" is baked in quite specifically.
> 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.
> 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
I strongly believe it also applies to the AI itself.
If the AI wrote the code to the top of its ability, it doesn’t have the capability to debug said code, because its ability to detect and correct issues has already been factored in.
You end up with a constant stream of “I see the issue, it’s: <not the actual issue>”, which is consistent with my experience of trying to have LLM’s debug their own code without basically doing the work myself and pointing them to the specific actual issue.
It's fine for tooling or weekend project. I did it on an internal tool. It's got so much functionality now though, that Cursor struggles. It was great when I had a blank project, needed x, y, z and it went off and did It's thing. The moment the project got bug and need modifications, it is better that I do it myself.
Also I am a backend engineer. I don't know what kind of code it's producing for my front end. I just hit accept all. But seeing how it does the backend code and having to prompt it to do something better (architectural, performance, code reuse) I have no doubt the front end of my pool is a pile of poop.
I fear that management will see these small quick gains and think it applies to everything.
I'm of the opinion now, that vibe coding is good if you are familiar with the code & stack and can ensure quality. You don't want to give it to a product owner and have them try to be an engineer (or have a backend dev do front end, vice versa).
Like you, I’m far too risk averse to not fact check everything an LLM outputs, but I’ve also fixed bugs that have been present for 5+ years. Maybe at a certain point you can just wait for the next generation of model to fix the bugs. And wait for the generation after that to fix the newly introduced and/or more subtle bugs.
> 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
And I’ve also had to spend hours at work tracking down badly copy pasted stack overflow code, or from other places in the codebase that didn’t do what the programmer thought it did. A shitty carpenter will build a shitty staircase whether they have a chisel or a dremel
But what about a middling carpenter? Moralism about "shitty programmers" is not helpful when we're really talking about aggregate trends, and when it comes to aggregates -- tools do matter. Defaults matter. Precedent matters. Things like these are why culture has such an outsized impact on a teams' ability to ship good, quality code over a long period of time.
One difference is that orgs are tracking AI coding assistant usage as a (positive) metric, soemthing they never did with SO. Given finite time, being pushed to AI code whether or not it makes sense or is efficient in either quality or delivery time, and with no relief of time constraints, means other things will fall by the wayside.
A good carpenter will build a shitty staircase if he is forced to use the wrong tool, given a timeline that doesn't accommodate it, and paid for delivering something that superficially resembles a staricase on time regardless of quality.
> Sure they can copy paste the error into the LLM and hope for the best, but what happens when that doesn’t fix it?
Neither side cares unfortunately.
When users attempt to prompt away their problems without understanding the error and it doesn't solve it, that is still good news for Cursor and Anthropic and it is more money for them.
The influencers encouraging "vibe coding" also don't care. They need to be paid for their Twitter money or YouTube ad revenue.
It's like doomscrolling. Originally it meant compulsively reading depressing content about the state of the world, wars, etc., explaining the "doom" part, but eventually it evolved (or perhaps devolved) into just meaning obsessively checking any sort of online content whether or not it was depressing.
in a lot of ways that is understandable when so much of the news is bad news, if all the highlights of the day point toward the world going to hell even reading a normal newsfeed can feel like doomscrolling.
And I think that *horribly* muddies the definition because programming and getting a bit of AI help here and there (since it's read the docs better than you have, and scanned Stack Overflow for common problems and mistakes more thoroughly than you have) is, imo, a very, very valid way to program; but you're still very much in the driver's seat. It's not creating whole design patterns, etc, for you.
I wonder if maybe some people have been trying to jump on the "I have also tried vibe coding" train without being willing to hop as far as the term initiator defined it.
I definitely still stick to the "Vibe Coding is when you don't read / grok the code" definition.
I agree - I'm not endorsing this broad usage of the term, just noting how I see it used in practice. This seems to be half driven by grifters on social media promoting their AI coding course du jour and half by people who just discovered Cursor, Windsurf, etc., and think any use of those tools counts.)
Another commenter said these people only read half of Karpathy's tweet - I disagree. I don't think they read it at all, have heard the phrase, and are using it with reckless abandon.
In the project I’m currently developing (a rewrite of an old timer app), I wanted to implement drag-and-drop icons, but didn’t have much experience with UICollectionView, which is one of the iOS technologies that displays a matrix of elements.
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.
It is a scam. Invented by someone who is an AI researcher, but not a software engineer which the latter rigorously focuses on code quality.
"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.
Saying that Andrej Karpathy is "an AI researcher, but not a software engineer" isn't a very credible statement.
If you read to the end of his tweet, he specifically says "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."
Your comment might make sense when it's scoped down to that article when he coined that term. If you take a look at his larger collection of statements on software engineering recently, it's hard not to put him in the bucket of overenthusiastic AI peddlers of today.
> Saying that Andrej Karpathy is "an AI researcher, but not a software engineer" isn't a very credible statement.
I think it is. He is certainly a great AI researcher / scientist, but not really a software engineer.
> 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."
So is that the future of software engineering? "Accept all changes", "Copy paste stuff", "It mostly works" and little to no tests whatsoever as that is what "Vibe coding" is.
Would you yourself want vibe-coded software that is in highly critical systems such as in aeroplanes, hospitals, or in energy infrastructure?
Where did Andrej say it was "the future of software engineering"? He very clearly described vibe coding as an entertaining way to hack on throwaway weekend projects.
> The job of a software developer is not (just) to churn out code and features. We need to create code that demonstrably works, and can be understood by other humans (and machines), and that will support continued development in the future.
> We need to consider performance, accessibility, security, maintainability, cost efficiency. Software engineering is all about trade-offs—our job is to pick from dozens of potential solutions by balancing all manner of requirements, both explicit and implied.
> We also need to read the code. My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.
> If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development. The usage of an LLM to support that activity is immaterial.
> Where did Andrej say it was "the future of software engineering"? He very clearly described vibe coding as an entertaining way to hack on throwaway weekend projects.
... And then a few weeks later, my boss' boss scolded the team for not having heard of the term, and told us to learn and use vibe coding because it's the future.
> Saying that Andrej Karpathy is "an AI researcher, but not a software engineer" isn't a very credible statement.
Broadly I agree with the two other replies: his 'day job' has not been coding in some time, so I would put him in the same bucket as e.g. a manager who got promoted out of writing code 5-10 years ago. I do want to understand where you're coming from here -- do you think that's a fair characterization?
I absolutely hate the polarization around "vibe coding".
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.
No, I actually do want them to eventually be better than humans at everything.
I'm okay with directing AI to write exactly the software I need, without having to manage "stakeholders", deal with the egos of boomers up the management chain, and all the shitty things certain people do in any organizations that get large enough.
> "And then in twelve months, we may be in a world where AI is writing essentially all of the code," Anthropic CEO Dario Amodei said at a Council on Foreign Relations event on Monday. [last week]
> 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.
I agree with that. The problem I have is that people are getting sucked into the hype and evaluating the results of those tests with major rose-colored glasses. They glaze over all the issues and fool themselves into thinking that the overall result is favorable.
I think the issue most of us have, is that vibe-coding is not being treated as a dog fooding experiment, but as a legitimate way to deliver production code.
I am already seeing "vibe coding experts" and other attempts to legitimize the practice as a professional approach to software development.
The issue is clear, if you have accepted all PRs with no reviews as vibe-coding suggests, you will end up with security and functionality flaws.
Even if you do review, if you are the type of developer who thinks you can vibe-code a serious project, I doubt you are interested in regular security reviews.
Lastly, businesses are long lasting projects, and the state of AI is constantly evolving. Your codebases stability and speed of development is your businesses success, and if only the AI model who built it understands your code, you are on shaky ground when the models evolve. They are not constantly forward evolutions, there will be interactions that fail to fix or implement code in the codebase it previously wrote. Human engineers may not even be able or willing to save you, after 3 years of vibe coding your product.
> but as a legitimate way to deliver production code.
Beyond the developer side of the hype that gets talked a lot, I'm witnessing a trend on the "company side" that LLM coding is a worthy thing to shell out $$$ to, IOW there is an expected return on investment for that $$$/seat, IOW it is expected to increase productivity by at least twice that much $$$.
Companies already have a hard time throwing away the prototype - god forbid you showcase a flashy PoC - and priorise quality tasks (which may need to run over a quarter) over product items (always P0), and in that ROI context I don't see that LLM-assisted trend helping with software quality at all.
Anyone who has maintained code that written by engineers new to the industry, who didn’t understand the context of a system or the underlying principles of what they’re writing, may disagree.
The hype levels are so overwhelming that AI coding could never hope to meet them. I've tried having a highly-ranked AI
coding app write unit tests for a relatively complex codebase. 80% of the generated test cases failed. But an experienced human such as myself could use those as a starting point since it took care of some of the tedious boilerplate. It genuinely saved me some time and annoyance, but could never hope to replace even the lowliest competent junior dev.
That's what AI is good for right now - boilerplate acceleration. But that's clearly not enough to drive the immense transfers of capital that this high ecosystem demands.
I do somewhat worry that AI will harm language development.
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 think there will be an ossification of current languages/frameworks/libraries. The technologies that already have a large amount of documentation, tutorials, example code, etc. will have a huge advantage over a brand new language because all of that content will be in the pretraining for all LLMs. Would you rather use JavaScript/TypeScript and Python (which will work relatively well with LLMs), or some brand new thing that will barely work at all with LLMs.
It's tough to say in a vacuum. Generally, the lower level you go, the more "boilerplate" you'll need. That cost of iteration is to give such programmers more control over the task.
So python may sneer at such boilerplate. Whereas Rust would prefer being more verbose.
I'm finding this as well. I can't trust it to go beyond boilerplate or PoC's or I risk lagging behind in understanding and actually slowing down in the long term. Best workflow is to tackle silo'd problems and iterate on them with LLM.
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.
AI is to SWEs what self-driving cars (or like features on new cars) are to taxi drivers. A neat thing that may make some basic things a little easier.
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.
> AI is unlocking computers for people who have never written a line of code in their life.
I don't think I can dispute the claim, but it feels more like someone who can't build a house being able to do it now that they have YouTube tutorials. Unless the person was already quite smart and competent, the house will probably have significant structural issues.
Is that a bad thing? For housing, governments the world over seem to agree that it is. But coding has never had a real attempt at regulation. You're going to end up with "vibe coded" production code handling people's personal and financial information, and that is genuinely a bad idea. A novice will not spot security issues, and AI will happily produce them.
I disagree that coding doesn’t have regulation. If you have never developed code in a professionally regulated industry such as Airworthiness then you haven’t been exposed yet to an area that requires rigorous process. There are regulated areas where software is regulated.
I have DIY’d an addition onto my house with professionally architected blueprints and engineering seal. During various stages, I would call the City who would send code inspection officials to incrementally sign off on my project’s progress. Other than pouring a new slab of concrete and electrical, I built it all myself to code. I followed YouTube tutorials.
My point is that DIY isn’t the issue - lack of oversight is. With standards, expert input, and review processes, even non-experts can safely build. AI-assisted coding needs the same approach.
All true but tell the average programmer that you think their industry should be regulated and they should potentially be held liable for their code.
This is not a popular opinion on software development circles - unless you're already in one of those regulated fields, like where a software engineer (a literal accredited engineer) is required.
But it's been an increasingly common talking point from a lot of experts. Bruce Schneier writes about it a lot - he convinced me long ago that our industry is pretty pathetic when it comes to holding corporations liable for massive security failures, for example.
We have to mature as an industry. Things like not staying up to date on third party dependencies, not including cybersecurity as part of the build pipeline, lack of static and dynamic analysis, not encrypting at rest secrets, etc
It is already costing millions of dollars and it’s just accepted.
I couldn’t build a house, but I did learn a lot of smaller skills I would have otherwise called a pro in over. Turns out changing a toilet is pretty much putting it in place and screwing on the pipe, and you can program keys to my Xterra by toggling certain controls in a certain order.
I wouldn’t expect a vibe coder to build a full featured app on vibes alone and produce a quality codebase, but for smaller tasks and apps it is just fine.
>It doesn't matter if it sometimes disengages to have an operator step in
I'd say that breaks the entire concept of "self driving" at that point. If people are fine with some of those "actually Indian" stories where supposedly AI powered tools turned out to have a significant human element to it, why not just go back to the taxi? You clearly don't care about the tech, you care about being driven to a destination.
I'd like to know which app and model you were using, along with the prompts.
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.
LLMs don’t even understand fucking TypeScript, which you would expect a computer program to be able to understand. I can’t get it to write valid Drizzle code to save my life, it will confidently hallucinate method imports that don’t even exist.
Claude Code refactored numerous projects for us into TS, often one-shotting it. Saying LLMs don't understand TS (which may be true, in that LLMs questionably understand anything) says more about your perception than model and agent abilities.
I have also had a really hard time getting Claude and Gemini to create valid TypeScript in somewhat complex legacy projects. Sometimes it will do the most kludgey things to sort of make it work (things a human developer would never consider acceptable).
Right, LLMs don't understand TS, because they're not integrated with it. When they come across something they don't know, they just start hallucinating, and don't even verify if it's actually valid (because they can't)
LLMs can't, but agents can. They can read documentation into context, verify code, compile, use analysis tools, and run tests.
Hallucinations do occur, but they're becoming more rare (especially if you prompt to the strengths of the model and provide context) and tests catch them.
There's a difference between AI assisted "vibe coding" and what I’ll call (for now) "craft coding."
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.
This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necessary, and will just build the thing exactly as written in the spec. The result being that to get the end product you want, the spec needs to be so finely detailed and refined that by the time you get both specification and implementation to the desired quality level, it would have been the same amount of effort (and probably less time and frustration) to just build the system in-house.
Of course outsourcing software development hasn't gone away, but it hasn't become anywhere near as prevalent and dominant as its proponents would've had you believe. I see the same happening with AI coding - it has its place, certainly for prototyping and quick-and-dirty solutions - but it cannot and will not truly replace human understanding, ingenuity, creativity and insight.
Somebody will have to add some syntax to these LLM prompting systems to include text that doesn’t get converted. So the next round of PMs can ask you to documents your prompts).
> As you say, by the time you specify everything, you've written the code
Sadly not when it’s a 2000 page word document with a million formatting quirks and so many copy-paste versions you don’t know if you should trust “reqs_new25”, “reqs_new25v1” or the x number of other copies floating around.
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 think this erratic manner of trying to find the correct way is the issue. I am currently nearing my 2nd year at a company A in my industry, and while I did know they all kinda suck in their own special way, I honestly had no idea it was this bad until I had to try to make this craziness somehow work for us. Even if there are standards, I do not see people following them. Last year, the one girl, who did seem to try to follow some common sense approach, got fired for effectively using common sense against big boss wishes.
What I am saying it is a mess from beginning to end and I am honestly not sure if there is one factor that could solve it..
> Last year, the one girl, who did seem to try to follow some common sense approach, got fired for effectively using common sense against big boss wishes.
What did your manager say when you said this to them?
Sigh, sadly, I didn't, because I found out largely after the fact and, more amusingly, after record profit year at the company with the project in question clearly being a major part of everyone's goals ( not mine, I was kinda roped in at the last stages ).
that girl doing stuff is one thing, but if you're so scared you can't even ask your direct boss (not the big boss, obvs) a question, like, yo, I dunno.
Do any of these vibe coding tools write out the prompts as specs and then keep the specs up to date as you continue prompting? Seems like specs == formal prompts.
You don't need a tool for that. "You're going to assist me in writing a detailed software spec in markdown. At each step adjust the document to incorporate new information. Suggest improvements and highlight areas which have been ignored so far. Initial description: ..."
If you have multiple of those, you can tell it about required sections / format, or provide a good past example.
> This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications
I worked at [insert massive retailer here] a few years ago and this mindset is still very much alive.
In my experience, directly hiring (or hiring through a local company) developers in a “low-income country” - in my experience, Eastern Europe and Latin America - goes a lot better than just contracting out a body of work to a third party. Especially if your company is already fully remote, you’re able to get developers who integrate onto your team just like American devs, and are just as good at coding.
No, when I was at a large, well-known company a year ago, job listings were 2:1 off-shore (India, South America) vs on-shore. There was also an increasing amount of contractors used, even for public-facing stuff you wouldn't expect.
It’s sad you’re getting downvoted by gatekeepers. It’s absolutely a good thing that more people have access. Maybe not for inflated costal salaries and egos, however.
Software is going to completely change. The writing is on the wall, it's just a matter of who can step back to see it.
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.
> it's just a matter of who can step back to see it
I’m not sure why those fully bought into the AI hype so often dismiss anyone who’s less bullish as simply too small-minded to see the writing on the wall.
That aside, while I do think software is going to change, I’m not sure that I agree with your particular version. What examples of apps with 100k, 500k+ LoC codebases are going to get decimated? The biggest successes in software today have moats around inventory or network effects. Are people going to make their own Netflix or Uber? Even at a smaller level, is the idea that local gym owners are going to replace gym management software with their own mini apps? Or restaurants are going to do their own point of sales apps? Unless AI can make the cost of maintaining software something close to zero time, which is a really tall order, why would business owners waste time on something outside of their core business. And if this is such an untapped opportunity why didn’t we see the start of it with the no-code movement?
Will a big chunk of the software market fall off and be replaced by custom mini apps that the layperson crafts with AI? Maybe? But I don’t see how one justifies the level of confidence I see from these predictions.
Because, as we all know, what is important about coding is outputting lines of code.
This is the main difficulty, this is were IA will change the game forever.
Thinking about the code you write, that's worthless, do not do that. Improving a large code base ? Again, no need to think to do that. Just inject random lines of code and it will do the trick.
Of course, in a world where your code has no value because it's just a copy/paste from elsewhere that has a low lifetime expectancy, IA is shinning.
But if you want something a bit more useful, a bit more clever, a bit more adapted to your use case, IA sucks. Because IA do not think.
IA is a threat to dev that do not think. Good ridance, they won't be missed.
> treat the AI like a super-speedy but junior developer on your team
That sounds like it's going to take a lot more time that just writing the code for an experienced developer. The issue with AI for me is that it produces plausible-looking code which requires a lot of attention to read through, because things that look superficially "right", including any justification in code comments, can actually have really problematic flaws.
I remember when I'd rushed a piece of work when studying, I had a lecturer who told us something like:
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.
He could have been copying General Kurt Hammerstein. Paraphrasing here:
There are four kinds of military officers: smart and lazy, smart and hard working, dumb and hardworking, dumb and lazy.
Keep the dumb and hardworking away from any high level position. They actively make things worse. Dumb and lazy are useful for simple tasks with oversight. Smart and hardworking are excellent for high level staff and analyst positions.
The Smart and Lazy should be saved for high level command. They expend only the energy necessary to get the job done and then focus on the next important task.
Except you ask it to not to. Sure it's far from perfect but honestly that is not an issue. If you ask Claude to study and document the codebase and then write unit tests I am sure there are only very few broken ones, less hallucination more like real small bugs.
I've found utility + speed go up the more conservative (in number of lines) the model generates. If it only completed a line it's much more likely to be exactly what I was about to type
As a consultant the majority of my work is around business process automation and integrating cloud systems. We build a lot of small "applications" that change almost constantly. The number of concurrent users is low, the lifespan of the software typically short and to justify the effort has to be done quickly and efficiently.
It's 100% "value engineering".
AI agent pairing has been an absolute game changer. It can single shot most requirements and refactors. I basically am just writing technical requirements and reading pull requests all day now.
I actually think the quality of the output has gone up significantly because you can just accomplish much more in the same limited budget.
Yes not all coding is equal. A bit like not all wordsmithing is equal. A presidential speech is not the same as an airplane safety announcement, even they can both be encoded as words.
Different people clearly mean different things when they talk about software quality. There is quality as perceived by the user: few bugs, accurately models the problem they have, no more complicated than necessary, etc. Then there is this other notion of quality as something to do with how the software is built. How neat and clear it is. How easy it is to extend or change.
The first kind of quality is the only kind that matters in the end. The second kind has mattered a lot up until now because of how involved humans are in typing up and editing software. It doesn't need to matter going forward. To a machine, the entire application can be rewritten just as easily as making a small change.
I would gladly give up all semblance of the second kind of quality in exchange for formal specifications and testing methods, which an AI goes through the trouble of satisfying for me. Concepts and models matter in the problem domain (assuming humans are the ones using the software), but they will increasingly have no place in the solution domain.
The second type of quality is necessary to achieve the first type of quality for systems with nontrivial levels of complexity. It doesn’t need to be perfect, or even close to perfect, but it does need to be “good enough” -
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.
Software architecture was never about code elegance, it’s about making it easier to get reliable results. And that’s mostly about using automated tooling to check correctness and easy to understand and to modify modules.
That’s the easiest way to get both definitions of quality as it’s way esier to test isolated modules and their integration than testing the whole system as a whole. And way easier to correct wrong code.
> Software architecture was never about code elegance, it’s about making it easier to get reliable results. And that’s mostly about using automated tooling to check correctness and easy to understand and to modify modules.
The first isn't entirely true, and automating tooling is actually quite poor at doing any sort of architecture analysis since the "right" architecture is heavily dependent on factors you cannot see in the code itself: What sort of SLO are you setting? What is your services load and usage pattern (read heavy? write heavy? blend?). Read heavy and high availability? You may want CQRS, but if the service is only experiencing light loading that could easily be over-engineering. Tooling won't help you identify that; you'll need experienced engineers to make judgements.
Isn’t that system design? And automated tooling is for correctness, not performance or availability. So things like linting, tests runner, static analysis and the like.
There seems to be a world in software where "it works" well enough to grow a large user base to achieve a a large valuation and then dip out is also a viable option.
Growing/evolving the code does not matter because the product no longer matters after the founders have made a large sum of money.
I hear what you're saying; but the implications seem ... net harmful? If you're actively hacking something together with the intent of boosting a valuation, selling your company and GTFOing before your purchasers figure out the bag of unmaintainable garbage you've sold them, that ...
You're harming:
* your customers who trusted you
* the people that purchased your product
I think "grift" is a good term (GPT recommended 'predatory exit' as an alternative) for what a team that's done that has done.
There’s nothing wrong with iterating fast or building MVPs. But when teams knowingly pass off a brittle mess to others, they’ve stopped building products and started selling lies.
I was not trying to imply that it was not. Just observing that when money is on the table there appears little incentive in some cases to build a good product.
Or to follow good engineering practices because the founders & investors already made money without it.
> The first kind of quality is the only kind that matters in the end.
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.
The problem domain is part of the solution domain: writing a good specification and tests is a skill.
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).
> The first kind of quality is the only kind that matters in the end.
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.
Low/no code MVP solutions have existed for a long time. Vibe coding seems like you'll get worse results than just using one of those, at least from a bug/support standpoint.
You are talking about an imagined future not current reality.
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.
> The second kind has mattered a lot up until now because of how involved humans are in typing up and editing software. It doesn't need to matter going forward.
The problem is that the first kind of quality is something that's hard for even human programmers to do well, while AI is, like the rest of the tools that came before, much better at the second.
Are today's juniors never gonna reach senior levels because of AI assisted coding ? Do you think AI assisted coding has a negative impact on developer's growth ?
Is the need for developers gonna increase in the longterm but decrease in shortterm ?
Those are just some of the questions that are in my head lately. I would appreciate other people's opinion.
> 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.
I think it is a losing battle. People are energy preserving creatures and we skip paying attention if we can. Because paying attention is effort. Vibe coding is exactly this, low effort development and thus is enticing. Now if we can get away with low effort why shouldn’t we? I am not advocating serious NATO missions to be vibe coded for trajectories, no. When billions are at stake no way. But what if billions are not at stake? What if nothing is? This weekend I added a way to maximise my QApplication app. I just asked Claude code to do it and tested it. It worked. That is all I need for my own app that I use. It’s not that I don’t have any other users but works on my machine is the motto of this specific free and open source app.
>People are energy preserving creatures and we skip paying attention if we can.
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.
Running AI itself is not low effort though, far from it at current efficiency levels it burns way more energy to produce outputs than humans. Setting latest advanced models to think about the problem on your behalf doesn't necessarily make it low effort overall.
Vibe coding is first and foremost moving some of your problems to the AI and that can be suffice even in professional setting where there's a lot of mundane requests, e.g. setting up slack alerts, running simple data transforms or figuring out one-off data analysis. Maintainability is less of an issue on tasks where it can be done from scratch if need be.
If your situation is result-driven and easily verifiable AI-driven solutions are absolutely appropriate.
Vibe coding for me meant a roll-the-dice approach to building something that world. Never a care for strong architecture or good code standards. Allowing anyone to become an "engineer". A friend of mine, who can't code, used Cursor to build fully functional Nextjs web apps. I was impressed. Vibe coding is a super power for average people.
I do think this article fully grasps that change. Using AI to do tasks is not vibe coding. At least to me.
When will the first vibe coding book come out I wonder?
I mainly use vibe coding to figure out how hard something is to do if I would do it 'for real', so I vibe code working prototypes, often to find out there is no way this is feasible and, more often, finding it is easier than I thought it would be. When I have an issue, I search for a library to solve that issue, but to figure it it does and if it does in a friendly way, I have to try it, so I ask claude to give me my example in that library. I already know something is up if it doesn't work first shot; to me is not a shock that 99.9999% (well that is actually not true of all language ecosystems but the most popular ones) of all libraries out there are total garbage with very strange 'opinionated' abstractions/choices in them that truly suck and actually make some use cases impossible without changing the library itself even though it says in the manual it is possible but without an example. In that case the LLM usually hallucinates a parameter or function that it doesn't have but that is from another library or does not exist at all, ideally needed to implement said use case. LLMs save me a ton of time there and I assume it's low quality as I won't use that exact piece of code anyway, but now I know the effort involved to meet my specific use case.
Wanted to say something similar : high-quality code is not an excuse to make something that doesn't "work" (in regards to sales, usefulness, iterations, learning - all for which vibe coding are a perfect fit IMHO)
This is common sense. The whole article read like they asked ChatGPT to fluff one sentence "review vibe code with a human before pushing to prod" into an entire article.
Not an excuse, but maybe an explanation. I was just talking to someone who was bragging about getting the cost of coding down to a penny a line. Seems like an insane metric to use, to me, since it takes no account of features developed or maintainability/modifiability.
I think all this rests on the unacknowleged fact that most software never goes into production. When you have a choice between paying expensive humans to create software that works vs cheap AI to create software that doesn't, if nobody is ever going to use it, the AI option is the one to pick.
>In essence, let the AI handle the grunt work, not the brain work.
And importantly make sure the user doing the brain work has the experience and support to do it properly. The XY problem can cause a lot of damage with AI agents that implement what's asked of them instead of asking why.
I don't mean to be dismissive (here goes, though) but the whole article boils down to one point, and it's one that frightens me that it needs to be repeated so often: use AI as your intern, not your replacement
I feel like people don’t really understand that ideology - if all you ever do is break things (or produce broken things), then you’re not actually moving fast at all.
It's hard to take anyone seriously who takes the term "vibe coding" this seriously, considering that the whole thing spawned from a casual tongue-in-cheek tweet. I recently saw a job posting for a "Vibe Coder". Nuts.
Given that o3 just spun its wheels endlessly trying to correct a CSS issue by suggesting to create a "tailwind.config.X" file despite being given the package JSON which contained a clear reference to Tailwind 4x - I'd say any engineer capable of reading and learning from basic documentation.
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.
Tell the AI to comment above the include why it uses a specific version, ask it to document the version and it's specific quirks after fixing it with it.
Not sure how o3 is generally at coding, but this kind of meta information works well for me to avoid version missmatches with Claude and Gemini
It's kinda important that the AI finds the issues itself so it can properly document it in her own words.
I'm a big booster of AI, but this doesn't even make sense. Any project using even the very best code generator in existence is going to need to be stewarded and tightly monitored by a competent programmer. AI is miraculous, but can't do crap reliably on it's own.
Whatever percentage that can hire an engineer at all.
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.
I built Plandex[1] to try to enable a more sustainable approach to vibe coding. It writes all of the model's changes to a cumulative version-controlled sandbox by default, which in my experience helps a lot to address many of the points raised in the article. While there are still categories of tasks I'd rather do myself than vibe code, the default-sandbox approach makes it feel a lot less risky to give something a shot.
On another note, a related but somewhat different technique that I think is still under-appreciated is "vibe debugging", i.e. repeatedly executing commands (builds, tests, typechecks, dependency installs, etc.) until they run successfully. This helps a lot with what imo are some of the most tedious tasks in software development—stuff like getting your webpack server to startup correctly, getting a big C project to compile for the first time, fixing random dependency installation errors, getting your CloudFormation template to deploy without errors, and so on. It's not so much that these tasks are 'difficult' really. They just require a lot of trial-and-error and have a slow feedback loop, which makes them naturally a good fit for AI.
I put a lot of focus on execution control in Plandex in order to make it helpful for these kinds of problems. It's built to be transactional—you can apply the changes from the sandbox, run pending commands, and then roll back all changes if the commands fail. You can do this repeatedly, even letting it continue automatically for some number of tries until the commands succeed (or you hit the tries limit). While there are some limitations to the terminal modality in terms of UX, I think this is an area where a CLI-based agent can really shine.
So what have we redefined vibe coding to mean exactly?
The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't.
Are people now using this term to mean "giving an AI agent broad tasks"?
[1] https://x.com/karpathy/status/1886192184808149383?lang=en
I wrote about this last month: "Not all AI-assisted programming is vibe coding" - https://simonwillison.net/2025/Mar/19/vibe-coding/
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 know if it's you and I (and some others) who are just uptight sticklers or something, but it bothers me a ton too. Same thing happening with "open source" in connection to LLMs, where suddenly some companies have decided to try to redefine the meaning, people lack the care to make the distinction.
In a dream world, each new terminology goes through an RFC to figure out a meaning we all (some of us) can agree to, so at least we can link to an angry RFC when people continue to misuse the term anyways.
Yeah that "open source" thing is SO frustrating. We have a very well established definition for what "open source" means: https://opensource.org/osd
I have a suspicion that Facebook insist on calling their open weights models "open source" because the EU AI act says "This Regulation does not apply to AI systems released under free and open-source licences" but doesn't do a good job of defining what "open-source" means! Bottom of this page: https://artificialintelligenceact.eu/article/2/
Correction: the closest it gets to defining open source is in https://artificialintelligenceact.eu/recital/102/
> The licence should be considered to be free and open-source also when it allows users to run, copy, distribute, study, change and improve software and data, including models under the condition that the original provider of the model is credited, the identical or comparable terms of distribution are respected.
(I found that by piping the entire EU AI act through Gemini 2.5 Flash - https://gist.github.com/simonw/f2e341a2e8ea9ca75c6426fa85bc2...)
In this wonderful future where we can leave responses longer than a tweet and have conversations longer than 30-second sound bytes, that people can understand, well at least get them understanding your point of view, even if they don't join the team. Having a succinct explanation for the sticklierness is still key though. For not letting Mark Zuckerberg co-opt the term Open Source, it's that it's not open source if I can't see why the LLM won't tell me how to make cocaine. Need to workshop that a lot so it fits on a t-shirt, but that is the gist of it.
Also, with LLMs, the traditional Four Freedoms of free software are no longer enough :
https://elevenfreedoms.org/freedoms/
[dead]
I don't really think it's that people couldn't be bothered to read the tweet. It's that vibe coding is very good term but a niche activity. Meanwhile there's a much less niche activity that people would like a name for. I think if we want to save the term for the niche activity we'd need to invent a good one for the less niche activity.
We do need a simple term for "used AI to write code (semi)autonomously, but checked and/or tweaked the result and I care about the quality".
Vibe-but-verify? Faux-Vibe? AiPair? (... I'll see myself out...)
I think the term for this is: "coding".
The term for this is "unicorn"
Entirely fictional creature that doesn't exist
Every person who I have seen embracing AI coding has been getting lazier and lazier about verifying
> yeah bro, leave the easy and fun part (googling and typing code) to an AI, and let the human deal with the tedious and error-prone part (checking all the edge cases)
What did you really expect?
Huh, I have never found searching for information and typing code particularly fun. The part I enjoy is seeing something work.
What I personally like is solving a problem in my mind and then building a solution.
Watching a solution being built after describing the problem robs me of that joy. And of the growth opportunity in flexing my reasoning.
I call it “AI coding”
Visual Studio with intellisense
re: "semantic diffusion", sometime the opposite happens. Consider "meme" which was once very general and is now much more specific. "semantic speciation"?
It's as if the culture wants a certain level of specificity for a phrase and if you start too far from it, it'll ignore your wishes and drift to that level anyway.
Vibe coding is shifting to mean when they don’t review the code, vs the original meaning of when they don’t intend to review the code.
So the issue you're taking with 'thing is crap' is not 'thing is not crap', but 'you have redefined thing to be reviewed and held to standards and then called it crap'? And so, what, if we just accept it as it is, it's not crap? Or it is, but it everyone knows it (do they?) so it's not worth calling crap?
Well, let's be clear: the original definition was actually the one that Simon describes here, and there's no ambiguity around that fact since it came from one specific tweet where Andrej Karpathy laid out a definition for the term quite directly:
"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. ... 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 ... 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. ..."
So yes, "not reading the code" is baked in quite specifically.
From that tweet:
> 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.
> 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
Kernighan's law still applies.
https://www.laws-of-software.com/laws/kernighan/
I strongly believe it also applies to the AI itself.
If the AI wrote the code to the top of its ability, it doesn’t have the capability to debug said code, because its ability to detect and correct issues has already been factored in.
You end up with a constant stream of “I see the issue, it’s: <not the actual issue>”, which is consistent with my experience of trying to have LLM’s debug their own code without basically doing the work myself and pointing them to the specific actual issue.
[dead]
Also from the tweet;
> It's not too bad for throwaway weekend projects, but still quite amusing
You were never supposed to vibe code on serious projects.
Any project that solves a real need will invariably become serious.
I have lost count of the number of quick one off scripts that ended up still being used in production workloads five (or more) years later.
It's fine for tooling or weekend project. I did it on an internal tool. It's got so much functionality now though, that Cursor struggles. It was great when I had a blank project, needed x, y, z and it went off and did It's thing. The moment the project got bug and need modifications, it is better that I do it myself.
Also I am a backend engineer. I don't know what kind of code it's producing for my front end. I just hit accept all. But seeing how it does the backend code and having to prompt it to do something better (architectural, performance, code reuse) I have no doubt the front end of my pool is a pile of poop.
I fear that management will see these small quick gains and think it applies to everything.
I'm of the opinion now, that vibe coding is good if you are familiar with the code & stack and can ensure quality. You don't want to give it to a product owner and have them try to be an engineer (or have a backend dev do front end, vice versa).
Just my opinion.
[dead]
Like you, I’m far too risk averse to not fact check everything an LLM outputs, but I’ve also fixed bugs that have been present for 5+ years. Maybe at a certain point you can just wait for the next generation of model to fix the bugs. And wait for the generation after that to fix the newly introduced and/or more subtle bugs.
> 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
And I’ve also had to spend hours at work tracking down badly copy pasted stack overflow code, or from other places in the codebase that didn’t do what the programmer thought it did. A shitty carpenter will build a shitty staircase whether they have a chisel or a dremel
But what about a middling carpenter? Moralism about "shitty programmers" is not helpful when we're really talking about aggregate trends, and when it comes to aggregates -- tools do matter. Defaults matter. Precedent matters. Things like these are why culture has such an outsized impact on a teams' ability to ship good, quality code over a long period of time.
One difference is that orgs are tracking AI coding assistant usage as a (positive) metric, soemthing they never did with SO. Given finite time, being pushed to AI code whether or not it makes sense or is efficient in either quality or delivery time, and with no relief of time constraints, means other things will fall by the wayside.
A good carpenter will build a shitty staircase if he is forced to use the wrong tool, given a timeline that doesn't accommodate it, and paid for delivering something that superficially resembles a staricase on time regardless of quality.
> Sure they can copy paste the error into the LLM and hope for the best, but what happens when that doesn’t fix it?
Neither side cares unfortunately.
When users attempt to prompt away their problems without understanding the error and it doesn't solve it, that is still good news for Cursor and Anthropic and it is more money for them.
The influencers encouraging "vibe coding" also don't care. They need to be paid for their Twitter money or YouTube ad revenue.
> Sure they can copy paste the error into the LLM and hope for the best, but what happens when that doesn’t fix it?
Then you throw the code away and start newly from scratch. Or you accept that your problem cannot be solved by vibe coding.
[dead]
It's like doomscrolling. Originally it meant compulsively reading depressing content about the state of the world, wars, etc., explaining the "doom" part, but eventually it evolved (or perhaps devolved) into just meaning obsessively checking any sort of online content whether or not it was depressing.
I honestly though the doom part was about you being stuck in an horrible loop / situation, not the essence of the news
in a lot of ways that is understandable when so much of the news is bad news, if all the highlights of the day point toward the world going to hell even reading a normal newsfeed can feel like doomscrolling.
The definition seems to have pretty rapidly moved to 'used an AI coding assistant in some capacity'.
And I think that *horribly* muddies the definition because programming and getting a bit of AI help here and there (since it's read the docs better than you have, and scanned Stack Overflow for common problems and mistakes more thoroughly than you have) is, imo, a very, very valid way to program; but you're still very much in the driver's seat. It's not creating whole design patterns, etc, for you.
I wonder if maybe some people have been trying to jump on the "I have also tried vibe coding" train without being willing to hop as far as the term initiator defined it.
I definitely still stick to the "Vibe Coding is when you don't read / grok the code" definition.
I agree - I'm not endorsing this broad usage of the term, just noting how I see it used in practice. This seems to be half driven by grifters on social media promoting their AI coding course du jour and half by people who just discovered Cursor, Windsurf, etc., and think any use of those tools counts.)
Another commenter said these people only read half of Karpathy's tweet - I disagree. I don't think they read it at all, have heard the phrase, and are using it with reckless abandon.
More specifically, using AI bots that can write functions, sometimes entire classes, refactor code, etc.
GitHub copilot which is mostly single line completions isn't "vibe coding".
I think vibe coding also entails some "what it did was so simple, I didn't bother to check it".
In the project I’m currently developing (a rewrite of an old timer app), I wanted to implement drag-and-drop icons, but didn’t have much experience with UICollectionView, which is one of the iOS technologies that displays a matrix of elements.
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 coder - someone who uses more coding assistance than I do
It's like driving. Someone doing more vibe coding then me is a maniac and irresponsible, someone doing less is a slow control freak.
It is a scam. Invented by someone who is an AI researcher, but not a software engineer which the latter rigorously focuses on code quality.
"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?
Saying that Andrej Karpathy is "an AI researcher, but not a software engineer" isn't a very credible statement.
If you read to the end of his tweet, he specifically says "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."
Your comment might make sense when it's scoped down to that article when he coined that term. If you take a look at his larger collection of statements on software engineering recently, it's hard not to put him in the bucket of overenthusiastic AI peddlers of today.
> put him in the bucket of overenthusiastic AI peddlers of today.
It's his job to sell now. He's selling.
> Saying that Andrej Karpathy is "an AI researcher, but not a software engineer" isn't a very credible statement.
I think it is. He is certainly a great AI researcher / scientist, but not really a software engineer.
> 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."
So is that the future of software engineering? "Accept all changes", "Copy paste stuff", "It mostly works" and little to no tests whatsoever as that is what "Vibe coding" is.
Would you yourself want vibe-coded software that is in highly critical systems such as in aeroplanes, hospitals, or in energy infrastructure?
I don't think so.
Where did Andrej say it was "the future of software engineering"? He very clearly described vibe coding as an entertaining way to hack on throwaway weekend projects.
Try reading the whole tweet! https://twitter.com/karpathy/status/1886192184808149383
"Would you yourself want vibe-coded software that is in highly critical systems such as in aeroplanes, hospitals, or in energy infrastructure?"
Of course not. That's why I wrote https://simonwillison.net/2025/Mar/19/vibe-coding/#using-llm...
To save you the click:
> The job of a software developer is not (just) to churn out code and features. We need to create code that demonstrably works, and can be understood by other humans (and machines), and that will support continued development in the future.
> We need to consider performance, accessibility, security, maintainability, cost efficiency. Software engineering is all about trade-offs—our job is to pick from dozens of potential solutions by balancing all manner of requirements, both explicit and implied.
> We also need to read the code. My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.
> If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development. The usage of an LLM to support that activity is immaterial.
He might not have but some industry insiders, for instance YC are releasing videos like this:
"Vibe Coding Is The Future" https://www.youtube.com/watch?v=IACHfKmZMr8
Urgh, I had not seen that one.
> Where did Andrej say it was "the future of software engineering"? He very clearly described vibe coding as an entertaining way to hack on throwaway weekend projects.
... And then a few weeks later, my boss' boss scolded the team for not having heard of the term, and told us to learn and use vibe coding because it's the future.
Your boss' boss clearly didn't read to the end of Andrej's tweet.
Yup. Or just ignored it because it didn't fit the predetermined narrative being pushed on us.
> Saying that Andrej Karpathy is "an AI researcher, but not a software engineer" isn't a very credible statement.
Broadly I agree with the two other replies: his 'day job' has not been coding in some time, so I would put him in the same bucket as e.g. a manager who got promoted out of writing code 5-10 years ago. I do want to understand where you're coming from here -- do you think that's a fair characterization?
His GitHub contributions graph (1,261 contributions in 2024) looks pretty healthy to me. https://github.com/karpathy
He spends a lot of time as an educator these days.
his commit messages leave something to be desired
> Merge pull request #740 from karpathy/gordicaleksa-fix_dataloader2
> - fix tokenizer omg
> - attempt to fix PR
> - Merge branch 'fix_dataloader2' of https://github.com/gordicaleksa/llm.c into gordicaleksa-fix_dataloader2
Come on really?
Do you write perfect commit messages every single time on every project you work on?
I absolutely hate the polarization around "vibe coding".
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.
"The whole point of AI agents is to eventually get good enough to do this stuff better than humans do"
You can be an enthusiastic adopter of AI tooling (like I am) without wanting them to eventually be better than humans at everything.
I'm very much still in the "augment, don't replace" camp when it comes to AI tooling.
No, I actually do want them to eventually be better than humans at everything.
I'm okay with directing AI to write exactly the software I need, without having to manage "stakeholders", deal with the egos of boomers up the management chain, and all the shitty things certain people do in any organizations that get large enough.
Why do you think any of those are going away? You can be the best programmer in the world and you'll still be dealing with that.
If you're in a situation where you don't have to deal with that, it won't be the result of using AI
> Software engineers will eventually become managers of AI agents.
Source? This seems very optimistic on both ends (that AI will replace SE work, AND SEs will still be employed to manage them).
> "And then in twelve months, we may be in a world where AI is writing essentially all of the code," Anthropic CEO Dario Amodei said at a Council on Foreign Relations event on Monday. [last week]
https://www.businessinsider.com/anthropic-ceo-ai-90-percent-...
The entire Council on Foreign Relations on stage chat is on YouTube.
I don't need a source, this is my prediction of the future.
> 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.
I agree with that. The problem I have is that people are getting sucked into the hype and evaluating the results of those tests with major rose-colored glasses. They glaze over all the issues and fool themselves into thinking that the overall result is favorable.
I think the issue most of us have, is that vibe-coding is not being treated as a dog fooding experiment, but as a legitimate way to deliver production code.
I am already seeing "vibe coding experts" and other attempts to legitimize the practice as a professional approach to software development.
The issue is clear, if you have accepted all PRs with no reviews as vibe-coding suggests, you will end up with security and functionality flaws.
Even if you do review, if you are the type of developer who thinks you can vibe-code a serious project, I doubt you are interested in regular security reviews.
Lastly, businesses are long lasting projects, and the state of AI is constantly evolving. Your codebases stability and speed of development is your businesses success, and if only the AI model who built it understands your code, you are on shaky ground when the models evolve. They are not constantly forward evolutions, there will be interactions that fail to fix or implement code in the codebase it previously wrote. Human engineers may not even be able or willing to save you, after 3 years of vibe coding your product.
> but as a legitimate way to deliver production code.
Beyond the developer side of the hype that gets talked a lot, I'm witnessing a trend on the "company side" that LLM coding is a worthy thing to shell out $$$ to, IOW there is an expected return on investment for that $$$/seat, IOW it is expected to increase productivity by at least twice that much $$$.
Companies already have a hard time throwing away the prototype - god forbid you showcase a flashy PoC - and priorise quality tasks (which may need to run over a quarter) over product items (always P0), and in that ROI context I don't see that LLM-assisted trend helping with software quality at all.
Anyone who has maintained code that written by engineers new to the industry, who didn’t understand the context of a system or the underlying principles of what they’re writing, may disagree.
The hype levels are so overwhelming that AI coding could never hope to meet them. I've tried having a highly-ranked AI coding app write unit tests for a relatively complex codebase. 80% of the generated test cases failed. But an experienced human such as myself could use those as a starting point since it took care of some of the tedious boilerplate. It genuinely saved me some time and annoyance, but could never hope to replace even the lowliest competent junior dev.
That's what AI is good for right now - boilerplate acceleration. But that's clearly not enough to drive the immense transfers of capital that this high ecosystem demands.
I do somewhat worry that AI will harm language development.
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 think there will be an ossification of current languages/frameworks/libraries. The technologies that already have a large amount of documentation, tutorials, example code, etc. will have a huge advantage over a brand new language because all of that content will be in the pretraining for all LLMs. Would you rather use JavaScript/TypeScript and Python (which will work relatively well with LLMs), or some brand new thing that will barely work at all with LLMs.
tbf that applies pre-AI as well.
>Boilerplate… is bad, right?
It's tough to say in a vacuum. Generally, the lower level you go, the more "boilerplate" you'll need. That cost of iteration is to give such programmers more control over the task.
So python may sneer at such boilerplate. Whereas Rust would prefer being more verbose.
I'm finding this as well. I can't trust it to go beyond boilerplate or PoC's or I risk lagging behind in understanding and actually slowing down in the long term. Best workflow is to tackle silo'd problems and iterate on them with LLM.
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.
AI is to SWEs what self-driving cars (or like features on new cars) are to taxi drivers. A neat thing that may make some basic things a little easier.
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.
> AI is unlocking computers for people who have never written a line of code in their life.
I don't think I can dispute the claim, but it feels more like someone who can't build a house being able to do it now that they have YouTube tutorials. Unless the person was already quite smart and competent, the house will probably have significant structural issues.
Is that a bad thing? For housing, governments the world over seem to agree that it is. But coding has never had a real attempt at regulation. You're going to end up with "vibe coded" production code handling people's personal and financial information, and that is genuinely a bad idea. A novice will not spot security issues, and AI will happily produce them.
I disagree that coding doesn’t have regulation. If you have never developed code in a professionally regulated industry such as Airworthiness then you haven’t been exposed yet to an area that requires rigorous process. There are regulated areas where software is regulated.
I have DIY’d an addition onto my house with professionally architected blueprints and engineering seal. During various stages, I would call the City who would send code inspection officials to incrementally sign off on my project’s progress. Other than pouring a new slab of concrete and electrical, I built it all myself to code. I followed YouTube tutorials.
My point is that DIY isn’t the issue - lack of oversight is. With standards, expert input, and review processes, even non-experts can safely build. AI-assisted coding needs the same approach.
All true but tell the average programmer that you think their industry should be regulated and they should potentially be held liable for their code.
This is not a popular opinion on software development circles - unless you're already in one of those regulated fields, like where a software engineer (a literal accredited engineer) is required.
But it's been an increasingly common talking point from a lot of experts. Bruce Schneier writes about it a lot - he convinced me long ago that our industry is pretty pathetic when it comes to holding corporations liable for massive security failures, for example.
We have to mature as an industry. Things like not staying up to date on third party dependencies, not including cybersecurity as part of the build pipeline, lack of static and dynamic analysis, not encrypting at rest secrets, etc
It is already costing millions of dollars and it’s just accepted.
I couldn’t build a house, but I did learn a lot of smaller skills I would have otherwise called a pro in over. Turns out changing a toilet is pretty much putting it in place and screwing on the pipe, and you can program keys to my Xterra by toggling certain controls in a certain order.
I wouldn’t expect a vibe coder to build a full featured app on vibes alone and produce a quality codebase, but for smaller tasks and apps it is just fine.
Your analogy makes no sense. There is no equivalent of an operator who will fix your code if it fails.
You're asking someone with zero coding experience to jump in and fix bugs so niche or complex that the LLM is incapable of doing it.
Sure. Who's gonna do it though? This whole year's theme is in fact about de-regulation.
"Think instead what a self driving car is to someone who cannot drive."
It would be a very dangerous thing if said self-driving car crashes ten times every ride.
> AI is unlocking computers for people who have never written a line of code in their life.
And this is why the holodeck tries to kill its occupants in half the episodes in which it is featured.
>It doesn't matter if it sometimes disengages to have an operator step in
I'd say that breaks the entire concept of "self driving" at that point. If people are fine with some of those "actually Indian" stories where supposedly AI powered tools turned out to have a significant human element to it, why not just go back to the taxi? You clearly don't care about the tech, you care about being driven to a destination.
I'd like to know which app and model you were using, along with the prompts.
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.
LLMs don’t even understand fucking TypeScript, which you would expect a computer program to be able to understand. I can’t get it to write valid Drizzle code to save my life, it will confidently hallucinate method imports that don’t even exist.
fucking real, i've had claude code make obvious syntax errors in C# by declaring a tuple as `var (a, string b)` which i thought we were past.
The question is which LLM, invoked how?
Claude Code refactored numerous projects for us into TS, often one-shotting it. Saying LLMs don't understand TS (which may be true, in that LLMs questionably understand anything) says more about your perception than model and agent abilities.
I have also had a really hard time getting Claude and Gemini to create valid TypeScript in somewhat complex legacy projects. Sometimes it will do the most kludgey things to sort of make it work (things a human developer would never consider acceptable).
Right, LLMs don't understand TS, because they're not integrated with it. When they come across something they don't know, they just start hallucinating, and don't even verify if it's actually valid (because they can't)
LLMs can't, but agents can. They can read documentation into context, verify code, compile, use analysis tools, and run tests.
Hallucinations do occur, but they're becoming more rare (especially if you prompt to the strengths of the model and provide context) and tests catch them.
There's a difference between AI assisted "vibe coding" and what I’ll call (for now) "craft coding."
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.
I think you should try more tools and use cases.
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.
This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necessary, and will just build the thing exactly as written in the spec. The result being that to get the end product you want, the spec needs to be so finely detailed and refined that by the time you get both specification and implementation to the desired quality level, it would have been the same amount of effort (and probably less time and frustration) to just build the system in-house.
Of course outsourcing software development hasn't gone away, but it hasn't become anywhere near as prevalent and dominant as its proponents would've had you believe. I see the same happening with AI coding - it has its place, certainly for prototyping and quick-and-dirty solutions - but it cannot and will not truly replace human understanding, ingenuity, creativity and insight.
More than one project manager has insisted that everything about the system must be documented--that's called the source code.
As you say, by the time you specify everything, you've written the code.
Theoretically a PM could say "the code is disposable and obsoleted by the next deployment. let's just document our prompts."
I don't know if that's a good idea but a lot of people are going to try it.
This is an obviously terrible idea that will lead to regressions on every deployment.
How long should we wait after promotions before prompting to add logging back to the service?
Who needs logging when we can just ask the LLM to confabulate the logs?
I'm afraid you're going to have to spell it out for the kids in the back who aren't paying attention.
It's like NixOS but instead of the much-maligned Nix language, you can use the English language!
What could go wrong?
You mean like COBOL ?
Wait shit brb, getting millions in VC funding.
The prompts are the source code in that case.
The LLM is some sort of transpiler.
Somebody will have to add some syntax to these LLM prompting systems to include text that doesn’t get converted. So the next round of PMs can ask you to documents your prompts).
> As you say, by the time you specify everything, you've written the code
Sadly not when it’s a 2000 page word document with a million formatting quirks and so many copy-paste versions you don’t know if you should trust “reqs_new25”, “reqs_new25v1” or the x number of other copies floating around.
Someone should come up with a tex2fortran conversion LLM.
Oh yes[1]
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 think this erratic manner of trying to find the correct way is the issue. I am currently nearing my 2nd year at a company A in my industry, and while I did know they all kinda suck in their own special way, I honestly had no idea it was this bad until I had to try to make this craziness somehow work for us. Even if there are standards, I do not see people following them. Last year, the one girl, who did seem to try to follow some common sense approach, got fired for effectively using common sense against big boss wishes.
What I am saying it is a mess from beginning to end and I am honestly not sure if there is one factor that could solve it..
> Last year, the one girl, who did seem to try to follow some common sense approach, got fired for effectively using common sense against big boss wishes.
What did your manager say when you said this to them?
Sigh, sadly, I didn't, because I found out largely after the fact and, more amusingly, after record profit year at the company with the project in question clearly being a major part of everyone's goals ( not mine, I was kinda roped in at the last stages ).
If my manager fire somebody for using common sense, I’m not going to tell them anything. Because I can be next.
that girl doing stuff is one thing, but if you're so scared you can't even ask your direct boss (not the big boss, obvs) a question, like, yo, I dunno.
Agree it is a mess. I wonder if we would all be better off accepting this and learning to laugh out loud more often.
Reminds me of this post:
https://berthub.eu/articles/posts/how-tech-loses-out/
That was awesome.
Do any of these vibe coding tools write out the prompts as specs and then keep the specs up to date as you continue prompting? Seems like specs == formal prompts.
You don't need a tool for that. "You're going to assist me in writing a detailed software spec in markdown. At each step adjust the document to incorporate new information. Suggest improvements and highlight areas which have been ignored so far. Initial description: ..."
If you have multiple of those, you can tell it about required sections / format, or provide a good past example.
> This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications
I worked at [insert massive retailer here] a few years ago and this mindset is still very much alive.
Have we stopped, really?
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.
In my experience, directly hiring (or hiring through a local company) developers in a “low-income country” - in my experience, Eastern Europe and Latin America - goes a lot better than just contracting out a body of work to a third party. Especially if your company is already fully remote, you’re able to get developers who integrate onto your team just like American devs, and are just as good at coding.
> Have we stopped, really?
No, when I was at a large, well-known company a year ago, job listings were 2:1 off-shore (India, South America) vs on-shore. There was also an increasing amount of contractors used, even for public-facing stuff you wouldn't expect.
The problem with outsourcing is on holding people accountable for a written specification. It's not on the location of the developers.
Deleted
I don’t think this addresses the comment you’re replying to.
It’s sad you’re getting downvoted by gatekeepers. It’s absolutely a good thing that more people have access. Maybe not for inflated costal salaries and egos, however.
Software is going to completely change. The writing is on the wall, it's just a matter of who can step back to see it.
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.
> it's just a matter of who can step back to see it
I’m not sure why those fully bought into the AI hype so often dismiss anyone who’s less bullish as simply too small-minded to see the writing on the wall.
That aside, while I do think software is going to change, I’m not sure that I agree with your particular version. What examples of apps with 100k, 500k+ LoC codebases are going to get decimated? The biggest successes in software today have moats around inventory or network effects. Are people going to make their own Netflix or Uber? Even at a smaller level, is the idea that local gym owners are going to replace gym management software with their own mini apps? Or restaurants are going to do their own point of sales apps? Unless AI can make the cost of maintaining software something close to zero time, which is a really tall order, why would business owners waste time on something outside of their core business. And if this is such an untapped opportunity why didn’t we see the start of it with the no-code movement?
Will a big chunk of the software market fall off and be replaced by custom mini apps that the layperson crafts with AI? Maybe? But I don’t see how one justifies the level of confidence I see from these predictions.
You are absolutely right
Because, as we all know, what is important about coding is outputting lines of code.
This is the main difficulty, this is were IA will change the game forever.
Thinking about the code you write, that's worthless, do not do that. Improving a large code base ? Again, no need to think to do that. Just inject random lines of code and it will do the trick.
Of course, in a world where your code has no value because it's just a copy/paste from elsewhere that has a low lifetime expectancy, IA is shinning.
But if you want something a bit more useful, a bit more clever, a bit more adapted to your use case, IA sucks. Because IA do not think.
IA is a threat to dev that do not think. Good ridance, they won't be missed.
Complexity is going up rather than down. Companies already solve simple problems with spreadsheets.
The spreadsheet is the hammer or the white collar office worker.
> treat the AI like a super-speedy but junior developer on your team
That sounds like it's going to take a lot more time that just writing the code for an experienced developer. The issue with AI for me is that it produces plausible-looking code which requires a lot of attention to read through, because things that look superficially "right", including any justification in code comments, can actually have really problematic flaws.
I remember when I'd rushed a piece of work when studying, I had a lecturer who told us something like:
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.
He could have been copying General Kurt Hammerstein. Paraphrasing here:
There are four kinds of military officers: smart and lazy, smart and hard working, dumb and hardworking, dumb and lazy.
Keep the dumb and hardworking away from any high level position. They actively make things worse. Dumb and lazy are useful for simple tasks with oversight. Smart and hardworking are excellent for high level staff and analyst positions.
The Smart and Lazy should be saved for high level command. They expend only the energy necessary to get the job done and then focus on the next important task.
[dead]
Except you ask it to not to. Sure it's far from perfect but honestly that is not an issue. If you ask Claude to study and document the codebase and then write unit tests I am sure there are only very few broken ones, less hallucination more like real small bugs.
I've found utility + speed go up the more conservative (in number of lines) the model generates. If it only completed a line it's much more likely to be exactly what I was about to type
It totally depends on the use case.
As a consultant the majority of my work is around business process automation and integrating cloud systems. We build a lot of small "applications" that change almost constantly. The number of concurrent users is low, the lifespan of the software typically short and to justify the effort has to be done quickly and efficiently.
It's 100% "value engineering".
AI agent pairing has been an absolute game changer. It can single shot most requirements and refactors. I basically am just writing technical requirements and reading pull requests all day now.
I actually think the quality of the output has gone up significantly because you can just accomplish much more in the same limited budget.
Yes not all coding is equal. A bit like not all wordsmithing is equal. A presidential speech is not the same as an airplane safety announcement, even they can both be encoded as words.
Different people clearly mean different things when they talk about software quality. There is quality as perceived by the user: few bugs, accurately models the problem they have, no more complicated than necessary, etc. Then there is this other notion of quality as something to do with how the software is built. How neat and clear it is. How easy it is to extend or change.
The first kind of quality is the only kind that matters in the end. The second kind has mattered a lot up until now because of how involved humans are in typing up and editing software. It doesn't need to matter going forward. To a machine, the entire application can be rewritten just as easily as making a small change.
I would gladly give up all semblance of the second kind of quality in exchange for formal specifications and testing methods, which an AI goes through the trouble of satisfying for me. Concepts and models matter in the problem domain (assuming humans are the ones using the software), but they will increasingly have no place in the solution domain.
The second type of quality is necessary to achieve the first type of quality for systems with nontrivial levels of complexity. It doesn’t need to be perfect, or even close to perfect, but it does need to be “good enough” -
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.
Software architecture was never about code elegance, it’s about making it easier to get reliable results. And that’s mostly about using automated tooling to check correctness and easy to understand and to modify modules.
That’s the easiest way to get both definitions of quality as it’s way esier to test isolated modules and their integration than testing the whole system as a whole. And way easier to correct wrong code.
> Software architecture was never about code elegance, it’s about making it easier to get reliable results. And that’s mostly about using automated tooling to check correctness and easy to understand and to modify modules.
The first isn't entirely true, and automating tooling is actually quite poor at doing any sort of architecture analysis since the "right" architecture is heavily dependent on factors you cannot see in the code itself: What sort of SLO are you setting? What is your services load and usage pattern (read heavy? write heavy? blend?). Read heavy and high availability? You may want CQRS, but if the service is only experiencing light loading that could easily be over-engineering. Tooling won't help you identify that; you'll need experienced engineers to make judgements.
Isn’t that system design? And automated tooling is for correctness, not performance or availability. So things like linting, tests runner, static analysis and the like.
> The first kind of quality is the only kind that matters in the end.
How easy it is to maintain and extend does absolutely matter, in a world where software is constantly growing and evolving and never "finished"
I'm not disagreeing with you.
Just an observation though:
There seems to be a world in software where "it works" well enough to grow a large user base to achieve a a large valuation and then dip out is also a viable option.
Growing/evolving the code does not matter because the product no longer matters after the founders have made a large sum of money.
I hear what you're saying; but the implications seem ... net harmful? If you're actively hacking something together with the intent of boosting a valuation, selling your company and GTFOing before your purchasers figure out the bag of unmaintainable garbage you've sold them, that ...
You're harming:
I think "grift" is a good term (GPT recommended 'predatory exit' as an alternative) for what a team that's done that has done.There’s nothing wrong with iterating fast or building MVPs. But when teams knowingly pass off a brittle mess to others, they’ve stopped building products and started selling lies.
> but the implications seem ... net harmful?
I was not trying to imply that it was not. Just observing that when money is on the table there appears little incentive in some cases to build a good product.
Or to follow good engineering practices because the founders & investors already made money without it.
> The first kind of quality is the only kind that matters in the end.
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
The problem domain is part of the solution domain: writing a good specification and tests is a skill.
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).
> The first kind of quality is the only kind that matters in the end.
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.
Low/no code MVP solutions have existed for a long time. Vibe coding seems like you'll get worse results than just using one of those, at least from a bug/support standpoint.
You are talking about an imagined future not current reality.
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.
> The second kind has mattered a lot up until now because of how involved humans are in typing up and editing software. It doesn't need to matter going forward.
Tell that to the vagus nerve in the giraffe.
The problem is that the first kind of quality is something that's hard for even human programmers to do well, while AI is, like the rest of the tools that came before, much better at the second.
The urge to spagetti code is strong but must be denied.
Are today's juniors never gonna reach senior levels because of AI assisted coding ? Do you think AI assisted coding has a negative impact on developer's growth ? Is the need for developers gonna increase in the longterm but decrease in shortterm ?
Those are just some of the questions that are in my head lately. I would appreciate other people's opinion.
I think all of this depends.
> 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.
I think it is a losing battle. People are energy preserving creatures and we skip paying attention if we can. Because paying attention is effort. Vibe coding is exactly this, low effort development and thus is enticing. Now if we can get away with low effort why shouldn’t we? I am not advocating serious NATO missions to be vibe coded for trajectories, no. When billions are at stake no way. But what if billions are not at stake? What if nothing is? This weekend I added a way to maximise my QApplication app. I just asked Claude code to do it and tested it. It worked. That is all I need for my own app that I use. It’s not that I don’t have any other users but works on my machine is the motto of this specific free and open source app.
>People are energy preserving creatures and we skip paying attention if we can.
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.
Running AI itself is not low effort though, far from it at current efficiency levels it burns way more energy to produce outputs than humans. Setting latest advanced models to think about the problem on your behalf doesn't necessarily make it low effort overall.
Vibe coding is first and foremost moving some of your problems to the AI and that can be suffice even in professional setting where there's a lot of mundane requests, e.g. setting up slack alerts, running simple data transforms or figuring out one-off data analysis. Maintainability is less of an issue on tasks where it can be done from scratch if need be.
If your situation is result-driven and easily verifiable AI-driven solutions are absolutely appropriate.
I for one advocate NATO using vibe coded lowest-bidder technology. It will make the world a safer place.
NASA* :D
Vibe coding for me meant a roll-the-dice approach to building something that world. Never a care for strong architecture or good code standards. Allowing anyone to become an "engineer". A friend of mine, who can't code, used Cursor to build fully functional Nextjs web apps. I was impressed. Vibe coding is a super power for average people.
I do think this article fully grasps that change. Using AI to do tasks is not vibe coding. At least to me.
When will the first vibe coding book come out I wonder?
I mainly use vibe coding to figure out how hard something is to do if I would do it 'for real', so I vibe code working prototypes, often to find out there is no way this is feasible and, more often, finding it is easier than I thought it would be. When I have an issue, I search for a library to solve that issue, but to figure it it does and if it does in a friendly way, I have to try it, so I ask claude to give me my example in that library. I already know something is up if it doesn't work first shot; to me is not a shock that 99.9999% (well that is actually not true of all language ecosystems but the most popular ones) of all libraries out there are total garbage with very strange 'opinionated' abstractions/choices in them that truly suck and actually make some use cases impossible without changing the library itself even though it says in the manual it is possible but without an example. In that case the LLM usually hallucinates a parameter or function that it doesn't have but that is from another library or does not exist at all, ideally needed to implement said use case. LLMs save me a ton of time there and I assume it's low quality as I won't use that exact piece of code anyway, but now I know the effort involved to meet my specific use case.
Wanted to say something similar : high-quality code is not an excuse to make something that doesn't "work" (in regards to sales, usefulness, iterations, learning - all for which vibe coding are a perfect fit IMHO)
This is common sense. The whole article read like they asked ChatGPT to fluff one sentence "review vibe code with a human before pushing to prod" into an entire article.
Vibe blogging.
So much of this now and so much more coming.
Looks human written to me. And they didn't use em-dashes when appropriate so that indicates human.
Not an excuse, but maybe an explanation. I was just talking to someone who was bragging about getting the cost of coding down to a penny a line. Seems like an insane metric to use, to me, since it takes no account of features developed or maintainability/modifiability.
I think all this rests on the unacknowleged fact that most software never goes into production. When you have a choice between paying expensive humans to create software that works vs cheap AI to create software that doesn't, if nobody is ever going to use it, the AI option is the one to pick.
>In essence, let the AI handle the grunt work, not the brain work.
And importantly make sure the user doing the brain work has the experience and support to do it properly. The XY problem can cause a lot of damage with AI agents that implement what's asked of them instead of asking why.
If you use AI to make low-quality work, then you made low-quality work. It’s pretty simple.
I don't mean to be dismissive (here goes, though) but the whole article boils down to one point, and it's one that frightens me that it needs to be repeated so often: use AI as your intern, not your replacement
Simple.
“We as a team are still responsible for every line that goes into the repo”
You use AI to make a PR? You are still responsible. You code reviewed the PR? Also responsible.
The AI is not responsible.
"The big takeaway is that speed means nothing without quality" - I feel like this is not true in 'move fast and break things' ideology
I feel like people don’t really understand that ideology - if all you ever do is break things (or produce broken things), then you’re not actually moving fast at all.
[dead]
Maybe I could introduce vibe cooking, vibe driving, vibe teaching, vibe accounting, vibe plumbing, vibe working.
Vibe coding is what we used to call “a hack”
It is not software engineering.
Vibe seo vibe seo vibe seo vibe seo
Code vibing.
Funny, that's all I thought it ever was.
LLMs are to software engineering as 3D printers are to mechanical engineering.
Great analogy! I'm stealing this.
Why are they being sold as DROs then?
Do you mean VMCs or something?
I meant a Digital Readout, a DRO. A digital nechanism that provides metrology assistance to machining operations.
LLMs for code are currently sold as sort of that.
It's hard to take anyone seriously who takes the term "vibe coding" this seriously, considering that the whole thing spawned from a casual tongue-in-cheek tweet. I recently saw a job posting for a "Vibe Coder". Nuts.
This sums it all up:
> embrace the vibes, but honor the craft
[dead]
[dead]
[flagged]
What percentage of companies can hire an engineer who writes better code than o3?
Given that o3 just spun its wheels endlessly trying to correct a CSS issue by suggesting to create a "tailwind.config.X" file despite being given the package JSON which contained a clear reference to Tailwind 4x - I'd say any engineer capable of reading and learning from basic documentation.
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.
Tell the AI to comment above the include why it uses a specific version, ask it to document the version and it's specific quirks after fixing it with it.
Not sure how o3 is generally at coding, but this kind of meta information works well for me to avoid version missmatches with Claude and Gemini
It's kinda important that the AI finds the issues itself so it can properly document it in her own words.
Is breaking API changes how we defeat the killer robots?
It is most definitely 100%. Any competent programmer can write code better than the current AI tools.
I'm a big booster of AI, but this doesn't even make sense. Any project using even the very best code generator in existence is going to need to be stewarded and tightly monitored by a competent programmer. AI is miraculous, but can't do crap reliably on it's own.
Whatever percentage that can hire an engineer at all.
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.
100%
highly doubt that
Then why ask the question, if you're so sure of the answer?
This question isn’t useful without context. But yes the answer is probably 100%.
I built Plandex[1] to try to enable a more sustainable approach to vibe coding. It writes all of the model's changes to a cumulative version-controlled sandbox by default, which in my experience helps a lot to address many of the points raised in the article. While there are still categories of tasks I'd rather do myself than vibe code, the default-sandbox approach makes it feel a lot less risky to give something a shot.
On another note, a related but somewhat different technique that I think is still under-appreciated is "vibe debugging", i.e. repeatedly executing commands (builds, tests, typechecks, dependency installs, etc.) until they run successfully. This helps a lot with what imo are some of the most tedious tasks in software development—stuff like getting your webpack server to startup correctly, getting a big C project to compile for the first time, fixing random dependency installation errors, getting your CloudFormation template to deploy without errors, and so on. It's not so much that these tasks are 'difficult' really. They just require a lot of trial-and-error and have a slow feedback loop, which makes them naturally a good fit for AI.
I put a lot of focus on execution control in Plandex in order to make it helpful for these kinds of problems. It's built to be transactional—you can apply the changes from the sandbox, run pending commands, and then roll back all changes if the commands fail. You can do this repeatedly, even letting it continue automatically for some number of tries until the commands succeed (or you hit the tries limit). While there are some limitations to the terminal modality in terms of UX, I think this is an area where a CLI-based agent can really shine.
1 - https://github.com/plandex-ai/plandex