vibecoding != AI.

For example: I'm a senior dev, I use AI extensively but I fully understand and vet every single line of code I push. No exceptions. Not even in tests.

Whilst I agree with your point, I think what sometimes gets lost in these conversations is that reviewing code thoroughly is harder than writing code.

Personally, and I’m not trying to speak for everyone here, I found it took me just as long to review AI output as it would have taken to write that code myself.

There have been some exceptions to that rule. But those exceptions have generally been in domains I’m unfamiliar with. So we are back to trusting AI as a research assistant, if not a “vibe coding” assistant.

Unfortunately, the people who are "pro-AI" are so often because it lets them skip the understanding part with less scrutiny

> Not even in tests.

This should be "especially in tests". It's more important that they work than the actual code, because their purpose is to catch when the rest of the code breaks.

That is my preferred way to use it also, though I see many folks seemingly pushing for pure vibe coding, apparently striving for maximum throughput as a high-priority goal. Which goal would be hindered by careful review of the output.

It's unclear to me why most software projects would need to grow by tens (or hundreds) of thousands of lines of code each day, but I guess that's a thing?

And I do a lot of top level design when I use it. AIs are terrible at abstraction and functional decomposition.

Aye. AI is also great for learning specifics of poorly documented APIs, e.g. COM-based brainrot from Microsoft.