Proudly zero. I just wrote and posted an article explaining why. The short version: genuine engineering is an abandoned skill I want to revive.

Zero.

But there wasn't this much hate for people who copied random Javascript off whatever site LYCOS linked you to back in the day. Vibe coding for non-critical applications doesn't seem all that different to me.

Zero

Zero. I care about the code I write and value doing things well and building knowledge through deep understanding. Over the years I’ve proven to myself (and others) that approach improves both speed and accuracy, as well as reduce the need for rewrites because experience increases the chance I’ll get it right early on and design in a way that I don’t paint myself into corners.

I’ve noticed that coding with an LLM leads to severely diminished knowledge retention and learning (not to mention it’s less fun), and I suspect overuse would lead to a degree of dependency I don’t wish for myself.

Depends on the task. I use AI for planning/figuring out how to implement stuff. Probably 80% is with AI to bounce ideas off and figure things out.

Writing the code, probably 30% is with AI. Our product requires a lot of context for AI to get stuff right so it's challenging to get it to write good, working code. If it's a small thing that doesn't require a lot of context then I use AI.

I use various tools for this, let me know your needs and I can provide recommendations.

Vibe coding in the traditional sense (coined by Karpathy back in Feb): 20%

Vibe coding using detailed, structured requirements (from tools like Userdoc): 65%

Very little. It's directly forbidden for my day job, and if I'm programming anything in my off hours, it's for my own enjoyment.

All of the code that I've generated by LLM has backed itself into a corner very early on, so I tend to use that as a starting point, then fix and refactor. I've made some toy-sized programs that way (but hours quicker than I would've looking up library documentation on my own).

I've had good luck refining my understanding of some concepts, talking through design of pieces of code, and basically generating snippets of example code on demand. Even in those limited cases, I end up relying on my own experience to determine what's helpful and what's crap. They're usually intertwined.

Partly. Mostly I write it myself, and only ask the LLM when I encounter problems.

I almost never tell it to just write me a thing (what I think of as vibe coding). (2%)

I sometimes write a pretty detailed doc or spec; have the AI draft an implementation; then review and fix it myself. I try to keep this to “reasonable PR” size, a few hundred lines (a module or two) max, and will do a few rounds per hour. (~25%)

I will often stub out modules or classes (sometimes with docstrings) and tab-complete big chunks of them. (And then turn tab completion off and rage-code the rest by hand because the AI is so far off base.) (~25%)

I will often tell the AI to write tests for stubbed methods prior to implementation. I then double check the tests before moving on to manual or AI-assisted implementation. This is usually in increments of a single AI request/response. (~35%)

I will occasionally ask the AI to change existing code and tests, usually in a single request/response. I’ve had very mixed results with this. (~10%)

I have been finding myself writing code in smaller standalone libraries and then assembling those into larger and larger composites so that each library is a size a model can more realistically reason about; and for the layers on top of it the AI wont fill its context up reading all that source instead of just the public API docs.

Zero.

I've now convinced myself current LLM's are much closer to a "stochastic parrot" than an AGI in all areas other than natural language processing. In natural language they are super-human, meaning they can wordsmith better than most humans and are far faster at it than all humans.

That means it you are writing something it's seen a lot of before in it's training data in a language that's somewhat forgiving (so, not C), vibe coding might have 1/2 a chance. I don't do that. But if you're building UI's in javascript using a common framework it might work for you.