Two kinds of vibe coding

Posted by jxmorris12 12/18/2025

137 points | 106 commentspage 2

wrs 12/18/2025|

Aaargh, I hate it when useful terms get diffused to meaninglessness. No, there’s one kind of vibe coding. The definition of vibe coding is letting the LLM write the code and not looking at it. That’s what the word “vibe” is there for.

doctoboggan 12/18/2025||

I agree with you that there is one original definition, but I feel like we've lost this one and the current accepted definition of vibe coding is any code is majority or exclusively produced by an LLM.

I think I've seen people use the "vibe engineering" to differentiate whether the human has viewed/comprehended/approved the code, but I am not sure if that's taken off.

platevoltage 12/18/2025|||

I have no idea why an experienced developer who uses LLM's to make them more productive would want to degrade their workflow by calling it "vibe coding".

ares623 12/18/2025||

It’s a chance to become the next Uncle Bob in a new era of software

christophilus 12/19/2025|||

Yeah. I agree the distinction is important, but it’s already been lost. Maybe, we need a new phrase to describe “a product you absolutely cannot trust because I blindly followed a non-deterministic word generator.”

Maybe, “dingus coding”?

pessimizer 12/18/2025|||

> Aaargh, I hate it when useful terms get diffused to meaninglessness.

I think that when you say this, you have an obligation to explain how the term "vibe coding" is useful, and is only useful by the definition that you've become attached to.

I think that the author is accepting that there's no such thing as the vibe coding that you've defined (except for very short and very simple scripts), and that in all other cases of "vibe coding" there will be a back and forth between you and the machine where you decide whether what it has done has satisfied your requirements. Then they arbitrarily distinguish between two levels of doing that: one where you never let the LLM out of the yard, and the other where you let the LLM run around the neighborhood until it gets tired and comes back.

I think that's a useful distinction, and I think that the blog makes a good case for it being a useful distinction. I don't find your comment useful, or the strictness of definition that it demands. It's unrealistic. Nobody is asking an LLM to do something, and shipping whatever it brings back without any follow-up. If nobody is doing that, a term restricted to only that is useless.

wrs 12/19/2025|||

People definitely are doing that. Anyone who is not a programmer and asks the LLM to write a program is doing exactly that. The LLM will do that itself behind the scenes nowadays (yesterday Claude wrote a Python program when I simply asked it to give me the document it wrote in Word format!).

References: This is the original definition ("forget that the code even exists"). [0] Simon Willison wrote a much longer version of my comment. [1] He also suggested the term "vibe engineering" for the case where you are reviewing the LLM output. [2]

[0] https://x.com/karpathy/status/1886192184808149383

[1] https://simonwillison.net/2025/Mar/19/vibe-coding/

[2] https://simonwillison.net/2025/Oct/7/vibe-engineering/

brikym 12/19/2025|||

It needs a short concise name. Vibe-cod-ing is catchy. Ell-Ell-Em-Cod-ing isn't.

francisofascii 12/19/2025|||

At this point I think it is no longer a binary yes/no but rather a nebulous percentage. For example, this codebase was 90% vibe coded, leaving 10% that was edited manually or reviewed.

dbtc 12/18/2025|||

In that case, "blind" would be more accurate.

hackable_sand 12/18/2025|||

I'm ngl, when I first heard "vibe coding" I immediately imagined programming from memory.

parpfish 12/18/2025||

My mind went… elsewhere. Specifically, the gutter.

https://en.wikipedia.org/wiki/Teledildonics

bitwize 12/18/2025|||

Unsurprisingly, the Rust community has you covered there also:

https://github.com/buttplugio/buttplug

https://github.com/Gankra/cargo-mommy (has integration with the former)

hackable_sand 12/19/2025|||

Ooooh very interesting

exe34 12/18/2025||

you're still allowed to alternate between letting it do and consolidating, no?

acedTrex 12/18/2025||

no, vibe coding is explicitly NOT looking at the output.

MisterTea 12/18/2025|||

From my understanding, the vibe part means you go along with the vibe of the LLM meaning you don't question the design choices the LLM makes and you just go with the output it hands you.

Izkata 12/19/2025|||

This is where the term came from: https://x.com/karpathy/status/1886192184808149383?lang=en

exe34 12/19/2025|||

In that case I cannot be accused of vibe-coding!

exe34 12/19/2025|||

okay so I'm not vibe coding, I'm just writing shittier code than before.

