I don't trust Armin for that, he's too good a developer for vibe coding. The question is whether someone who can't program at all can make something that works well with LLMs, not whether Armin can.

Is that the question? I definitely don't think that's remotely reasonable for someone who can't program. For small things yes, but large things? They're going to get into a spin cycle with the LLM on some edge case it's confused about where they consistently say "the button is blue!" and the bot confirms it is indeed not blue.

It really depends on the area though. Some areas are simple for LLMs, others are quite difficult even if objectively simple.

Granted atm i'm not a big believer in vibe coding in general, but imo it requires quite a bit of knowledge to be hands off and not have it fall into wells of confusion.

That's what I understood from the top-level question, and it's my experience as well. If you don't review the LLM's code, it breaks very quickly. That's why the question for me isn't "how many agents can I run in parallel?", but "how many changes can I review in parallel?".

For me, that's "just one", and that's why LLM coding doesn't scale very far for me with these tools.

if you have to understand the code, it's not vibe coding. Karpathy's whole tweet was about ignoring the code.

if you have to understand the code to progress, it's regular fucking programming.

I don't go gushy about code generation when I use yasnippet or a vim macro, why should super autocomplete be different?

this is an important distinction because if Karpathy's version becomes real we're all out of a job, and I'm sick of hearing developers role play publicly towards leaders that their skills aren't valuable anymore

I disagree, i think there's degrees of governance that these concepts cover. It's all subjective of course. For me though, i've "vibe coded" projects (as testing grounds) with minimal review, but still used my programming experience to shape the general architecture and testing practices to what i thought would best fit the LLM.

The question is how much do you review, and how much does your experience help it? Even if you didn't know code you're still going to review the app. Ideally incrementally or else you won't know what's working and what isn't. Reviewing the technical "decisions" from the LLM is just an incremental step towards reviewing every LOC. There's a large gulf between full reviews and no reviews.

Where in that gulf you decide to call it "vibe coding" is up to you. If you only consider it vibing if you never look at the code though, then most people don't vibe code imo.

I think of "vibe coding" as synonymous with "sloppy/lazy coding". Eg you're skipping details and "trusting" that the LLM is either correct or has enough guardrails to be correct in the impl. How many details you skip though is variable, imo.

> The question is whether someone who can't program at all can make something that works well with LLMs

Is that where the goalposts are now?

No, this is where this discussion is, since the top comment. Please go elsewhere for straw men.

No one mentioned anything about "people who can't program at all" until your comment. Up until then the discussion was about using LLMs for production ready code. It's a given that people working on production systems know how to program.

That is what "auto-edits" (in the first comment) and "vibe coding" (in the second comment) mean.

The bit you're missing is that people who can program also use "auto edits" and "vibe coding" when it fits the problem at hand

As someone who can program and used vibe coding, when they use vibe coding and don't look at the output, how do they ensure errors don't compound?

I'll give you that - you can't vibe code, not look at the output, and push to main of a production codebase. Same as writing code normally.

But you can vibe code and auto-edit your way to a good PR. But you're reviewing the code being output when the agent finishes each task. Maybe that's not pure vibe coding?

The definition of vibe coding is that you aren't looking at the code. That's what's never worked for me.