No, I read what you wrote, and you wrote "vibecoded", and the definition of vibe coding is not reading what you generated, then always hitting "Accept All". And it has a space in it. I'll quote the definition below, so you don't have to look it up yourself, and we can both be on the same page.
It's right there on the label. If you didn't mean "vibe coded" then don't vibe write "vibecoded", and instead read what you wrote, then look up the meaning and spelling of the terms you are using, and do not neglect to correct yourself because it's not what you meant.
I have to correct typos like that all the time when I write them by hand. But making typos and having to correct them and having to look up the meaning and spelling of words does not make me complain about all human generated code and text just because it requires me to proofread what I wrote.
Reading what you wrote or what ai generated and looking up terms is all part of the process, because people and llms make mistakes. Vibe coding is not giving a shit about that, thinking it doesn't apply to you, and hitting "Accept All" without reading the code, by definition.
And if you can't accept that, then don't write or generate code or text, and don't complain about how you have to read what you and llms generate and correct it, and understand what words mean.
>I had to literally vibecode a separate linter for this
Why would you "literally vibecode" a linter and use it to review other llm generated code without reading the linter's code itself? That is "literally" vibe coding eating its own tail.
I take your emphatic use of the word "literally" to mean that you are "literally" using the well know definition of vibe coding as it was coined by Andrej Karpathy of OpenAI, which is "iterally" (and I quote):
>I "Accept All" always, I don't read the diffs anymore.
Am I misunderstanding you, or are you vibe writing the wrong term without reviewing the meaning of your own words?
Here is the full literal quote so there is no room for confusion or claims of missing context:
https://x.com/karpathy/status/1886192184808149383
>Andrej Karpathy @karpathy:
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. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. 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, I'd have to really read through it for a while. 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. 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.
That is the "literal" widely understood and well defined meaning of what you wrote, but misspelled "vibecoding", according to the well known AI expert from OpenAI who originally defined and championed the term. Its meaning has not suddenly changed.
Only a vibe coder would vibe code a linter to vibe lint vibe coded code for them, without looking at ANY of that code themselves, by just hitting "Accept All" always. Because vibe coders by definition don't want to bother reading what they generated, don't care what it means, and still expect it to come out perfect.
Don't be a vibe coder, or a vibe writer, or a human stochastic parrot: read what you write and know the definitions of the words you use.
And if you're not a vibe coder, then don't claim to "vibecode": that's "not engineering" just "magical and wishful thinking", as you like to say.
>"I always have to correct its hallucinations during the day. Why would I ever let it run unsupervised overnight?"
And the answer to your question is: because you are using git, so you can look at the diffs before merging and deploying into production. You are using git and looking at the diffs, aren't you? Have you heard of PRs and code reviews? Or is that too much to ask of a "vibecoder"?