gaigalas 12/18/2025||

There's something wrong with this vibe coded stuff, any kind of it.

_It limps faster than you can walk_, in simple terms.

At each model release, it limps faster, but still can't walk. That is not a good sign.

> Do we want this?

No. However, there's a deeper question: do people even recognize they don't want this?

dash2 12/19/2025||

I tried the new vibe-coded Mandelbrot viewer and it didn't seem to work well on Safari. I could only get it to zoom in once, and most of the keys didn't work. Maybe the author hasn't done enough manual testing?

davidbau 12/28/2025|

Right. Just saw this thread. Yesterday asked claude+codex to add a fallback to WebGL support (another 5000 LoC!). So now it works a bit better on Linux, Safari, though the WebGL impl is not as smooth as WebGPU.

cornhole 12/19/2025||

it took me a bit to figure out my aversion to ai usage in programming, but it comes down to the fact that i like building the thing instead of telling the computer to do it in detailed ways. if i wanted to tell people what to do, I would’ve become a manager

satisfice 12/19/2025||

This article is premised on a shallow notion of testing. Because of this, the author lacks a conceptual toolkit to discuss product risk. He speaks of the most important part of the testing process (human thinking and judgment) as if it were “the most boring job in the world” and then later contradicts that by speaking of “testing the tests” as if that were a qualitatively different process (it’s not, it’s exactly the same cognitive process as what he called boring).

The overall effect is to use the word “test” as if it were a magical concept that you plaster onto your work to give it unearned prestige.

What the article demonstrates is that vibe coding is a way to generate orders of magnitude of complexity that no one in the world can understand and no one can take real responsibility for, even in principle.

I call it slop-coding, and I am happy to slop-code throwaway tools. I instruct Claude never to “test” anything I ask it to create, because I need to test it myself in order to apply it responsibly and feel close to it. If I want automated output checking (a waste of time with most tools I create), I can slop-code a framework for that, a la carte.

This way it burns fewer tokens of silly shallow testing.

davidbau 12/28/2025|

Fair. Let me be more precise.

The distinction is between two ways of deploying human thinking. In the first, you are the test oracle: think about every test, repeat every five minutes, or every 30. In the second, you design the evaluation infrastructure: what to measure, what's untested, what hypotheses to prioritize. Both require judgment. But the first scatters your attention; the second concentrates it. I disagree that an LLM cannot be used to write tests, but as with any battery of tests, you cannot trust it blindly. You need to think about how to test the tests.

As for product risk: I do not know what is hiding in 13,000 lines I haven't read; there are certainly bugs to be found. But that is just as true when you manage a big team. The solution has never been to read every line your collaborators write. You need to invest in (technical and human) systems that give you confidence without requiring you to personally verify everything. The question is how to build systems that are good enough.

jackfranklyn 12/19/2025||

The "going in circles" problem several people mention seems like the key thing to watch for. In my experience it tends to happen when the codebase outgrows what the model can hold in context effectively.

What's worked better for me: treating it like onboarding a contractor. Very specific, bounded tasks with clear acceptance criteria. The moment you're spending more time explaining context than it would take to just write the code yourself, that's the signal to switch back.

darkstar_16 12/19/2025|

I do the same. Directed tasks with smaller context and start a new "chat" when it's done what I want.

predkambrij 12/18/2025||

Things about those approaches did and will change more when LLMs are getting better. I got some unbelievable good results back in March, then I was tasking LLMs too hard problems and got bunch of frustrations, then learned to prompt better (to give LLMs methods to test their own work). It's an art to do good balance of spending time writing prompts that will work. A prompt could be "fix all the issues on Github", but maybe it going to fail :)

agumonkey 12/18/2025||

I asked absurd question to chatgpt 4o when it came out, by mixing haskell and lisp books terminology (say design an isomorphic contravariant base class so that every class fills <constraint>). The result was somehow consistent and it suddenly opened my brain to what kind of stupid things i could explore.

Felt like I became a phd wannabe in 5 minutes

alyxya 12/19/2025||

I don’t think the two kinds of vibe coding are entirely separate. There’s a spectrum of how much context you care to understand yourself, and it’s feasible to ask a lot of questions to gain more understanding or let loose and give more discretion to the LLM.

TYPE_FASTER 12/19/2025|

> It is when you use a coding agent to build towers of complexity that go beyond what you have time to understand in any detail.

I think the quality of the product depends on the person (or people) responsible for it understanding the details.

More comments...