- "a low quality solution"

- "a low-quality solution, but you also spend extra time (sometimes - other people's time) on learning to solve the problem yourself"

- "a high-quality solution, but you've spent years on becoming an expert is this domain"

It's good that you brought this up.

Often, learning to solve a class of problems is simply not a priority. Low-quality vide-coded tools are usually means to an end. And the end goals that they achieve are often not even the most important end goals that you have. Digging so deep into the details of those is not worth it. Those are temporary, ad-hoc things.

In the original post, the author references our previous discussion about "Worse Is Better". It's a very relevant topic! Over there, I actually made a very similar point about priorities. "Worse" software is "better" when it's just a component of a system where the other components are more important. You want to spend as much time as possible on those other components, and not on the current component.

A (translated) example that I gave in that thread:

> In the 1970s, K&R were doing OS research. Not PL research. When they needed to port their OS, they hacked a portable low-level language for that task. They didn't go deep into "proper" PL research that would take years. They ported their OS, and then returned straight to OS research and achieved breakthroughs in that area. As intended.

> It's very much possible that writing a general, secure-by-design instrument would take way more time than adding concrete hacks on the application level and producing a result that's just as good (secure or whatever) when you look at the end application.