I so hate the phrase "vibe coding"
artiss.blog
artiss.blog
> Getting LLMs, who have learnt from people who have generously shared their code online, to write code for you, often poor quality, with no accountability and often with no understanding from the person doing it, of what could be wrong with it, and hence unsupportable as a result. At best, the requester does code but is so uninterested in the art of coding that they’d rather debug poor quality AI results rather than write it themselves.
Savage, but absolutely on point. I chuckle when I read linkedinlunatic CEOs talking about vibe coding features into their product as if that's some kind of badge of honor. Major yikes vibes on all levels.
The thing is, I see AI coding tools, especially agents, as a major force multiplier for individual devs and small teams. The output of AI is everything from total AI slop to actually good, scoped PRs, or even occasionally fixing bugs that were otherwise impossible to fix within a given time-box. I don't see how using tools like this is bad at all. A lot of it really comes down to the operator --when I use coding agents, I end up leaning even harder into my background/knowledge on higher level abstractions, architecture, design decisions, etc.
It's a bit like putting sawdust in a car instead of oil. She'll run smooth as silk...for a few miles.
Right now, we have a solid core of developers with enough knowledge (built mainly by actually coding themselves) to be able to call bullshit on LLM's when they write poor code. For those people, yes, it's a solid tool.
The problem is when you consider coding in 10 years. The draw to use vibe coding both in schools and among nascent hackers will be incredibly strong. Those folks will get positive reinforcement from having code that just magically works without having to spend a ton of time designing and actually coding. If a whole generation of would-be programmers comes up using that technology exclusively, that core of hackers that have the chops to recognize bad code and prevent maintenance headaches down the road will slowly dwindle over time.
At that point, LLM's will be consuming LLM code that hasn't been properly reviewed and sanitized. Garbage in, garbage out (unless there is some magical AGI breakthrough that makes this all moot).
Going from a manual saw to a buzz saw can really cut down the time needed to get the job done, but without the knowhow of how to use a saw effectively, eventually fingers will replace the time being cut.
Why is there a loading spinner but nothing loading? It was probably vibe coded.
Would you judge a chef by how many hamburgers he could make in a minute, or the dish that takes talent, experience, and human taste? Robots can make hamburgers, but I wouldn't say they're better cooks.
When you ask a chef for a meal - you didn’t “make it”. He did. You just consume it.
(Joking really. It’s was a funny inventive and evocative term. The sadness is that it is getting traction as a serious phrase.)
Still get fingernails on a chalkboard cringe every time I come across a language model’s “confabulation” (conscious or subconscious filling in of unknown details or facts) being called “hallucinations” (false experiences in sensory systems as they iterate partially or completely unmoored from their normally grounding flow of external information).
There are real questions about when anthropomorphizing is appropriate directly or by analogy. But inconsistently applied anthropomorphization is grotesquely unnecessary confusion. As someone who has spent a career being careful with terms, it hurts. Bad terminology and notation create subtle but often permanent drags on clarity.
Even poor emphasis does real damage. Tell a three year old a standard circle’s radius is 1 and circumference is called tau. Cool! Tell another 3 year old a standard circumference is 2*pi, perhaps also noting that a half standard sized circle has a radius of 1/2, a diameter of 1, and a circumference of pi to “simplify” things, and see which child more readily takes a conceptual step forward. Because even an extra 2 creates real (transcendental!) conceptual drag.
"Confabulation was originally defined as "the emergence of memories of events and experiences which never took place" - From the year 1900
Yes both terms anthropomorphize. And I do think anthropomorphic terminology is reasonable. For models. Given the disclaimer that strong similarities do not necessarily imply serious equivalence.
But if we are going to anthropomorphize, we should at least keep the meanings of words consistent.
The definition/source of confabulate you give is great. I think its modern use includes fill-in facts, and often emphasizes the fill-in of details of events, experiences, and factual knowledge in terms of how our memories & recall work on a normal basis.
We all do it. But less is better.
My response was that I code by vibe, and really I meant that I was improving the nightmare of working in our backend code while trying to learn the business logic, restructuring our backend code structure, hardening our unit tests, and adding swagger documentation. While doing so, I uncovered tons of bugs.
All in all, “vibe coding” to me is similar to “smelly code”, where the intuition depends on the implementor, but with the latter, “bad” coders can be silent and aren’t forced to make change smells. Good coders, however, prove their intuition skills when identifying and fixing code smells, even though today we have automated tools to tell us why our code smells feel or look bad
I had an idea for a little app I wanted to build at work, and while the result seemed like it would be neat and useful, the amount of effort required never seemed worth it, so it sat unbuilt for years. So to test out Cursor, I wrote a ~2 page doc with detailed requirements on what the app should do and how it should do it, then made a mock in lucid chart and gave these two things to Cursor and Claude. It was almost able to single-shot the app, it was up and running in about 30 mins, then I spent a few hours fiddling with the UI and getting just right.
I did not read a single line of code, I have no clue what's in there, but the app works, does what I want it to do, and actually exists unlike before.
I understand it as playing around, POC, MVP stuff. Which lots of people were doing before AI came around.
If people are "vibe coding" for mission critical applications then that is a problem.
Through a process known as Eval-Rinse-Reload-And-Repeat, FuckItJS repeatedly compiles your code, detecting errors and slicing those lines out of the script. To survive such a violent process, FuckItJS reloads itself after each iteration, allowing the onerror handler to catch every single error in your terribly written code.The blog itself doesn't really contain any interesting insights, imho. It's just a rant against coding with AI assistants ending with the inane unworkable idea of watermarking AI-assisted code.
I guess you could argue that applying the RIAA-level logic of "LLMs learning from existing material is stealing!" to code is somewhat novel, albeit equally stupid ("You wouldn't download an open source repo!").
Very sad to see the same people who railed against bootcamp grads and Fiverr devs for lowering the bar, legitimizing this. As the article states, "vibe code" is essentially scraped OSS code that reduces the human programmer to become a janitor for sloppy code -- exactly the criticism they had for bootcamp grads.
I think of the act of using an LLM's assistance to produce code as two distinct actions, depending on who's doing it:
* Amateurish efforts, by someone who doesn't really understand or care about code quality. This is "vibe coding," where the LLM is doing maybe 95% of the work. Back in the day, the pejorative term "script kiddies" was used to describe would-be hackers who basically just ran scripts written by others, rather than developing their own skills. And those are the sorts of people I would describe nowadays as vibe coders.
* Judicious use by someone who knows what they're doing and just wants to move faster. Rather than letting the LLM do 95% of the work, it's more like a pair programming session, where the "senior" developer remains in the driver's seat but lets the "junior" LLM handle smaller, well-defined tasks that can be easily reviewed for quality.
If that's how a dev is using it, then they aren't "vibe coding".
I thought vibe coding means you end up with the vibe of an app, not an actual app.
Consistency, sure.
Higher quality...? I'll take my artisan bread over Wonder bread, my hand-crafted table over Ikea, etc.
We like to hate on bland industrial mass-produced stuff nowadays but it wasn't all great before.
Before I accept that AI is the next industrial revolution I'd like to see actual, superior, production ready software churned out at a quality the average human developer cannot match. Not just toy products or pelikans on bicycles. Wake me up when AI can one-shot something equivalent to Wordpress in quality and scope. Otherwise it's just another tool in the toolbelt for developers.
Update: Sorry not really sure if I'm mixing up the book with another one. Was a long time ago...
“Vice code” - Was that an intentional typo? Made me laugh.
This is why the current zealotry is reckless and harmful.
> LLMs don’t miraculously know how to create code – it’s learning from what’s available to it online already. Do you think it’s learnt from closed code such as Microsoft software, or anything from Apple? No. It’s taking advantage of the generosity and sharing spirit of the open-source community.
So if I learn from open source community, pick up good coding habits, patterns etc., and then apply what I've learned to write new code - does this also constitute stealing? While IP laws are without doubt not without fault, I'm rather more used to people claiming that they are too strict, if anything. Now, the author essentially claims that we need to introduce on top of copyright also "trainingright" (or "learningright"?), essentially extending the definition of "derivative works" to plus infinity. This doesn't sit right with me.
Each time I tried it, with custom rules, git, and all the best practices I found, it went amazingly well initially, and garbage afterward.
Using the same technique, after a while, it generates a lot more shitty code than helpful.
> So, it’s shit and you’ll spend a long time fixing it.
It just takes more time overall to make it functional. Fixing, debugging and improving vibed code takes more mental resources and time than just writing it from scratch.
Also, there's the flow aspect. Each time you let it "vibe", you're losing the flow state that is important while creating and thinking about complex work.
I'm wondering what this means.
Kind of by definition, you wouldn't be able to tell "successful vibe coding" from "successful coding", right? Unless someone announces it. And a quick look at the comments here, or any other thread with about AI & coding, would immediately tell you is a bad idea to announce.
There's a few things you just don't say on HN, because you'll be piled-on immediately: don't criticize Kagi, don't hint at being pro-cryptocurrency, don't announce you "vibe coded" something even if it's extremely successful, etc.
(The immediate downvotes on this is actually hilarious, and proves the point)
It's like how "crypto bro" used to be a badge of honor but is now usually considered an insult. No change to the term was necessary thanks to how dumb it already sounded.
My suspicion is that "vibe coding" will eventually become an insult, too, thanks to the nature of the phrase.
And you all can help me start this trend!
Like vibe heart surgeon.
It never had any other meaning to me.
Sure someone doing it thinks it's fine, but they are by definition, well let's say not to be admired.
If someone hates the term because it makes them feel bad, I can only say "correct".
How are you going to debug your already poor implementation if you can't read the language?
Expand it with a newer feature?
Maintain it in the future and close bugs/vulnerabilities?