You want to solve a family of problems using some tool. You measure the relevant solutions performance metrics.

Now, you or someone else vibe-coded a new tool. You created new solutions and measure again.

You have just quantified the result of using the new tool.

How do you measure them if you don't understand what you're doing? A shitty benchmark or small test suite is not how solid software gets made.

You measure results, you benchmark what you care about. It works often enough to be useful

Good, you achieved a 10% speedup for a particular workload that some users said they care about. But how do you find out that was really the feature that should have been built next? How do you prevent adding badly factored code? How to make sure you don't pile on top of existing tech debt in the codebase, that you are solving the most fundamental issues first?

> some users said they care about

But how could they possibly know what they should care about if they don't understand the code?

> how do you find out that was really the feature that should have been built next?

Phew right they don't know. Only the devs understand what software should do.

I actually explained well enough why this requires to a large degree a competent developer to judge.

I think a sufficiently smart non-competent developer can still do this to great effect, but it definitely helps if someone is both a competent developer, smart, and a seasoned user of LLMs.

Just because AI is not yet a god that is better than all humans at creativity and product decisions and design does not mean it is not a huge accelerant right now.