Your Karpathy quote there is out of context. It starts with: https://twitter.com/karpathy/status/1886192184808149383

  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.

Not all AI-assisted programming is vibe coding. If you're paying attention to the code that's being produced you can guide it towards being just as high quality (or even higher quality) than code you would have written by hand.

It's appropriate for the commenter I was replying to, who asked how they can understand things, "while having never even read most of their code."

I like AI-assisted programming, but if I fail to even read the code produced, then I might as well treat it like a no-code system. I can understand the high-levels of how no-code works, but as soon as it breaks, it might as well be a black box. And this only gets worse as the codebase spans into the tens of thousands of lines without me having read any of it.

The (imperfect) analogy I'm working on is a baker who bakes cakes. A nearby grocery store starts making any cake they want, on demand, so the baker decides to quit baking cakes and buy them from the store. The baker calls the store anytime they want a new cake, and just tells them exactly what they want. How long can that baker call themself a "baker"? How long before they forget how to even bake a cake, and all they can do is get cakes from the grocer?

> 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 insane that this quote is coming from one of the leading figures in this field. And everyone's... OK that software development has been reduced to chance and brute force?

There are two ways to approach this. One is a priori: "If you aren't doing the same things with LLMs that humans do when writing code, the code is not going to work".

The other one is a posteriori: "I want code that works, what do I need to do with LLMs?"

Your approach is the former, which I don't think works in reality. You can write code that works (for some definition of "works") with LLMs without doing it the way a human would do it.

I re-read your comment a few times, but don't understand what you're saying unfortunately.

    You can write code that works (for some definition of "works") with LLMs without doing it the way a human would do it.

Really having a hard time understanding what this possibly means.

It means that just because a human can't read the code doesn't mean the code is not correct. Obfuscators exist, for example, and it's conceivable that the LLM writes perfectly correct code even though it's unmaintainable to us.

Thanks, that's a good insight into my value system then. I understand that code doesn't have to be human-readable to be correct. I don't want to work on a codebase filled with unreadable code which no human colleague understands though. This is also why I don't like a lot of web frameworks - the final code outputted to the page is a huge spaghetti of un-inspectable Javascript and HTML.

I want to have the ability to understand each relevant layer of the system, even if I don't necessarily have the full understanding at every given moment.

Also, to add to my point earlier: You don't like frameworks but it's frameworks all the way down to microcode, and that's a massive amount of layers. Javascript isn't an absolute source of truth, you're just picking one layer out of the entire abstraction stack and saying "this is good enough for me".

It's perfectly fine to do that, but also realize that other people might just choose a different layer, and that's fine too if the end result fulfills its purpose.

Sure, but that's more your preference than an objective way to do software "correctly". We're still figuring out what the latter means when LLMs are involved (hence my article here).

the hardware you typed this on was designed by hardware architects that write little to no code. just types up a spec to be implemented by verilog coders.