That would be safety-critical, so you had better not vibe code it.

“using AI tools to write code” is too clunky of a phrase. Unless someone proposes a sticky two/three-syllable verb (that people actually want to use, inb4 some sarcastic person suggests “poop-coding” or something) then people are going to fall back on vibe-coding because it’s quick to say, its definition will become blurred, and we’ll have no one to blame but ourselves.

Might as well have it code in assembler then. Get the performance boost.

Then enjoy your security holes, placeholder fake features, and miles of atrocious 'clever' hacks.

In my experience, it's still possible to learn from the AI's mistakes. I've seen others comment similarly: sometimes the AI will invent a feature, variable, exception type, etc., and while this is wrong for the specific implementation, it's often a pretty good idea for something that may have been overlooked with the initial spec. Reading the AI outputs can still be a valuable step in an interactive feedback process, even if you only ever start a new context from scratch with the AI each time. The user's context is what grows.

> I'll set those up, let the AI go, see if it works.

Hmm. And maintenance?

> see if it works

But this is, properly expressed, "see if it works, based on my incomplete understanding of the code that I haven't worked through and corrected by trying to write it, but I have nevertheless communicated directly to an AI that may not have correctly understood it and therefore may not have even the vaguest inkling of the edge cases I haven't thought to mention yet".

Vibe-coded output could only properly be said to "work" if we were communicating our intentions in formal methods logic.

What you mean is "apparently works".

> just like taking away a hard task from someone less experienced

except someone less experienced never gets to try, since all the experienced programmers are now busy shepherding AI agents around, they aren't available to mentor the next generation.

The problem is that hidden among that complexity/detail is often the value that software developers bring e.g. security issues, regulatory compliance, diagnosability/monitoring, privacy, scalability, resilience etc.

There will be bugs that the AI cannot fix, especially in the short term, which will mean that code needs to be readable and understandable by a human. Without human review that will likely not be the case.

I'm also intrigued by "see if it works". How is this being evaluated? Are you writing a test suite, manually testing?

Don't get me wrong, this approach will likely work in lower risk software, but I think you'd be brave to go no human review in any non-trivial domain.

We professionals need to stop with paroles like "vibe coding is bad". If you don't have dev skills and experience, your code will be shit - no matter if vibe coded or manually done. If you can't guide another dev - here the a.i. - the result will be as good as the clueless leading the clueless.

Fully agree, from the original post: "and forget that the code even exists."

Nah, we need defined levels like for autonomous driving. Level 5 is live deployment of a change where a business need was discovered by AI, the change specified and planned by AI, implemented by AI, and reviewed by AI. Vibe coding (without reading) would be even lower, as a human is in the loop.

IDK.

My wife used the $20 claude.ai and Claude Code (the latter at my prompting) to vibe-code an educational game to help our five-year-old with phonics and basic math.

She noticed that she was constantly hitting token limits and that tweaking or adding new functionality was difficult. She realized that everything was in index.html, and she scrolled through it, and it was clear to her that there was a bunch of duplicated functionality.

So she embarked on a quest to refactor the application, move stuff from code to config, standardize where the code looks for assets, etc. She did all this successfully - she's not hitting token limits anymore and adding new features seems to go more smoothly - without ever knowing a lick of JS.

She's a UX consultant so she has lots of coding-adjacent skills, and talks to developers enough that she understands the code / content division well.

What would you call what she's doing (she still calls it vibe coding)?

Hi Simon, thanks for your comment. I’m the author, just discovering the thread here on HN (and thanks everyone for the enthusiasm!).

I do think we need a new definition for vibe-coding, because the way the term is used today shouldn’t necessarily include “not even reading the code”.

I’m aware that Karpathy’s original post included that idea, but I think we now have two options: - Let the term vibe-coding evolve to cover both those who read the code and those who don’t. - Or define a new term — something that also reflects production-grade coding where you actually read the code. If that’s not vibe-coding, then what is it? (To me, it still feels different from traditional coding.)

Indeed. You can however be a moron and delegate it to another moron.

> This is very dumb. Of course you can.

When it's your problem being delegated, you can't delegate consequences away. I can eat for you, but you won't get satiated this way.

It is a philosophical remark and it is true on that level for sure.

You cannot delegate the act of thinking because the process of delegation is itself a decision you have made in your own mind. The thoughts of your delegates are implicitly yours.

Just like if you include a library in your code, you are implicitly hiring the developers of that library onto your project. Your decision to use the library is hiring the people who wrote it, to implicitly write the code it replaces. (This is something I wish more people understood)

Soon, but not yet. At this point one should at least skim the code, and have a veritable zoo of validation and correction mechanisms in place (tests, LSP, complexity eval, completion eval, bot review, human review etc).

That said, if you spend most of your time sussing out function signatures and micromanaging every little code decision the LLM makes, then that's time wasted imo and something that will become unacceptable before long.

Builders will rejoice, artisan programmers maybe not so much.

> productivity is limited by how much code you can write.

So you measure “productivity” in lines of code? Say no more.

I'm not clear on the point you're making, but I do know that reading/reviewing is often more time-consuming and harder than actually writing code - at least if you're doing it right. Anyhow, I think we all just got too mesmerized with the LLM magic tricks and are slowly realizing that in real software writing we simply got a "slightly better stackoverflow". The claims of hyper-productivity are the same old ones of "I just copy and paste stuff other people wrote", i.e. people are just writing simple PoCs and really bad software - it's mostly bullshiters that couldn't and still can't do fizzbuzz. The real stuff continues to be written same way as before - and this is gonna become more and more apparent as the LLM garbage sneaks in more and more software.

why should we give even tiny bit F about our employer when they are using AI to do interviews?

I am not struggling to believe it at all. Because I am an old guy with a CS degree but decades of web development experience. Apparently this is called being "a legacy developer".

This is the logical conclusion of the indiscipline of undereducated developers who have copied and pasted throughout their career.

This reality is then expressed as "but humans also copy and paste" as if this makes it OK to just hand that task over now to an AI that might do it better, where the solution is to train people to not copy and paste.

Everything about AI is the same story, over and over again: just pump it out. Consequences are what lawyers are for.

It's really interesting to me that within basically a generation we've gone from people sneering at developers with old fashioned, niche development skills and methodologies (fortran, cobol, Ada) to sneering at people with the old-fashioned mindset that knowing what your code is doing is a fundamental facet of the job.

junior developer doesn't delete tests to "make tests pass"

In my experience it is more like a quite skilled developer, but who is dead drunk.